From dotis@mail-abuse.org Tue May 1 05:51: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 F182A21F84F0 for ; Tue, 1 May 2012 05:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 yA7vEWxv8jOq for ; Tue, 1 May 2012 05:51:33 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id E3CD821E828D for ; Tue, 1 May 2012 05:51:27 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 329E61740283 for ; Tue, 1 May 2012 12:51:23 +0000 (UTC) Message-ID: <4F9FDC4A.6000409@mail-abuse.org> Date: Tue, 01 May 2012 05:51:22 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120424204450.GR55967@mail.yitter.info> <4F9D8038.3040601@dcrocker.net> <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.com> <4515001.OynnCJLaov@scott-latitude-e6320> In-Reply-To: <4515001.OynnCJLaov@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 12:51:34 -0000 On 4/30/12 2:25 PM, Scott Kitterman wrote: > On Monday, April 30, 2012 06:29:40 AM Murray S. Kucherawy wrote: >> I have made the changes stated below in my working copy, but will hold off >> including them in a posted -08 until we're sure there's no objection and >> WGLC has ended (or the chairs direct me otherwise). >>> -----Original Message----- >>> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf >>> Of Dave Crocker Sent: Sunday, April 29, 2012 10:54 AM >>> Cc: spfbis@ietf.org >>> Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >>> >>>> 3.1. DNS Resource Record Types >>> ... >>> >>>> these surveys pulled a large number of domain names >>>> >>>> from recent activity logs >>> The surveys are, presumably, distinguished by which activity logs they >>> were based on. The introduction should state this and should provide >>> some basic description of the operational activities that provided the >>> sources of logging data. A log from a personal email operation is a >>> rather different sampling environment from an email service provider >>> having hundreds of millions of mailboxes... >> In all cases they were based on domains found in actual email traffic, so >> I've tweaked that text to say so explicitly. >>> As I recall, these are activity logs of large receivers. Unless there >>> is a reason to sanitize their names, use them. >> I've added the survey numbers in the case of the DNS surveys to the credits >> at the end, which allows attribution. I could add them parenthetically to >> the "DNS Survey #X" tags as well if you like. >>> Also, what is the difference between an "activity log" and a >>> "nameserver >>> log"? The text uses both terms without explanation. (I'm suggesting >>> adding clauses, not sentences, to explain these.) >> Clarified in the text. "activity log" is email traffic data; "nameserver >> log" is a trace of queries received by a nameserver. >>>> 3.2. Implementations >>> It might be worth adding an analytic conclusion suggesting that these >>> data point mean that there are reasonably good software choices for >>> using either mechanism, so that the gating factor probably was >>> operational policy, rather than lack of coding sources. >> Added. >> >>>> 3.3. The SUBMITTER SMTP Extension >>> I suggest starting with a one sentence summary of the function. It >>> isn't explained elsewhere in the doc. >>> >>> Hmmm, probably worth doing a sentence describing PRA, too. >> Added. >> >>>> Fewer than 4.5% of these advertised the >>>> >>>> SUBMITTER extension. >>> This is picky, but the earlier, table format for this kind of data, >>> makes it particularly easy to extract core data from the document. I >>> suggest re-using the format for all data, such as the one here. >> I'll see what I can come up with. There are so few numbers in this case >> that it seems like overkill to create a table, but perhaps I can add a line >> that's more illustrative to make it worthwhile. >>>> Over 97% of the responding MTAs advertising the SUBMITTER SMTP >>>> >>>> extension were different instances of one MTA. >>> My general fear of common problems in casual reading during reviews >>> worries that this sentence might be mis-read to mean that 97% of active >>> MTAs implement the feature, rather than 97% of the 4.5%. >> Fixed. >> >>>> 4. Evidence of Differences >>> It is probably worth adding a sentence at the end of this section that >>> >>> observes something along the lines of: >>> Anecdotally, the differences in conclusions have not been noted >>> >>> as >>> causing significant operational problems by the email-receiving >>> community. >> Added. >> >>>> 5. Analysis >>> ... >>> >>>> 6. Although they may be marginal, there remain obstacles to >>>> >>>> deployment of protocols that use DNS RRTYPEs other than the >>> most >>> >>>> common ones, >>> Drop the opening clause. Opinions about the import of the obstacles >>> vary quite a bit, and it is not necessary to resolve it in this >>> document. >>> >>> The fact is that barriers remain and that they are important enough to >>> mention here. >> Done. > > Since you're doing another update, I'll take another shot at resolving my > objection to the introduction.... > > The current published version starts: > > In April 2006, the IETF published the [SPF] and Sender ID email > authentication protocols, the latter consisting of three documents > ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols > enable one to publish via the Domain Name System a policy declaring > which mail servers were authorized to send email on behalf of a > specific domain name. The two protocols made use of this same policy > statement and some specific (but different) logic to evaluate whether > the email client sending or relaying a message was authorized to do > so. > > Consensus did not clearly support one protocol over the other, and > > there was significant concern that the two would conflict in some > significant operational situations, interfering with message > delivery. The IESG required the publication of all of these > documents as Experimental, and requested that the community observe > deployment and operation of the protocols over a period of two years > from the date of publication in order to determine a reasonable path > forward. > > Reading it again, I'm also not sure any reference to consensus is appropriate > as there were never any IETF attempts at consensus on these two documents. > I'd be happy with the following if you think it's OK: > > In April 2006, the IETF published the [SPF] and Sender ID email > authentication protocols, the latter consisting of three documents > ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols > enable one to publish via the Domain Name System a policy declaring > which mail servers were authorized to send email on behalf of a > specific domain name. There was significant concern that the two would > conflict in some significant operational situations, interfering with message > delivery. > > The IESG required the publication of all of these documents as > Experimental, and requested that the community observe > deployment and operation of the protocols over a period of two years > from the date of publication in order to determine a reasonable path > forward. > > I think that says enough for our purpose and avoids the issue I was concerned > about. Dear Scott, Agreed, misstatement of consensus effort should be corrected. This text does just that well. Regards, Douglas Otis From john@jlc.net Tue May 1 06:36: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 D72C721E80C8 for ; Tue, 1 May 2012 06:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.115 X-Spam-Level: X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=0.484, 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 kATsisYgV-dq for ; Tue, 1 May 2012 06:36:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6262221E809C for ; Tue, 1 May 2012 06:36:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id D9B0C33C22; Tue, 1 May 2012 09:36:39 -0400 (EDT) Date: Tue, 1 May 2012 09:36:39 -0400 From: John Leslie To: Scott Kitterman Message-ID: <20120501133639.GO99904@verdi> References: <20120424204450.GR55967@mail.yitter.info> <4F9D8038.3040601@dcrocker.net> <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.com> <4515001.OynnCJLaov@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4515001.OynnCJLaov@scott-latitude-e6320> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 13:36:41 -0000 I think Scott's Introduction text is good, but I'd raise one nit: Scott Kitterman wrote: > > I'd be happy with the following if you think it's OK: > > In April 2006, the IETF published the [SPF] and Sender ID email > authentication protocols, the latter consisting of three documents > ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols > enable one to publish via the Domain Name System a policy declaring > which mail servers were authorized to send email on behalf of a > specific domain name. There was significant concern that the two would ^^^^^^^^^^^ I'd drop this "significant". > conflict in some significant operational situations, interfering > with message delivery. > > The IESG required the publication of all of these documents as > Experimental, and requested that the community observe > deployment and operation of the protocols over a period of two years > from the date of publication in order to determine a reasonable path > forward. -- John Leslie From spf2@kitterman.com Tue May 1 06:41:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31DB21E8239 for ; Tue, 1 May 2012 06:41:11 -0700 (PDT) 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 4hZP9wOj-fP4 for ; Tue, 1 May 2012 06:41:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC921E809C for ; Tue, 1 May 2012 06:41:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EEC2120E411C; Tue, 1 May 2012 09:41:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335879670; bh=NubLQ2Z+PSGlOZTdxfb8+DiZrdxGy9cUQc+303YY8js=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=KaQeNmI1ywJ+UFtZtCzLSIiRgyEtEoc24RYRB0lhWFXydI+IbyfoExCMKCaqIOJt7 qNt/IYH8zwFpCUojbP0XqtOHii8qVjLifNB6Rl+gK+SHTttyJ22v20fwiU6PGT5iYd LaKft+PRO4kwTfYccgwAWTkfEpJIwiHgZr3PmStY= 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 D5E4220E40B9; Tue, 1 May 2012 09:41:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 01 May 2012 09:41:09 -0400 Message-ID: <3316929.8TLCDKeesb@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-24-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120501133639.GO99904@verdi> References: <20120424204450.GR55967@mail.yitter.info> <4515001.OynnCJLaov@scott-latitude-e6320> <20120501133639.GO99904@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] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 13:41:11 -0000 On Tuesday, May 01, 2012 09:36:39 AM John Leslie wrote: > I think Scott's Introduction text is good, but I'd raise one nit: > > Scott Kitterman wrote: > > I'd be happy with the following if you think it's OK: > > In April 2006, the IETF published the [SPF] and Sender ID email > > authentication protocols, the latter consisting of three documents > > ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols > > enable one to publish via the Domain Name System a policy declaring > > which mail servers were authorized to send email on behalf of a > > specific domain name. There was significant concern that the two > > would > > ^^^^^^^^^^^ > I'd drop this "significant". > > > conflict in some significant operational situations, interfering > > with message delivery. > > > > The IESG required the publication of all of these documents as > > Experimental, and requested that the community observe > > deployment and operation of the protocols over a period of two years > > from the date of publication in order to determine a reasonable path > > forward. I'm OK with it either way. That's carried forward from the current text. At the time, I think the concern was significant (else they'd have just approved them both), but if people prefer that dropped, I think it's fine. Scott K From msk@cloudmark.com Tue May 1 06:46: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 2B75421E828B for ; Tue, 1 May 2012 06:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YWvcgO-kDhY for ; Tue, 1 May 2012 06:46:14 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9683621E8281 for ; Tue, 1 May 2012 06:46:14 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 4dls1j0030as01C01dlsJ2; Tue, 01 May 2012 06:45:52 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=T7IOvo2Q c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MY9gt07EUMIXn2KaM3YA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 1 May 2012 06:45:52 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNIlseXt7nF5KnvEq9U7F2f34qNJaykr8AgABbSVCAAXILAIABD26AgAABQoD//4tsAA== Date: Tue, 1 May 2012 13:45:52 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928107DD9@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <4515001.OynnCJLaov@scott-latitude-e6320> <20120501133639.GO99904@verdi> <3316929.8TLCDKeesb@scott-latitude-e6320> In-Reply-To: <3316929.8TLCDKeesb@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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335879952; bh=XV4rt6qjB3wCqgfeZ+uSdN6uqM18zILQa/z3lMpM5+E=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Mwlqpkkq1EPh6oO4orD6o3IqWaK8JcI1AiFvbFzyzoicvMPskOI+3/wt9yYJSmxgH 6gmNAZz6ezXlL1EmGWga8j8eH+zLsk8q+GEhpIrCTdQ4GFK3PrXAUZf4P3y9oT5Ts8 c9j/4aZPKVZyXRSlPlLoeT+4hdhxpIBA2Ly09cdA= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 13:46:15 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, May 01, 2012 6:41 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment > =20 > I'm OK with it either way. That's carried forward from the current > text. At the time, I think the concern was significant (else they'd > have just approved them both), but if people prefer that dropped, I > think it's fine. I think it's semantically correct to include it, but use of the same word t= wice in the same sentence close together is just weak writing. So I'm fine= either taking it out or replacing it with "substantial" or something. -MSK From barryleiba.mailing.lists@gmail.com Tue May 1 08:20: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 802D921F8ABA for ; Tue, 1 May 2012 08:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 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 2p6MwSuHW0jz for ; Tue, 1 May 2012 08:20:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B63B021F8AB5 for ; Tue, 1 May 2012 08:20:32 -0700 (PDT) Received: by lagj5 with SMTP id j5so2856706lag.31 for ; Tue, 01 May 2012 08:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ViGEgjFIOqgA6EkxzSVOQoIjGOaoiRg+5lGU/frNZt4=; b=s84qMZvcaQ6C0S2ufMEhZtw0rmgFgPsd3h1s64OYlhuMtuyIxcm6slG8/AYMtIlA+u Zso3HfQ36f9SXyG7/h9WblBUyfUoPI9v6k+6V/DoE2hcVSpL/jwK3rx5ORO+ssLlzkHN PQpLmaRRdfF8c+QdOdre4UsDWTseC8v0NWqHK0c2zVZrtSHqlC7UkJelc7TgJAT4UFOs 0PL0zmkXPqRsVJyi4f90EVHoHbYNfabQO6P3sSpZDMvGXvTpcEsFGc8fG46paIZH8LXQ QQX0R62zUvVWEw+Q8mW+4wZOs+2eIMcOYK7spF/m4yZi+sTgqs1KaezL+jOTtnaLWNfR kMaA== MIME-Version: 1.0 Received: by 10.152.105.19 with SMTP id gi19mr23822165lab.11.1335885631772; Tue, 01 May 2012 08:20:31 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Tue, 1 May 2012 08:20:31 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E003928107DD9@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <4515001.OynnCJLaov@scott-latitude-e6320> <20120501133639.GO99904@verdi> <3316929.8TLCDKeesb@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928107DD9@exch-mbx901.corp.cloudmark.com> Date: Tue, 1 May 2012 11:20:31 -0400 X-Google-Sender-Auth: MUdbRWotKn3eSeLMU_43WVzZFZM Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 15:20:33 -0000 >> I'm OK with it either way. =A0That's carried forward from the current >> text. =A0At the time, I think the concern was significant (else they'd >> have just approved them both), but if people prefer that dropped, I >> think it's fine. > > I think it's semantically correct to include it, but use of the same word= twice > in the same sentence close together is just weak writing. =A0So I'm fine = either > taking it out or replacing it with "substantial" or something. I like the diffs, and I'm happy with Scott's proposed change (with or without the "significant" or "substantial" word). Barry From dhc@dcrocker.net Tue May 1 08:28: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 7B13E21F8C54 for ; Tue, 1 May 2012 08:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.668, 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 qxqqkr+Qm0TO for ; Tue, 1 May 2012 08:28:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E074821F8C52 for ; Tue, 1 May 2012 08:28:23 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q41FSEjS009281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 May 2012 08:28:14 -0700 Message-ID: <4FA0010C.80900@dcrocker.net> Date: Tue, 01 May 2012 08:28:12 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba References: <20120424204450.GR55967@mail.yitter.info> <4515001.OynnCJLaov@scott-latitude-e6320> <20120501133639.GO99904@verdi> <3316929.8TLCDKeesb@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928107DD9@exch-mbx901.corp.cloudmark.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]); Tue, 01 May 2012 08:28:14 -0700 (PDT) Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 15:28:24 -0000 On 5/1/2012 8:20 AM, Barry Leiba wrote: > I like the diffs, and I'm happy with Scott's proposed change (with or > without the "significant" or "substantial" word). +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Tue May 1 08:31: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 2C56021E8085 for ; Tue, 1 May 2012 08:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SSdCKVAPsS0 for ; Tue, 1 May 2012 08:31:02 -0700 (PDT) Received: from groups.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9A121E8049 for ; Tue, 1 May 2012 08:31:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1214; t=1335886259; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Sw+r+B+RPgQeKoSxulHXMcZNBIw=; b=wYyi74Xigjbfe4IkgDxn LH+/Vkn0dmZzVLXJzbn9hIZq/YVbRatkolWl12SWYVpm1zrio0YW84lr79FMllCm 30IyhJZtnQ17JYWWMIB0zwgAxkn3HT2qP33omOqp2kk5dSacBKeyg2sU07kW+EfJ lSCFCmtCtMtzFTNcYNVAsZc= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 01 May 2012 11:30:59 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 498101043.42666.2920; Tue, 01 May 2012 11:30:57 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1214; t=1335885904; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=oLhHYYv qu4qPCdYS4j5QSD5xK4LVFlMa1j7L5MFCATI=; b=sJa6gguif9UoYoZ+w4zBqAk ST3Wkxmi8f+TCj1o1vFoKU4IE/veKzCpzF1ByyYc2mIj1Fk6kcI2JYWOtw763FM1 p4o8MTMbIpoXduV3tT8h9u8whUBMpMyji+zxbCOMjYEIdCCb/yfpyLelDGaejBP7 rsFTIb+DrNJ1DeN8w7Qs= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 01 May 2012 11:25:04 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1096992456.4228.2716; Tue, 01 May 2012 11:25:03 -0400 Message-ID: <4FA001BC.2050007@isdg.net> Date: Tue, 01 May 2012 11:31:08 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Leslie References: <20120424204450.GR55967@mail.yitter.info> <4F9D8038.3040601@dcrocker.net> <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.com> <4515001.OynnCJLaov@scott-latitude-e6320> <20120501133639.GO99904@verdi> In-Reply-To: <20120501133639.GO99904@verdi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 15:31:03 -0000 John Leslie wrote: > I think Scott's Introduction text is good, but I'd raise one nit: > > Scott Kitterman wrote: >> I'd be happy with the following if you think it's OK: >> >> In April 2006, the IETF published the [SPF] and Sender ID email >> authentication protocols, the latter consisting of three documents >> ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols >> enable one to publish via the Domain Name System a policy declaring >> which mail servers were authorized to send email on behalf of a >> specific domain name. There was significant concern that the two would > ^^^^^^^^^^^ > I'd drop this "significant". > >> conflict in some significant operational situations, interfering >> with message delivery. +1 on dropping or change it to below: IMO, it is was significant (or substantial) then why was it immediately addressed then or in fact, just not dropped? There was no "significant concern" from the stand point of # of people, however, I suggest: There were concerns ..... and that would be good enough and more accurate in either direction. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From sm@elandsys.com Thu May 3 02:46: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 B1EC921F8595 for ; Thu, 3 May 2012 02:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivhm1i0xuhEL for ; Thu, 3 May 2012 02:46:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE62C21F857D for ; Thu, 3 May 2012 02:46:46 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.232]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q439kWbF024011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 May 2012 02:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336038405; i=@elandsys.com; bh=vc9i6l9DJatPIobisSyqQ+NcBvdj993GU7U6DapT0eo=; h=Date:To:From:Subject:Cc; b=H3M36A5gRiWSpAca5g+sEJNgo57FkQZTMe4u8Yq3d0IlfndNzz/RbRawnKcNlJ+fa uT0VX9llkW/WG4K7aL++kNN68HxzcspBmZDJcdxkCnFYx0x1M01eeRLdDWmfP6r6yk AWRQF0WNpHQMKG+eCgrzll6/lxr0A+9kIhCO+Kvc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1336038405; i=@elandsys.com; bh=vc9i6l9DJatPIobisSyqQ+NcBvdj993GU7U6DapT0eo=; h=Date:To:From:Subject:Cc; b=3LD5TcQ+6r24zw3TExn8bNzflMVEpqAoGwDHpjcilvD/K1okM3bq1R0Qh9EQHX4gD vKQ17pKxEs0drk0Rjfo2VY+IVNXVJxPBeJ1bgqqEbCYIKXnB5SWJQYpOGT/7RM/tU5 ET6wvnl41cN4SQzDGETS9Do7deD4QKYFw2wvvt6Y= Message-Id: <6.2.5.6.2.20120503015605.0ad32c38@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 May 2012 02:45:12 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Status: draft-ietf-spfbis-experiment-07 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 May 2012 09:46:47 -0000 This is a rough summary of the comments received for the WGLC of draft-ietf-spfbis-experiment-07. As usual, if your comments have been misinterpreted, please post a note on this thread. Please do not use this thread for WGLC comments. The last call closes on 2012-05-09 at 00:00 UTC. On April 24, Scott Kitterman posted a message about the "policy statement and some specific (but different) logic" being factually incorrect [1]. Although the message was posted before the WGLC, I'll mention it. Barry Leiba is happy with -07 [2]. In a message posted on April 25, Dotzero agreed with Scott on the record re-use issue and mentioned that leaving this unaddressed is problematic [3]. Douglas Otis [4] and John Levine [5] also agreed with Scott's concern. John Levine mentioned that "although the data suggest that reused records had only a minor effect in practice, we did not resolve the issue, and so long as people continue to use both SPF and Sender-ID, there remains some risk that systems that intend to publish SPF will inavertently have their mail filtered by Sender-ID" [6]. Hector Santos does not think that there is a conflict [7]. Murray S. Kucherawy does not think "the SIDF re-use of SPF records is an important thing to call out in the experiment document because its contribution to the stats is hypothetical" [8] and Hector Santos agreed with him [9]. On April 26, Paul Midgen stated that he does not "see the point in trying to record some kind of historical note about the intentions of folks publishing SPF1 records with respect to how SenderID verifiers would use those records. Outside of hypothetical discussions, it has proven immaterial in practice" [10]. He mentioned in a further message that he agrees with -07. Alessandro Vesely suggested having a survey about SPF deployment [11]. Philip Gladstone posted a clarification about the date he provided [12]. Douglas Otis agreed with the text suggested by Scott Kitterman to correct a "misstatement of the consensus effort" [13]. John Leslie also agreed and mentioned a nit [14]. On April 29, Dave Crocker posted a review [15]. The document editor that he made the changes which were suggested in his working copy [16]. There was also an exchange between Barry Leiba and Dave Crocker about normative references. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg01434.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg01454.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01457.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg01458.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg01460.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg01464.html 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg01465.html 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg01471.html 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg01472.html 10. http://www.ietf.org/mail-archive/web/spfbis/current/msg01483.html 11. http://www.ietf.org/mail-archive/web/spfbis/current/msg01484.html 12. http://www.ietf.org/mail-archive/web/spfbis/current/msg01495.html 13. http://www.ietf.org/mail-archive/web/spfbis/current/msg01498.html 14. http://www.ietf.org/mail-archive/web/spfbis/current/msg01499.html 15. http://www.ietf.org/mail-archive/web/spfbis/current/msg01492.html 16. http://www.ietf.org/mail-archive/web/spfbis/current/msg01493.html From msk@cloudmark.com Thu May 3 16:02: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 EDE4711E8079 for ; Thu, 3 May 2012 16:02:17 -0700 (PDT) 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 sXmzXGQGvrWI for ; Thu, 3 May 2012 16:02:13 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id D213611E8080 for ; Thu, 3 May 2012 16:02:13 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 5b2U1j0010ZaKgw01b2Uhe; Thu, 03 May 2012 16:02:28 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=g9KGZx59HMgA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=jkrSUcw1kdZGkBrWNUYA:9 a=CjuIK1q_8ugA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 3 May 2012 16:02:02 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Status: draft-ietf-spfbis-experiment-07 Thread-Index: AQHNKRGpxSAQKXxgNEi9nOyRxn9x+5a4ryMw Date: Thu, 3 May 2012 23:02:02 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810C162@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120503015605.0ad32c38@elandnews.com> In-Reply-To: <6.2.5.6.2.20120503015605.0ad32c38@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336086148; bh=HljCJcvu/Ab5U5tyDotG5vN7AnlEJzwKYkh84Vl0qMs=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=N3Bw/fm+ZXzAjmLEJDHH39WvjX+S/vD4SMKSMOmbzJ4OKNt0kWdJPGRIYpgbqU22n Vx7jkofPYNMuqYBPdtPanYc7pKQ2yTl+SThyarJRennksnorbdZFA4eKQSzB9tUJmt 1vHI/gJHlqYJqI2buw775JELuaZCKC1x1aPccD+g= Subject: Re: [spfbis] Status: draft-ietf-spfbis-experiment-07 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 May 2012 23:02:18 -0000 One correction that will appear in the -08 version: All of the percentages = in tables that read "<0.1%" are actually supposed to be "<1.0%". Thanks to= Philip Gladstone for spotting the error. -MSK From vesely@tana.it Mon May 7 10: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 B95ED21F8604 for ; Mon, 7 May 2012 10:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.639 X-Spam-Level: X-Spam-Status: No, score=-4.639 tagged_above=-999 required=5 tests=[AWL=0.080, 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 EdYpEdWrkB9O for ; Mon, 7 May 2012 10:45:47 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1474C21F85EA for ; Mon, 7 May 2012 10:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1336412743; bh=NGty51tns9Kr5vClVBsQwla0/aakMpWGHVQ8LX6reEQ=; l=3047; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=JuiVL9X1vq/JkYrGAjR4quFY35UJ/yBdYpesiG9kUpQsZDJBGqSvuGach360tYehA W5ZkFvPkQZ/0USb6QI95gveAVVYkJWI4JmxkcMJ9Xd0Ak2xKuJOtUOXvZSK0DsrH82 rdfjK2ceOQWvkHJIkyahPIkhiyB0SWxjC62JYr84= 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, 07 May 2012 19:45:43 +0200 id 00000000005DC048.000000004FA80A47.00001B46 Message-ID: <4FA80A46.5090808@tana.it> Date: Mon, 07 May 2012 19:45:42 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120424204450.GR55967@mail.yitter.info> In-Reply-To: <20120424204450.GR55967@mail.yitter.info> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Ned Freed Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 17:45:49 -0000 On Mon 07/May/2012 10:14:36 +0200 Andrew Sullivan wrote: > > Please perform a complete review of the document and send your remarks > to the mailing list. Although I agree with the text composed thus far, I think the Resolution of The SPF and Sender ID Experiments lacks some consideration of the interoperability issues that SPF causes. Such issues are relevant to the resolution of the experiment inasmuch as they are part of the reasons why SPF and Sender ID were given Experimental status. I propose the following additions/changes: Section 3.2 *Implementations* First part of the introductory paragraph moved to the new subsection: OLD It is likely impossible to determine from a survey which Mail Transfer Agents (MTAs) have SPF and/or Sender ID checking enabled at message ingress since it does not appear, for example, in the reply to the EHLO command from extended [SMTP]. We therefore rely on evidence found via web searches, and observed the following: NEW We collected evidence of existing implementations of the core functionality via web searches, and observed the following: New subsection of Section 3 *Detectable Checks* An active survey cannot determine which Mail Transfer Agents (MTAs) have SPF and/or Sender ID checking enabled at message ingress since it does not appear, for example, in the reply to the EHLO command from extended [SMTP]. Nevertheless, the option to reject a sender at the early stages of an SMTP transaction is provided for by [RFC4408]. Our test program was able to start an SMTP session in about 80% of cases. After EHLO, it issued a MAIL command with an SPF-invalid parameter such as --a domain publishing a TXT RR with "v=spf1 -all". In 78% of cases MAIL was accepted. In about 1.2% of the sample cases, the domain's MX server rejected the SPF-invalid parameter but accepted both an RSET and a subsequent MAIL command with an SPF-valid sender. While the ability to start a session only characterizes the sample (random parts of DNS Survey# 2) and possibly the testing host, that small percentage of rejections seems to be stable under variations of the sample and the helo identity. On answering a questionnaire submitted to 70 mail admins, 14 of them (29%) said SPF can cause rejection on their systems. However, rejection does not have to occur at the MAIL command, and SPF results may just contribute to message score. Section 5. *Analysis* The added subsection can be condensed in an additional point[*]: N. SPF can be deployed with relative ease, and causes no interoperability problems except those that can be solved using some sort of sender rewriting scheme. [*] See Ned's answers (2) and (3) to his own questions in http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf-smtp&i=01OF6HRP963S0006TF%40mauve.mrochek.com I don't attempt to add to the Conclusions, but alluding to a recharter for SPF deployment --Ned's "mitigation strategies"-- might be in order. From msk@cloudmark.com Mon May 7 11:10: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 67E8121F8667 for ; Mon, 7 May 2012 11:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22puT1wo+vk4 for ; Mon, 7 May 2012 11:10:19 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3120521F865E for ; Mon, 7 May 2012 11:10:19 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 76Am1j0010as01C016AmDC; Mon, 07 May 2012 11:10:46 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=_y1Qy5JH2LwA:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=dqLhg3ObAAAA:8 a=mdCbtzrclyrZBqT_FLQA:9 a=sUpRBRi90XcHx3SEmiIA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=y3ZDLB1yaQwA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Mon, 7 May 2012 11:10:18 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNIlseXt7nF5KnvEq9U7F2f34qNJa/IxQA//+L02A= Date: Mon, 7 May 2012 18:10:17 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> In-Reply-To: <4FA80A46.5090808@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336414246; bh=AoNGJ0UjMFsLS61sUbZMOQL38OAhCa64KshHfCjG1Hc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EmUyGrg9fNj6QBB4fh3fJ9XDlNHZ2hf8z3DeOMNw5iF1T2wrEOi5Q+145YvZgzlj5 MPZUENoii5FG6OohynS5A+JLyXt8Oy8lUPT/DsHKzBd/1KEGeWQ7q8lLlqYBKsMH7s r5zGhArMjlevwRxkTduL0DNu5mD10BFaK32u4yNs= Cc: Ned Freed Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:10:20 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Monday, May 07, 2012 10:46 AM > To: spfbis@ietf.org > Cc: Ned Freed > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > Although I agree with the text composed thus far, I think the > Resolution of The SPF and Sender ID Experiments lacks some > consideration of the interoperability issues that SPF causes. Such > issues are relevant to the resolution of the experiment inasmuch as > they are part of the reasons why SPF and Sender ID were given > Experimental status. > [...] I don't believe we're chartered to re-evaluate why SPF and Sender ID were g= iven Experimental status. The answer to that question for those that wonde= r is in the IESG Note added to RFC4405-4408. > An active survey cannot determine which Mail Transfer Agents (MTAs) > have SPF and/or Sender ID checking enabled at message ingress since > it does not appear, for example, in the reply to the EHLO command > from extended [SMTP]. Nevertheless, the option to reject a sender > at the early stages of an SMTP transaction is provided for by > [RFC4408]. >=20 > Our test program was able to start an SMTP session in about 80% of > cases. After EHLO, it issued a MAIL command with an SPF-invalid > parameter such as --a domain publishing a TXT > RR with "v=3Dspf1 -all". In 78% of cases MAIL was accepted. In > about 1.2% of the sample cases, the domain's MX server rejected the > SPF-invalid parameter but accepted both an RSET and a subsequent > MAIL command with an SPF-valid sender. This sample shows that in 22% of your tests, the MTA rejected the envelope = sender. How do you know for certain that SPF is the reason? And for the 7= 8% that accepted it, it's not possible to tell whether SPF (or Sender ID) i= s in use. As for the additional conclusion, that's an interesting conclusion if it's = also the case that we can say something comparative about Sender ID. Do yo= u have something like that to include? But more importantly, how does this help us resolve the experiment question= ? The question we're answering is "Which has seen wider use?", and we're s= pecifically avoiding speculation about why. -MSK From spf2@kitterman.com Mon May 7 11:50: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 76BDD21F85E5 for ; Mon, 7 May 2012 11:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k306kfq0nEQN for ; Mon, 7 May 2012 11:50:07 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id D4A9221F8534 for ; Mon, 7 May 2012 11:50:06 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 34846D0408B; Mon, 7 May 2012 13:50:06 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1336416606; bh=x0ACf63bEXwLfaNth9hZuGoZY/rdjqBiV3iBT3ozvO8=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=VLX7OTBqDyjHa/mP4eXl00H78Ym4Rc0cwBwYjKGEG594X8hmrGpvCGaIWayErEMJR UjatuJbdcqTMuhRI/vCsbv4mKU2W/bKbFC5u3JYU9hiGD/Tg458eTAfthU9rkXmScE zeZT47hlKkfB5yNarfsH9CYb92Yp/OnNiHRYmREQ= Received: from 122.sub-97-210-248.myvzw.com (122.sub-97-210-248.myvzw.com [97.210.248.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8D0ACD04088; Mon, 7 May 2012 13:50:05 -0500 (CDT) References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> User-Agent: K-9 Mail for Android In-Reply-To: <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 07 May 2012 13:48:24 -0500 To: "spfbis@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:50:09 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On >Behalf Of Alessandro Vesely >> Sent: Monday, May 07, 2012 10:46 AM >> To: spfbis@ietf.org >> Cc: Ned Freed >> Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >> >> Although I agree with the text composed thus far, I think the >> Resolution of The SPF and Sender ID Experiments lacks some >> consideration of the interoperability issues that SPF causes. Such >> issues are relevant to the resolution of the experiment inasmuch as >> they are part of the reasons why SPF and Sender ID were given >> Experimental status. >> [...] > >I don't believe we're chartered to re-evaluate why SPF and Sender ID >were given Experimental status. The answer to that question for those >that wonder is in the IESG Note added to RFC4405-4408. > >> An active survey cannot determine which Mail Transfer Agents (MTAs) >> have SPF and/or Sender ID checking enabled at message ingress since >> it does not appear, for example, in the reply to the EHLO command >> from extended [SMTP]. Nevertheless, the option to reject a sender >> at the early stages of an SMTP transaction is provided for by >> [RFC4408]. >> >> Our test program was able to start an SMTP session in about 80% of >> cases. After EHLO, it issued a MAIL command with an SPF-invalid >> parameter such as --a domain publishing a TXT >> RR with "v=spf1 -all". In 78% of cases MAIL was accepted. In >> about 1.2% of the sample cases, the domain's MX server rejected the >> SPF-invalid parameter but accepted both an RSET and a subsequent >> MAIL command with an SPF-valid sender. > >This sample shows that in 22% of your tests, the MTA rejected the >envelope sender. How do you know for certain that SPF is the reason? >And for the 78% that accepted it, it's not possible to tell whether SPF >(or Sender ID) is in use. > >As for the additional conclusion, that's an interesting conclusion if >it's also the case that we can say something comparative about Sender >ID. Do you have something like that to include? > >But more importantly, how does this help us resolve the experiment >question? The question we're answering is "Which has seen wider use?", >and we're specifically avoiding speculation about why. FWIW, Postfix, by default, defers all such processing to the recpt to stage when checking SPF (and other things) via its policy interface. I don't know what fraction of the queried MTAs were Postfix, but that's an example of why we can't draw too much from these numbers. Scott K From vesely@tana.it Mon May 7 12:04: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 A6E0D21F8543 for ; Mon, 7 May 2012 12:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[AWL=0.078, 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 4UfESwd-tmld for ; Mon, 7 May 2012 12:04:49 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C273121F844C for ; Mon, 7 May 2012 12:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1336417487; bh=N/zbEZdv2XmA5alMUgH4ZabWmtt3XGM04NzCNje3uG4=; l=1449; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=PYXSEs4MzAor3tVZKeVTms0553YB1pKYHvmixhOytDMZLXtmf68RWQ1FJs6UqYFdL 4e5VeoCcJNxnQZRM3MdUhHAK/avYY2tcOYIb5XA8NNg3udwq3Q1vS2Ehw+vm++gvop GzmMdtsJECaQs/lTHYPSDoPdqucC2/ejK2AykCn4= 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, 07 May 2012 21:04:47 +0200 id 00000000005DC033.000000004FA81CCF.00002D0E Message-ID: <4FA81CCF.1060902@tana.it> Date: Mon, 07 May 2012 21:04:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , Ned Freed Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 19:04:49 -0000 On Mon 07/May/2012 20:44:16 +0200 Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> Our test program was able to start an SMTP session in about 80% of >> cases. After EHLO, it issued a MAIL command with an SPF-invalid >> parameter such as --a domain publishing a TXT >> RR with "v=spf1 -all". In 78% of cases MAIL was accepted. In >> about 1.2% of the sample cases, the domain's MX server rejected the >> SPF-invalid parameter but accepted both an RSET and a subsequent >> MAIL command with an SPF-valid sender. > > This sample shows that in 22% of your tests, the MTA rejected the > envelope sender. No, 22% includes a 20% of servers that I couldn't start a session with. The feebly detectable trace of SPF deployment is in the remaining 2%. Sorry if I misreported that. > How do you know for certain that SPF is the reason? Some of that 2% didn't take RSET, some rejected the good sender too. About 1.2% seems to be discerning SPF. That percentage varies with the sample (1.6 among #2 domains publishing "-all", 2.5% for the domains from my inbox.) > And for the 78% that accepted it, it's not possible to tell whether > SPF (or Sender ID) is in use. Not without overly intrusive and abusive surveying. And also, it would be more instructive to reason in terms of email addresses rather than domains, but I'm not going to buy a million-address CD for that :-) From msk@cloudmark.com Mon May 7 12:29: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 6104F21F8678 for ; Mon, 7 May 2012 12:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Itj+0md6NTAf for ; Mon, 7 May 2012 12:29:39 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id ACA5A21F865F for ; Mon, 7 May 2012 12:29:39 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 77Vw1j0010ZaKgw017Vwjo; Mon, 07 May 2012 12:29:56 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=_y1Qy5JH2LwA:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=fM0LAuDfGyPv2UwUrNoA:9 a=XMbBEza-OKjo4Q8SHikA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Mon, 7 May 2012 12:29:28 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNIlseXt7nF5KnvEq9U7F2f34qNJa/IxQA//+L02CAAIpFgP//kK7g Date: Mon, 7 May 2012 19:29:27 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928118689@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> <4FA81CCF.1060902@tana.it> In-Reply-To: <4FA81CCF.1060902@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336418996; bh=7+u/I6JvCoYuTJU1pIrQXisi/arVSTNMuQ4AIz2DQWs=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=MaKRRL+RT/wgzngIvrfeH9lAREO/44rNmmBDz6sF/Ij9KwadcHQDNyGBp5jDcLev/ 0vQem5qVQiSKuhsBHwKWp+1qMhuGXy4TxXHesqT+kU85Z7kbosIinoTu62SDdnvjlw UH58DP3jCwk7jufgagw5PNEhApYzYQW1l1vwwRXw= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 19:29:40 -0000 > -----Original Message----- > From: Alessandro Vesely [mailto:vesely@tana.it] > Sent: Monday, May 07, 2012 12:05 PM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org; Ned Freed > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > No, 22% includes a 20% of servers that I couldn't start a session with. > The feebly detectable trace of SPF deployment is in the remaining 2%. > Sorry if I misreported that. >=20 > > How do you know for certain that SPF is the reason? >=20 > Some of that 2% didn't take RSET, They violate RFC5321 Section 4.1.1.5. > some rejected the good sender too. > About 1.2% seems to be discerning SPF. 1.2% seems to be applying reject-on-failure for SPF at the MAIL command. S= cott points out there are other implementations, and that's assuming those = rejections are all caused by SPF, which cannot be determined. -MSK From vesely@tana.it Tue May 8 00:54: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 A6C6621F855F for ; Tue, 8 May 2012 00:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfstihctzM0P for ; Tue, 8 May 2012 00:54:59 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA4921F8533 for ; Tue, 8 May 2012 00:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1336463693; bh=vEhXwGKrlnktYpGu/7TOUHHUz8L0H7SsbbjYL5KK9qI=; l=5655; h=Message-ID:Date:From:Mime-Version:To:References:In-Reply-To; b=Oe/1Nc50N033UteWTrF9NBXiIsPCtLOqN6ZmoIK3qcwxB43YuiXMmcerzRkS28Cgt RNyOMTULe0XxkfU8WVJ6Lok8cEjY35rMuXqRBTykGOU0mby2OfAO22XefsLFQ4K71p Lbqo+mpBtNS9jCUh+RNcblboXp9IiDnu9ktx+1oA= 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, 08 May 2012 09:54:53 +0200 id 00000000005DC03F.000000004FA8D14D.00005A42 Message-ID: <4FA8D14D.7050909@tana.it> Date: Tue, 08 May 2012 09:54:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-23106-1336463693-0001-2" To: spfbis@ietf.org References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> <4FA81CCF.1060902@tana.it> <9452079D1A51524AA5749AD23E003928118689@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928118689@exch-mbx901.corp.cloudmark.com> Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 07:54:59 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-23106-1336463693-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Tue 08/May/2012 09:30:27 +0200 Murray S. Kucherawy wrote: >> From: Alessandro Vesely >> About 1.2% seems to be discerning SPF. > > 1.2% seems to be applying reject-on-failure for SPF at the MAIL > command. Scott points out there are other implementations, and > that's assuming those rejections are all caused by SPF, which > cannot be determined. Yup. When you see the attached text it looks clear. The further the SMTP transaction, the fuzzier the SPF contribution. For example, consider a server who accept SPF-invalid senders only if it finds valid DKIM signatures. It would reject after end of data, using a convoluted message. --=_north-23106-1336463693-0001-2 Content-Type: text/plain; charset=windows-1252; name="reject.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="reject.txt" bXlzcWw+IHNlbGVjdCBtYWlsX2NvZGUsIGNvdW50KCopIEFTIGMsIHJlcGx5X21haWwgZnJv bSBzdXJ2ZXkgd2hlcmUgcmVzdWx0PSdSLU9OLUZBSUwnIGdyb3VwIGJ5IG1haWxfY29kZSwg cmVwbHlfbWFpbCBvcmRlciBieSBjIGRlc2MgbGltaXQgMTA7CistLS0tLS0tLS0tLSstLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwp8IG1haWxfY29k ZSB8IGMgIHwgcmVwbHlfbWFpbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKKy0t LS0tLS0tLS0tKy0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rCnwgICAgICAgNTUwIHwgNDggfCA1LjcuMSBTZW5kZXItSWQvU1BGIGNoZWNrIGZhaWxl ZDogbm90IHBlcm1pdHRlZCBpbiAiTUFJTCBGUk9NOjxwb3N0bWFzdGVyQHNwZi1hbGwuY29t PiIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAp8ICAgICAgIDU1MCB8IDQ0IHwgNS43LjEgQ2xpZW50IGhvc3QgcmVqZWN0 ZWQ6IFBsZWFzZSBzZWUgaHR0cDovL3NwZi5wb2JveC5jb20vd2h5Lmh0bWw/c2VuZGVyPXBv c3RtYXN0ZXIlNDBzcGYtYWxsLmNvbSZpcD02Mi45NC4yNDMuMjI2JnJlY2VpdmVyPSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKfCAgICAgICA1NTQgfCAzMiB8IFNlbmRpbmcgYWRkcmVzcyBu b3QgYWNjZXB0ZWQgZHVlIHRvIHNwYW0gZmlsdGVyICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CnwgICAgICAgNTU0IHwgMjUgfCByZWZ1c2VkIG1h aWxmcm9tIGJlY2F1c2Ugb2YgU1BGIHBvbGljeSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAp8ICAgICAgIDUxNyB8IDIyIHwgU1BG IGZhaWwgcG9zdG1hc3RlckBzcGYtYWxsLmNvbTogQWRkcmVzcyBkb2VzIG5vdCBwYXNzIHRo ZSBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKfCAgICAgICA1ODcgfCAx NSB8IHBvc3RtYXN0ZXJAc3BmLWFsbC5jb20gc2VuZGVyIGRvbWFpbiBkb2VzIG5vdCBtYXRj aCBTUEYgcmVjb3JkcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CnwgICAgICAg NTUwIHwgMTQgfCA1LjcuMSA8cG9zdG1hc3RlckBzcGYtYWxsLmNvbT46IFNlbmRlciBhZGRy ZXNzIHJlamVjdGVkOiBQbGVhc2Ugc2VlIGh0dHA6Ly93d3cub3BlbnNwZi5vcmcvV2h5P2lk PXBvc3RtYXN0ZXIlNDBzcGYtYWxsLmNvbSZpcD02Mi45NC4yNDMuMjI2JnJlY2VpdmVyPWVm b3J3YXJkMWMucmVnaXN0cmFyLXNlcnZlcnMuY29tIDogUmVhc29uOiBtZWNoYW5pc20gfAp8 ICAgICAgIDU1MCB8IDExIHwgNS43LjEgPHBvc3RtYXN0ZXJAc3BmLWFsbC5jb20+OiBTZW5k ZXIgYWRkcmVzcyByZWplY3RlZDogUGxlYXNlIHNlZSBodHRwOi8vd3d3Lm9wZW5zcGYub3Jn L1doeT9pZD1wb3N0bWFzdGVyJTQwc3BmLWFsbC5jb20maXA9NjIuOTQuMjQzLjIyNiZyZWNl aXZlcj1lZm9yd2FyZDFhLnJlZ2lzdHJhci1zZXJ2ZXJzLmNvbSA6IFJlYXNvbjogbWVjaGFu aXNtIHwKfCAgICAgICA1NTAgfCAxMCB8IDUuNy4xIFNQRiBNQUlMIEZST00gY2hlY2sgZmFp bGVkOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CnwgICAgICAgNTUwIHwgMTAgfCA1LjcuMSA8cG9zdG1hc3RlckBzcGYt YWxsLmNvbT46IFNlbmRlciBhZGRyZXNzIHJlamVjdGVkOiBQbGVhc2Ugc2VlIGh0dHA6Ly93 d3cub3BlbnNwZi5vcmcvV2h5P2lkPXBvc3RtYXN0ZXIlNDBzcGYtYWxsLmNvbSZpcD02Mi45 NC4yNDMuMjI2JnJlY2VpdmVyPWVmb3J3YXJkMWIucmVnaXN0cmFyLXNlcnZlcnMuY29tIDog UmVhc29uOiBtZWNoYW5pc20gfAorLS0tLS0tLS0tLS0rLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKMTAgcm93cyBpbiBzZXQgKDAuMDIgc2VjKQoK --=_north-23106-1336463693-0001-2-- From msk@cloudmark.com Tue May 8 09:17:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9849021F85F0 for ; Tue, 8 May 2012 09:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMJwuA7sqtyr for ; Tue, 8 May 2012 09:17:42 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id EA5B121F85AA for ; Tue, 8 May 2012 09:17:41 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 7UHJ1j0010as01C01UHJPz; Tue, 08 May 2012 09:17:18 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=R/iB6KtX c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=Q7V8cVKIh0SoYW12cLMA:9 a=pWzVrTCyDAcNJpSXrfQA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 8 May 2012 09:17:18 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNIlseXt7nF5KnvEq9U7F2f34qNJa/IxQA//+L02CAAIpFgP//kK7ggAFGfICAABbj4A== Date: Tue, 8 May 2012 16:17:18 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039281194A5@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> <4FA81CCF.1060902@tana.it> <9452079D1A51524AA5749AD23E003928118689@exch-mbx901.corp.cloudmark.com> <4FA8D14D.7050909@tana.it> In-Reply-To: <4FA8D14D.7050909@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336493838; bh=ev/ch10aWVcvq/mSkZv7tO2E9vTsYzhCaOpOqLxJFpU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bc385JVdGrHS3q0uTY0zrZNxNhaPs0HoKy3+SFAEr6Y9Bb3kH3FeRVRKgJKFTk9SL r3eyafaV32CpmUigxcS8k3I8cNWzSdkulQXEaOfI/h4zUgcGWgJv+Ijxf6zjnMGyP/ fx2gJqMazgv8IXX0aQfHgaHF5vx8jFCnco1pH1iI= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:17:42 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Tuesday, May 08, 2012 12:55 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > Yup. When you see the attached text it looks clear. The further the > SMTP transaction, the fuzzier the SPF contribution. For example, > consider a server who accept SPF-invalid senders only if it finds valid > DKIM signatures. It would reject after end of data, using a convoluted > message. Two of your examples are ambiguous as to whether it was an SPF decision. From SRS0=xZNgE=DM==stuart@gathman.org Tue May 8 09:38: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 9CEE121F8592 for ; Tue, 8 May 2012 09:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=0.6, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdtVuMVFEVLm for ; Tue, 8 May 2012 09:38:15 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id E617911E8080 for ; Tue, 8 May 2012 09:38:14 -0700 (PDT) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=72.209.196.211 (fairfax.gathman.org); auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart; dkim=pass (Good signature.) header.d=bmsi.com header.i=@bmsi.com Authentication-Results: mail.bmsi.com; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bmsi.com; i=@bmsi.com; q=dns/txt; s=default; t=1336495089; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=RbL55bSdpT9BI6ke98oayJL1lj9CZaNT9hkapB+MuHc=; b=UkBWg5oqNTjfFrNR3j1hWXMBJPBSdk6szZa4hj8PAX9iott5A3eMuzxXvj2jILjjfY4XLCTOGkAMYKFFDp60HuBkyiTogk+pvgfTlhpTYjglS4uWneb/Nd5U5/VDKJzeFBTo0XhThKJZ1pNqUrjAMpNzyjd8JfROtUxfceKsPlQ= 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 q48Gc9HG019428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 May 2012 12:38:09 -0400 Message-ID: <4FA94BF1.4060503@gathman.org> Date: Tue, 08 May 2012 12:38:09 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F98A578.6020902@mail-abuse.org> In-Reply-To: <4F98A578.6020902@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] In support of retaining Received-SPF Header Field X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 May 2012 17:00:35 -0000 Long ago, Nostradamus foresaw that on 04/25/2012 09:31 PM, Douglas Otis would write: > It would never be in a users interest to adopt result formats aimed at > disabling third-party competitors by omitting essential information. I think what Douglas is trying to say is that Authentication-Results has less information than Received-SPF, and therefore Received-SPF should be retained. +1 retain Received-SPF I have implemented both headers in production over the past week, and the information in A-R is only a brief summary of the information in Received-SPF. So there is little redundancy in having both in a message. The additional information in Received-SPF is very valuable for the reasons Doug mentioned at length, and also for diagnosing problems. (This is for the existing RFC 5451. I haven't checked the proposed extensions.) We should not deprecate Received-SPF until all its information has been standardized in the A-R header. Here is a live example of both headers: Received-SPF: Pass (mail.bmsi.com: domain of accion.netcommunity1.com designates 205.139.105.170 as permitted sender) client-ip=205.139.105.170; envelope-from="DSN.10310.15484773.7195596@accion.netcommunity1.com"; helo=d2pdcsmmta02v0.blackbaud.com; receiver=mail.bmsi.com; mechanism="ip4:205.139.104.0/22"; identity=mailfrom Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=205.139.105.170 (d2pdcsmmta02v0.blackbaud.com); spf=pass (sender SPF authorized) smtp.helo=d2pdcsmmta02v0.blackbaud.com smtp.mailfrom=DSN.10310.15484773.7195596@accion.netcommunity1.com The missing field in this example is "mechanism" (including iprev method makes up for missing client ip). Additionally, HELO SPF result is often included in Received-SPF (and x-bestguess result as an extension in my case). From vesely@tana.it Wed May 9 04:23: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 1681721F85AE for ; Wed, 9 May 2012 04:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.605 X-Spam-Level: X-Spam-Status: No, score=-4.605 tagged_above=-999 required=5 tests=[AWL=0.114, 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 aozgZSEbJsvb for ; Wed, 9 May 2012 04:23:40 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CB69921F859F for ; Wed, 9 May 2012 04:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1336562614; bh=8VPjRKayUWEwWRciD7ViQR1yRBafW7aoULpJQfhhuBY=; l=1863; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=cHLG6V4+ZDGfLHJcCmLSwNmGfUH4SJsMMgx99kJpYyKTufzH75TEu/9rn417ld/k4 NWbH1icV4DUT28jlh13aKuJhCpZbbx2oOMgPkdnwRGaJaGWQ8wTdCUk0xs5jNVV6g7 bxKasjBAQPqNCuJlLEmNLWeopLBxQQZ1j6zjF0OQ= 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, 09 May 2012 13:23:34 +0200 id 00000000005DC039.000000004FAA53B6.0000634A Message-ID: <4FAA53B6.9000408@tana.it> Date: Wed, 09 May 2012 13:23:34 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> <4FA81CCF.1060902@tana.it> <9452079D1A51524AA5749AD23E003928118689@exch-mbx901.corp.cloudmark.com> <4FA8D14D.7050909@tana.it> <9452079D1A51524AA5749AD23E0039281194A5@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039281194A5@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 11:23:41 -0000 On Wed 09/May/2012 11:42:34 +0200 Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >> Yup. When you see the attached text it looks clear. The further the >> SMTP transaction, the fuzzier the SPF contribution. For example, >> consider a server who accept SPF-invalid senders only if it finds valid >> DKIM signatures. It would reject after end of data, using a convoluted >> message. > > Two of your examples are ambiguous as to whether it was an SPF decision. I guess you mean "554 Sending address not accepted due to spam filter" (well, that's one). I only queried for the top ten, so probably there are more cases that don't mention SPF explicitly. Some ambiguity is intrinsic in this kind of test, and in statistics in general. Actually, I inferred SPF checking by just the first digit of the reply code and how it changed submitting an spf-valid sender. Rather than sweeping all the names, I run two random ~30K-item samples varying the helo identity, obtaining 1.11% after an address literal and 1.21% after a proper helo name. I also run a much smaller sample (~5K names) with the same helo name and got 1.18%. Thence I draw that such result is stable. However, its value depends on the domain names where I extracted the samples from, because on a 558-item sample extracted from my inbox I got 2.77% (address literal) and 2.75% (proper helo name) --no surprise that an inbox is cleaner than activity logs. This test shows that a base of indomitable MTAs who do reject-on-fail exists. At the same time, the test shows that reject-on-fail is so hard to deploy as to be uncommon in practice. Anyone else has an opinion on this? Arguably, reject-on-fail is one of the "serious open issues" mentioned in the IESG Note, since it would seriously affect interoperability if it were widespread. From spf2@kitterman.com Wed May 9 04:28: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 3D6AA21F85C6 for ; Wed, 9 May 2012 04:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUXetj4G-6VR for ; Wed, 9 May 2012 04:28:10 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 81C4D21F85C5 for ; Wed, 9 May 2012 04:28:10 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id E2A0AD0408B; Wed, 9 May 2012 06:28:09 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1336562889; bh=iRZohtbyiZhQaGYu/WW39erOwcRy4LLQ+EWCAlm5YDA=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=jkTD4h3FnaW/KAieheVLi9PicP5AnrFtuG5b0kfF+72oDbGZsxKOWeNh1EAqmk2Oh fapwVscBSB6pskGDpr9rHqY4hQ5y55yzXvaWniGNpyg51TcYDi05QCoc2/PTa/HwAv 9KAZ+NVwgbnfRDe0r/ed9ZKj09QcagGoxzg/c4wE= Received: from 247.sub-97-211-145.myvzw.com (247.sub-97-211-145.myvzw.com [97.211.145.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4FDB7D04088; Wed, 9 May 2012 06:28:09 -0500 (CDT) References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> <4FA81CCF.1060902@tana.it> <9452079D1A51524AA5749AD23E003928118689@exch-mbx901.corp.cloudmark.com> <4FA8D14D.7050909@tana.it> <9452079D1A51524AA5749AD23E0039281194A5@exch-mbx901.corp.cloudmark.com> <4FAA53B6.9000408@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <4FAA53B6.9000408@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 09 May 2012 06:28:03 -0500 To: spfbis@ietf.org Message-ID: <5ce5d98d-e235-4a3d-9d1e-d14324bbce12@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 11:28:11 -0000 Alessandro Vesely wrote: >On Wed 09/May/2012 11:42:34 +0200 Murray S. Kucherawy wrote: >>> From: ietf.org On Behalf Of Alessandro Vesely >>> >>> Yup. When you see the attached text it looks clear. The further >the >>> SMTP transaction, the fuzzier the SPF contribution. For example, >>> consider a server who accept SPF-invalid senders only if it finds >valid >>> DKIM signatures. It would reject after end of data, using a >convoluted >>> message. >> >> Two of your examples are ambiguous as to whether it was an SPF >decision. > >I guess you mean "554 Sending address not accepted due to spam filter" >(well, that's one). I only queried for the top ten, so probably there >are more cases that don't mention SPF explicitly. >Some ambiguity is intrinsic in this kind of test, and in statistics in >general. > >Actually, I inferred SPF checking by just the first digit of the reply >code and how it changed submitting an spf-valid sender. Rather than >sweeping all the names, I run two random ~30K-item samples varying the >helo identity, obtaining 1.11% after an address literal and 1.21% >after a proper helo name. I also run a much smaller sample (~5K >names) with the same helo name and got 1.18%. Thence I draw that such >result is stable. However, its value depends on the domain names >where I extracted the samples from, because on a 558-item sample >extracted from my inbox I got 2.77% (address literal) and 2.75% >(proper helo name) --no surprise that an inbox is cleaner than >activity logs. > >This test shows that a base of indomitable MTAs who do reject-on-fail >exists. At the same time, the test shows that reject-on-fail is so >hard to deploy as to be uncommon in practice. > >Anyone else has an opinion on this? Arguably, reject-on-fail is one >of the "serious open issues" mentioned in the IESG Note, since it >would seriously affect interoperability if it were widespread. Only if done improperly. The architectural concerns only arise if it's not done at the border. Scott K From msk@cloudmark.com Wed May 9 06:32: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 71DFC21F85C9 for ; Wed, 9 May 2012 06:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q47JjxulqJ6H for ; Wed, 9 May 2012 06:32:50 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id CB24D21F85C6 for ; Wed, 9 May 2012 06:32:50 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 7pZ81j0010ZaKgw01pZ8Vn; Wed, 09 May 2012 06:33:08 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=A6i4I0diIpbzHeUZ0z0A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 9 May 2012 06:32:39 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNIlseXt7nF5KnvEq9U7F2f34qNJa/IxQA//+L02CAAIpFgP//kK7ggAFGfICAABbj4IABtcAA//+tRNA= Date: Wed, 9 May 2012 13:32:39 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392811AC42@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> <4FA81CCF.1060902@tana.it> <9452079D1A51524AA5749AD23E003928118689@exch-mbx901.corp.cloudmark.com> <4FA8D14D.7050909@tana.it> <9452079D1A51524AA5749AD23E0039281194A5@exch-mbx901.corp.cloudmark.com> <4FAA53B6.9000408@tana.it> In-Reply-To: <4FAA53B6.9000408@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336570388; bh=stkUZBKtwLK6L7jn9J6h/nWToxW+9pW9INGr84Aul0Y=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=kXgdMve0jgkb0ZG9RLlQCOzs4d3ogD5B9TDQBeszw1nFpctmVI0F5bCyfoiP2W93t 39PX7e7oHl+4FT7jAcPk9nn6+GZvCxwLIZ1XZr7nrUARQRgFdK4K1VpGYeXJh1rr1g CMnvkGsH7Hu5kXi435itRb2n6dykPXGBXd5P78OI= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:32:51 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Wednesday, May 09, 2012 4:24 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > This test shows that a base of indomitable MTAs who do reject-on-fail > exists. At the same time, the test shows that reject-on-fail is so > hard to deploy as to be uncommon in practice. >=20 > Anyone else has an opinion on this? Arguably, reject-on-fail is one of > the "serious open issues" mentioned in the IESG Note, since it would > seriously affect interoperability if it were widespread. Since reject-on-fail was not a mandatory component of RFC4408, as has alrea= dy been pointed out many times, and since a co-chair formally declared on A= pril 20th that this was off-topic, we really need to drop this. At a minim= um, it has nothing to do with the experiment, and is consuming our energy w= hich we'll need for our second deliverable. -MSK From hsantos@isdg.net Wed May 9 06:53: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 2F4EA21F8514 for ; Wed, 9 May 2012 06:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imyGLD9GXi3i for ; Wed, 9 May 2012 06:53:55 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 33D3521F851C for ; Wed, 9 May 2012 06:53:54 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2026; t=1336571624; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=NO6kYFecPPhFBzgXn7ldNU5GLnA=; b=at5/Y5YcJmZ3MJBBLPrn 3Bd5WDDL0NRuxcCfQcPyBqtvUA1W5VDVwUxpvjycqSjwlyXi8ZvzABkBCQJASvQa VdgjDLHQ9WFhXqXajzr5cM7z04om8pdOnhJVj4mWOoV7CuRaLqq13qF+74SbQS7Q uqxkw6M6P8Td5S4hSXaRx/Y= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 09 May 2012 09:53:44 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1183458613.53060.5016; Wed, 09 May 2012 09:53:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2026; t=1336571611; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=c49bUEy njLawO4t8OECY+vdO4nGiHDmsMWzE4MK3SRk=; b=PPoPj5cHqBxudGa/HBKCQyB KbAoWwLllIFDUGC8swAv8piw3rBklV/ZVJLa350fG+2p6gpRGwGXYTOH6O5pCRI6 HW8yHwZz3QZ7GPsrniAd1ckrXM3SU8G3DDK7DavDsH584F+NDWOlCH7uPvLmWVCt hylLoEt1newhnQwBqBZU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 09 May 2012 09:53:31 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1782344128.5835.5984; Wed, 09 May 2012 09:53:30 -0400 Message-ID: <4FAA76CA.8070001@isdg.net> Date: Wed, 09 May 2012 09:53:14 -0400 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: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> <4FA81CCF.1060902@tana.it> <9452079D1A51524AA5749AD23E003928118689@exch-mbx901.corp.cloudmark.com> <4FA8D14D.7050909@tana.it> <9452079D1A51524AA5749AD23E0039281194A5@exch-mbx901.corp.cloudmark.com> <4FAA53B6.9000408@tana.it> <9452079D1A51524AA5749AD23E00392811AC42@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392811AC42@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:53:56 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> Anyone else has an opinion on this? Arguably, reject-on-fail is one of >> the "serious open issues" mentioned in the IESG Note, since it would >> seriously affect interoperability if it were widespread. > > Since reject-on-fail was not a mandatory component of RFC4408, as has already > been pointed out many times, and since a co-chair formally declared on April > 20th that this was off-topic, we really need to drop this. At a minimum, it has > nothing to do with the experiment, and is consuming our energy which we'll > need for our second deliverable. > -1. I disagree with your assessment. It (REJECT-ON-FAIL) is and always was a critical mandatory part of RFC4408 and there should be not ambiguity about long time history of deployment it at all scales and from the purity of a raw protocol, despite the scale level of usage. I believe the co-chair declared that the idea of whether REJECT-ON-FAIL was part of the protocol or not, was off-topic. Not that REJECT-ON-FAIL is not part of the protocol. I believe the miscommunication was related to RFC119 level language. I agree REJECT-ON-FAIL has nothing to do with the experiment because its already part of the protocol considerations and should not be questioned whether its an deployment option or not. However, as issue #29 exemplifies, the local deployment option to choose REJECT-ON-FAIL or MARK-ON-FAIL, is very critical for RFC4409bis from many angles and in particular security related. The clear outline reasoning showing where and why are things that should not be watered down as insignificant. It would incredibly awesome to recognize these points and in the interest of reducing WG noise, not wait for escalation to occur to finally realize REJECT-ON-FAIL is a significant part of the protocol. To not do so, will be wasting energy. -- Hector Santos http://www.santronics.com http://hector.wildcatblog.com jabber: hector@jabber.isdg.net From hsantos@isdg.net Wed May 9 07:14: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 22CD721F8483 for ; Wed, 9 May 2012 07:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iag91A38pApM for ; Wed, 9 May 2012 07:14:46 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2E26B21F847A for ; Wed, 9 May 2012 07:14:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2233; t=1336572878; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ykBbjyNBzO9aUdlgaEHQhPQJkLg=; b=TFKtojI67TTj4jLsoCwy Xcdad18CTFK3+YkFcP12cNL5Bfcu0Y7KWiGQHwlGGfjMsgmkCmjJ1SnuV+v2tJwH StsPbfLijlk+tUFKlaq5pnHJ4aCrUnsy1gtA2+tDIr1HXrxRPZ7bYr8oPV948EZk +ULeZ7Y5toWuCSdE+5UzGmE= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 09 May 2012 10:14:38 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1184713719.53060.2924; Wed, 09 May 2012 10:14:38 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2233; t=1336572869; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Du8m5UO ubGWjCPro3Lx+maRGeFqZ2Okv3Z3AQFb3BDk=; b=elfMBPPpVnJEbC7nDPC2edS /XM5P6FQa+t3038d+95ylShT3edK+QhQoalY2ShrFossSPQwRWEMRJTpYjiOFG5r JwJc0PfdYR2w85beZR0GOU4XBH9e9Ww3uOKe5iM6ppzT6rIS6/vVOzQFI0/CAkix 1bARTMkgNyZ6Ne3OBtY8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 09 May 2012 10:14:29 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1783602081.5841.7220; Wed, 09 May 2012 10:14:28 -0400 Message-ID: <4FAA7BB3.10505@isdg.net> Date: Wed, 09 May 2012 10:14:11 -0400 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: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <9452079D1A51524AA5749AD23E003928118547@exch-mbx901.corp.cloudmark.com> <4FA81CCF.1060902@tana.it> <9452079D1A51524AA5749AD23E003928118689@exch-mbx901.corp.cloudmark.com> <4FA8D14D.7050909@tana.it> <9452079D1A51524AA5749AD23E0039281194A5@exch-mbx901.corp.cloudmark.com> <4FAA53B6.9000408@tana.it> In-Reply-To: <4FAA53B6.9000408@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:14:47 -0000 Alessandro Vesely wrote: > > This test shows that a base of indomitable MTAs who do reject-on-fail > exists. At the same time, the test shows that reject-on-fail is so > hard to deploy as to be uncommon in practice. > > Anyone else has an opinion on this? Arguably, reject-on-fail is one > of the "serious open issues" mentioned in the IESG Note, since it > would seriously affect interoperability if it were widespread. My view is that REJECT-ON-FAIL or MARK-ON-FAIL are mandatory part of the purity of the SPF Protocol as deployment options and there should be no ambiguity about its usage, level of usage and who is using it. The only issue I have is related to protocol consistency when it comes to the local deployment option to use one or the other. In the end, both options SHOULD yield the same result and/or conclusion when the POV of the targeted user otherwise we have a *security loophole*. I have a problem that this is not recognized. I have provided background reasoning and also proposed some text to help close the security loophole potential with insights that local deployments MUST consider when choosing MARK-ON-FAIL over REJECT-ON-FAIL mode of local site operation. To assume REJECT-ON-FAIL is not in play is an major fault in this WG thinking. To assume MARK-ON-FAIL is the only way SPF is deployed is a major fault in this WG thinking. Both at part of the protocol and implementations SHOULD be prepared to offer it to operators, and SPF publishers of -ALL policy SHOULD be aware that any publicly exposed policy desire to reject-on-fail to help protect spoofing of their domains may not always happen. But I suggest that they do expect a negative classification and stream separation for the benefit of the user not to be harm by the receiver passing on -ALL failed messages. We can't control how MARK-ON-FAIL will be done, but RFC4408BIS SHOULD NOT be blind about it either. There is one reference to it and no definition behind it. REJECT-ON-FAIL is very clear. Mail Rejection, User does not get mail. How will the user see a MARK-ON-FAIL message? -- Hector Santos http://www.santronics.com http://hector.wildcatblog.com jabber: hector@jabber.isdg.net From hsantos@isdg.net Wed May 9 08:15: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 468651F0C60 for ; Wed, 9 May 2012 08:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAZ4X4ZVXjE7 for ; Wed, 9 May 2012 08:15:04 -0700 (PDT) Received: from groups.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 087291F0C51 for ; Wed, 9 May 2012 08:15:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2521; t=1336576494; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=X+dQuuN5OPbPspdCO8BkT5Z0ZPo=; b=Ly6BB8DEkfwS/8CxVEdh 29q+3qCUPdpSW/vHgu0weyCNWFOsOu+r3peUyTd7w2ZKNBucbeVXiW8wip7ap2nq OiXkvWz3QVRQY71foNKuVoR4uNvgirOgKeSR0jCWsWKvWCzTtnLe8bQWwaNZBHHN sH91MP8M1x7lJOHTZoPQdgw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 09 May 2012 11:14:54 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1188329011.53060.5004; Wed, 09 May 2012 11:14:53 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2521; t=1336576481; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=P0t02PI +udEddA/suJC1Mm7YK797JvqlWLdKEH2ndbI=; b=T2NsOdBwLwKUWQuZhiS/OG0 N33LKpCdSTiVbKcs+m2O415xPcAIVMPq+XCtiY1a9Oe7m9QCj+06VBfv+T1hdZzM DeBhECNdluMbOJxRCtSk2u4x5pWVUvbp1ypDAj5FJdUQvsd9J92niO+WFR/4SEB1 HvOPaYKoSqmtGBO8nkWA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 09 May 2012 11:14:41 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1787214081.5848.3036; Wed, 09 May 2012 11:14:40 -0400 Message-ID: <4FAA89D0.304@isdg.net> Date: Wed, 09 May 2012 11:14:24 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan , SPFBIS Working Group References: <20120424204450.GR55967@mail.yitter.info> In-Reply-To: <20120424204450.GR55967@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:15:05 -0000 Hi, I think the changes made to address my concerns were adequate and with its stated framework, it should be acceptable. However, I wish to state I believe the framework was in error as the Interop report offers very little in presenting anything new and very little in helping to address issues cataloged to help codify the pending RFC4408BIS work. In other words, the worth of the interop value would had increased if it had help address some of real deployment concerns and/or ambiguity in RFC4408. i.e. REJECT-ON-FAIL vs MARK-ON-FAIL. Instead, the report focused on addressing on what should be done between SenderID and SPF with too much energy spent on promoting the notion SenderID should be abandoned using data that isn't really all unexpected, new or help to show that it should be abandoned. (Note, the one thing gain was the Type 99 issue, where I felt it wasn't used, but the report had changed my mind regarding continuation to explore usage.) In other words, overall, nothing gain by this report. But at the very least, as it was written, it works for me. I don't know what the above means to the IETF consideration regarding WGLC and leave it to you to be the judge. -- Hector Santos http://www.santronics.com http://hector.wildcatblog.com jabber: hector@jabber.isdg.net Andrew Sullivan wrote: > Dear colleagues, > > This message begins a 2 week Working Group Last Call on the document > draft-ietf-spfbis-experiment-07. > > Please perform a complete review of the document and send your remarks > to the mailing list. > > Your chairs would like to be sure that the document really represents > WG consensus in the event we forward the document to the IESG for > publication. As a result, we would like to see as many reviewers as > possible who state that they have read the document and approve its > publication, and in no case fewer than five. In the case of those who > have read and reviewed previous versions of the document, we would > like evidence that you are amenable to changes that have been made in > response to your comments; we will count those among the five. > ("Five" is an arbitrary number intended to be a minimal threshold of > review; if we can't find five people who say something is a good idea > to publish, it's hard to argue that there's any interest at all.) > > SM will be the document shepherd for this document. > > This last call closes on 2012-05-09 at 00:00 UTC. > > Best regards, > > Andrew > From hsantos@isdg.net Wed May 9 20:36: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 3E35911E80EF for ; Wed, 9 May 2012 20:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=0.6, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCCf4Cwp37IZ for ; Wed, 9 May 2012 20:36:14 -0700 (PDT) Received: from ntbbs.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6357F11E80E4 for ; Wed, 9 May 2012 20:36:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1929; t=1336620965; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VrjZmFrRsqqKECrTPWaz0GCfkFY=; b=QkOendgq7D23H1JE9PxK cXwNEXm/TQ5oSC0NetS4ZkZz7cVLRz/DqqNPatilraAdou6SFtiHU5xOJfpz80hv 6pY7Y6ZiNlI6/SET6BmQMQawBhkPHzCiGp2YcvRyctOOttZ6Cs6ojckLylzAcRYX 6281tE/DsJ1h9SHnH4hsruY= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 09 May 2012 23:36:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1232799451.53060.1192; Wed, 09 May 2012 23:36:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1929; t=1336620953; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uDUidLo GLLHOt7Y0vXZUSax7gHnaT6un+/ULvhffBaw=; b=iJ5fKdwWxtmCjjwHb5DYfWT hcyiBFa1dBDinsp3eKBmsDPA+QMtLUR2u2xNFP7AJsuu2PhZ8h26BPKyMBVzPqZa UrTAlXJU4AAWO2UaGYUu7OP/wXk/Fjns1WzjVsFbXJIV6xhdx6HMa2wqPO8BTKKe 9hfMIz4pEQVjfMbYhCWo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 09 May 2012 23:35:53 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1831686128.5890.4048; Wed, 09 May 2012 23:35:52 -0400 Message-ID: <4FAB3786.2080108@isdg.net> Date: Wed, 09 May 2012 23:35:34 -0400 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: <4F98A578.6020902@mail-abuse.org> <4FA94BF1.4060503@gathman.org> In-Reply-To: <4FA94BF1.4060503@gathman.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] In support of retaining Received-SPF Header Field X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 10 May 2012 03:36:15 -0000 +1 -- HLS Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 04/25/2012 09:31 PM, Douglas Otis > would write: >> It would never be in a users interest to adopt result formats aimed at >> disabling third-party competitors by omitting essential information. > I think what Douglas is trying to say is that Authentication-Results has > less information than Received-SPF, and therefore Received-SPF should be > retained. > > +1 retain Received-SPF > > I have implemented both headers in production over the past week, and > the information in A-R is only a brief summary of the information in > Received-SPF. So there is little redundancy in having both in a > message. The additional information in Received-SPF is very valuable > for the reasons Doug mentioned at length, and also for diagnosing > problems. (This is for the existing RFC 5451. I haven't checked the > proposed extensions.) We should not deprecate Received-SPF until all > its information has been standardized in the A-R header. > > Here is a live example of both headers: > > Received-SPF: Pass (mail.bmsi.com: domain of accion.netcommunity1.com > designates 205.139.105.170 as permitted sender) > client-ip=205.139.105.170; > envelope-from="DSN.10310.15484773.7195596@accion.netcommunity1.com"; > helo=d2pdcsmmta02v0.blackbaud.com; receiver=mail.bmsi.com; > mechanism="ip4:205.139.104.0/22"; identity=mailfrom > > Authentication-Results: mail.bmsi.com; iprev=pass > policy.iprev=205.139.105.170 (d2pdcsmmta02v0.blackbaud.com); spf=pass > (sender SPF authorized) smtp.helo=d2pdcsmmta02v0.blackbaud.com > smtp.mailfrom=DSN.10310.15484773.7195596@accion.netcommunity1.com > > The missing field in this example is "mechanism" (including iprev method > makes up for missing client ip). > Additionally, HELO SPF result is often included in Received-SPF (and > x-bestguess result as an extension in my case). > From sm@elandsys.com Thu May 10 03:55: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 AC25F21F8668 for ; Thu, 10 May 2012 03:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecfyOyzK7rp6 for ; Thu, 10 May 2012 03:55:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E95AA21F8510 for ; Thu, 10 May 2012 03:54:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.173]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4AAseL1004750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 03:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336647293; i=@elandsys.com; bh=3FTCHqKwFe+MlyxxIvBbpwtrcTG0E/Y/VV5kedcTotE=; h=Date:To:From:Subject:Cc; b=VJkMahbk2gVl81FxO0kVzMDPGoLVp0WRQQq1kSiCT4AcU++erlgzDQRbggPFdMQdt KwNkmn8V8VtmpYI0AoflVEmAYnZ3k6rTdY5zrNHQ8RYSm7g6YR1KYVdwJDuzOFXF5p HiKw5kmXK7Pk8jdge32uxCj60uMzmVsLu7edWhH8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1336647293; i=@elandsys.com; bh=3FTCHqKwFe+MlyxxIvBbpwtrcTG0E/Y/VV5kedcTotE=; h=Date:To:From:Subject:Cc; b=jQBItFxnpnY59j9E0TxqgsxmH3lh9uE9VU2Q2QZ751Eh6HMWHEvjSUZVQzHg3tFMz p3kQB64HWTwSzcDuiDA2w8r/2RA7fMZD52ZaC2FOZSQpeJUblt4nKfkX/3vJBV6C0n kOmG2wU30qQym5MnX5ZzJTnoxe08ZhhKQuiTkWdo= Message-Id: <6.2.5.6.2.20120510034438.0a927520@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 May 2012 03:48:25 -0700 To: "Murray S. Kucherawy" From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] IPR disclosure - draft-ietf-spfbis-experiment-07 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 10 May 2012 10:55:07 -0000 Hi Murray, As you are the document editor for draft-ietf-spfbis-experiment-07, can you confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? Regards, S. Moonesamy SPFBIS WG co-chair From msk@cloudmark.com Thu May 10 06:44: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 E707A21F85B5 for ; Thu, 10 May 2012 06:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo-tdFGR9XKm for ; Thu, 10 May 2012 06:44:09 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 64A1921F8562 for ; Thu, 10 May 2012 06:44:09 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 8DkT1j0010as01C01DkT79; Thu, 10 May 2012 06:44:27 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=ZWjlqJ36OZkA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=wPPvXI8NAAAA:8 a=48vgC7mUAAAA:8 a=nu5teSh_mmRCJVSdIhAA:9 a=CjuIK1q_8ugA:10 a=pOcSzP0BEVkA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 10 May 2012 06:43:58 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: IPR disclosure - draft-ietf-spfbis-experiment-07 Thread-Index: AQHNLptWI0PtEKGpJkeo9s0dxcTk05bDCFJg Date: Thu, 10 May 2012 13:43:56 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392811CE00@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120510034438.0a927520@elandnews.com> In-Reply-To: <6.2.5.6.2.20120510034438.0a927520@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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336657467; bh=f0vHrque/OHA9v61AhOP18WYw0PdU6AhJqqu4JVWhSU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=pDwvifjrigGV92TkaFJ2pBSOYi5Y7KNcJFG+adekNYB+3hQvzIhVeoPmRd2EKzbHQ lcoiCWLMYx9jsckwws7N/9dQF9/rUxDDX0CvwB+UKBjmnkTlb6i1/Ax6oV7qH0cCON wOlocox0CUkutV+RW5HuOCf3NNZp8LqOa0OQnZ60= Subject: Re: [spfbis] IPR disclosure - draft-ietf-spfbis-experiment-07 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 10 May 2012 13:44:10 -0000 > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Thursday, May 10, 2012 3:48 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: IPR disclosure - draft-ietf-spfbis-experiment-07 >=20 > As you are the document editor for draft-ietf-spfbis-experiment-07, can > you confirm that any and all appropriate IPR disclosures required for > full conformance with the provisions of BCP 78 and BCP 79 have already > been filed? I am aware of no outstanding IPR claims on any of the material in that docu= ment (or in -08, which I'm about to post). -MSK From internet-drafts@ietf.org Thu May 10 06:54: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 2AB4421F8629; Thu, 10 May 2012 06:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swRlZmS17h1A; Thu, 10 May 2012 06:54:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A54321F8604; Thu, 10 May 2012 06:54:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120510135408.24757.71015.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 06:54:08 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-08.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: Thu, 10 May 2012 13:54:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Resolution of The SPF and Sender ID Experiments Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-08.txt Pages : 12 Date : 2012-05-10 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols. Both of these protocols enable one to publish via the Domain Name System a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents (RFC4405, RFC4406, RFC4407, and RFC4408) with Experimental status, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/ From msk@cloudmark.com Thu May 10 07:03: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 6E2BF21F863D for ; Thu, 10 May 2012 07:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRp9q6YGqs6G for ; Thu, 10 May 2012 07:03:46 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id BEF3A21F8638 for ; Thu, 10 May 2012 07:03:46 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 8E3D1j0010ZaKgw01E3DUx; Thu, 10 May 2012 07:03:13 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=R/iB6KtX c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=T9ymzoN1stAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=NT-2j5NWm9YkwfVGEqEA:9 a=zIMzC8mig1Zeh0V56qIA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 10 May 2012 07:03:14 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: I-D Action: draft-ietf-spfbis-experiment-08.txt Thread-Index: AQHNLrRmqKtgQ7pJq06IUD67MbX6PpbDC4+g Date: Thu, 10 May 2012 14:03:13 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392811CE9F@exch-mbx901.corp.cloudmark.com> References: <20120510135408.24757.71015.idtracker@ietfa.amsl.com> In-Reply-To: <20120510135408.24757.71015.idtracker@ietfa.amsl.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336658593; bh=5UoeZ1KIY1CyVz/CAFvZODfzj93rAteWnaNXPDjWVBs=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=s/4w0bBhmmC2m9y8uu5jWlDNWsfDEfjrafrzyHKmocn4RgIwH3nm5TiPY6m2Kwyee lPylbGurVgy0dGVjI3qk4g6krraiAzObC22a1jfaPPC4qaiqQCaueU7Z75xRKrQN6M S6VzInK/MucwVWVdI9lVsMzBWp3fff+T5Xmv9qpM= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-08.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: Thu, 10 May 2012 14:03:47 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, May 10, 2012 6:54 AM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: I-D Action: draft-ietf-spfbis-experiment-08.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group > of the IETF. >=20 > Title : Resolution of The SPF and Sender ID Experiments > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-08.txt > Pages : 12 > Date : 2012-05-10 > [...] Working Group Last Call completed yesterday. This is the result. Here's a= summary of the changes since -07, which was the consensus text at the star= t of WGLC, all of which were either merely editorial in nature or reached c= onsensus on the list: - Abstract reworked with suggestions from Barry, Scott and others - Additional specifics about the surveys added for clarity - Background on what SUBMITTER and PRA are was added for reader convenience - SUBMITTER survey table added for reader convenience - Clarification on the "differences" point added - Swap the order of Sections 7 and 8, since IANA Considerations will be del= eted (avoids later renumbering) The -08 version is thus submitted to the chairs for handoff to the IESG at = their convenience. -MSK From msk@cloudmark.com Thu May 10 07:10: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 A689621F8666 for ; Thu, 10 May 2012 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWDdAzXvrLqQ for ; Thu, 10 May 2012 07:10:34 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id E50CF21F8661 for ; Thu, 10 May 2012 07:10:34 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 8EB31j0010ZaKgw01EB3HW; Thu, 10 May 2012 07:11:03 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=T9ymzoN1stAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=n3p35pEGYvZFYFd26IkA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 10 May 2012 07:10:34 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: I-D Action: draft-ietf-spfbis-experiment-08.txt Thread-Index: AQHNLrRmqKtgQ7pJq06IUD67MbX6PpbDC4+ggAADryA= Date: Thu, 10 May 2012 14:10:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392811CF3A@exch-mbx901.corp.cloudmark.com> References: <20120510135408.24757.71015.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E00392811CE9F@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392811CE9F@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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336659063; bh=Agrnvh/2/rzqCDUIY5ReNxRcu2jlPWQB4QatIJqhAfE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=GVsOdkekzovMeg2St/9IdYscxE6JBsU1LEv5slQFKfLmAn2fEe+Xr1fMcGMzvkU4o PLzshL69Q5jUebNBIV0lmCaisC3WLL4BsyaNep7LZW7Lpls763LfP3dGnM/9mojgCB MD1PHbDhMXeJK7zmqECSE2ARQ6xGOySuXQjI8M7A= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-08.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: Thu, 10 May 2012 14:10:35 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Murray S. Kucherawy > Sent: Thursday, May 10, 2012 7:03 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-08.txt >=20 > Working Group Last Call completed yesterday. This is the result. > Here's a summary of the changes since -07, which was the consensus text > at the start of WGLC, all of which were either merely editorial in > nature or reached consensus on the list: I forgot: - TDP survey numbers updated, as they are ongoing; the counts are larger bu= t the percentages are effectively static -MSK From ajs@anvilwalrusden.com Fri May 11 11:50: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 C84F221F8707 for ; Fri, 11 May 2012 11:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grL1uPxd3WpV for ; Fri, 11 May 2012 11:50:53 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCE521F8705 for ; Fri, 11 May 2012 11:50:53 -0700 (PDT) Received: from mail.yitter.info (nat-05-mht.dyndns.com [216.146.45.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6B72C1ECB41D for ; Fri, 11 May 2012 18:50:52 +0000 (UTC) Date: Fri, 11 May 2012 14:50:51 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120511185047.GI15782@mail.yitter.info> References: <20120510135408.24757.71015.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120510135408.24757.71015.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-08.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, 11 May 2012 18:50:53 -0000 Dear colleagues, On Thu, May 10, 2012 at 06:54:08AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SPF Update Working Group of the IETF. > > Title : Resolution of The SPF and Sender ID Experiments > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-08.txt > Pages : 12 > Date : 2012-05-10 As far as your chairs can tell, that document now represents the consensus of the WG. Watch for the shepherd to post the PROTO report soon. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Fri May 11 16:03: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 5527F9E800A for ; Fri, 11 May 2012 16:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46VLYSB7Gp9N for ; Fri, 11 May 2012 16:03:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B61579E8009 for ; Fri, 11 May 2012 16:03:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.164]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4BN2fZJ021464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 16:02:51 -0700 (PDT) Message-Id: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 May 2012 16:02:36 -0700 To: "Murray S. Kucherawy" From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 May 2012 23:03:06 -0000 Hello, Here's my review as Document Shepherd. I am copying it to the mailing list as WG information. Summary: The document is almost ready for publication as an Informational RFC but has a few issues that should be fixed before publication. The document is well-written and it provides evidence about the SPF and Sender ID experiments and conclusions in Section 5. If this was not a best effort by the working group, I would have ask for some of the text in Appendix A to be backed by facts. The question of the status of the RFCs may be raised during the Last Call. I don't consider it as an issue based on the SPFBIS WG discussions. I suggest waiting for the review from the Responsible Area Director instead of getting into a discussion about an issue which may turn out to be a non-issue. The discussion in Appendix A about "pressure" might cause some controversy. As there is WG consensus on the draft, I won't suggest any change. The "DNS experts within the community that will undoubtedly" comment may also be controversial. I note that draft-schlitt-spf-classic-02 was the draft approved by the IESG. I'll suggest waiting for AD review. I'll wait for the document to address the review. Minor issues: In Section 5: "2. Of the records retrieved, fewer than 3% included specific requests for processing of messages using the PRA algorithm, which is an essential part of Sender ID." The first point is about "DNS resource record". It is not clear what "records retrieved" are in the above. I am listing this as minor due to text clarity; it could have been filed as a nit. "3. Although the two mechanisms often used different email address fields as the subject being evaluated, no data collected showed any substantial operational benefit, in terms of improved accuracy, to using one mechanism over the other." What mechanisms does the above refer to? "6. Ample options are available in terms of software to implement either of the two protocols." I'll suggest: "multiple implementations of either of the two protocols are available." From an IETF perspective, software is the implementation of a protocol. Nits: In Section 3.3: "The PRA is the output of a heuristic that seeks to scan a message" I suggest expanding on first use. "An unknown number of SMTP clients implement SUBMITTER." I suggest adding "SMTP extension" at the end of the sentence. "Although there is substantial activity showing its use in MTA logs, it is not possible to determine whether they are multiple instances of the same client, or separate client implementations." I'll suggest: Although information from MTA logs indicate substantial use of the SMTP extension, it is not possible to determine whether the usage is from multiple instances of the same SMTP client or different SMTP client implementations. "An active survey was done of running and publicly reachable MTAs." Sugested: An active survey of MTAs accessible over the Internet was performed. "The MTAs selected were found by querying for MX and A records of a" Suggested: resource records In Section 5, point 4: implementations "Later, after RRTYPE 99 was assigned (long after IESG approval of the document, in fact)" It's not clear what the document is in the above. Regards S. Moonesamy (as document shepherd) From spf2@kitterman.com Fri May 11 16:07: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 E4E4521F8624 for ; Fri, 11 May 2012 16:07:51 -0700 (PDT) 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 HFpcZHlTfHIC for ; Fri, 11 May 2012 16:07:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE0B21F8584 for ; Fri, 11 May 2012 16:07:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2897E20E40D0; Fri, 11 May 2012 19:07:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1336777663; bh=nfVmBAjjDmAS9FBblaZVM+LMpm0Z6tVLhvJ9CrLGmMs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=XWQlVg/xSEwizjfiZQKZzMdZpm5bY0ahqo499VP/r+UEPFTyKeVv8CqPZ5sK4AIVY 4xevmv5KdlwLVi3bwz4cKHpH2nIwQpuMFd5KKBRcteLhqIL4PpRZ8uJLqQh9KHysYT +QHYfZ3dsYttafbVTmX0y638rtm+PWxF7dWqiBAY= 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 0BEE220E4083; Fri, 11 May 2012 19:07:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 11 May 2012 19:07:42 -0400 Message-ID: <1516274.isISRXUOpE@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-24-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> References: <6.2.5.6.2.20120511160211.08f92588@elandsys.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] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 May 2012 23:07:52 -0000 On Friday, May 11, 2012 04:02:36 PM S Moonesamy wrote: > In Section 5, point 4: implementations > > "Later, after RRTYPE 99 was assigned (long after IESG approval of the > document, in fact)" > > It's not clear what the document is in the above. draft-schlitt-spf-classic-02 Scott K From msk@cloudmark.com Fri May 11 16:12: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 9A96B21F866B for ; Fri, 11 May 2012 16:12:12 -0700 (PDT) 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 rBAtbi4DnEYf for ; Fri, 11 May 2012 16:12:11 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id B748E21F8664 for ; Fri, 11 May 2012 16:12:11 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 8nCK1j0010ZaKgw01nCKU8; Fri, 11 May 2012 16:12:19 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=Gnv7Iswf-UgA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=wPPvXI8NAAAA:8 a=48vgC7mUAAAA:8 a=yYfCM_HaidBd6-JMYScA:9 a=DY3VE7at33j65hsJJcEA:7 a=CjuIK1q_8ugA:10 a=pOcSzP0BEVkA:10 a=7U1PH3j7Tnely0BJ:21 a=BPMC_vCvSkQu-1D7:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Fri, 11 May 2012 16:11:49 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: Document shepherd review of draft-ietf-spfbis-experiment-08 Thread-Index: AQHNL8o4EKDZmDseoUmmbtWi+bjwW5bFNz9A Date: Fri, 11 May 2012 23:11:49 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392811EC0B@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> In-Reply-To: <6.2.5.6.2.20120511160211.08f92588@elandsys.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336777939; bh=gryexpEGJ1GztSbKqlE9W9VO09ErLWnzzia3YY9f7ko=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bCaw+e/QD2uJhi907pje2CbCivlMMkZ8g2eWbe1zgHhvx81FNbpnqhqxMAHz+LHC1 5NymYsuJCkuZJwzCYBWXkLE60w14vNghN2nMu0JwyUtiMArrM1XJAiuYNMXUl9J4d9 05TjQrqQwZzAXUokYAfbakZtvp3uNvxjr5pm9PVg= Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 May 2012 23:12:12 -0000 > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Friday, May 11, 2012 3:57 PM > To: Murray S. Kucherawy > Cc: spfbis@tools.ietf.org > Subject: Document shepherd review of draft-ietf-spfbis-experiment-08 >=20 > Hello, >=20 > Here's my review as Document Shepherd. I am copying it to the mailing=20 > list as WG information. >=20 > Summary: The document is almost ready for publication as an=20 > Informational RFC but has a few issues that should be fixed before=20 > publication. >=20 > The document is well-written and it provides evidence about the SPF=20 > and Sender ID experiments and conclusions in Section 5. If this was=20 > not a best effort by the working group, I would have ask for some of=20 > the text in Appendix A to be backed by facts. I claim everything in Appendix A is factual. Certainly much of it is anecd= otal, but there are enough people participating in this working group that = were also around for the earlier work, and the MXCOMP and spf-discuss list = archives are available as references, that it can all be "proven" if needed= . That it has WG consensus means to me that we feel it is an accurate refl= ection of the relevant history. I suggest we leave it as-is, and respond by including specific links to lis= t archives and such if challenged during IETF Last Call or IESG Evaluation. > The question of the status of the RFCs may be raised during the Last=20 > Call. I don't consider it as an issue based on the SPFBIS WG=20 > discussions. I suggest waiting for the review from the Responsible=20 > Area Director instead of getting into a discussion about an issue=20 > which may turn out to be a non-issue. I propose we allow that discussion to happen independent of the working gro= up as much as possible, and allow the IESG to make that ultimate determinat= ion. They might, in fact, decide they want to do that on their own even if= it doesn't come up during IETF Last Call. Or there could be an individual= request to do so. > The discussion in Appendix A about "pressure" might cause some=20 > controversy. As there is WG consensus on the draft, I won't suggest=20 > any change. The "DNS experts within the community that will=20 > undoubtedly" comment may also be controversial. I note that > draft-schlitt-spf-classic-02 was the draft approved by the IESG. I'll=20 > suggest waiting for AD review. I concur. > I'll wait for the document to address the review. Which document? > Minor issues: >=20 > In Section 5: >=20 > "2. Of the records retrieved, fewer than 3% included specific > requests for processing of messages using the PRA algorithm, > which is an essential part of Sender ID." >=20 > The first point is about "DNS resource record". It is not clear what=20 > "records retrieved" are in the above. I am listing this as minor due=20 > to text clarity; it could have been filed as a nit. It could say "DNS records" to be precise, but I'd also point out that the D= NS records were the only record retrievals done during any of the data coll= ection described in the earlier sections. > "3. Although the two mechanisms often used different email address > fields as the subject being evaluated, no data collected showed > any substantial operational benefit, in terms of improved > accuracy, to using one mechanism over the other." >=20 > What mechanisms does the above refer to? SPF and Sender ID. "Protocols" might be better. > "6. Ample options are available in terms of software to implement > either of the two protocols." >=20 > I'll suggest: >=20 > "multiple implementations of either of the two protocols are=20 > available." >=20 > From an IETF perspective, software is the implementation of a=20 > protocol. I think I prefer "ample", as it is descriptive of the fact that there were = enough of them that any reasonable operator had the option to find support = for one protocol or the other. "Multiple" could mean "two", and there were= actually several more than that in each case. > Nits: >=20 > In Section 3.3: >=20 > "The PRA is the output of a heuristic that seeks to scan a message" >=20 > I suggest expanding on first use. Agree. > "An unknown number of SMTP clients implement SUBMITTER." >=20 > I suggest adding "SMTP extension" at the end of the sentence. I think that's redundant to the second paragraph, but sure. > "Although there is substantial activity showing its use in MTA logs, > it is not possible to determine whether they are multiple instances > of the same client, or separate client implementations." >=20 > I'll suggest: >=20 > Although information from MTA logs indicate substantial use of the=20 > SMTP > extension, it is not possible to determine whether the usage is=20 > from multiple > instances of the same SMTP client or different SMTP client=20 > implementations. OK. > "An active survey was done of running and publicly reachable MTAs." >=20 > Sugested: >=20 > An active survey of MTAs accessible over the Internet was performed. OK. > "The MTAs selected were found by querying for MX and A records of a" >=20 > Suggested: resource records OK. > In Section 5, point 4: implementations >=20 > "Later, after RRTYPE 99 was assigned (long after IESG approval of the > document, in fact)" >=20 > It's not clear what the document is in the above. RFC4408. We can change that. Would you like an -09, or should we handle these during IETF Last Call, sin= ce they are minor? -MSK From internet-drafts@ietf.org Fri May 11 16:21: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 788AA9E801D; Fri, 11 May 2012 16:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+UOQm5nWMe7; Fri, 11 May 2012 16:21:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4529E800A; Fri, 11 May 2012 16:21:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120511232153.6414.8118.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2012 16:21:53 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-09.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, 11 May 2012 23:21:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Resolution of The SPF and Sender ID Experiments Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-09.txt Pages : 12 Date : 2012-05-11 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols. Both of these protocols enable one to publish via the Domain Name System a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents (RFC4405, RFC4406, RFC4407, and RFC4408) with Experimental status, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/ From msk@cloudmark.com Fri May 11 16:22: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 B5C1E21F8476 for ; Fri, 11 May 2012 16:22:32 -0700 (PDT) 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 pdDLJrsDuIWj for ; Fri, 11 May 2012 16:22:32 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1FC21F8473 for ; Fri, 11 May 2012 16:22:32 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 8nP11j0010as01C01nP1Wa; Fri, 11 May 2012 16:23:01 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=qUeodMWIlWAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=ArsBaqCB88RB0iRtB9EA:9 a=KkFyh2zJkEnc54ehYdUA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 11 May 2012 16:22:31 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-09.txt Thread-Index: AQHNL8za/yfj0XGqN0OHMFCvx7ygYJbFOidw Date: Fri, 11 May 2012 23:22:31 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392811EC51@exch-mbx901.corp.cloudmark.com> References: <20120511232153.6414.8118.idtracker@ietfa.amsl.com> In-Reply-To: <20120511232153.6414.8118.idtracker@ietfa.amsl.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336778581; bh=ZbRC/jfkIkEiwQ3dh3igk2WhmWzUWD2OQsMY9oAhDT4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=c4+nnWCMUufd54aK/0iiV5M74eJ8KAIm4ki/B58NZGPpwGrPAtrHv80KSfgTb8zew DrxjQ8zR3rLAYmqLUs65JqwlWJbZ7aHrh4I6Bko+R172oiSHFxxa9bE7Jpzx2lVfiQ qcwfdCW8S1CvBeoiOj8FBICa3jAax3tzDK7BiBSI= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-09.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, 11 May 2012 23:22:32 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Friday, May 11, 2012 4:22 PM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-09.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group > of the IETF. >=20 > Title : Resolution of The SPF and Sender ID Experiments > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-09.txt > Pages : 12 > Date : 2012-05-11 > [...] Per Document Shepherd review. -MSK From sm@elandsys.com Fri May 11 16:42: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 74AE121F85B9 for ; Fri, 11 May 2012 16:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4xlKdZ-JaYi for ; Fri, 11 May 2012 16:42:13 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F190F21F84FF for ; Fri, 11 May 2012 16:42:12 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.164]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4BNfxVd023162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 16:42:09 -0700 (PDT) Message-Id: <6.2.5.6.2.20120511161343.0a3773b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 May 2012 16:41:52 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E00392811EC0B@exch-mbx901.corp.cl oudmark.com> References: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> <9452079D1A51524AA5749AD23E00392811EC0B@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] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 May 2012 23:42:13 -0000 Hi Murray, At 16:11 11-05-2012, Murray S. Kucherawy wrote: >I claim everything in Appendix A is factual. Certainly much of it >is anecdotal, but there are enough people participating in this >working group that were also around for the earlier work, and the >MXCOMP and spf-discuss list archives are available as references, >that it can all be "proven" if needed. That it has WG consensus >means to me that we feel it is an accurate reflection of the relevant history. Ok. >I suggest we leave it as-is, and respond by including specific links >to list archives and such if challenged during IETF Last Call or >IESG Evaluation. I'll suggest not to make waves. :-) My task is to help the working group and other parties resolve any issue raised during the Last Call and the IESG Evaluation. >I propose we allow that discussion to happen independent of the >working group as much as possible, and allow the IESG to make that >ultimate determination. They might, in fact, decide they want to do >that on their own even if it doesn't come up during IETF Last >Call. Or there could be an individual request to do so. Yes. >Which document? I noticed that I left out editor after sending the message. >It could say "DNS records" to be precise, but I'd also point out >that the DNS records were the only record retrievals done during any >of the data collection described in the earlier sections. I'll leave it to you as it is an editorial nit. >SPF and Sender ID. "Protocols" might be better. Ok. >I think I prefer "ample", as it is descriptive of the fact that >there were enough of them that any reasonable operator had the >option to find support for one protocol or the other. "Multiple" >could mean "two", and there were actually several more than that in each case. Ok. >I think that's redundant to the second paragraph, but sure. Ok. >RFC4408. We can change that. Here's what you have in -09: "Later, after RRTYPE 99 was assigned (long after IESG approval of [SPF], in fact)" It's actually incorrect. As this is in the Appendix, I'll just put it to an editorial comment. >Would you like an -09, or should we handle these during IETF Last >Call, since they are minor? I read -09. I consider the comments as addressed. Regards, S. Moonesamy (as document shepherd) From msk@cloudmark.com Fri May 11 16:47: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 3A0979E8026 for ; Fri, 11 May 2012 16:47:04 -0700 (PDT) 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 R++19ZFwUX7r for ; Fri, 11 May 2012 16:47:03 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id AC4D19E8025 for ; Fri, 11 May 2012 16:47:03 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 8nn21j0010as01C01nn2gf; Fri, 11 May 2012 16:47:02 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=R/iB6KtX c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=D6Hq91Ic0zIA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=wPPvXI8NAAAA:8 a=48vgC7mUAAAA:8 a=H-8G5kp2m6f0XueSLhUA:9 a=CjuIK1q_8ugA:10 a=pOcSzP0BEVkA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 11 May 2012 16:47:03 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08 Thread-Index: AQHNL8+whN35oPtPgkuT6aBZgp7XCpbFQJpg Date: Fri, 11 May 2012 23:47:02 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392811ECDD@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> <9452079D1A51524AA5749AD23E00392811EC0B@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120511161343.0a3773b0@resistor.net> In-Reply-To: <6.2.5.6.2.20120511161343.0a3773b0@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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336780022; bh=4XK/WyrStaIjlWZVReBceT5ngqSyjw7dMffQaBYj3wY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=sioBf5SxK/ZyrEQkAPLSWo2fBjbTjuID0e3WN0ZQ5WTbTPyBLC4XI13pe958vvvCW TTfiRmKZ4lpPTw2GK2QYo+e+sxojn7qGCKHtYk7LAotx4q65ied8aoDxkQQucnbv42 KWocwMWW6/PNd44O9pEQ923R5K7lfZI73lspyG8o= Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 May 2012 23:47:04 -0000 > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Friday, May 11, 2012 4:42 PM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-exper= iment-08 >=20 > Here's what you have in -09: >=20 > "Later, after RRTYPE 99 was assigned (long after IESG approval of > [SPF], in fact)" >=20 > It's actually incorrect. As this is in the Appendix, I'll just put it > to an editorial comment. Would you prefer "the draft that became [SPF]"? Anyway, I think we can deal with that in IETF LC. -MSK From sm@elandsys.com Fri May 11 18:03: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 6208421F85E5 for ; Fri, 11 May 2012 18:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpxeq6an4k6b for ; Fri, 11 May 2012 18:03:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9D721F8593 for ; Fri, 11 May 2012 18:03:29 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.164]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4C13HMp010118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 18:03:27 -0700 (PDT) Message-Id: <6.2.5.6.2.20120511175420.089a2730@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 May 2012 18:02:46 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E00392811ECDD@exch-mbx901.corp.cl oudmark.com> References: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> <9452079D1A51524AA5749AD23E00392811EC0B@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120511161343.0a3773b0@resistor.net> <9452079D1A51524AA5749AD23E00392811ECDD@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] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 May 2012 01:03:30 -0000 Hi Murray, At 16:47 11-05-2012, Murray S. Kucherawy wrote: >Would you prefer "the draft that became [SPF]"? I'll have to give this some more thought. >Anyway, I think we can deal with that in IETF LC. I would leave this nit for IETF Last Call or even later. Regards, S. Moonesamy (as document shepherd) From hsantos@isdg.net Fri May 11 20:16: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 0BC2721F858D for ; Fri, 11 May 2012 20:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHIwSbPjq5Gt for ; Fri, 11 May 2012 20:16:09 -0700 (PDT) Received: from ntbbs.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C86C821F8587 for ; Fri, 11 May 2012 20:16:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4732; t=1336792560; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=0uSXhZdnE77gAJhiGbykE7L9yfo=; b=kSKK8fd9ieH3rOoE0fqM Qgat/eBJ6DD5YJSulboNdMYA/gY3AmgmGpLmrwsdXaK9zIcYqvSrF62ynZd3M+Gr 3V0GSRZiwZuhT0C8UulG+zM9JaOMQPJa+K4rieIErxIGKQLZu+9SGWffx7F2OSBc 6vaBCl3m9vA4q7cPSjZl1QU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 11 May 2012 23:16:00 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1404392189.55079.3472; Fri, 11 May 2012 23:15:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4732; t=1336792542; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=3ylPBl1 Gg9kIT5Cn3FRUW1OKz5117lPcqiioQGJYNRc=; b=Py6+X/WI40SDRTPJ+ur+g4I Yr3+jb+h/JpO5bFNqhFy2fv2PMg7fRPojotYIEYESC0koUorBQ22FfiVQkFk49L+ s4Xd9V1dTYEIUz/OQeHRCNvlRNoNoYukyAzC/aRGoEJhPDbNFhenp9yeGzgKcfzG f5Zg4X6LxU4yzJePoDE8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 11 May 2012 23:15:42 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2003275269.6970.7108; Fri, 11 May 2012 23:15:41 -0400 Message-ID: <4FADD5BF.8030006@isdg.net> Date: Fri, 11 May 2012 23:15:11 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> In-Reply-To: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 May 2012 03:16:10 -0000 S Moonesamy wrote: > Hello, > The question of the status of the RFCs may be raised during the Last > Call. I don't consider it as an issue based on the SPFBIS WG > discussions. I suggest waiting for the review from the Responsible Area > Director instead of getting into a discussion about an issue which may > turn out to be a non-issue. > > The discussion in Appendix A about "pressure" might cause some > controversy. As there is WG consensus on the draft, I won't suggest any > change. The "DNS experts within the community that will undoubtedly" > comment may also be controversial. I have a question. Are we pass the point that the SPFBIS can be endorsed as Proposed Standard without its special RRTYPE? Background: I think I was among those here that advocated continued SPF special RR TYPE (type99) support because: a) Surprisingly, evidence presented here showed support or it was enabled. Our implementation has it OFF by default because of the #1 reason - SPF already had a very high DNS overhead and waste in blind queries of domains. b) The early desires to use new RRTYPEs with the coupled expectations DNS Servers will evolved to support RFC3597 unnamed RRTYPEs. c) To help with the IETF endorsement of already questionable protocol surely to have a high DNS overhead and waste (NXDOMAIN) in queries. I didn't think SPF was IETF material before MARID, the same way I didn't think Greylisting was IETF material. No one in the SMTP and DNS community would support these ideas which were considered by many as KLUDGE solutions. Just consider many of the same people here (and in IETF-SMTP) were vehemently against both of these new ideas, and today, you will many supporting them today as IETF material. So to me, it was always about the "IETF Endorsement" value and while text in the appendix could be considered part of the facts, it was more about make SPF "IETF endorsement" material. The "pressure" was not just DNS people, but most, if not all, involved as early adopters of all these new DNS based applications using TXT records. What really highlighted the concern was Microsoft's introduction of CEP, the XML-formatted version of SPF. To me, it showed the changing mindset of Application Developers with little or lesser concerns with system level scaled designs. XML for DNS TXT records? You got to be kidding me! It was already to use TXT records and no way the IETF/DNS people would accept XML on that of that! It was the first thing that had to go if we can get the IETF/DNS to even consider SPF for endorsement! But times has changed, just look at the IETF work for GreyListing! No way, did you even dare bring that up in 2003. Outside of SPF, today we have other DNS applications as proposed standards or standard track all as TXT-only support: Proposed standards with DNS TXT-ONLY requirement DKIM VBR ADSP ATPS and even new ones like DMARK that even adds more DNS redundancy and waste, and without a doubt more complex in application design support! So if these protocols were endorsed as IETF proposed standard RFCs, which might suggest the DNS concerns are lesser today for many other reasons like faster hardware, higher I/O bandwidth and more reliable, robust DNS servers, then SPF no longer has the same IETF endorsement considerations using RRTYPES as it did back in 2004-2006. This was all why I felt it was necessary to ask these questions in the IETF and DNS-OPS list, to see what the IETF/DNS community mindset is today. From all the responses I saw in these threads, I came out with the general view that it was be "NICE" to have RRTYPE type for DNS applications, but either because the practical reality of not having a wide cross section of compatible DNS servers in all OSes, not just *nix systems, the Domain Hosting Web Managers don't support unnamed types entries, and/or the current performance and operations of DNS is so much better today, the overhead associated with all these DNS TXT lookups is a lesser concern, making TXT records acceptable by the IETF for proposed standards. So if we are pass the IETF endorsement quality of the question for no longer requiring a RRTYPE in order to get a proposed standard, then I think the report should recommend dropping support for type99 in RFC4408BIS for the following reasons: - No longer required for IETF endorsement, - Other IETF proposed standards exist for DNS TXT only records, - Lack of wide DNS servers supporting RFC3597 on all OS platforms with no short or near term expectation this will change, and - Removing type99 will lower DNS overhead of dual type lookups. -- HLS From sm@elandsys.com Sat May 12 01:31: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 D1F9321F85AD for ; Sat, 12 May 2012 01:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpMTRvQDCjLj for ; Sat, 12 May 2012 01:31:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2668A21F85AA for ; Sat, 12 May 2012 01:31:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.164]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4C8HttZ019532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 May 2012 01:18:05 -0700 (PDT) Message-Id: <6.2.5.6.2.20120511221652.09f85980@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 12 May 2012 00:39:34 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <4FADD5BF.8030006@isdg.net> References: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> <4FADD5BF.8030006@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 May 2012 08:31:17 -0000 Hi Hector, At 20:15 11-05-2012, Hector Santos wrote: >I have a question. > >Are we pass the point that the SPFBIS can be endorsed as Proposed >Standard without its special RRTYPE? At the end of the discussions relating to Issue #9, the WG Chair mentioned the following: "that the document will say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99." When it comes to a draft, the IETF is only past a point when it is published as a RFC. The SPFBIS working group is past the point on Issue #9 (SPF RR Type and TXT RR). A working group participant may raise an issue if there is new information available; i.e. information which was not considered when the issue was discussed. >This was all why I felt it was necessary to ask these questions in >the IETF and DNS-OPS list, to see what the IETF/DNS community mindset is today. There will be an IETF Last Call on draft-ietf-spfbis-experiment-09. There will be an IETF Last Call for 4408bis. Comments will be solicited from the IETF Community. I don't see any reason to ask the DNS Community a question as it is not like the working group is updating a DNS specifications or taking on new work which has an impact on DNS. There are some participants from the DNS Community which are aware of the work being done in this working group. They also have the opportunity to comment during the IETF Last Calls. > From all the responses I saw in these threads, I came out with the > general view that it was be "NICE" to have RRTYPE type for DNS > applications, but either because the practical I performed an individual review of draft-ietf-spfbis-experiment-09 as Document Shepherd. The questions I asked were addressed. I did not raise the RRTYPE issue as it has been widely discussed by the working group and I didn't find anything new which would be useful input to the discussion. >So if we are pass the IETF endorsement quality of the question for >no longer requiring a RRTYPE in order to get a proposed standard, >then I think the report should recommend dropping support for type99 >in RFC4408BIS for the following reasons: > > - No longer required for IETF endorsement, > > - Other IETF proposed standards exist for DNS TXT only records, > > - Lack of wide DNS servers supporting RFC3597 on all OS platforms > with no short or near term expectation this will change, and > > - Removing type99 will lower DNS overhead of dual type lookups. I read the message posted on 9 May, 2012 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01520.html ) and all the other messages which have been posted during the WGLC. My conclusion is that nobody has threatened an appeal or otherwise indicated extreme discontent during the WGLC. If there are any areas of conflict, e.g. a WG participant threatened an appeal or is unhappy about an issue, I can add that to the write-up. If I have missed something, let me know. RFC 4858 provides information about document shepherding. The task is to help with IETF process details and to help the working group address any future issue raised outside the working group. I encourage a WG participant to discuss any significant issue within the working group. If anyone believes that the working group did not give careful consideration to an issue, I'll bring it to the attention of the Responsible AD. I would appreciate if such issues are accompanied by an explanation as the Responsible AD will ask me to explain the problem clearly. Regards, S. Moonesamy (as document shepherd) From vesely@tana.it Sat May 12 03:10: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 1347021F858E for ; Sat, 12 May 2012 03:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.591 X-Spam-Level: X-Spam-Status: No, score=-4.591 tagged_above=-999 required=5 tests=[AWL=0.128, 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 Y2LIwJWFpk4m for ; Sat, 12 May 2012 03:10:52 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F176721F858A for ; Sat, 12 May 2012 03:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1336817450; bh=pNogJeRNBn4yZSp62bVIcxBUVtH9lZ+UDBip85HHZHs=; l=2776; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Cqj70dbpa/9xmiaCBfBGUGijQWXeeBgNM2EJhhPijKZ1FPgjaCXS2MI1ESDI7ocwT VVhs7DdIbFuy848dGA0zEnMnCJWNyT/lhd8GIpPOv7r1ftCu1VKASpUF6ntgHmt50I MTWXF3xylg2tyYReC3HwDVQpi7/zwinxNAZbSNqw= 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, 12 May 2012 12:10:50 +0200 id 00000000005DC033.000000004FAE372A.000071B6 Message-ID: <4FAE372A.3030403@tana.it> Date: Sat, 12 May 2012 12:10:50 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> <4FADD5BF.8030006@isdg.net> <6.2.5.6.2.20120511221652.09f85980@elandnews.com> In-Reply-To: <6.2.5.6.2.20120511221652.09f85980@elandnews.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 May 2012 10:10:53 -0000 On Sat 12/May/2012 11:19:12 +0200 S Moonesamy wrote: > At 20:15 11-05-2012, Hector Santos wrote: > >> So if we are pass the IETF endorsement quality of the question for >> no longer requiring a RRTYPE in order to get a proposed standard, >> then I think the report should recommend dropping support for type99 >> in RFC4408BIS for the following reasons: >> >> - No longer required for IETF endorsement, >> >> - Other IETF proposed standards exist for DNS TXT only records, >> >> - Lack of wide DNS servers supporting RFC3597 on all OS platforms >> with no short or near term expectation this will change, and >> >> - Removing type99 will lower DNS overhead of dual type lookups. > > I read the message posted on 9 May, 2012 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01520.html ) > and all the other messages which have been posted during the WGLC. My > conclusion is that nobody has threatened an appeal or otherwise > indicated extreme discontent during the WGLC. As far as RRTYPE 99 is concerned, it seems to me we're all happy to remove such cumbersomeness --at least, I am. I guess most of us will be even more happy when SPF will be able to drop RRTYPE 16 and use its own type in a well defined and supported manner. IMHO, Appendix A expresses such feeling quite directly. > If there are any areas of conflict, e.g. a WG participant threatened > an appeal or is unhappy about an issue, I can add that to the > write-up. If I have missed something, let me know. RFC 4858 provides > information about document shepherding. The task is to help with IETF > process details and to help the working group address any future issue > raised outside the working group. To stay on the safe side, the third paragraph of the Introduction should read: In line with the IESG's request to evaluate after a period of time, this document concludes the experiments and presents evidence regarding a deployment feature and comparative effects of the two protocols. At the end it presents conclusions based on the data collected. > I encourage a WG participant to discuss any significant issue within > the working group. There are significant issues that are being moderated out, so I'd better not do so. I assume there is plenty of good reasons to keep those issues open at this stage. Nevertheless, it wouldn't be correct to pretend they're closed. I've already cited [Ned]: I think mitigation strategies for the issues SPF causes are highly relevant to the question of whether or not SPF should be placed on the standards track. But that's not relevant to the document at hand. -- [Ned] http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf-smtp&i=01OF6HRP963S0006TF%40mauve.mrochek.com From sm@elandsys.com Sat May 12 08:23: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 DC50D21F85E3 for ; Sat, 12 May 2012 08:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDmLWJ3GOxJK for ; Sat, 12 May 2012 08:23:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB4621F85A7 for ; Sat, 12 May 2012 08:23:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.51]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4CFN4Q8005034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 May 2012 08:23:14 -0700 (PDT) Message-Id: <6.2.5.6.2.20120512074736.09c2d568@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 12 May 2012 07:51:56 -0700 To: Pete Resnick From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: [spfbis] Publication request for draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 May 2012 15:23:24 -0000 Hi Pete, The SPFBIS WG requests publication of draft-ietf-spfbis-experiment-09. The Document Shepherd Write-Up is below. (1) The type of RFC being requested is Informational. The draft documents the resolution of the SPF and Sender ID Experiments. The type is indicated in the title page header. (2) The approval announcement contains the following sections: Technical Summary In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols with Experimental status. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. Working Group Summary The SPFBIS working group had a difficult task ahead as it was not clear how to conclude the SPF and Sender ID Experiments and how to address the IESG Notes in RFC 4405, RFC4406, RFC4407, and RFC4408. There were discussions about how to proceed. Only one proposal was submitted and it was adopted by the working group. The discussions about the RRTYPE 99 DNS Resource Record were controversial. The issue was resolved. There was consensus that Sender ID re-use of SPF DNS Resource Records does not have to be called out in the document. This document represents a best effort by the SPFBIS working group to conclude the experiments which were documented in the above-mentioned RFCs. Document Quality The document does not specify a protocol. The document was reviewed by the SPFBIS working group. Barry Leiba, as an individual, and Dave Crocker performed a thorough review of the document. Personnel S. Moonesamy is the Document Shepherd for this document. Pete Resnick is the Responsible Area Director. (3) I have personally reviewed draft-ietf-spfbis-experiment-09. Even though the milestone for the draft is August 2012, given that it has achieved the goals set forth in the SPFBIS working group charter, I believe that the draft is reading for forwarding to the IESG for publication. (4) This document has been reviewed by at least five SPFBIS WG participants. The document has also been reviewed by Andrew Sullivan. I do not have any concerns about the depth and breath of the reviews performed. (5) The document will also be reviewed by Alexey Melkinov on behalf of the Applications Area Directorate. (6) I do not have any specific concerns or issues with the document. (7) The author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. (8) There are no IPR disclosures referencing this document. (9) The WG as a whole understand and agree with the document. It has WG consensus. (10) Nobody has threatened an appeal or otherwise indicated extreme discontent during the WGLC. (11) Id-nits lists an error in Appendix A due to a SHOULD and the absence of a reference to RFC 2119. The reference is not necessary. (12) The document does not require any formal review. (13) All references within this document been identified as either normative or informative. (14) The document normatively references RFCs. (15) As the intended document status is Informational, the normative references to Experimental RFCs are not downward references. (16) The publication of this document does not change the status of any existing RFCs. (17) No IANA action is requested. This is clearly indicated in the IANA Considerations Section. (18) The document does not make use of any IANA registries. (19) The document does not contain any formal language. Regards, S. Moonesamy From msk@cloudmark.com Sat May 12 21:41: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 D2F2721F84FC for ; Sat, 12 May 2012 21:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RcIt40Vxd99 for ; Sat, 12 May 2012 21:41:55 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3521F84D6 for ; Sat, 12 May 2012 21:41:54 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 9GhL1j0030ZaKgw01GhLmH; Sat, 12 May 2012 21:41:20 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=F7XVh9dN c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=D6Hq91Ic0zIA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=0X38bGDCrvaWIGvg0mMA:9 a=P378CeKNnuBVWXOQoe0A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sat, 12 May 2012 21:41:21 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08 Thread-Index: AQHNMCeKAm7TOs/ej0e3WAQOFZKy1ZbHI2YQ Date: Sun, 13 May 2012 04:41:20 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392811FDE8@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120511160211.08f92588@elandsys.com> <4FADD5BF.8030006@isdg.net> <6.2.5.6.2.20120511221652.09f85980@elandnews.com> <4FAE372A.3030403@tana.it> In-Reply-To: <4FAE372A.3030403@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336884080; bh=rezd1deE8XWJO7P4S1OuFhODxol7/sSnV1K9Cnr/7xM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=civoYImsCFrBctiA81CY9hU5LXaqfIgcRfV71+Nn0YmhwTZ9CGsRLRVNMIvTGLQz2 Jt0L1eKg+z2e5k/gSWf9FELX5eZTWub04QGI5TpoQuxcSwTdYn82URn4g4AHXEpa6V 7wr2nVte+5SG2Uj1szjrvCxvBSA6BzGI54X159Rc= Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-experiment-08 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 May 2012 04:41:55 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Saturday, May 12, 2012 3:11 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-exper= iment-08 >=20 > As far as RRTYPE 99 is concerned, it seems to me we're all happy to > remove such cumbersomeness --at least, I am. I guess most of us will > be even more happy when SPF will be able to drop RRTYPE 16 and use its > own type in a well defined and supported manner. IMHO, Appendix A > expresses such feeling quite directly. I think I agree with all of that, although if the same issues exist when we= eventually consider moving some future version of SPF to its own RRTYPE, I= think we'll have the same trepidation. The bar to getting an RRTYPE assig= ned is (I'm told) substantially lower, but getting things like provisioning= tools to adapt has to get simpler. The whole field has to get better for = new RRTYPEs before that's a viable solution. > > I encourage a WG participant to discuss any significant issue within > > the working group. >=20 > There are significant issues that are being moderated out, so I'd > better not do so. I assume there is plenty of good reasons to keep > those issues open at this stage. Nevertheless, it wouldn't be correct > to pretend they're closed. Let's be careful not to mix "keeping focus" with "moderation". Nobody's "pretending" that the issues I know you're referring to are closed= . This is simply the wrong place to discuss them. > I've already cited [Ned]: >=20 > I think mitigation strategies for the issues SPF causes are highly > relevant to the question of whether or not SPF should be placed on > the standards track. >=20 > But that's not relevant to the document at hand. Right. -MSK From sm@elandsys.com Sun May 13 00:24: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 4D8BF21F86B8 for ; Sun, 13 May 2012 00:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTP5ufF-D93g for ; Sun, 13 May 2012 00:24:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5B621F85A5 for ; Sun, 13 May 2012 00:24:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.166]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4D7OCnw016101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 May 2012 00:24:23 -0700 (PDT) Message-Id: <6.2.5.6.2.20120512231503.098bcf38@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 13 May 2012 00:23:45 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <4FA80A46.5090808@tana.it> References: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 07:24:26 -0000 Hi Alessandro, At 10:45 07-05-2012, Alessandro Vesely wrote: > While the ability to start a session only characterizes the sample > (random parts of DNS Survey# 2) and possibly the testing host, that > small percentage of rejections seems to be stable under variations > of the sample and the helo identity. On answering a questionnaire > submitted to 70 mail admins, 14 of them (29%) said SPF can cause > rejection on their systems. However, rejection does not have to > occur at the MAIL command, and SPF results may just contribute to > message score. I didn't explain why I did not make use of the questionnaire and its results as I thought that it was obvious. It's not about your work not being good. If I am going to make use of the opinion of 70 mail admins, someone might ask whether "well deployed" means at least 70 people. It's not convincing to say that 14 not-so-random people are doing X. People who have a strong opinion about X might argue otherwise. It is better to consider the perspective of people who have not been involved in the WG. Regards, S. Moonesamy (as document shepherd) From hsantos@isdg.net Sun May 13 09:18: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 3C79821F8516 for ; Sun, 13 May 2012 09:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_20=-0.74, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah20iQ7ZByQM for ; Sun, 13 May 2012 09:18:43 -0700 (PDT) Received: from news.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 508E921F8507 for ; Sun, 13 May 2012 09:18:42 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2987; t=1336925913; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=0TQNr8MEz+nHBSdjowtCiEdoz7c=; b=s0oiCQRBrMeoz7AiPtP3 5WTU7+YIdwmcoc1a2Q93TXzsio00XtAvwufwZ0lrCw1MVOdfG85QuwxCdpJYazt+ x9M7uPe/6RIksAzLaDKcpCtN2XelEuFJZQCss6q+IVgMKdBmatxjm+jn6H+jZXt7 GjbcUzh7thyFajR5H4GjkDQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 13 May 2012 12:18:33 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1537743903.57055.1168; Sun, 13 May 2012 12:18:32 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2987; t=1336925894; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=UbkJn1Q aqljAJxDFdCG5jCLkkF7F+QNde8UfSbb8f8o=; b=SCnRH1DCT1Up5yYg7EfG3a1 exdWFXkyfWLaSA9TQYJsbchDE6Iw5hJ4/mmoifO3BO/SFwX3DqL+UerDHX1Z36fq lx2p2c+kMuxEpKIG9B1Z8trPhvD0FXCMx5bMb0juLBcDTjwphGIMH+cpUW9Nm2gP uKyrc1WhwNsqeCRxpKL8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 13 May 2012 12:18:14 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2136625644.7205.6496; Sun, 13 May 2012 12:18:12 -0400 Message-ID: <4FAFDED3.9040805@isdg.net> Date: Sun, 13 May 2012 12:18:27 -0400 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: <20120424204450.GR55967@mail.yitter.info> <4FA80A46.5090808@tana.it> <6.2.5.6.2.20120512231503.098bcf38@resistor.net> In-Reply-To: <6.2.5.6.2.20120512231503.098bcf38@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] -ALL is BAD, ~ALL is MAYBE BAD, ?ALL is I don't KNOW! X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 May 2012 16:18:44 -0000 S Moonesamy wrote: > Hi Alessandro, > At 10:45 07-05-2012, Alessandro Vesely wrote: >> While the ability to start a session only characterizes the sample >> (random parts of DNS Survey# 2) and possibly the testing host, that >> small percentage of rejections seems to be stable under variations >> of the sample and the helo identity. On answering a questionnaire >> submitted to 70 mail admins, 14 of them (29%) said SPF can cause >> rejection on their systems. However, rejection does not have to >> occur at the MAIL command, and SPF results may just contribute to >> message score. My Opinion: I don't get it why ADMINS will dispute and make life harder to ignore the -ALL declaration of what is considered "bad" within SPF when the domain owner is telling you! -ALL is BAD, not MAYBE BAD, not "I don't know". If the domain thinks it is MAYBE BAD, then that is what SOFTFAIL (~ALL) is for. If the domain is completely ignorant of its operations, then that is what the ?ALL declaration is far. But -ALL is BAD and the domain publisher knowns better than anyone else. I can understand how this conflicts with people who have this "Reputation" angle view of things. But when one ignores the strong -ALL declaration, all it does it add delayed, belated, complex, unknown, non-consistent, non-persistent, ADMIN level "Favorite SPAM tool" derivatives across different sites which at the end of the day all yield different belated results and/or scores when it SHOULD all yield the same ultimate result, it was BAD after all. Admins should consider the huge DNS overhead SPF presents at the system level and it is critical that this overhead is minimized and come with some level of a payoff, not come with complete indeterminate results even for the -ALL declaration. I will venture that domains that have a -ALL published have a near 100% REJECT-ON-FAIL expectation and a near 100% deployment at the applying it to others as well. In other words, you expect others will do the same your -ALL violations as you will do to their -ALL violations. If MARK-ON-FAIL is actually the recommended mode of operations, then unless this is strongly defined in SPF-BIS, I don't think I can continue to endorse SPF or support for a IETF proposed standard. There are many domains with -ALL, even with ietf.org: v=spf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 ip4:208.66.40.224/27 ip6:2001:1890:123a::0/56 ip6:2001:1890:1112:1::0/64 -all Its telling me what to expect for its MTAs. Why should anyone dispute what the DNS record publisher thought very hard of what it was doing here with a -ALL declaration? If he/she wasn't sure, it would of had a SOFTFAIL (~ALL) or NEUTRAL (?ALL). Just follow the protocol, its that simple. -ALL violations means BAD and the only real protocol problem is the undefined MARK-ON-FAIL deployment option. REJECT-ON-FAIL is well understood and simple definition, SMTP 550 rejection. -- HLS From sm@elandsys.com Sun May 13 11:25: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 A7D4721F8577 for ; Sun, 13 May 2012 11:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYj-ZRlAT3ff for ; Sun, 13 May 2012 11:25:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C4621F8539 for ; Sun, 13 May 2012 11:25:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.166]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4DIOpZY023640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 May 2012 11:25:01 -0700 (PDT) Message-Id: <6.2.5.6.2.20120513112253.0ade1218@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 13 May 2012 11:24:14 -0700 To: Alexey Melnikov From: S Moonesamy In-Reply-To: <4FAFF135.8030906@isode.com> References: <4FAFF135.8030906@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] APPSDIR review of draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 May 2012 18:25:03 -0000 Hi Alexey, At 10:36 13-05-2012, Alexey Melnikov wrote: >I have been selected as the Applications Area Directorate reviewer >for this draft (for background on appsdir, please see [snip] >Summary: This draft is ready for publication as an Informational document. Thanks for the review. Regards, S. Moonesamy From sm@elandsys.com Sun May 13 18:01:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDDE21F84DF for ; Sun, 13 May 2012 18:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkbtDDlIOjkg for ; Sun, 13 May 2012 18:01:55 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F5421F84DE for ; Sun, 13 May 2012 18:01:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.192]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4E11g3m022221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 May 2012 18:01:52 -0700 (PDT) Message-Id: <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 13 May 2012 17:46:14 -0700 To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= From: S Moonesamy In-Reply-To: <4FB05450.4000706@it.aoyama.ac.jp> References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 01:01:56 -0000 Hi Martin, Thanks for the feedback. I am forwarding it to SPFBIS. Regards, S. Moonesamy (as document shepherd) At 17:39 13-05-2012, Martin J. D=FCrst wrote: >Sorry to just use this review to piggyback a=20 >comment that I wanted to make for a while: > >It would be very good if the abstract could=20 >include a summary of the document, not (only) an=20 >introduction to the history (two paragraphs) and=20 >a meta-summary of what it contains (paragraph copied below). > > After six years, sufficient experience and evidence have been > collected that the experiments thus created can be considered > concluded. This document presents those findings. > >If I understand=20 >http://tools.ietf.org/html/draft-ietf-spfbis-experiment-09#section-6=20 >correctly, this could be done e.g. by changing the above paragraph to: > > After six years, sufficient experience and evidence have been > collected that the experiments thus created can be considered > concluded. This document finds that SPF has widespread > implementation and deployment, comparable to many standards > track protocols, but that there is an absence of significant > adoption for Sender ID. > >This is just a first try; I'd personally favor=20 >to cut down the history part of the abstract and=20 >add more details to the conclusion part if possible. From msk@cloudmark.com Sun May 13 22:46: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 076A321F859A for ; Sun, 13 May 2012 22:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf5HA8ieyE2W for ; Sun, 13 May 2012 22:45:59 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2456321F858E for ; Sun, 13 May 2012 22:45:59 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 9hln1j0030as01C01hlnz7; Sun, 13 May 2012 22:45:47 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=F7XVh9dN c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=1tjM5sM3BxMA:10 a=zutiEJmiVI4A:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=84feO4C1NpwbjwojlQoA:9 a=_nld8Ef3r1rDnUGcYhQA:7 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Sun, 13 May 2012 22:45:48 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09 Thread-Index: AQHNMS7Xw1v1/eqweEa3iIWFjPHUxpbI5xcAgAAB0QD//935gA== Date: Mon, 14 May 2012 05:45:47 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928120678@exch-mbx901.corp.cloudmark.com> References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120513174313.0af10eb8@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336974357; bh=9EXBtfgLuXukHtjN5MzQG9CqvzGSbt+fgLdeVic0Dg8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=FfpRcj9e9NVQfMWxzv1TkavFlrxXhlRCcvjEclNiLq6zZ4qYTWWX3XiwsMdJnbXyY vt+WNX06BVcsnzSdhfWzCpQlFOY6EBGtZGs1o06cTY1nlxbT+qt6JgwpXmBu0evfeV Qs2xZ4RTaom2R1hCp4rfSZV28oi6VG0umf4bTOOo= Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 05:46:00 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Sunday, May 13, 2012 5:46 PM > To: "Martin J. D=FCrst" > Cc: spfbis@ietf.org > Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-= experiment-09 >=20 > >It would be very good if the abstract could include a summary of the > >document, not (only) an introduction to the history (two paragraphs) > >and a meta-summary of what it contains (paragraph copied below). > > > > After six years, sufficient experience and evidence have been > > collected that the experiments thus created can be considered > > concluded. This document presents those findings. > > > >If I understand > >http://tools.ietf.org/html/draft-ietf-spfbis-experiment-09#section-6 > >correctly, this could be done e.g. by changing the above paragraph to: > > > > After six years, sufficient experience and evidence have been > > collected that the experiments thus created can be considered > > concluded. This document finds that SPF has widespread > > implementation and deployment, comparable to many standards > > track protocols, but that there is an absence of significant > > adoption for Sender ID. > > > >This is just a first try; I'd personally favor to cut down the history > >part of the abstract and add more details to the conclusion part if > >possible. I don't have any particular objection except that we shouldn't change it at= this point unless we get AD direction to do so. Consensus and all that. = :-) -MSK From hsantos@isdg.net Sun May 13 22:51: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 BB1D521F8595 for ; Sun, 13 May 2012 22:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=0.183, 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 pl2Sdje9xAUz for ; Sun, 13 May 2012 22:51:14 -0700 (PDT) Received: from mail.catinthebox.net (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9167121F858E for ; Sun, 13 May 2012 22:51:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1979; t=1336974665; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lVEEc8+jzuaBG60FjXNAT27N9g0=; b=tQ6ZTKEWy1lGsmDAvng5 bHu9SVga9aQu1eV/nGncEGlJk5ktwPzr/WNO/cjzfQEwzun8d/MtB7JTRs+JLJ+O K802FOrXk9Xvil0vmu/mVTe7lna8Btedomo/KZXfnLN4Q4GSnG8ewM/3xAdon08l sNljYcXu4+bhVbrilk1g3Fk= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 14 May 2012 01:51:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1586495198.4.736; Mon, 14 May 2012 01:51:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1979; t=1336974648; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=z3aqO6P iEEuLKjd/yAvhD1YG8pbgCzXTY7qsCmM/QDc=; b=a6JnN3rokmRngbbanod3DqH tBK4wmKqO5bZO46AtFPymSG7RYBP3v25gTb1b4pm4CNVjbrVIQrY9jBXFu9eD5Ec xGZbxk/ABL5cc2Tp0SNWf75fr7plJYpGHRkhGFsO2McFfbrjgv9Quj54K96KVl81 F01IdIV5xmHrZ5fF5ypw= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 14 May 2012 01:50:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2185380097.7330.3708; Mon, 14 May 2012 01:50:46 -0400 Message-ID: <4FB09D35.4000208@isdg.net> Date: Mon, 14 May 2012 01:50:45 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 05:51:15 -0000 S Moonesamy wrote: >> After six years, sufficient experience and evidence have been >> collected that the experiments thus created can be considered >> concluded. This document finds that SPF has widespread >> implementation and deployment, comparable to many standards >> track protocols, but that there is an absence of significant >> adoption for Sender ID. Maybe I never mastered my English, but I don't I follow this, nor does it match my understand on what a protocol should be. -1 The experimental questions and expressed concerns have not been adequately reviewed in this report. Its uses a "deployment" criteria which does not adequately address the original expectations questions and concerns and is not sufficient to judge anything, in my production and field experience. i.e. this report provides me no justification to "drop" SUBMITTER support, and I am concern that just an abstract written as above expressed the notion that is it "OK" to drop support. Even if one wishes to use a triage concept, just look at hotmail.com - it ignores RFC4408 -ALL publications and is appears to be just work with sender-id in its operation and with AUTH-RES reporting. Nothing SPF related is shown, not even Received-SPF. Until an adequate protocol technical review of both protocols as expected by the original IESG 2006 expectations and concerns, this report can not make any judgments on SENDER-ID, nor SUBMITTER. Far too many clients support these protocols. This SPFBIS effort can only promote SPF RFC4408 only to PS considerations and can do so without judging SENDER-ID which I see no adequate data to make any decision. The experiment which amounts to the integration issues of the protocols, in my view, is not concluded. For the record, we don't implement SENDER-ID, but we support SUBMITTER. The fact we continue to see significant usage of SUBMITTER is evidence that SENDER-ID is in play by many clients. -- HLS From duerst@it.aoyama.ac.jp Sun May 13 23:25: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 DE7D321F84EA for ; Sun, 13 May 2012 23:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.287 X-Spam-Level: X-Spam-Status: No, score=-99.287 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDGiPj7aF1ki for ; Sun, 13 May 2012 23:25:48 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 03A9C21F84A1 for ; Sun, 13 May 2012 23:25:47 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q4E6Pbtx006128 for ; Mon, 14 May 2012 15:25:37 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 123e_96aa_9ea17b18_9d8d_11e1_b71e_001d096c566a; Mon, 14 May 2012 15:25:36 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35375) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 14 May 2012 15:25:37 +0900 Message-ID: <4FB0A55C.6080302@it.aoyama.ac.jp> Date: Mon, 14 May 2012 15:25:32 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Hector Santos References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> <4FB09D35.4000208@isdg.net> In-Reply-To: <4FB09D35.4000208@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 13 May 2012 23:29:09 -0700 Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 06:25:49 -0000 Hello Hector, I'm sorry if I got the summary wrong. But what I wanted to stress is that there should be a summary of the conclusions of the document, not only a summary of the history that lead to this document. Regards, Martin. On 2012/05/14 14:50, Hector Santos wrote: > S Moonesamy wrote: > >>> After six years, sufficient experience and evidence have been >>> collected that the experiments thus created can be considered >>> concluded. This document finds that SPF has widespread >>> implementation and deployment, comparable to many standards >>> track protocols, but that there is an absence of significant >>> adoption for Sender ID. > > Maybe I never mastered my English, but I don't I follow this, nor does > it match my understand on what a protocol should be. > > -1 > > The experimental questions and expressed concerns have not been > adequately reviewed in this report. Its uses a "deployment" criteria > which does not adequately address the original expectations questions > and concerns and is not sufficient to judge anything, in my production > and field experience. i.e. this report provides me no justification to > "drop" SUBMITTER support, and I am concern that just an abstract written > as above expressed the notion that is it "OK" to drop support. > > Even if one wishes to use a triage concept, just look at hotmail.com - > it ignores RFC4408 -ALL publications and is appears to be just work with > sender-id in its operation and with AUTH-RES reporting. Nothing SPF > related is shown, not even Received-SPF. > > Until an adequate protocol technical review of both protocols as > expected by the original IESG 2006 expectations and concerns, this > report can not make any judgments on SENDER-ID, nor SUBMITTER. Far too > many clients support these protocols. > > This SPFBIS effort can only promote SPF RFC4408 only to PS > considerations and can do so without judging SENDER-ID which I see no > adequate data to make any decision. > > The experiment which amounts to the integration issues of the protocols, > in my view, is not concluded. > > For the record, we don't implement SENDER-ID, but we support SUBMITTER. > The fact we continue to see significant usage of SUBMITTER is evidence > that SENDER-ID is in play by many clients. > From sm@elandsys.com Mon May 14 00:17: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 150CF9E8011; Mon, 14 May 2012 00:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlUBLJdOJ1xU; Mon, 14 May 2012 00:17:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A02919E800C; Mon, 14 May 2012 00:17:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.151]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4E7HjjX021526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 00:17:55 -0700 (PDT) Message-Id: <6.2.5.6.2.20120514000059.09296d70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 14 May 2012 00:16:23 -0700 To: spfbis@ietf.org, apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E003928120678@exch-mbx901.corp.cl oudmark.com> References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> <9452079D1A51524AA5749AD23E003928120678@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 07:17:58 -0000 At 22:45 13-05-2012, Murray S. Kucherawy wrote: >I don't have any particular objection except that we shouldn't >change it at this point unless we get AD direction to do >so. Consensus and all that. :-) Ok. :-) I am copying this message to apps-discuss@ in case anyone from that mailing list wishes to follow up on the AppsDir review about draft-ietf-spfbis-experiment-09. The reviews (including Gen-ART and SecDir) and comments will be processed as part of the Last Call comments. Please note that the document shepherd write-up may be updated with the following text being added to the Working Group Summary: Some participants were unhappy with the document's incomplete coverage of the history of the four Experimental documents and the controversies surrounding them. In the end, working group consensus was for factual reporting. Historical completeness is not the goal of this document. Regards, S. Moonesamy (as document shepherd) From vesely@tana.it Mon May 14 07:05: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 8684B21F8472; Mon, 14 May 2012 07:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[AWL=0.118, 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 AAWVq5kKJOvp; Mon, 14 May 2012 07:05:08 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id BFC5E21F8470; Mon, 14 May 2012 07:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1337004306; bh=KaiNXQWFzIfeavNW+ugJtzaeacjhiwSaApoLhmoDP/4=; l=831; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=T26sUJt59mqanmS3ogOeM7cVVF2ijOSj4xjknfiHM6Uw7cfKQLm/ewaiyYh6moFtB Oq71VpB3n6ROi0bl7RIxoZIj9/u9CWYOaaOP3VHtPzdK+4TZ9YIJYXWmIwJy+AFlL2 GcU4WdMs4F29KiRx75r86F5nIuTHWIin5b3mdjrg= 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, 14 May 2012 16:05:05 +0200 id 00000000005DC035.000000004FB11111.00002B4F Message-ID: <4FB11111.9020400@tana.it> Date: Mon, 14 May 2012 16:05:05 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: S Moonesamy References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> <9452079D1A51524AA5749AD23E003928120678@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120514000059.09296d70@resistor.net> In-Reply-To: <6.2.5.6.2.20120514000059.09296d70@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, AppsAWG Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 14:05:08 -0000 Hi SM, On Mon 14/May/2012 15:32:20 +0200 S Moonesamy wrote: > > Please note that the document shepherd write-up may be updated with > the following text being added to the Working Group Summary: > > Some participants were unhappy with the document's incomplete > coverage of the history of the four Experimental documents and the > controversies surrounding them. In the end, working group consensus was > for factual reporting. Historical completeness is not the goal of this > document. For a fair update, I'd rather remove references to history, unless you refer to the history that lead to this document. I and others have indicated a (not extreme) discontent for not covering some deployment aspects, which cannot be considered historical albeit they used to be upheld more vigorously in historical times. From sm@elandsys.com Mon May 14 09:17: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 E7DAF21F85C9; Mon, 14 May 2012 09:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO8R2bcn51Ww; Mon, 14 May 2012 09:17:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 653E921F8532; Mon, 14 May 2012 09:17:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.151]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4EGHRo7017272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 09:17:37 -0700 (PDT) Message-Id: <6.2.5.6.2.20120514082120.0978fc68@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 14 May 2012 08:33:30 -0700 To: spfbis@ietf.org, apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <4FB11111.9020400@tana.it> References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> <9452079D1A51524AA5749AD23E003928120678@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120514000059.09296d70@resistor.net> <4FB11111.9020400@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 16:17:41 -0000 At 07:05 14-05-2012, Alessandro Vesely wrote: >For a fair update, I'd rather remove references to history, unless you >refer to the history that lead to this document. I and others have >indicated a (not extreme) discontent for not covering some deployment >aspects, which cannot be considered historical albeit they used to be >upheld more vigorously in historical times. It is up to the document shepherd, with the consent of the Responsible Area Director, to determine what goes into the write-up. Based on feedback from two persons, it is easier for me to drop the suggested change to the write-up. BTW, the "discontent" is not in the write-up as it was not apparent from the WGLC comments. I'll send a note to the Responsible Area Director about that. Regards, S. Moonesamy (as document shepherd) From msk@cloudmark.com Mon May 14 09:41: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 76BF121F87F7 for ; Mon, 14 May 2012 09:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhLeErPmd7-l for ; Mon, 14 May 2012 09:41:16 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id D27AA21F87E3 for ; Mon, 14 May 2012 09:41:16 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 9sgt1j0010as01C01sgtQm; Mon, 14 May 2012 09:40:53 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=F7XVh9dN c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=khHYZIhUkPoA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=VmPL5tqvNl5MO7UEisIA:9 a=ZVG_1pNywB0oVD0I6ecA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=WA2nMZcDe4mUTxAl:21 a=VRLbuXbK-lAnlgJU:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Mon, 14 May 2012 09:40:54 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: "Fair" text (was RE: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09) Thread-Index: AQHNMfBUpcvZtJxiMkmD4BnfUCPpPQ== Date: Mon, 14 May 2012 16:40:54 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928120E63@exch-mbx901.corp.cloudmark.com> References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> <9452079D1A51524AA5749AD23E003928120678@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120514000059.09296d70@resistor.net> <4FB11111.9020400@tana.it> <6.2.5.6.2.20120514082120.0978fc68@elandnews.com> In-Reply-To: <6.2.5.6.2.20120514082120.0978fc68@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1337013654; bh=smE1ign1kw08IoWzCgrYRJNKJi5dEhg3z5NPsASYpVg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=x4AAvGKHocdXFdoqr2e+LZowH6MVzM+jXLRG5mdalQw2uKMrQLMV5QK1iXKQqa2LW 1PgtyP0Pk94v5G0eCUKUklv9fmqh91cxDW1aup9AR9o0ClOM3FKdTZFXQ6lwj7erz6 BygePQklRUnAoBfdE0+fW0jA5nhrXSDWf/RBQEqg= Subject: [spfbis] "Fair" text (was RE: [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 16:41:17 -0000 [removing apps-discuss from this thread] > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Monday, May 14, 2012 8:34 AM > To: spfbis@ietf.org; apps-discuss@ietf.org > Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-= experiment-09 >=20 > At 07:05 14-05-2012, Alessandro Vesely wrote: > >For a fair update, I'd rather remove references to history, unless you > >refer to the history that lead to this document. I and others have > >indicated a (not extreme) discontent for not covering some deployment > >aspects, which cannot be considered historical albeit they used to be > >upheld more vigorously in historical times. >=20 > It is up to the document shepherd, with the consent of the Responsible > Area Director, to determine what goes into the write-up. Based on > feedback from two persons, it is easier for me to drop the suggested > change to the write-up. >=20 > BTW, the "discontent" is not in the write-up as it was not apparent > from the WGLC comments. I'll send a note to the Responsible Area > Director about that. I don't see the distinction between "history" and "the history that led to = this document". Please elaborate. I also have yet to see any valid argument for why the discussed "deployment= aspects" have anything to do with answering the basic question, "Which one= have people deployed?", which is the focus of this document. A treatise on the differences between SPF and Sender ID in technical terms = might be interesting, but it is not part of our charter. Maybe someone sho= uld start that as an individual submission, even if only to have a focus fo= r all of this energy people seem to have. Finally, I don't agree with the claim that either the document or the PROTO= are not fair representations of either the facts or working group consensu= s. -MSK From barryleiba.mailing.lists@gmail.com Mon May 14 10: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 13EE721F8732 for ; Mon, 14 May 2012 10:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.024, 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 tyB6xxdVPirD for ; Mon, 14 May 2012 10:37:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3255421F8723 for ; Mon, 14 May 2012 10:37:34 -0700 (PDT) Received: by lagv3 with SMTP id v3so2559089lag.31 for ; Mon, 14 May 2012 10:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=8aFXqUPtV0FYPlu743fe9RzOPLwClPznSViWWVP0V6c=; b=Hp0GKW7J7frQZI+UGibXBrn/DD60XXOXvgMA/mSXKm3Qw+MmDxpNhD51Y4sEZjJsSt KNNyp30+z2vUKmVGSv+yXDnV0SM6POFeBBfil/2unL+XXeZrHlAn/Ir421c0f5QhD2vX bicPe6kjqyiweJ7FiZIxtzyFW68XokHhOwAHvwA9rWtQpFEVv/YOMwWq0g9TUxkYlcDO //1PJbw3n/bRaJDRhsU7h2k4K2im+teLVY8BI6sqgTjn+1lhoQ5H+zMwDNdaoMAYec34 rQN9aUx20ArzSkt0kL8xQGfPMMXaCYljWWNXgRIxi6bqfrG5SSmCUnje8Na1MgFBBgjt cF4w== MIME-Version: 1.0 Received: by 10.112.37.71 with SMTP id w7mr3915031lbj.2.1337017053170; Mon, 14 May 2012 10:37:33 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Mon, 14 May 2012 10:37:33 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120514082120.0978fc68@elandnews.com> References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> <9452079D1A51524AA5749AD23E003928120678@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120514000059.09296d70@resistor.net> <4FB11111.9020400@tana.it> <6.2.5.6.2.20120514082120.0978fc68@elandnews.com> Date: Mon, 14 May 2012 13:37:33 -0400 X-Google-Sender-Auth: ETGvypHC7rfRpXnHoWOr4ikcjFE Message-ID: From: Barry Leiba To: spfbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 17:37:35 -0000 (Just to spfbis; no need to include apps-discuss on this.) SM says... > Please note that the document shepherd write-up may be updated with the > following text being added to the Working Group Summary: > > =A0Some participants were unhappy with the document's incomplete > =A0coverage of the history of the four Experimental documents and the > =A0controversies surrounding them. =A0In the end, working group consensus= was > =A0for factual reporting. =A0Historical completeness is not the goal of t= his > =A0document. Just to be clear about where this came from: It was I who suggested that SM add this to the writeup, in order to make it clear to the IESG that the WG did have a discussion about how much of the history to include here, and that there was not complete agreement with the result. I made the suggestion to make sure the other ADs are aware of this, and that IESG Evaluation doesn't re-hash some of what was already discussed here. If other ADs want to bring the issue up *with* that knowledge, that's for them to decide. Remember a couple of things: - The purpose of the shepherd writeup is to make sure that the document has been properly reviewed and to provide information to the IESG for use in IESG Evaluation. - The document shepherd writeup is not subject to working group consensus. Quite the opposite, it's the place for the shepherd to communicate with the ADs, and SHOULD include information that the shepherd thinks is important, even or especially if the WG isn't in agreement. My suggestion to SM about adding that text was just a suggestion, and he may (and will) do as he pleases with it. Barry From vesely@tana.it Mon May 14 12:11: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 C55C821F889B for ; Mon, 14 May 2012 12:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.605 X-Spam-Level: X-Spam-Status: No, score=-4.605 tagged_above=-999 required=5 tests=[AWL=0.114, 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 U64UmGMOQNFr for ; Mon, 14 May 2012 12:11:15 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E628F21F889D for ; Mon, 14 May 2012 12:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1337022664; bh=VbvWT3rWZJMy6qtZJMXsZ1xJtzH4+A95QiwbTLxb8vc=; l=2789; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Z73WqFKhj+MhN2M3PkBtQ0A+4LvTtnZRRJYpNrBLeGx4UOPBGF5rFJvD34JnKHnmK OCR6se7mzha/687vybqi2UPuHVJptVNazTxCHTZhvmLPB1EXyhm+sX1BjICQjAUGta NP+5TnwTsseaF2h5hNuBA7FS+HtfhO/ZfLTiTo1g= 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, 14 May 2012 21:11:04 +0200 id 00000000005DC045.000000004FB158C8.00007AD1 Message-ID: <4FB158C8.5060405@tana.it> Date: Mon, 14 May 2012 21:11:04 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> <9452079D1A51524AA5749AD23E003928120678@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120514000059.09296d70@resistor.net> <4FB11111.9020400@tana.it> <6.2.5.6.2.20120514082120.0978fc68@elandnews.com> <9452079D1A51524AA5749AD23E003928120E63@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928120E63@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] "Fair" text (was RE: [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 19:11:28 -0000 On Mon 14/May/2012 19:55:15 +0200 Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of S Moonesamy >> At 07:05 14-05-2012, Alessandro Vesely wrote: > >>> For a fair update, I'd rather remove references to history, unless you >>> refer to the history that lead to this document. I and others have >>> indicated a (not extreme) discontent for not covering some deployment >>> aspects, which cannot be considered historical albeit they used to be >>> upheld more vigorously in historical times. >> >> It is up to the document shepherd, with the consent of the Responsible >> Area Director, to determine what goes into the write-up. Based on >> feedback from two persons, it is easier for me to drop the suggested >> change to the write-up. >> >> BTW, the "discontent" is not in the write-up as it was not apparent >> from the WGLC comments. I'll send a note to the Responsible Area >> Director about that. I guess the discontent was not apparent because it was not extreme. Accordingly, it doesn't need to go in the write-up. I only suggested a slightly shorter but more comprehensive wording. Namely: Some participants were unhappy with the document's incomplete coverage of the four Experimental documents and the controversies surrounding them. In the end, working group consensus was for factual reporting. Completeness is not the goal of this document. Of course, that suggestion is useless in case the write-up won't be updated. > I also have yet to see any valid argument for why the discussed > "deployment aspects" have anything to do with answering the basic > question, "Which one have people deployed?", which is the focus of > this document. There is a possible misunderstanding: Since completeness is not a goal, it is legitimate to focus on a specific topic, and other aspects can be left out. However, readers may think that completeness was a goal, since it's not clearly stated otherwise. See my proposed rewording of the third paragraph of the Introduction in http://www.ietf.org/mail-archive/web/spfbis/current/msg01538.html (WGLC was over already, so I was proposing to /read/ that paragraph that way, not to actually rewrite it.) I don't think WG documents have to overcautiously prevent any possible misinterpretation. A document can omit some aspects without explaining why, and without implying that omitted aspects are historic. > Finally, I don't agree with the claim that either the document or > the PROTO are not fair representations of either the facts or > working group consensus. I claimed that describing the discontent as being related to just historical questions would not be fair. As long as the Working Group Summary is not updated, or is updated correctly, I'm fine with it. From sm@elandsys.com Mon May 14 15:18:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D4521F88EE for ; Mon, 14 May 2012 15:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttkWNaznUnpK for ; Mon, 14 May 2012 15:18:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6723E21F88EB for ; Mon, 14 May 2012 15:18:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.177]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4EMIgHd002612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 May 2012 15:18:52 -0700 (PDT) Message-Id: <6.2.5.6.2.20120514122457.09d8e5b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 14 May 2012 13:06:14 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4FB158C8.5060405@tana.it> References: <4FAFF135.8030906@isode.com> <4FB05450.4000706@it.aoyama.ac.jp> <6.2.5.6.2.20120513174313.0af10eb8@elandnews.com> <9452079D1A51524AA5749AD23E003928120678@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120514000059.09296d70@resistor.net> <4FB11111.9020400@tana.it> <6.2.5.6.2.20120514082120.0978fc68@elandnews.com> <9452079D1A51524AA5749AD23E003928120E63@exch-mbx901.corp.cloudmark.com> <4FB158C8.5060405@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] "Fair" text (was RE: [apps-discuss] APPSDIR review of draft-ietf-spfbis-experiment-09) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 May 2012 22:18:59 -0000 Barry Leiba, who happens to be one of the Applications Area Directors, explained how document shepherding works at http://www.ietf.org/mail-archive/web/spfbis/current/msg01552.html It is entirely appropriate to blame the document shepherd of draft-ietf-spfbis-experiment for not being fair as it will be a document shepherd decision. It is not appropriate to blame anyone else for what will end up as the Working Group Summary. Regards, S. Moonesamy (as document shepherd) From iesg-secretary@ietf.org Sat May 26 05: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 C566821F85F0; Sat, 26 May 2012 05:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTWB9HfFDOAN; Sat, 26 May 2012 05:44:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427F621F85E6; Sat, 26 May 2012 05:44:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120526124417.28073.97552.idtracker@ietfa.amsl.com> Date: Sat, 26 May 2012 05:44:17 -0700 Cc: spfbis@ietf.org Subject: [spfbis] Last Call: (Resolution of The SPF and Sender ID Experiments) to Informational RFC X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 12:44:18 -0000 The IESG has received a request from the SPF Update WG (spfbis) to consider the following document: - 'Resolution of The SPF and Sender ID Experiments' as Informational RFC 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-06-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols. Both of these protocols enable one to publish via the Domain Name System a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents (RFC4405, RFC4406, RFC4407, and RFC4408) with Experimental status, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/ballot/ No IPR declarations have been submitted directly on this I-D. From msk@cloudmark.com Tue May 29 12:04: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 A24D111E80FB for ; Tue, 29 May 2012 12:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVTJI+iiRDKu for ; Tue, 29 May 2012 12:04:25 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id E840F11E80D6 for ; Tue, 29 May 2012 12:04:24 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id Fv4P1j0010as01C01v4PPc; Tue, 29 May 2012 12:04:23 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=dpJZ+ic4 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=Nd0-PibDfu8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=b6nfwRhkAAAA:8 a=48vgC7mUAAAA:8 a=GDThVHyN_hZ64527sycA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 29 May 2012 12:04:23 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" , IETF Discuss Thread-Topic: [spfbis] Last Call: (Resolution of The SPF and Sender ID Experiments) to Informational RFC Thread-Index: AQHNOz1INsCQPVSMfUCCwx/dWdUXtZbhI4RA Date: Tue, 29 May 2012 19:04:22 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392813826C@exch-mbx901.corp.cloudmark.com> References: <20120526124417.28073.97552.idtracker@ietfa.amsl.com> In-Reply-To: <20120526124417.28073.97552.idtracker@ietfa.amsl.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1338318263; bh=lJxMbq64HAARGGVhcr5jpNpHAi04yj9jfFotQ4pgl8c=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=un6Kp4Up/me6fZRMgrmqthml9Ahzj79fi6g/Q16DODxeWDGxvj643UgDm4MBe7ULQ ETP0TcQhVViZv7yrOcdJPz90dPiI7mD4vTXJt/eBs3r0EnuY0OVqkfyQ6dF1vuHr4p GASlGVtaTmTbqVJbqhJ+Z21/OmeN39J3PMm1WLZE= Subject: Re: [spfbis] Last Call: (Resolution of The SPF and Sender ID Experiments) to Informational RFC X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 May 2012 19:04:25 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of The IESG > Sent: Saturday, May 26, 2012 5:44 AM > To: IETF-Announce > Cc: spfbis@ietf.org > Subject: [spfbis] Last Call: (Resol= ution of The SPF and Sender ID Experiments) to Informational RFC >=20 > The IESG has received a request from the SPF Update WG (spfbis) to > consider the following document: > - 'Resolution of The SPF and Sender ID Experiments' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-06-09. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. In my quest to ensure I'm never done with a document I'm editing, I reviewe= d this myself and found a couple of things I plan to change after Last Call= completes. They are either grammar corrections or removal of redundant te= xt, and aren't substantive, so I don't expect they're controversial. So ju= st to head off other reviewers' comments: 1) The Introduction's first and second paragraph contain substantially iden= tical text. This will be trimmed. 2) In the Analysis section, I believe conclusions 4 and 6 are redundant. I= propose to remove 6. 3) There are a few places where I should've used "that" instead of "which". -MSK