From ajs@anvilwalrusden.com Thu Nov 1 07:04:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CAA21F8CAB for ; Thu, 1 Nov 2012 07:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1D-A1DYNWTq for ; Thu, 1 Nov 2012 07:04:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D94B921F8CA9 for ; Thu, 1 Nov 2012 07:04:20 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 84B508A031 for ; Thu, 1 Nov 2012 14:04:18 +0000 (UTC) Date: Thu, 1 Nov 2012 10:04:36 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20121101140435.GB64654@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] [nomcom-chair@ietf.org: CORRECTION: Help the NomCom] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:04:21 -0000 Dear colleagues, The NomCom is looking for feedback. Please send some. ----- Forwarded message from NomCom Chair ----- Date: Thu, 01 Nov 2012 05:17:22 -0700 From: NomCom Chair To: Working Group Chairs Subject: CORRECTION: Help the NomCom List-Id: Working Group Chairs I sent a message several hours ago requesting that you help and make your working group aware that the NomCom is looking for input from the community. This message had a minor error. The NomCom needs to receive community input by November 11, 2012. The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org ----- End forwarded message ----- -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Fri Nov 2 12:41:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91021F0C80 for ; Fri, 2 Nov 2012 12:41:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QecOElivXV1U for ; Fri, 2 Nov 2012 12:41:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4D51F0C71 for ; Fri, 2 Nov 2012 12:41:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.33]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA2JfbrQ006882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Nov 2012 12:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351885308; bh=x1V4lIqfIoFb3Ch/PDCY4wJhtFywKzr6peKvDlYDYw8=; h=Date:To:From:Subject:Cc; b=cF32TcRBMiMZ4UgUTvbKs4Yf9sib8Gor6vuFvoFaPXPlcMcIVM6/+N57nnwX2UxPd 6OyMZSbZDQ4JI9X+59qx1zNnQpFUBRK/PrJMwtJQjoonZ9/U0SgAFjBesHf0ldPPzs IvZsRPaSv6icp82K6Vr1tx2s0lCnT/q+0fazMXrg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1351885308; i=@elandsys.com; bh=x1V4lIqfIoFb3Ch/PDCY4wJhtFywKzr6peKvDlYDYw8=; h=Date:To:From:Subject:Cc; b=Z4grFj19cCiq7dPwqFGPh5LneF0MMDefPKZdp8XXH9TrdPK4bQUySxXuXmo2X8bm0 2Lvau2+1QENRFBDJU2WsMn3Wj09paIZup6dAQ12DVHJlCei3QEx+0FnBsb0QazCVSn suvz1d9UHAjn2y1RYDbdCX7T/ffogIkHkVIrNl9U= Message-Id: <6.2.5.6.2.20121102121645.0b2552f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 02 Nov 2012 12:36:01 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Remote participation for IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Nov 2012 19:41:51 -0000 Hello, The SPFBIS WG will be meeting in room 209 on Thursday from 17:30 to 18:30 EST (22:30 - 23:30 UTC). The agenda for the SPFBIS session is at https://datatracker.ietf.org/meeting/85/agenda/spfbis/ The meeting materials (slides, etc.) can be downloaded from https://datatracker.ietf.org/meeting/85/materials.html The audio stream will be accessible at http://ietf85streaming.dnsalias.net/ietf/ietf851.m3u You can join the spfbis@jabber.ietf.org Jabber room to participate remotely or use Meetecho ( http://www.meetecho.com/ietf85/spfbis ). It is recommended that remote participants test the remote audio stream, or Meetecho if you will be using it, before the SPFBIS session. We need a minute taker and a Jabber scribe for the session. Please volunteer by sending an email to spfbis-chairs@tools.ietf.org. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Fri Nov 2 12:45: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 810641F0C8F for ; Fri, 2 Nov 2012 12:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGM1mtC3VdjP for ; Fri, 2 Nov 2012 12:45:54 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 591121F0C6A for ; Fri, 2 Nov 2012 12:45:54 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 86B05D04088; Fri, 2 Nov 2012 14:45:51 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1351885551; bh=oGp6IWwG4Vk11j1KANN7NqtreF/vu2lr4yyhSNrw5mA=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Mes+lY4ZFdIQKNr4ZL01/WxoqWpS4l+ISP8NHTvIJ1PNcpGO5NPDOE6REnS7tW2Pr 95AuSHu7u1LqWPmL8YNhsqwHn4P1KglLEe2/32TDcX1Q28MB1YpWkMGqzfOzlVtEKY gB4CI1WAZ582kDwJ0eenYHjEUzmaayIEdeEJ5vtE= Received: from [IPV6:2600:1003:b016:b6b4:9d0e:34f2:f740:ab95] (unknown [IPv6:2600:1003:b016:b6b4:9d0e:34f2:f740:ab95]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DA1C2D04058; Fri, 2 Nov 2012 14:45:47 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20121030115138.0957f450@resistor.net> References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 02 Nov 2012 13:24:04 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:45:55 -0000 S Moonesamy wrote: >At 13:37 17-09-2012, Murray S. Kucherawy wrote: >>On reviewing the -07 draft I observed that the flow could be improved, >>and that's thus one of the things I tried to do in the proposal. > >Could the WG let me know whether the following is an adequate summary >of the discussion about the proposal? Please note that this message >is not about debating about the views that were expressed. There >should be ample time during the face-to-face (Jabber for remote >participants) meeting for that discussion. > >Murray Kucherawy mentioned that the specification has however become >somewhat bloated with documentation of nuance and other text that has >nothing to do with interoperability, security, or other topics >critical to defining a protocol and enabling interoperability. Much >of that bloat may well have been there in RFC4408 itself, and the >working group has focused on developing it rather than cleaning it up. >[1] > >John Leslie mentioned that "we're going 'round in circles largely >because we have differing opinions on what is protocol and what is >operational advice." [2] William Leibzon noted that that such >re-organization is likely to go against original intent of SPF. The >intent was to have it published as a standard document and if part of >it is split into "informational" type document that is very different >especially given that SPF was published as experimental standard >already [3]. Dave Crocker posted the following questions [4]: > > 1. Is it generally 'legal' to reorganize a specification document >during an effort > like spfbis and specifically legal for spfbis? > > 2. Does the existing organization have some issues? > >3. Does the proposed reorganization increase clarity or otherwise >improve the > document? > >Scott Kitterman mentioned that the current document (4408) is the >basis for multiple, interoperable implementations [5]. That was only part of my argument. Not only has RFC4408 been successful in supporting development of multiple interoperable implementations (demonstrating that the current organization is a successful one and there is inherent risk in choosing an alternative), I think the primary technical audience for 4408bis will be maintainers of existing implementations.and so the existing structure will be more familiar and a new one will be more likely to cause confusion to them (even if the proposed reorganization might be more clear to a new reader (which I don't think is true of the proposal). Scott K William >Leibzon mentioned that the material has been used and understood by >countless developers [6]. Alessandro Vesely commented that Version >-07 was still organized according to RFC 4408, with such >idiosyncrasies as putting macros after Received-SPF rather than along >with mechanisms and modifiers where they pertain and separating >filter handling from the result computation is a needed cleanup that >this reorganization opens nicely [7]. Arthur Thisell commented that >deciding the order of the macro and received-spf headers is not >important [8]. > >Andrew Sullivan tried to clarify the goals of the discussion about >the proposed reorganization [9]. > >Regards, >S. Moonesamy > >1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html >2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html >3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html >4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html >5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html >6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html >7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html >8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html >9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From john.kelley@teamaol.com Fri Nov 2 12:49: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 2E83611E80BF for ; Fri, 2 Nov 2012 12:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz8t+PeeHW+f for ; Fri, 2 Nov 2012 12:49:24 -0700 (PDT) Received: from imr-mb01.mx.aol.com (imr-mb01.mx.aol.com [64.12.207.164]) by ietfa.amsl.com (Postfix) with ESMTP id 6B82F11E80D3 for ; Fri, 2 Nov 2012 12:49:24 -0700 (PDT) Received: from AOLDTCMEI31.ad.aol.aoltw.net (aoldtcmei31.office.aol.com [10.180.121.109]) by imr-mb01.mx.aol.com (Outbound Mail Relay) with ESMTP id B56D51C0001A2 for ; Fri, 2 Nov 2012 15:49:23 -0400 (EDT) Received: from [10.181.184.27] (172.17.8.193) by AOLDTCMEI31.ad.aol.aoltw.net (10.180.121.109) with Microsoft SMTP Server (TLS) id 14.2.318.1; Fri, 2 Nov 2012 15:49:23 -0400 Message-ID: <509423C2.1040602@teamaol.com> Date: Fri, 2 Nov 2012 15:49:22 -0400 From: John Kelley User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> In-Reply-To: <6.2.5.6.2.20121030115138.0957f450@resistor.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.8.193] Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:49:25 -0000 Apologies in advance, I am a newbie with an agenda. As a fairly neutral observer, I think if both documents are "standards track ready" then neither needs to be preferred over the other. I have read other standards edited by Murray and his reorganization certainly makes sense to me, but that is not to say that Scott's latest edit is unacceptable. I think moving SPF forward is important, I think that other work that relies upon SPF or even uses of technologies pioneered in the SPF (or Sender-ID?) spec(s) may be waiting for this document to work its way thru the process to become a standard. So this is a poor answer to your question, SM. I do believe that you have summarized the discussion very well. John Kelley AOL On 10/30/2012 3:29 PM, S Moonesamy wrote: > At 13:37 17-09-2012, Murray S. Kucherawy wrote: >> On reviewing the -07 draft I observed that the flow could be improved, >> and that's thus one of the things I tried to do in the proposal. > > Could the WG let me know whether the following is an adequate summary > of the discussion about the proposal? Please note that this message > is not about debating about the views that were expressed. There > should be ample time during the face-to-face (Jabber for remote > participants) meeting for that discussion. > > Murray Kucherawy mentioned that the specification has however become > somewhat bloated with documentation of nuance and other text that has > nothing to do with interoperability, security, or other topics > critical to defining a protocol and enabling interoperability. Much > of that bloat may well have been there in RFC4408 itself, and the > working group has focused on developing it rather than cleaning it up. > [1] > > John Leslie mentioned that "we're going 'round in circles largely > because we have differing opinions on what is protocol and what is > operational advice." [2] William Leibzon noted that that such > re-organization is likely to go against original intent of SPF. The > intent was to have it published as a standard document and if part of > it is split into "informational" type document that is very different > especially given that SPF was published as experimental standard > already [3]. Dave Crocker posted the following questions [4]: > > 1. Is it generally 'legal' to reorganize a specification document > during an effort > like spfbis and specifically legal for spfbis? > > 2. Does the existing organization have some issues? > > 3. Does the proposed reorganization increase clarity or otherwise > improve the > document? > > Scott Kitterman mentioned that the current document (4408) is the > basis for multiple, interoperable implementations [5]. William > Leibzon mentioned that the material has been used and understood by > countless developers [6]. Alessandro Vesely commented that Version > -07 was still organized according to RFC 4408, with such > idiosyncrasies as putting macros after Received-SPF rather than along > with mechanisms and modifiers where they pertain and separating filter > handling from the result computation is a needed cleanup that this > reorganization opens nicely [7]. Arthur Thisell commented that > deciding the order of the macro and received-spf headers is not > important [8]. > > Andrew Sullivan tried to clarify the goals of the discussion about the > proposed reorganization [9]. > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html > 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html > 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html > 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html > 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html > 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html > 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html > 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html > 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From dhc@dcrocker.net Fri Nov 2 12:56:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B17811E80F0 for ; Fri, 2 Nov 2012 12:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCFk2MuykdK0 for ; Fri, 2 Nov 2012 12:56:25 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 68A3311E80ED for ; Fri, 2 Nov 2012 12:56:25 -0700 (PDT) Received: from [192.168.1.9] (adsl-67-127-56-94.dsl.pltn13.pacbell.net [67.127.56.94]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id qA2JuMKV006909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Nov 2012 12:56:22 -0700 Message-ID: <5094255F.40202@dcrocker.net> Date: Fri, 02 Nov 2012 12:56:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Scott Kitterman References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 02 Nov 2012 12:56:23 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:56:26 -0000 On 11/2/2012 10:24 AM, Scott Kitterman wrote: > S Moonesamy wrote: >> Scott Kitterman mentioned that the current document (4408) is the >> basis for multiple, interoperable implementations [5]. > > That was only part of my argument. Not only has RFC4408 been > successful in supporting development of multiple interoperable > implementations (demonstrating that the current organization is a > successful one and there is inherent risk in choosing an > alternative), I think the primary technical audience for 4408bis will > be maintainers of existing implementations. If that were certain, there would be little point in pursuing standardization. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From steven.m.jones@gmail.com Fri Nov 2 14:18: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 67C4211E80DE for ; Fri, 2 Nov 2012 14:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZcC-2V-Y-+x for ; Fri, 2 Nov 2012 14:18:46 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCA511E80D2 for ; Fri, 2 Nov 2012 14:18:46 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1972619wey.31 for ; Fri, 02 Nov 2012 14:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SngFtlSYVDMqvB99/dXK+TxnB0rrwKV7XqWNIpiuIKg=; b=l3gC5vG3blrJmsbH/NrxcWaWpuAq3PG4k/Et1aP/RFgnA9gSkwg5M/ySKn2E3gw07X 3cjgVVDCPwnpE07gZOunjtBWMDQXsFymYOjOrC4iaEgksxzyXhtPFff3ALvEGLeH84kM HGAXrxvdwtRLv0Pul8SHM/HjeFckcDPXzDkqh58qONrN+AhLKpO6Zi/KXjVBAVeJSDyw ZGRvBcHR7ftd1wQaXZJe0DujrEsTE3RSIgMJECdLr4MaZLaZxZ/bGou3hEAToBcREdK/ vhQOHZxYKl7hbN4lNcwgk9Yl+ZEoDI1AuIqc3arREP4gx92byintXw4cuwlAXC34bYNa SY7A== MIME-Version: 1.0 Received: by 10.180.82.104 with SMTP id h8mr4241965wiy.19.1351891125794; Fri, 02 Nov 2012 14:18:45 -0700 (PDT) Received: by 10.227.193.135 with HTTP; Fri, 2 Nov 2012 14:18:45 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20121102121645.0b2552f0@elandnews.com> References: <6.2.5.6.2.20121102121645.0b2552f0@elandnews.com> Date: Fri, 2 Nov 2012 14:18:45 -0700 Message-ID: From: Steve Jones To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d044280d853f8e804cd89aef3 Cc: spfbis@ietf.org Subject: Re: [spfbis] Remote participation for IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Nov 2012 21:18:47 -0000 --f46d044280d853f8e804cd89aef3 Content-Type: text/plain; charset=ISO-8859-1 Thank you for sharing the remote participation details, and for confirming the meeting time. I had previously been looking at the agenda object you referenced, which says Wednesday the 7th, and wondering which date was correct... --f46d044280d853f8e804cd89aef3 Content-Type: text/html; charset=ISO-8859-1 Thank you for sharing the remote participation details, and for confirming the meeting time. I had previously been looking at the agenda object you referenced, which says Wednesday the 7th, and wondering which date was correct...
--f46d044280d853f8e804cd89aef3-- From sm@elandsys.com Fri Nov 2 15:05:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4412B1F0C92 for ; Fri, 2 Nov 2012 15:05:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9y-3Fkrr+2H for ; Fri, 2 Nov 2012 15:05: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 7A8001F0C90 for ; Fri, 2 Nov 2012 15:05:46 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.33]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA2M5T6o013359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 15:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351893943; bh=9/llRxyLRhRgATvxG+z3x2tmajODZN6cvAuI/a2qMPs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kykslIet+V6AO1Cbi826SaRfsdOWTKf7eWs71M2llqoh5rVvPUcDAc1Mu+HJ656ps BXyqOSAh215I7qTReWguiuHZ9fp032+W6xRuUMbOl+UifsSM1hRIoNcwc4DR4EFE7g uwUqdh1ZDI8HP71kiaO85HHnBqWZwOG9bfzvULN0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1351893943; i=@elandsys.com; bh=9/llRxyLRhRgATvxG+z3x2tmajODZN6cvAuI/a2qMPs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fm+z751fdHOchJ8/QE2P93LHdvYsGY7ZgWYbzjShCDrViPb4UdG85yb/xterQchY1 ep41bLbMDIxccj+lz3VVdY0BkgYTIlCyGXPggh5tITJULe/KzN/1mM6ArlRgqJfCMu OrVmfgVSAQ064Ex7fLYFWMNrPjEquRjWDuPo3p40= Message-Id: <6.2.5.6.2.20121102144854.099f0d28@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 02 Nov 2012 14:59:45 -0700 To: Steve Jones From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20121102121645.0b2552f0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Remote participation for IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Nov 2012 22:05:47 -0000 Hi Steve, At 14:18 02-11-2012, Steve Jones wrote: >Thank you for sharing the remote participation details, and for >confirming the meeting time. I had previously been looking at the >agenda object you referenced, which says Wednesday the 7th, and >wondering which date was correct... Andrew Sullivan posted a message about the session being rescheduled for Thursday 8 November, 2012 [1]. I forgot to update the agenda at https://datatracker.ietf.org/meeting/85/agenda/spfbis/ Apologies for causing the confusion. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02954.html From jtrentadams@gmail.com Fri Nov 2 15:43: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 A641D11E80F8 for ; Fri, 2 Nov 2012 15:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH34vUtszM0v for ; Fri, 2 Nov 2012 15:43:42 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D456811E80F5 for ; Fri, 2 Nov 2012 15:43:41 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6449784iec.31 for ; Fri, 02 Nov 2012 15:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=AFDZGG5rWbzxmQSyOZBSwufdV5VCYjx986GidRfRcYc=; b=e/GuabF2QbawjO/+ovmlf+prAUv19oyclz2HH6x1yWsk9xHzE63GIh4oKwMfpWmoEm lrkuxgCz1mcbuDYy1P9o4amE1Zf0BBWvlb24uWpB0tNmDWZdZ73eGnnwSI+OawZ6AuIy fgHCjearkLw9QK0eNdElux9U/zcN3B3z4HfUKH5NyfeHejCoW6VXVrlWQcqrvhuDJFM6 BUNDDqWhuPAdQoabxKmam9vygvPhsKaIDMl+m1cCHniMf7Fc6dNIbuYSjLB0BRrInRal ZqgnkeBdwnHDnTf5B/8DWP5B1GPXsgqFPfSITaR+QoBoJWPz0KxdRKtti6qeAmiNi9wG HHRw== Received: by 10.50.46.199 with SMTP id x7mr3251107igm.19.1351896221533; Fri, 02 Nov 2012 15:43:41 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPS id 10sm174268ign.5.2012.11.02.15.43.40 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 15:43:41 -0700 (PDT) Message-ID: <50944C9C.2050201@gmail.com> Date: Fri, 02 Nov 2012 16:43:40 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [spfbis] Focusing on reaching Standards Track X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Nov 2012 22:43:42 -0000 It's great to see this work making it's way toward an important milestone, and I wanted to toss in my voice of support. Given the existing, and growing, reliance on SPF by the email anti-abuse ecosystem, I think it's clear the experiment succeeded in proving the merit and utility. The challenge is in how to build on this success. I looked to the charter for guidance, and at this point it suggests we restrict our energies to fine-tuning and to focus on the major goal of moving onto the standards track. Going into Atlanta, it seems that we all share the goal of striking the right balance necessary for the specification to qualify as an IETF standard. It's obvious we don't all agree on the specifics for the fine-tuning (eg. "the great Macros debate" come to mind), but it helps that we're all on the same page regarding the next big step. And that's the lens through which I ask whether the -07 version of the document or the proposed re-organization get's us closer to acceptance by the IESG as graduating from the "experiment" phase. Either way, we should evaluate them in the context of which will advance the work in a positive direction. Looking forward to the conversations in Atlanta (albeit remotely). - Trent -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From spf2@kitterman.com Sat Nov 3 12:09:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E699121F9CCD for ; Sat, 3 Nov 2012 12:09:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAGdKRlPb82X for ; Sat, 3 Nov 2012 12:09:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 395A821F9CC0 for ; Sat, 3 Nov 2012 12:09:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5BF7620E40CD; Sat, 3 Nov 2012 15:09:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1351969768; bh=eCRPMt76qSc6djnHZqgiSi0LVTKg61BpnA/S8k8zkB0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VQ2D5R9+3uUQpYgAsNaxZ/fgOP73nQhCdqxRte7x+gUP0ZI8KLTma3yvISvAHz4hQ Azje6RL38Ry6KFFN10nmJAvASjcxS55ZGbPIFZq299CvjbTKS96Qqz5c7f/2fvvckO Hj3PPsh7Wa4glr82mxX4EMZtGLzknRrXOoAySvuQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2DE7620E4062; Sat, 3 Nov 2012 15:09:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 03 Nov 2012 15:09:27 -0400 Message-ID: <2175978.MUpSqq7Nk2@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-17-generic; KDE/4.9.2; i686; ; ) In-Reply-To: <5094255F.40202@dcrocker.net> References: <5094255F.40202@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 19:09:30 -0000 On Friday, November 02, 2012 12:56:15 PM Dave Crocker wrote: > On 11/2/2012 10:24 AM, Scott Kitterman wrote: > > S Moonesamy wrote: > >> Scott Kitterman mentioned that the current document (4408) is the > >> basis for multiple, interoperable implementations [5]. > > > > That was only part of my argument. Not only has RFC4408 been > > successful in supporting development of multiple interoperable > > implementations (demonstrating that the current organization is a > > successful one and there is inherent risk in choosing an > > alternative), I think the primary technical audience for 4408bis will > > be maintainers of existing implementations. > > If that were certain, there would be little point in pursuing > standardization. I think one of the reasons to pursue standardization is to make it easier for other work to build on SPF. While there's already one approved downref to RFC 4408 in a standards track RFC, that was done at least in part predicated on the assumption that this working group was coming soon to produce a standards track document. Even if no new implementations are done, there is value associated with documenting the ~existing protocol as a stable, standardized basis for other work. Scott K From hsantos@isdg.net Sun Nov 4 11: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 DB85621F867B for ; Sun, 4 Nov 2012 11:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AewJENlB8lTW for ; Sun, 4 Nov 2012 11:12:12 -0800 (PST) Received: from secure.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5BF21F865E for ; Sun, 4 Nov 2012 11:12:10 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1105; t=1352056318; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=vHWw8IankcLcnD+8UByrzpHRcTs=; b=dHdWrxBPqaghSaq+8vf+ piFHF2qtJ8CJdNijo1nxf99TLk5aAysW3RqQDnNtieMCQm3Up8djvItq3qEkQvOS UmkebKbESy+70GJjpt3Phc/G9OqMg7JsWm3DnBCpPSINJmtI8Z5lqCmQ9lZLWBEx ALnEra5Pot6f+7HCPiL7328= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 04 Nov 2012 14:11:58 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3783075658.5477.5480; Sun, 04 Nov 2012 14:11:57 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1105; t=1352055812; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=06mk0pT 0SQn9ZcinQcjDnmikE5noE9MFZRp9VUY9utQ=; b=2/dFqZkQdv9HNI/cy2gYU4U c30ZZXKQHfl9FXzaXqUvf2X9zxnoyD0NKXVlEDFCwROy0uYdaWfVgdEqwiRsScQU rNjcYElmgEn7ffs5iw+/7uiVCehY6iCc1SIkl2U9bM2+kxxq6zgnorqC49jLP1Ru 7JzgLzC22qY639V6MisM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 04 Nov 2012 14:03:32 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 86675647.7.4800; Sun, 04 Nov 2012 14:03:31 -0500 Message-ID: <5096BD72.1040003@isdg.net> Date: Sun, 04 Nov 2012 14:09:38 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <5094255F.40202@dcrocker.net> <2175978.MUpSqq7Nk2@scott-latitude-e6320> In-Reply-To: <2175978.MUpSqq7Nk2@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:12:13 -0000 Scott Kitterman wrote: > > I think one of the reasons to pursue standardization is to make it easier for > other work to build on SPF. While there's already one approved downref to RFC > 4408 in a standards track RFC, that was done at least in part predicated on > the assumption that this working group was coming soon to produce a standards > track document. Even if no new implementations are done, there is value > associated with documenting the ~existing protocol as a stable, standardized > basis for other work. +1, but precisely among the top concerns I have is where other external, non-WG work items, perhaps standard track, Informational or BCP track RFCs can alter and define what theRFC4408bis framework, process model and design takes. If RFC ABC (current or pending) says X, and 4408 says Y, than does X override Y or alters Y or finally defines what may have been to some an ambiguous Y? I believe this has occurred already. I think it will help if we can focus on a pure SPF first for protocol standardization that has no external protocol influence. -- HLS From superuser@gmail.com Sun Nov 4 12:15: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 BAA7A21F882E for ; Sun, 4 Nov 2012 12:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxL2gwdx7SNp for ; Sun, 4 Nov 2012 12:15:19 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBBF21F8828 for ; Sun, 4 Nov 2012 12:15:19 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so3947871lbo.31 for ; Sun, 04 Nov 2012 12:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cmL2t5SLc7/YTBXV2ilOYpoPazKWPY65yZRTQQk94Kk=; b=wIukKPxIUDpx2/27KG+uTZxkWOecq6tLd8jGnroiZ7uwdeiN5gN4r3dAWTGBlMqGoV sZMyq8vXMq3jcT01xS8auvm6xOqDLpv0KwRVzk2MQEr1kXcci9S9TFVMXe1mI/6Qzcsa V8f+ZwSvp9u7HQVfPtY4krEemVSF2kGC2J/cXs4kHs1zknrqUWvDNopmV8UE5PJM/Z2J 0IGAL6vAc6wU7WOu50gvX9VhexyeBVgZsJuJbvcWdXrd/kdjuEoNWQlF0wYGNI/royVP s5R3qL2kZjLKeKGJi95bBxEBV/fwjUIlRM4yNV1wdMlhavZM8uu1zV0KnVS7tPIkRXiH aQbw== MIME-Version: 1.0 Received: by 10.112.37.41 with SMTP id v9mr3149376lbj.97.1352060118165; Sun, 04 Nov 2012 12:15:18 -0800 (PST) Received: by 10.112.83.232 with HTTP; Sun, 4 Nov 2012 12:15:17 -0800 (PST) In-Reply-To: References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> Date: Sun, 4 Nov 2012 15:15:17 -0500 Message-ID: From: "Murray S. Kucherawy" To: Dotzero Content-Type: multipart/alternative; boundary=e0cb4efe322a0ee9e904cdb107ad Cc: "spfbis@ietf.org" , S Moonesamy Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:15:20 -0000 --e0cb4efe322a0ee9e904cdb107ad Content-Type: text/plain; charset=ISO-8859-1 I concur that SM's is an adequate summary. I agree with the reasons Scott stated for pursuing standardization in general, which is why I started the chartering process in the first place. I also agree (obviously) that the quality of the document, and what I believe is the likely result of IESG Evaluation of a proposed standard, is a concern and therefore the basis for my proposal. I have trouble believing that the proposed new structure introduces difficulty for one skilled in the art, or that including a (typical these days) summary-of-changes appendix is an unreasonable compromise. I think the questions Dave and Alessandro pose in response to the summary are entirely on the mark and need to be addressed. Finally, this has certainly been an informative exercise in drafting charters. -MSK On Tue, Oct 30, 2012 at 3:42 PM, Dotzero wrote: > I think this is an adequate summary of the discussion but would point > out that the requirements for a successful standards track document > are more stringent than publishing an experimental document. > > Mike > > On Tue, Oct 30, 2012 at 3:29 PM, S Moonesamy wrote: > > At 13:37 17-09-2012, Murray S. Kucherawy wrote: > >> > >> On reviewing the -07 draft I observed that the flow could be improved, > >> and that's thus one of the things I tried to do in the proposal. > > > > > > Could the WG let me know whether the following is an adequate summary of > the > > discussion about the proposal? Please note that this message is not > about > > debating about the views that were expressed. There should be ample time > > during the face-to-face (Jabber for remote participants) meeting for that > > discussion. > > > > Murray Kucherawy mentioned that the specification has however become > > somewhat bloated with documentation of nuance and other text that has > > nothing to do with interoperability, security, or other topics critical > to > > defining a protocol and enabling interoperability. Much of that bloat > may > > well have been there in RFC4408 itself, and the working group has > focused on > > developing it rather than cleaning it up. [1] > > > > John Leslie mentioned that "we're going 'round in circles largely > because we > > have differing opinions on what is protocol and what is operational > advice." > > [2] William Leibzon noted that that such re-organization is likely to go > > against original intent of SPF. The intent was to have it published as a > > standard document and if part of it is split into "informational" type > > document that is very different especially given that SPF was published > as > > experimental standard already [3]. Dave Crocker posted the following > > questions [4]: > > > > > > 1. Is it generally 'legal' to reorganize a specification document > during an > > effort > > like spfbis and specifically legal for spfbis? > > > > 2. Does the existing organization have some issues? > > > > 3. Does the proposed reorganization increase clarity or otherwise > improve > > the > > document? > > > > Scott Kitterman mentioned that the current document (4408) is the basis > for > > multiple, interoperable implementations [5]. William Leibzon mentioned > that > > the material has been used and understood by countless developers [6]. > > Alessandro Vesely commented that Version -07 was still organized > according > > to RFC 4408, with such idiosyncrasies as putting macros after > Received-SPF > > rather than along with mechanisms and modifiers where they pertain and > > separating filter handling from the result computation is a needed > cleanup > > that this reorganization opens nicely [7]. Arthur Thisell commented that > > deciding the order of the macro and received-spf headers is not important > > [8]. > > > > Andrew Sullivan tried to clarify the goals of the discussion about the > > proposed reorganization [9]. > > > > Regards, > > S. Moonesamy > > > > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html > > 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html > > 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html > > 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html > > 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html > > 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html > > 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html > > 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html > > 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --e0cb4efe322a0ee9e904cdb107ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I concur that SM's is an adequate summary.

I agree with the reas= ons Scott stated for pursuing standardization in general, which is why I st= arted the chartering process in the first place.

I also agree (obvio= usly) that the quality of the document, and what I believe is the likely re= sult of IESG Evaluation of a proposed standard, is a concern and therefore = the basis for my proposal.

I have trouble believing that the proposed new structure introduces dif= ficulty for one skilled in the art, or that including a (typical these days= ) summary-of-changes appendix is an unreasonable compromise.

I think= the questions Dave and Alessandro pose in response to the summary are enti= rely on the mark and need to be addressed.

Finally, this has certainly been an informative exercise in drafting ch= arters.

-MSK


On Tue, Oct 30, 2012 at 3:42 PM, Dotzero <dotzero@gmail.com&= gt; wrote:
I think this is an adequate summary of the d= iscussion but would point
out that the requirements for a successful standards track document
are more stringent than publishing an experimental document.

Mike

On Tue, Oct 30, 2012 at 3:29 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:
> At 13:37 17-09-2012, Murray S. Kucherawy wrote:
>>
>> On reviewing the -07 draft I observed that the flow could be impro= ved,
>> and that's thus one of the things I tried to do in the proposa= l.
>
>
> Could the WG let me know whether the following is an adequate summary = of the
> discussion about the proposal? =A0Please note that this message is not= about
> debating about the views that were expressed. =A0There should be ample= time
> during the face-to-face (Jabber for remote participants) meeting for t= hat
> discussion.
>
> Murray Kucherawy mentioned that the specification has however become > somewhat bloated with documentation of nuance and other text that has<= br> > nothing to do with interoperability, security, or other topics critica= l to
> defining a protocol and enabling interoperability. =A0Much of that blo= at may
> well have been there in RFC4408 itself, and the working group has focu= sed on
> developing it rather than cleaning it up. [1]
>
> John Leslie mentioned that "we're going 'round in circles= largely because we
> have differing opinions on what is protocol and what is operational ad= vice."
> [2] =A0William Leibzon noted that that such re-organization is likely = to go
> against original intent of SPF. =A0The intent was to have it published= as a
> standard document and if part of it is split into "informational&= quot; type
> document that is very different especially given that SPF was publishe= d as
> experimental standard already [3]. =A0Dave Crocker posted the followin= g
> questions [4]:
>
>
> =A01. Is it generally 'legal' to reorganize a specification do= cument during an
> effort
> =A0 =A0 like spfbis and specifically legal for spfbis?
>
> =A02. Does the existing organization have some issues?
>
> =A03. Does the proposed reorganization increase clarity or otherwise i= mprove
> the
> =A0 =A0 document?
>
> Scott Kitterman mentioned that the current document (4408) is the basi= s for
> multiple, interoperable implementations [5]. =A0William Leibzon mentio= ned that
> the material has been used and understood by countless developers [6].=
> Alessandro Vesely commented that Version -07 was still organized accor= ding
> to RFC 4408, with such idiosyncrasies as putting macros after Received= -SPF
> rather than along with mechanisms and modifiers where they pertain and=
> separating filter handling from the result computation is a needed cle= anup
> that this reorganization opens nicely [7]. =A0Arthur Thisell commented= that
> deciding the order of the macro and received-spf headers is not import= ant
> [8].
>
> Andrew Sullivan tried to clarify the goals of the discussion about the=
> proposed reorganization [9].
>
> Regards,
> S. Moonesamy
>
> 1. http://www.ietf.org/mail-archive/web/spfbis/cu= rrent/msg02872.html
> 2. http://www.ietf.org/mail-archive/web/spfbis/cu= rrent/msg02874.html
> 3. http://www.ietf.org/mail-archive/web/spfbis/cu= rrent/msg02878.html
> 4. http://www.ietf.org/mail-archive/web/spfbis/cu= rrent/msg02881.html
> 5. http://www.ietf.org/mail-archive/web/spfbis/cu= rrent/msg02883.html
> 6. http://www.ietf.org/mail-archive/web/spfbis/cu= rrent/msg02884.html
> 7. http://www.ietf.org/mail-archive/web/spfbis/cu= rrent/msg02893.html
> 8. http://www.ietf.org/mail-archive/web/spfbis/cu= rrent/msg02895.html
> 9. http://www.ietf.org/mail-archive/web/spfbis/cu= rrent/msg02912.html
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--e0cb4efe322a0ee9e904cdb107ad-- From hsantos@isdg.net Mon Nov 5 08:33: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 E140821F8467 for ; Mon, 5 Nov 2012 08:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjJeIIrCYTWd for ; Mon, 5 Nov 2012 08:33:12 -0800 (PST) Received: from pop3.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2080621F8457 for ; Mon, 5 Nov 2012 08:33:09 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=973; t=1352133185; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=j1SxSy+O8Yu43vU8sGACHbBdJOA=; b=h5mAGaxyqs3IparsRcYp U9N+XIz9Z1IaZvXH7oidzCqaZw8IgMYSa2P9+1KQNfG/fDD/8jWYr3sWbj6/ycGC CUWNgAUXctNjr15iqYKRnhQzp2QgaNbeut6ygq4N/SftDuA1vk6jxBVsrCqAz1AS nKEzEMHuYHGMO76rT76e4Os= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 05 Nov 2012 11:33:05 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3859941828.3.3388; Mon, 05 Nov 2012 11:33:04 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=973; t=1352132866; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=Y3hGHBy UD8crIjpb3Wg7+j1+LM1x42TWwbj+HyJ5K2M=; b=GE783Rf5GgjSiA2B39/m63D JcOoYQ0mW/TDlJeQNGPKAraKfll6W1gZR2kwIYh+e6XSpX2QUmXxB1jeJPk6M+j1 r/jcdJwC1x+cVDprzI2GBG8UHGby2spnDjDDiz18OhJ+q3mZrN5M8CMURyFCGTHr aIxxhhz54lZ0n2QkAwq4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 05 Nov 2012 11:27:46 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 163730272.7.3872; Mon, 05 Nov 2012 11:27:46 -0500 Message-ID: <5097EA98.9050002@isdg.net> Date: Mon, 05 Nov 2012 11:34:32 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: "spfbis@ietf.org" References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:33:13 -0000 Murray S. Kucherawy wrote: > I also agree (obviously) that the quality of the document, and what I > believe is the likely result of IESG Evaluation of a proposed standard, is > a concern and therefore the basis for my proposal. Can you outline what specific areas the IESG review will focus on or look for that may be lacking in RFC4408 or the revised BIS draft at this point>? Not enough RFC 2119 wording? Too ambiguous? > I have trouble believing that the proposed new structure introduces > difficulty for one skilled in the art, or that including a (typical these > days) summary-of-changes appendix is an unreasonable compromise. From my SE perspective, the issue is what exactly is being proposed? What is new or different? What will the "reorganization" bring? Is it required for obtaining IESG, IETG and community passage? What exactly is the problem that the IESG reviewers will recognized and we failed to address here? -- HLS From tim@eudaemon.net Wed Nov 7 06:58: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 E0AD021F8BAE for ; Wed, 7 Nov 2012 06:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db6apmQIU7nm for ; Wed, 7 Nov 2012 06:58:05 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id F281421F8B98 for ; Wed, 7 Nov 2012 06:58:04 -0800 (PST) Received: from [10.0.1.3] (adsl-98-94-248-15.ard.bellsouth.net [98.94.248.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 1C9FACB46; Wed, 7 Nov 2012 09:58:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Draegen In-Reply-To: Date: Wed, 7 Nov 2012 09:58:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <99A762FC-0BE6-4463-89D0-006DD24DD7FD@eudaemon.net> References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> To: Scott Kitterman X-Mailer: Apple Mail (2.1499) Cc: spfbis@ietf.org Subject: [spfbis] audience for 4408bis (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:58:06 -0000 On Nov 2, 2012, at 1:24 PM, Scott Kitterman wrote: > I think the primary technical audience for 4408bis will be maintainers = of existing implementations.and so the existing structure will be more = familiar and a new one will be more likely to cause confusion to them = (even if the proposed reorganization might be more clear to a new reader = (which I don't think is true of the proposal). Thanks Scott, you've helped me get my bearings in terms of eventual = audience for 4408bis. While catching up on SPFbis list traffic in prep for the face-to-face = meeting, I've come to understand that there is a large consumer base of = 4408bis that will likely never find themselves contributing to the IETF. = Who are they? I teach email authentication classes for folks that want to get up to = speed on how to "do authentication". IMO, the largest audience for = 4408bis will be people that want to understand how the protocol works = and as a reference to people that want to write decent SPF records. In terms of audience, in second place I'd put new developers (who will = look at 4408bis, 4408, and reference existing implementations). In last = place I'd put down everyone that is already involved in the SPF space. =3D- Tim= From vesely@tana.it Wed Nov 7 07:24:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D5C21F8BE2 for ; Wed, 7 Nov 2012 07:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB-561TGc+24 for ; Wed, 7 Nov 2012 07:24:51 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1038D21F8BD2 for ; Wed, 7 Nov 2012 07:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352301883; bh=KBoZmC0KOORm3vDsTed/SK6utz1f6mGgJYseotqMt8E=; l=644; h=Date:From:To:References:In-Reply-To; b=Jui+q+2V0vAw9xuB5Xx9jwRZx5uVg4/Fv2cQovCANxY0NaWD5CYpZnBSSevsefNWG REqr3TB1WnE/faWorYRy5IBp6wT+xjDG46OsKTrgg3nCoy9mY5mLKaS/sT+pV/kknc J5FT97y4sQQg7rdijMjQVHUmbO2kn/jOhLZ3Ylyo= Received: from [130.129.23.14] (dhcp-170e.meeting.ietf.org [130.129.23.14]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 07 Nov 2012 16:24:41 +0100 id 00000000005DC035.00000000509A7D3A.000054A5 Message-ID: <509A7D36.4060208@tana.it> Date: Wed, 07 Nov 2012 10:24:38 -0500 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> <99A762FC-0BE6-4463-89D0-006DD24DD7FD@eudaemon.net> In-Reply-To: <99A762FC-0BE6-4463-89D0-006DD24DD7FD@eudaemon.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] audience for 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:24:52 -0000 On Wed 07/Nov/2012 09:58:13 -0500 Tim Draegen wrote: > On Nov 2, 2012, at 1:24 PM, Scott Kitterman wrote: >> I think the primary technical audience for 4408bis will be >> maintainers of existing implementations. > > IMO, the largest audience for 4408bis will be people that want to > understand how the protocol works and as a reference to people that > want to write decent SPF records. I'd agree with Tim. However, I think the audience we'll get is a function of --among other variables-- what we write on that I-D. IME, mail admins found it painful to adopt SPF when it came out. I hope we'll do better. From tim@eudaemon.net Wed Nov 7 08:23: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 109B421F8800 for ; Wed, 7 Nov 2012 08:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIN3otRzvZ8V for ; Wed, 7 Nov 2012 08:23:15 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6735921F8B6C for ; Wed, 7 Nov 2012 08:23:14 -0800 (PST) Received: from [10.0.1.3] (adsl-98-94-248-15.ard.bellsouth.net [98.94.248.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 040A4CB46 for ; Wed, 7 Nov 2012 11:23:43 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Draegen In-Reply-To: <20120917220040.GB59832@crankycanuck.ca> Date: Wed, 7 Nov 2012 11:23:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9E6AD41B-B5CF-4842-8CF7-DF98E16834C5@eudaemon.net> References: <20120917220040.GB59832@crankycanuck.ca> To: "spfbis@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:23:16 -0000 On Sep 17, 2012, at 6:00 PM, Andrew Sullivan = wrote: > Before going further, I'd like for participants in this debate to = state > where they stand with respect to the above arguments, and to clarify > what trade-offs they think are acceptable as a result. Andrew et al, my aim is help produce a Standards-track draft that meets = the needs of people outside of the IETF in as little time as possible, = and no less. In response to 3 arguments for proposed reorganization: - As an implementor I can wade through 4408 with a yellow high-lighter = and sticky-notes until I get it. - As someone responsible for teaching others, I would greatly appreciate = adoption of Murray's proposed reorganization. - As a rare participant in IETF process, I agree with the stance of "we = should clean it up now and not later".. pushing through an editorially = unchanged 4408 seems to me to miss the point of why we're all here = (regardless of Chartering). In response to counter-arguments: - After review, Murray's proposed reorganization does not change the = protocol, it only makes it easier for non-experts to understand. = Perhaps oddly, I don't see the counter-arguments as such. I see the = "move SPF from the experimental to the standards track" to mean "prepare = the document so that it behaves like other standards track documents", = which Murray's proposed reorganization gets us closer to. - I do not find the the "accidental protocol changes" argument = compelling, due to the passion, expertise, and character-by-character = review that all participants in this WG give to proposed changes. - Similarly, the need-for-side-by-side-comparison argument is lost on = me. Optimizing for easy-review is not on my list of concerns. I = understand that there is risk whenever change is introduced, but the = time to make change is when everyone is paying attention, which is now. Trade-offs for an acceptable result: - Commit to not changing the protocol; warts, macros, and all. - Recognize that the current draft does too much and interleaves too = many topics to make it a proper IETF standard. The risk of the IESG = kicking the draft back is one thing, but we might as well go all in to = meet perceived IESG requirements AND produce a doc that technology = generalists can read w/o importing the entire history of SPF into their = heads. - Everyone must commit to trying to "sneak in" at least 1 change. This = will keep everyone on their toes. Finally, I'd like to submit that the existing draft has done an = excellent job of producing interoperable technology within the community = of email anti-abuse developers. In the move from Experimental to = standards-track, though, the community will get larger, and therefore = the specification needs to be editorially easier to ingest. See y'all tomorrow, =3D- Tim From jtrentadams@gmail.com Wed Nov 7 08:28:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFE121F8B4D for ; Wed, 7 Nov 2012 08:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9hhbXhKyTjW for ; Wed, 7 Nov 2012 08:28:39 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5C621F8B0D for ; Wed, 7 Nov 2012 08:28:39 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so1392298iak.31 for ; Wed, 07 Nov 2012 08:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=3QuKk7j3vWddKzfbJzPLN5nsq3mJSKXk5RA1kAVabZw=; b=f0LqiTY313P5Jy7o+NpTe/uejKDMPopPkFa69Znneq3/v/hLrZn7jBbW6Mb82qJXfd JN4jhy8D5Klv5bKPpIpZKdJ97X1FPP2Fcbm6YyWy4IoszhM1LCalzFV6JpYfvqQYN/nr y97wK4MM4vqQStJ8n2Y8iAzp11bKCOCl688h0Fz1N+iej4t/XYE2FuVFApqK2vcAgj9X Acbb7JxEMTZzKeIhiyze2UeIqAFc9e15VEZ2ZAiCaVygwBDQSqNZvRxWaIcTh0gx6E+Y 3XDK1t+Y1pIryEA94lHjnr8pGLJwafKmA2IsRCKfvtrkW2oTCq0wvrxyafnd47kZ/4Yg Ypwg== Received: by 10.42.68.203 with SMTP id y11mr4591258ici.26.1352305718835; Wed, 07 Nov 2012 08:28:38 -0800 (PST) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPS id vq4sm2243196igb.10.2012.11.07.08.28.37 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 08:28:38 -0800 (PST) Message-ID: <509A8C35.10600@gmail.com> Date: Wed, 07 Nov 2012 09:28:37 -0700 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120917220040.GB59832@crankycanuck.ca> <9E6AD41B-B5CF-4842-8CF7-DF98E16834C5@eudaemon.net> In-Reply-To: <9E6AD41B-B5CF-4842-8CF7-DF98E16834C5@eudaemon.net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Tim Draegen Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:28:40 -0000 I found myself reading Tim's response and nodding the entire way through. +1 from me. - Trent On 11/7/12 9:23 AM, Tim Draegen wrote: > On Sep 17, 2012, at 6:00 PM, Andrew Sullivan wrote: >> Before going further, I'd like for participants in this debate to state >> where they stand with respect to the above arguments, and to clarify >> what trade-offs they think are acceptable as a result. > Andrew et al, my aim is help produce a Standards-track draft that meets the needs of people outside of the IETF in as little time as possible, and no less. > > In response to 3 arguments for proposed reorganization: > > - As an implementor I can wade through 4408 with a yellow high-lighter and sticky-notes until I get it. > - As someone responsible for teaching others, I would greatly appreciate adoption of Murray's proposed reorganization. > - As a rare participant in IETF process, I agree with the stance of "we should clean it up now and not later".. pushing through an editorially unchanged 4408 seems to me to miss the point of why we're all here (regardless of Chartering). > > In response to counter-arguments: > - After review, Murray's proposed reorganization does not change the protocol, it only makes it easier for non-experts to understand. Perhaps oddly, I don't see the counter-arguments as such. I see the "move SPF from the experimental to the standards track" to mean "prepare the document so that it behaves like other standards track documents", which Murray's proposed reorganization gets us closer to. > - I do not find the the "accidental protocol changes" argument compelling, due to the passion, expertise, and character-by-character review that all participants in this WG give to proposed changes. > - Similarly, the need-for-side-by-side-comparison argument is lost on me. Optimizing for easy-review is not on my list of concerns. I understand that there is risk whenever change is introduced, but the time to make change is when everyone is paying attention, which is now. > > Trade-offs for an acceptable result: > - Commit to not changing the protocol; warts, macros, and all. > - Recognize that the current draft does too much and interleaves too many topics to make it a proper IETF standard. The risk of the IESG kicking the draft back is one thing, but we might as well go all in to meet perceived IESG requirements AND produce a doc that technology generalists can read w/o importing the entire history of SPF into their heads. > - Everyone must commit to trying to "sneak in" at least 1 change. This will keep everyone on their toes. > > Finally, I'd like to submit that the existing draft has done an excellent job of producing interoperable technology within the community of email anti-abuse developers. In the move from Experimental to standards-track, though, the community will get larger, and therefore the specification needs to be editorially easier to ingest. > > See y'all tomorrow, > =- Tim > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From hsantos@isdg.net Wed Nov 7 08:52:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2221F8C83 for ; Wed, 7 Nov 2012 08:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLqkZy9OK6XG for ; Wed, 7 Nov 2012 08:52:37 -0800 (PST) Received: from winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 977BD21F8C6A for ; Wed, 7 Nov 2012 08:52:33 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3862; t=1352307143; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=FJoKKoDj2vAUfwfEPFKanMm8Ti0=; b=iJnHAON2pwRtUnmSvPun gYvzXUiOm8u7zUbtSLhwtfMHHNeAfv0wub+uD1tgB+lwXhmYdFSxst04/BS68NiO kBz3uUm0eSPqcsJLl9LAwhhlUepZK7hNROLZEg8GpW8TyS7JnVbVJHin5D+E9Nh8 F6SuT6+pVaT+GKbiQ1I57+Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 07 Nov 2012 11:52:23 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4033897326.394.3140; Wed, 07 Nov 2012 11:52:22 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3862; t=1352306817; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ESbmpRe l4n9doFJ4fizl07hC4gMF6ziTi+KMwXlcEAg=; b=is5SHBokHNuX34o8PYM3aQC FXsAfNEiWDfpDJ5nNTp4PJ5LuxIcu/9ecN3keBirk4synj9Pjm8SOIKXmg94Ap5E Yd9wCIMtFI43oeik3UoM/R90HCbMU7WtkRqVbDxRc6hUeEj/QfG898/BVu+GuwcY 3hx9guWS+Uk/JT3fcccA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 07 Nov 2012 11:46:57 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 337681147.9.6160; Wed, 07 Nov 2012 11:46:56 -0500 Message-ID: <509A91F4.6050707@isdg.net> Date: Wed, 07 Nov 2012 11:53:08 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tim Draegen References: <20120917220040.GB59832@crankycanuck.ca> <9E6AD41B-B5CF-4842-8CF7-DF98E16834C5@eudaemon.net> In-Reply-To: <9E6AD41B-B5CF-4842-8CF7-DF98E16834C5@eudaemon.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:52:39 -0000 I have a hard time understanding the focus and goal here for reorganization. Please state the main purpose and goal to adopt Murray's proposed changes. What is the benefits? In my engineering and product development opinion, the proposed changes does alter the scope of the SPF framework (relatively to how we have been using it for 9+years) and we are living proof that if we follow the proposed changes, it will be a very costly design change endeavor to the point we would have to consider the pros and cons and most likely ignore the new considerations emphasized in the proposed changes. I don't think this can't be "fixed" but it will does required accepting the policies already established in SPF and how these are functional specifications are translated into standard technical specifications fitting into the SMTP state machine as a 5321 technology, not 5322 technology. If we are focusing on 5322 material, then the scope is changing. -- HLS Tim Draegen wrote: > On Sep 17, 2012, at 6:00 PM, Andrew Sullivan wrote: >> Before going further, I'd like for participants in this debate to state >> where they stand with respect to the above arguments, and to clarify >> what trade-offs they think are acceptable as a result. > > Andrew et al, my aim is help produce a Standards-track draft that meets the needs of people outside of the IETF in as little time as possible, and no less. > > In response to 3 arguments for proposed reorganization: > > - As an implementor I can wade through 4408 with a yellow high-lighter and sticky-notes until I get it. > - As someone responsible for teaching others, I would greatly appreciate adoption of Murray's proposed reorganization. > - As a rare participant in IETF process, I agree with the stance of "we should clean it up now and not later".. pushing through an editorially unchanged 4408 seems to me to miss the point of why we're all here (regardless of Chartering). > > In response to counter-arguments: > - After review, Murray's proposed reorganization does not change the protocol, it only makes it easier for non-experts to understand. Perhaps oddly, I don't see the counter-arguments as such. I see the "move SPF from the experimental to the standards track" to mean "prepare the document so that it behaves like other standards track documents", which Murray's proposed reorganization gets us closer to. > - I do not find the the "accidental protocol changes" argument compelling, due to the passion, expertise, and character-by-character review that all participants in this WG give to proposed changes. > - Similarly, the need-for-side-by-side-comparison argument is lost on me. Optimizing for easy-review is not on my list of concerns. I understand that there is risk whenever change is introduced, but the time to make change is when everyone is paying attention, which is now. > > Trade-offs for an acceptable result: > - Commit to not changing the protocol; warts, macros, and all. > - Recognize that the current draft does too much and interleaves too many topics to make it a proper IETF standard. The risk of the IESG kicking the draft back is one thing, but we might as well go all in to meet perceived IESG requirements AND produce a doc that technology generalists can read w/o importing the entire history of SPF into their heads. > - Everyone must commit to trying to "sneak in" at least 1 change. This will keep everyone on their toes. > > Finally, I'd like to submit that the existing draft has done an excellent job of producing interoperable technology within the community of email anti-abuse developers. In the move from Experimental to standards-track, though, the community will get larger, and therefore the specification needs to be editorially easier to ingest. > > See y'all tomorrow, > =- Tim > From john.kelley@teamaol.com Wed Nov 7 08:53:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA71621F8C5C for ; Wed, 7 Nov 2012 08:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ideZpV2-bKT3 for ; Wed, 7 Nov 2012 08:53:37 -0800 (PST) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3D82A21F8C57 for ; Wed, 7 Nov 2012 08:53:37 -0800 (PST) Received: from AOLDTCMEI31.ad.aol.aoltw.net (aoldtcmei31.office.aol.com [10.180.121.109]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id qA7GrYAj023624 for ; Wed, 7 Nov 2012 11:53:34 -0500 Received: from [10.181.184.27] (172.17.8.193) by AOLDTCMEI31.ad.aol.aoltw.net (10.180.121.109) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 7 Nov 2012 11:53:34 -0500 Message-ID: <509A920D.6040402@teamaol.com> Date: Wed, 7 Nov 2012 11:53:33 -0500 From: John Kelley User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: References: <20120917220040.GB59832@crankycanuck.ca> <9E6AD41B-B5CF-4842-8CF7-DF98E16834C5@eudaemon.net> <509A8C35.10600@gmail.com> In-Reply-To: <509A8C35.10600@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.8.193] Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:53:38 -0000 I agree with Trent. Tim's arguments were compelling. +1 John Kelley On 11/7/2012 11:28 AM, J. Trent Adams wrote: > I found myself reading Tim's response and nodding the entire way through. > > +1 from me. > > - Trent > > > On 11/7/12 9:23 AM, Tim Draegen wrote: >> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan wrote: >>> Before going further, I'd like for participants in this debate to state >>> where they stand with respect to the above arguments, and to clarify >>> what trade-offs they think are acceptable as a result. >> Andrew et al, my aim is help produce a Standards-track draft that meets the needs of people outside of the IETF in as little time as possible, and no less. >> >> In response to 3 arguments for proposed reorganization: >> >> - As an implementor I can wade through 4408 with a yellow high-lighter and sticky-notes until I get it. >> - As someone responsible for teaching others, I would greatly appreciate adoption of Murray's proposed reorganization. >> - As a rare participant in IETF process, I agree with the stance of "we should clean it up now and not later".. pushing through an editorially unchanged 4408 seems to me to miss the point of why we're all here (regardless of Chartering). >> >> In response to counter-arguments: >> - After review, Murray's proposed reorganization does not change the protocol, it only makes it easier for non-experts to understand. Perhaps oddly, I don't see the counter-arguments as such. I see the "move SPF from the experimental to the standards track" to mean "prepare the document so that it behaves like other standards track documents", which Murray's proposed reorganization gets us closer to. >> - I do not find the the "accidental protocol changes" argument compelling, due to the passion, expertise, and character-by-character review that all participants in this WG give to proposed changes. >> - Similarly, the need-for-side-by-side-comparison argument is lost on me. Optimizing for easy-review is not on my list of concerns. I understand that there is risk whenever change is introduced, but the time to make change is when everyone is paying attention, which is now. >> >> Trade-offs for an acceptable result: >> - Commit to not changing the protocol; warts, macros, and all. >> - Recognize that the current draft does too much and interleaves too many topics to make it a proper IETF standard. The risk of the IESG kicking the draft back is one thing, but we might as well go all in to meet perceived IESG requirements AND produce a doc that technology generalists can read w/o importing the entire history of SPF into their heads. >> - Everyone must commit to trying to "sneak in" at least 1 change. This will keep everyone on their toes. >> >> Finally, I'd like to submit that the existing draft has done an excellent job of producing interoperable technology within the community of email anti-abuse developers. In the move from Experimental to standards-track, though, the community will get larger, and therefore the specification needs to be editorially easier to ingest. >> >> See y'all tomorrow, >> =- Tim >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis From tim@eudaemon.net Wed Nov 7 09:28:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5FD21F8C48 for ; Wed, 7 Nov 2012 09:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PseMzg+13evw for ; Wed, 7 Nov 2012 09:28:02 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id DA09A21F8C44 for ; Wed, 7 Nov 2012 09:28:01 -0800 (PST) Received: from [10.0.1.3] (adsl-98-94-248-15.ard.bellsouth.net [98.94.248.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 72A1BCB46; Wed, 7 Nov 2012 12:28:31 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Draegen In-Reply-To: <509A91F4.6050707@isdg.net> Date: Wed, 7 Nov 2012 12:28:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120917220040.GB59832@crankycanuck.ca> <9E6AD41B-B5CF-4842-8CF7-DF98E16834C5@eudaemon.net> <509A91F4.6050707@isdg.net> To: Hector Santos X-Mailer: Apple Mail (2.1499) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:28:02 -0000 On Nov 7, 2012, at 11:53 AM, Hector Santos wrote: > I have a hard time understanding the focus and goal here for = reorganization. Please state the main purpose and goal to adopt = Murray's proposed changes. What is the benefits? I'll try my best, but keep in mind my "main purpose" is my own. Main = purpose is to produce a document that the larger world can review to = orient themselves as to how SPF works. As an educator, the benefit is = to have access to a document that students/non-SPF-experts can reference = while groking the technology (mostly in the context of learning how to = create and maintain accurate SPF records). As a bonus, I think the proposed reorganization moves the document = closer to the "look and feel" of existing RFCs, which gets us all closer = to the goal of producing a standards-track document. > In my engineering and product development opinion, the proposed = changes does alter the scope of the SPF framework (relatively to how we = have been using it for 9+years) and we are living proof that if we = follow the proposed changes, it will be a very costly design change = endeavor to the point we would have to consider the pros and cons and = most likely ignore the new considerations emphasized in the proposed = changes. I don't think this can't be "fixed" but it will does required = accepting the policies already established in SPF and how these are = functional specifications are translated into standard technical = specifications fitting into the SMTP state machine as a 5321 technology, = not 5322 technology. If we are focusing on 5322 material, then the = scope is changing. I'm not sure I'm reading the above correctly. If we stick to editorial = changes, then the proposed reorg is not a factor in any alteration of = the scope of the SPF framework. Rather, the above is expressing that = the movement of SPF from Experimental to Standards-track will enable = future SPF-related work (aka alteration of the scope of the SPF = framework). If this is what is being expressed, I think I agree. I think the acceptance of already-established policies is a topic worth = its own thread. My experience is that the policy-component of SPF is = largely misunderstood; documenting all of the various ways that SPF = policy is consumed would be a fantastic exercise (and not just the = "HardFail means reject-at-SMTP-time" scenario.. upstream anti-spam = scanning, as an information feature in reputations systems, in the use = of mitigating joe-jobs, etc). A while ago a proposal for an extension was circulated to allow linkage = between SPF and 5322.=46rom headers. I believe that proposal was voted = off the island as out-of-scope item quite some time ago, therefore I'm = not sure what else there is to say about it. With my engineering and = deployment hat on, some stacks only consume SPF results after a message = has been accepted (post SMTP exchange), so it might be tough to stick to = 5321 if SPFbis wants to paint a complete picture of how SPF is being = used. HTH, =3D- Tim From sm@elandsys.com Wed Nov 7 09:40: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 E659F21F8C56 for ; Wed, 7 Nov 2012 09:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbdU4rmuhXn5 for ; Wed, 7 Nov 2012 09:40:23 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E6021F8C55 for ; Wed, 7 Nov 2012 09:40:22 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.136.90]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA7He9dQ014663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Nov 2012 09:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352310021; bh=fuigdSPMFbdZ4ZwwgurmYKWS0M2rzbK0M0FcVH6fDhk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Ou0Cl/PSicBQbHNgxzxAZfwblGOJsk40xfrOiPm/TXrt5A9wagHVmazqh0/05k7UZ EVF1ZkhHY4bNYr5rJQZVHBi0eBD0Mk0wnlY1KMKW3+S5YNeOeKF3M7Hctd5wOEkrgQ 4oqQEzpgfrpiO5+H1kSbnlAGSD27kDsqVJp5+QsY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352310021; i=@elandsys.com; bh=fuigdSPMFbdZ4ZwwgurmYKWS0M2rzbK0M0FcVH6fDhk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=L8yfcrhUVRPgOHHw+2/dyIvFJKfnGHokwogCbHvmNPzF6jpUYxn8QT1JssVOK2Mv3 viuQkiELmRHRnumHKKODt4nkoHNX7vVekyEdQ/LxcwxbdQUYuhU7VHbQi7ANeAngGZ dao2sRUbIAN2C/dwMWVg463vhIv0QNwc+1bm4Nk4= Message-Id: <6.2.5.6.2.20121107092335.0b01fef8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Nov 2012 09:38:15 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20121102144854.099f0d28@elandnews.com> References: <6.2.5.6.2.20121102121645.0b2552f0@elandnews.com> <6.2.5.6.2.20121102144854.099f0d28@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Remote participation for IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:40:24 -0000 Hello, This is a reminder about the the SPFBIS WG meeting in room 209 on Thursday 8, November from 17:30 to 18:30 EST (22:30 - 23:30 UTC). The details for remote participation are available at http://www.ietf.org/mail-archive/web/spfbis/current/msg02969.html and http://www.ietf.org/meeting/85/remote-participation.html We are still looking a minute taker and a Jabber scribe for the session. Please email spfbis-chairs@tools.ietf.org if you can help. If you would like to volunteer but you don't know what to do, send me an email and I'll explain. Regards, S. Moonesamy SPFBIS WG co-chair From dotzero@gmail.com Wed Nov 7 10:16: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 6A96821F8C6D for ; Wed, 7 Nov 2012 10:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjp7116oi+cN for ; Wed, 7 Nov 2012 10:16:07 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4A4C21F8C50 for ; Wed, 7 Nov 2012 10:16:07 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so3182390iec.31 for ; Wed, 07 Nov 2012 10:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=soDNSngRWRP5jnU5MgRRFyF6OHhrqYTNxrAaL6UctpY=; b=jUkyUKeMnVlM5UB+6iiO5Ovd23MKDNjJR5vLpqQG+2t1RYgltuVhoPda9Ocqod7pV8 NBJDfQGDZZPkfxLVg1paCpT6t+6pHXpVd5sIrI8GMn2JmZhGXl7emWs0uksDlPeByIbW AFQQTd/nRWmWHEiDr8THozcNlj57PteL/VQbv2lHOtucpWWIoBaejv0OioWTuOrnbI4A 6nQcsecCRJ+jwYsa7gMpAgUc9ZuWBaI97it1+iy1tj8shYWXDZ2M/KTdjmKEYZr0451s 25m/AwghejnjiyAKTTiPuoMOW9J6ia9uneYwNXjtAzoF8T5kmaI7tUuw1vi4WjhzNeu/ u8kA== MIME-Version: 1.0 Received: by 10.42.65.6 with SMTP id j6mr4953392ici.2.1352312167314; Wed, 07 Nov 2012 10:16:07 -0800 (PST) Received: by 10.64.110.138 with HTTP; Wed, 7 Nov 2012 10:16:07 -0800 (PST) In-Reply-To: References: <20120917220040.GB59832@crankycanuck.ca> <9E6AD41B-B5CF-4842-8CF7-DF98E16834C5@eudaemon.net> <509A91F4.6050707@isdg.net> Date: Wed, 7 Nov 2012 13:16:07 -0500 Message-ID: From: Dotzero To: "spfbis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:16:08 -0000 I'm going to take the liberty of top posting (apologies to any this might offend). I agree overall with Tim's comments (with the exception of people throwing in changes to test peoples attention) regarding how to move forward. I won't be able to make the session tomorrow (not even remotely) as I will be having surgery tomorrow and will still be under when the session occurs. For that reason I'd ask that my +1 and agreement with what Tim has written be considered as if I took this stance during the session tomorrow. Thanks. Mike On Wed, Nov 7, 2012 at 12:28 PM, Tim Draegen wrote: > On Nov 7, 2012, at 11:53 AM, Hector Santos wrote: >> I have a hard time understanding the focus and goal here for reorganizat= ion. Please state the main purpose and goal to adopt Murray's proposed cha= nges. What is the benefits? > > I'll try my best, but keep in mind my "main purpose" is my own. Main pur= pose is to produce a document that the larger world can review to orient th= emselves as to how SPF works. As an educator, the benefit is to have acces= s to a document that students/non-SPF-experts can reference while groking t= he technology (mostly in the context of learning how to create and maintain= accurate SPF records). > > As a bonus, I think the proposed reorganization moves the document closer= to the "look and feel" of existing RFCs, which gets us all closer to the g= oal of producing a standards-track document. > >> In my engineering and product development opinion, the proposed changes = does alter the scope of the SPF framework (relatively to how we have been u= sing it for 9+years) and we are living proof that if we follow the proposed= changes, it will be a very costly design change endeavor to the point we w= ould have to consider the pros and cons and most likely ignore the new cons= iderations emphasized in the proposed changes. I don't think this can't be= "fixed" but it will does required accepting the policies already establish= ed in SPF and how these are functional specifications are translated into s= tandard technical specifications fitting into the SMTP state machine as a 5= 321 technology, not 5322 technology. If we are focusing on 5322 material,= then the scope is changing. > > I'm not sure I'm reading the above correctly. If we stick to editorial c= hanges, then the proposed reorg is not a factor in any alteration of the sc= ope of the SPF framework. Rather, the above is expressing that the movemen= t of SPF from Experimental to Standards-track will enable future SPF-relate= d work (aka alteration of the scope of the SPF framework). If this is what= is being expressed, I think I agree. > > I think the acceptance of already-established policies is a topic worth i= ts own thread. My experience is that the policy-component of SPF is largel= y misunderstood; documenting all of the various ways that SPF policy is con= sumed would be a fantastic exercise (and not just the "HardFail means rejec= t-at-SMTP-time" scenario.. upstream anti-spam scanning, as an information f= eature in reputations systems, in the use of mitigating joe-jobs, etc). > > A while ago a proposal for an extension was circulated to allow linkage b= etween SPF and 5322.From headers. I believe that proposal was voted off th= e island as out-of-scope item quite some time ago, therefore I'm not sure w= hat else there is to say about it. With my engineering and deployment hat = on, some stacks only consume SPF results after a message has been accepted = (post SMTP exchange), so it might be tough to stick to 5321 if SPFbis wants= to paint a complete picture of how SPF is being used. > > HTH, > =3D- Tim > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From prvs=651beb782=fmartin@linkedin.com Wed Nov 7 10:16:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E030A21F8C7B for ; Wed, 7 Nov 2012 10:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZwl7TjeEPdh for ; Wed, 7 Nov 2012 10:16:19 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4153A21F8C72 for ; Wed, 7 Nov 2012 10:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1352312179; x=1383848179; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=TpxeGvdqIx162s8hj9NCtQCXOY8yhGoZoSgedWY5wrQ=; b=Hbs3m5WaP5DC9s8c1B6gqDdP0Piq2FCn4NCACDzZsDDfW4cleKoCH/a/ QXj+WHfHZIAapgEDON010PX9VxDmqnrvw/PXHjn3kO6ickBNmco0AOJx/ 4l9p29VyO+Jndj3VKRN3zWJpBoc+AXUkradKTiTDALNLQkL6ms5MppEF4 Y=; X-IronPort-AV: E=Sophos;i="4.80,731,1344236400"; d="scan'208";a="30077236" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Wed, 7 Nov 2012 10:16:03 -0800 From: Franck Martin To: John Kelley , "spfbis@ietf.org" Thread-Topic: [spfbis] Goals of this discussion Thread-Index: AQHNvQT1fxq/PHOwP0uA5TFs3qYg15ffHOqA//+Q/QA= Date: Wed, 7 Nov 2012 18:16:03 +0000 Message-ID: In-Reply-To: <509A920D.6040402@teamaol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <60E38D2F1177FA43A3AC1BBF007F0CA2@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:16:20 -0000 +1 for me too. Franck On 11/7/12 8:53 AM, "John Kelley" wrote: >I agree with Trent. Tim's arguments were compelling. > >+1 > >John Kelley > > >On 11/7/2012 11:28 AM, J. Trent Adams wrote: >> I found myself reading Tim's response and nodding the entire way >>through. >> >> +1 from me. >> >> - Trent >> >> >> On 11/7/12 9:23 AM, Tim Draegen wrote: >>> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan >>>wrote: >>>> Before going further, I'd like for participants in this debate to >>>>state >>>> where they stand with respect to the above arguments, and to clarify >>>> what trade-offs they think are acceptable as a result. >>> Andrew et al, my aim is help produce a Standards-track draft that >>>meets the needs of people outside of the IETF in as little time as >>>possible, and no less. >>> >>> In response to 3 arguments for proposed reorganization: >>> >>> - As an implementor I can wade through 4408 with a yellow high-lighter >>>and sticky-notes until I get it. >>> - As someone responsible for teaching others, I would greatly >>>appreciate adoption of Murray's proposed reorganization. >>> - As a rare participant in IETF process, I agree with the stance of >>>"we should clean it up now and not later".. pushing through an >>>editorially unchanged 4408 seems to me to miss the point of why we're >>>all here (regardless of Chartering). >>> >>> In response to counter-arguments: >>> - After review, Murray's proposed reorganization does not change the >>>protocol, it only makes it easier for non-experts to understand. >>>Perhaps oddly, I don't see the counter-arguments as such. I see the >>>"move SPF from the experimental to the standards track" to mean >>>"prepare the document so that it behaves like other standards track >>>documents", which Murray's proposed reorganization gets us closer to. >>> - I do not find the the "accidental protocol changes" argument >>>compelling, due to the passion, expertise, and character-by-character >>>review that all participants in this WG give to proposed changes. >>> - Similarly, the need-for-side-by-side-comparison argument is lost on >>>me. Optimizing for easy-review is not on my list of concerns. I >>>understand that there is risk whenever change is introduced, but the >>>time to make change is when everyone is paying attention, which is now. >>> >>> Trade-offs for an acceptable result: >>> - Commit to not changing the protocol; warts, macros, and all. >>> - Recognize that the current draft does too much and interleaves too >>>many topics to make it a proper IETF standard. The risk of the IESG >>>kicking the draft back is one thing, but we might as well go all in to >>>meet perceived IESG requirements AND produce a doc that technology >>>generalists can read w/o importing the entire history of SPF into their >>>heads. >>> - Everyone must commit to trying to "sneak in" at least 1 change. >>>This will keep everyone on their toes. >>> >>> Finally, I'd like to submit that the existing draft has done an >>>excellent job of producing interoperable technology within the >>>community of email anti-abuse developers. In the move from >>>Experimental to standards-track, though, the community will get larger, >>>and therefore the specification needs to be editorially easier to >>>ingest. >>> >>> See y'all tomorrow, >>> =3D- Tim >>> >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From prvs=651beb782=fmartin@linkedin.com Wed Nov 7 10:27: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 3132F21F8B75 for ; Wed, 7 Nov 2012 10:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYK30-OOQNsS for ; Wed, 7 Nov 2012 10:27:11 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 860DE21F8B74 for ; Wed, 7 Nov 2012 10:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1352312831; x=1383848831; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hHApPU/s98GRRQMLr6XD1HGxfpbyffyl+IJW7kg15Xk=; b=ENDNDHIA8m2dqKZ2a4xZ0wskwYgoBAl4e55hhto4OYVD9oMDCwb/BJ2F K7qQrcjsVVBDFlrzYIs5XPgoMEjfqMqbbUefAKIFiZyNY1K/B+KYqUceB lDAa4xTjXI7SK5ZKDyMyaus+yhjr4qV8Z/a0AU/uG/3Wu/Fgnn2zCt/Hr g=; X-IronPort-AV: E=Sophos;i="4.80,731,1344236400"; d="scan'208";a="30078384" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Nov 2012 10:26:58 -0800 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Wed, 7 Nov 2012 10:26:57 -0800 From: Franck Martin To: Hector Santos , Tim Draegen Thread-Topic: [spfbis] Goals of this discussion Thread-Index: AQHNvQhSCYdfeJzadEGCekxuxQ5oC5fesO4A Date: Wed, 7 Nov 2012 18:26:57 +0000 Message-ID: In-Reply-To: <509A91F4.6050707@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7D11AEE643BEF84994141D4DBD1B77F0@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:27:12 -0000 Hector, Murray has stated and several people have stated, they do not seek protocol change in this reorganization, but to follow Best Current Practices in writing a RFC. This needs to look like a proper RFC, rather than a babel tower=8A We have only one good shot in making SPF a standard, let's not fail due to poor grammar. On 11/7/12 8:53 AM, "Hector Santos" wrote: >I have a hard time understanding the focus and goal here for >reorganization. Please state the main purpose and goal to adopt >Murray's proposed changes. What is the benefits? > >In my engineering and product development opinion, the proposed >changes does alter the scope of the SPF framework (relatively to how >we have been using it for 9+years) and we are living proof that if we >follow the proposed changes, it will be a very costly design change >endeavor to the point we would have to consider the pros and cons and >most likely ignore the new considerations emphasized in the proposed >changes. I don't think this can't be "fixed" but it will does >required accepting the policies already established in SPF and how >these are functional specifications are translated into standard >technical specifications fitting into the SMTP state machine as a 5321 >technology, not 5322 technology. If we are focusing on 5322 >material, then the scope is changing. > >-- >HLS > > >Tim Draegen wrote: >> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan >>wrote: >>> Before going further, I'd like for participants in this debate to state >>> where they stand with respect to the above arguments, and to clarify >>> what trade-offs they think are acceptable as a result. >>=20 >> Andrew et al, my aim is help produce a Standards-track draft that meets >>the needs of people outside of the IETF in as little time as possible, >>and no less. >>=20 >> In response to 3 arguments for proposed reorganization: >>=20 >> - As an implementor I can wade through 4408 with a yellow high-lighter >>and sticky-notes until I get it. >> - As someone responsible for teaching others, I would greatly >>appreciate adoption of Murray's proposed reorganization. >> - As a rare participant in IETF process, I agree with the stance of "we >>should clean it up now and not later".. pushing through an editorially >>unchanged 4408 seems to me to miss the point of why we're all here >>(regardless of Chartering). >>=20 >> In response to counter-arguments: >> - After review, Murray's proposed reorganization does not change the >>protocol, it only makes it easier for non-experts to understand. >>Perhaps oddly, I don't see the counter-arguments as such. I see the >>"move SPF from the experimental to the standards track" to mean "prepare >>the document so that it behaves like other standards track documents", >>which Murray's proposed reorganization gets us closer to. >> - I do not find the the "accidental protocol changes" argument >>compelling, due to the passion, expertise, and character-by-character >>review that all participants in this WG give to proposed changes. >> - Similarly, the need-for-side-by-side-comparison argument is lost on >>me. Optimizing for easy-review is not on my list of concerns. I >>understand that there is risk whenever change is introduced, but the >>time to make change is when everyone is paying attention, which is now. >>=20 >> Trade-offs for an acceptable result: >> - Commit to not changing the protocol; warts, macros, and all. >> - Recognize that the current draft does too much and interleaves too >>many topics to make it a proper IETF standard. The risk of the IESG >>kicking the draft back is one thing, but we might as well go all in to >>meet perceived IESG requirements AND produce a doc that technology >>generalists can read w/o importing the entire history of SPF into their >>heads. >> - Everyone must commit to trying to "sneak in" at least 1 change. This >>will keep everyone on their toes. >>=20 >> Finally, I'd like to submit that the existing draft has done an >>excellent job of producing interoperable technology within the community >>of email anti-abuse developers. In the move from Experimental to >>standards-track, though, the community will get larger, and therefore >>the specification needs to be editorially easier to ingest. >>=20 >> See y'all tomorrow, >> =3D- Tim >>=20 > > > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From zwicky@yahoo-inc.com Wed Nov 7 13:28:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CB021F8BF9 for ; Wed, 7 Nov 2012 13:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.098 X-Spam-Level: X-Spam-Status: No, score=-18.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3AeCRei14jP for ; Wed, 7 Nov 2012 13:28:45 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id EEE9A21F8B4D for ; Wed, 7 Nov 2012 13:28:44 -0800 (PST) Received: from sp1-ex07cas01.ds.corp.yahoo.com (sp1-ex07cas01.ds.corp.yahoo.com [216.252.116.137]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id qA7LSNNg043051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 7 Nov 2012 13:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1352323704; bh=hIUoDagSsXJQz+z+6jwa4bMDSwDh+gb53IHgigzyrCs=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=XSboP+j/I0F0A6SNhdAUUwYWQqf52E96jiHDFUpdcUDkgrNEh0yC3wguovfUVByIz OOwDO5opT9mIOTAlXHV3BuXV3czT5XlzdyTmm2gTF5UgP+BlabpKusi3kaTG40ZtqL VqiUkaRbReZA08WVQQbtkzsWkRKp4kmzoTjEHM5I= Received: from SP1-EX07VS01.ds.corp.yahoo.com ([216.252.116.136]) by sp1-ex07cas01.ds.corp.yahoo.com ([216.252.116.137]) with mapi; Wed, 7 Nov 2012 13:28:23 -0800 From: Elizabeth Zwicky To: Franck Martin Date: Wed, 7 Nov 2012 13:28:22 -0800 Thread-Topic: [spfbis] Goals of this discussion Thread-Index: Ac29LtDdB09sG7alS1mc7nf9IFf7SA== Message-ID: <3E6CC480-E11B-4304-857D-E8603206ADDC@yahoo-inc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 323704001 Cc: "spfbis@ietf.org" , Tim Draegen , Hector Santos Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:31:15 -0000 As the person who would have to coordinate Yahoo's implementation if we were just now implementing SPF, I can say that the reorganization goes a long way towards making the RFC easier to use. I appreciate that reorganizations are a technical challenge while they are in progress, but optimizing for the process right now rather than the many readers down the road seems to me to be the wrong decision. As a receiver with SPF support I don't see how the proposed changes would cause us to change our implementation; could somebody clarify that for me? Elizabeth Zwicky On Nov 7, 2012, at 10:26 AM, Franck Martin wrote: > Hector, >=20 > Murray has stated and several people have stated, they do not seek > protocol change in this reorganization, but to follow Best Current > Practices in writing a RFC.=20 >=20 > This needs to look like a proper RFC, rather than a babel tower=8A >=20 > We have only one good shot in making SPF a standard, let's not fail due t= o > poor grammar. >=20 > On 11/7/12 8:53 AM, "Hector Santos" wrote: >=20 >> I have a hard time understanding the focus and goal here for >> reorganization. Please state the main purpose and goal to adopt >> Murray's proposed changes. What is the benefits? >>=20 >> In my engineering and product development opinion, the proposed >> changes does alter the scope of the SPF framework (relatively to how >> we have been using it for 9+years) and we are living proof that if we >> follow the proposed changes, it will be a very costly design change >> endeavor to the point we would have to consider the pros and cons and >> most likely ignore the new considerations emphasized in the proposed >> changes. I don't think this can't be "fixed" but it will does >> required accepting the policies already established in SPF and how >> these are functional specifications are translated into standard >> technical specifications fitting into the SMTP state machine as a 5321 >> technology, not 5322 technology. If we are focusing on 5322 >> material, then the scope is changing. >>=20 >> -- >> HLS >>=20 >>=20 >> Tim Draegen wrote: >>> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan >>> wrote: >>>> Before going further, I'd like for participants in this debate to stat= e >>>> where they stand with respect to the above arguments, and to clarify >>>> what trade-offs they think are acceptable as a result. >>>=20 >>> Andrew et al, my aim is help produce a Standards-track draft that meets >>> the needs of people outside of the IETF in as little time as possible, >>> and no less. >>>=20 >>> In response to 3 arguments for proposed reorganization: >>>=20 >>> - As an implementor I can wade through 4408 with a yellow high-lighter >>> and sticky-notes until I get it. >>> - As someone responsible for teaching others, I would greatly >>> appreciate adoption of Murray's proposed reorganization. >>> - As a rare participant in IETF process, I agree with the stance of "we >>> should clean it up now and not later".. pushing through an editorially >>> unchanged 4408 seems to me to miss the point of why we're all here >>> (regardless of Chartering). >>>=20 >>> In response to counter-arguments: >>> - After review, Murray's proposed reorganization does not change the >>> protocol, it only makes it easier for non-experts to understand. >>> Perhaps oddly, I don't see the counter-arguments as such. I see the >>> "move SPF from the experimental to the standards track" to mean "prepar= e >>> the document so that it behaves like other standards track documents", >>> which Murray's proposed reorganization gets us closer to. >>> - I do not find the the "accidental protocol changes" argument >>> compelling, due to the passion, expertise, and character-by-character >>> review that all participants in this WG give to proposed changes. >>> - Similarly, the need-for-side-by-side-comparison argument is lost on >>> me. Optimizing for easy-review is not on my list of concerns. I >>> understand that there is risk whenever change is introduced, but the >>> time to make change is when everyone is paying attention, which is now. >>>=20 >>> Trade-offs for an acceptable result: >>> - Commit to not changing the protocol; warts, macros, and all. >>> - Recognize that the current draft does too much and interleaves too >>> many topics to make it a proper IETF standard. The risk of the IESG >>> kicking the draft back is one thing, but we might as well go all in to >>> meet perceived IESG requirements AND produce a doc that technology >>> generalists can read w/o importing the entire history of SPF into their >>> heads. >>> - Everyone must commit to trying to "sneak in" at least 1 change. This >>> will keep everyone on their toes. >>>=20 >>> Finally, I'd like to submit that the existing draft has done an >>> excellent job of producing interoperable technology within the communit= y >>> of email anti-abuse developers. In the move from Experimental to >>> standards-track, though, the community will get larger, and therefore >>> the specification needs to be editorially easier to ingest. >>>=20 >>> See y'all tomorrow, >>> =3D- Tim >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >=20 > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From steven.m.jones@gmail.com Wed Nov 7 19:20: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 228F321F8A78 for ; Wed, 7 Nov 2012 19:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzK7qEHUV1ep for ; Wed, 7 Nov 2012 19:20:39 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAAC21F8A55 for ; Wed, 7 Nov 2012 19:20:39 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so1057852wgb.13 for ; Wed, 07 Nov 2012 19:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=t4OJ3vhp5CSEyIar6fZHv6udVn4T4Vp9uXGagwZTxc0=; b=JdpvE/2Hr0cyGgfrKuk6k9gqTSAk2egveVQYgBjzklun0N8HAHA7D9eZM/kjs1t2VV 2gIn1IE1Fz7t5TMljnTLL3IXIGTS4GIBuoz8gwUwi59Fhx0fK/FS6985oGaITqej7Ddk C9JRT2oa9ZwgwWHX/pqxP/Iqxo5rD31F0X1BzqzOIVHJde0jx+lnpEQ7CFiOSaPnJH3Q MaEkDy/AgTLyQ9umxIF5m2/d2wchNWghEJycQxT7+sIqS88yVGmKblWIt4o0M3JavGPH mw6lxNXmVRXrsRMCwfRx9miPPxiZ6QzYG9TXV/pucCMFv8AzsMCsrfL6TMpGaYpUSI3k xfvw== MIME-Version: 1.0 Received: by 10.216.207.18 with SMTP id m18mr2538390weo.203.1352344838466; Wed, 07 Nov 2012 19:20:38 -0800 (PST) Received: by 10.227.193.135 with HTTP; Wed, 7 Nov 2012 19:20:38 -0800 (PST) In-Reply-To: <5097EA98.9050002@isdg.net> References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> <5097EA98.9050002@isdg.net> Date: Wed, 7 Nov 2012 19:20:38 -0800 Message-ID: From: Steve Jones To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=0016e6db2ae2b5ee1504cdf351c0 Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 03:20:40 -0000 --0016e6db2ae2b5ee1504cdf351c0 Content-Type: text/plain; charset=ISO-8859-1 The goal of the working group is to have the SPF protocol adopted as an Internet Standard. I believe that any changes to the protocol itself have already been ruled as out of scope, and I'm fine with that. With a working group full of concerned participants, I'm confident that no functional changes are going to be introduced, accidentally or otherwise. Though unlike Mr. Draegen I will not suggest that participants attempt to do so in order to test each others' vigilance... This document has to meet the criteria and expectations for a mature standard, not an experiment. It has to have a clear and logical organization and not have various considerations and clarifications sprinkled throughout such that finding them all is an exercise. And the output of this WG should be in final form, not something that's known to need further refinement and revision. +1 for reorganizing. My day job is messaging architect (among other roles) in the financial sector, we've relied on SPF since 2004, and it is beneficial to our industry and our customers for SPF to transition from Experimental to Standard status. --Steve. --0016e6db2ae2b5ee1504cdf351c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The goal of the working group is to have the SPF protocol adopted as an Int= ernet Standard. I believe that any changes to the protocol itself have alre= ady been ruled as out of scope, and I'm fine with that.

With a w= orking group full of concerned participants, I'm confident that no func= tional changes are going to be introduced, accidentally or otherwise. Thoug= h unlike Mr. Draegen I will not suggest that participants attempt to do so = in order to test each others' vigilance...

This document has to meet the criteria and expectations for a mature st= andard, not an experiment. It has to have a clear and logical organization = and not have various considerations and clarifications sprinkled throughout= such that finding them all is an exercise. And the output of this WG shoul= d be in final form, not something that's known to need further refineme= nt and revision.

+1 for reorganizing. My day job is messaging architect (among other rol= es) in the financial sector, we've relied on SPF since 2004, and it is = beneficial to our industry and our customers for SPF to transition from Exp= erimental to Standard status.

--Steve.
--0016e6db2ae2b5ee1504cdf351c0-- From hsantos@isdg.net Thu Nov 8 03:52: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 262C921F8B5E for ; Thu, 8 Nov 2012 03:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.821 X-Spam-Level: X-Spam-Status: No, score=-101.821 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QoVu50XKv0Q for ; Thu, 8 Nov 2012 03:52:48 -0800 (PST) Received: from news.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 046DE21F8A55 for ; Thu, 8 Nov 2012 03:52:47 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2830; t=1352375559; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=vvIdsAfo2rcCexlhIa0RXCbwcco=; b=DqaxCJfkISwegfaoB//D /nbGIqyESF2mswCAaJmRZBs1/kpvJewaIjCXzi0nV4MizM8SE2QM97bigKuS3qq5 JVq2luRVoATBxR/azkHb2HpOFaSyBgjvTPzjzt2jOV/qsiArigFJnxHdiJUJuCGx GW757sHRlhTQUhYJetDVE7k= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 08 Nov 2012 06:52:39 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4102313249.1525.5280; Thu, 08 Nov 2012 06:52:38 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2830; t=1352375235; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fN8WWg2 I/+2FU52svQEZY+m2DlQQWXnNSpYdaQwzboA=; b=ee4PQ7WwiU09vyd1PrjeQg1 py7Zlxj75qnn6h80SIxWUoIbmkTkLP60zrsu+eMpxGCTqkAkX4NWNCyOexN0uDth ALg4lVaBtP4fKoYEoCWI9FlrOxa4q9Yhy21grRUukVp5cVuBn6XowI43mLjlG3dd lUDVjUQUpkW2dFLKt98Q= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 08 Nov 2012 06:47:15 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 406099053.9.3456; Thu, 08 Nov 2012 06:47:14 -0500 Message-ID: <509B9D56.3000509@isdg.net> Date: Thu, 08 Nov 2012 06:53:58 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Steve Jones References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> <5097EA98.9050002@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 11:52:49 -0000 If we are adding stuff, like AUTH-RES in this reorganization, deemphasizing Received-SPF and the FAIL (-ALL) policies with exclusive rejection operations, then the scope is changing from both a publishing standpoint (less confidence in -ALL usage) and a handling standpoint (less reason, payoff to process SPF). SPF is a security protocol and we have yet to resolve or get agreement on various issues such as Issue #29 which evolved to #33 and then #58 regarding local policy. If I am forced to support a non-rejecting form of -ALL policies, then we can no longer support SPF BIS. Of course, no one is forcing anyone, but we do FOLLOW specification and it must be made clear, reorganized or not, -ALL does fundamentally includes SMTP REJECTION and ACCEPTANCE is an local deployment option, and in my engineering opinion, the exception to the expected behavior by the -ALL publisher. I just don't wish to see SPF relaxed to satisfy other integrated or augmented protocols such as reporting and reputation mechanism because IMV, it waters it down as a strong _deterministic_ ANTI-SPOOFING protocol. Due to time constraints, I doubt I will be able to get my input into the remote meeting so I am hoping my concerns are heeded in the meeting. Thanks for your consideration. -- Hector Santos, CEO/CTO Santronics Software, Inc. http://www.santronics.com Steve Jones wrote: > The goal of the working group is to have the SPF protocol adopted as an > Internet Standard. I believe that any changes to the protocol itself have > already been ruled as out of scope, and I'm fine with that. > > With a working group full of concerned participants, I'm confident that no > functional changes are going to be introduced, accidentally or otherwise. > Though unlike Mr. Draegen I will not suggest that participants attempt to > do so in order to test each others' vigilance... > > This document has to meet the criteria and expectations for a mature > standard, not an experiment. It has to have a clear and logical > organization and not have various considerations and clarifications > sprinkled throughout such that finding them all is an exercise. And the > output of this WG should be in final form, not something that's known to > need further refinement and revision. > > +1 for reorganizing. My day job is messaging architect (among other roles) > in the financial sector, we've relied on SPF since 2004, and it is > beneficial to our industry and our customers for SPF to transition from > Experimental to Standard status. > > --Steve. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- HLS From vesely@tana.it Thu Nov 8 07:26:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C561121F87DF for ; Thu, 8 Nov 2012 07:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VwT+vy2JDBF for ; Thu, 8 Nov 2012 07:26:45 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 05E3821F85AA for ; Thu, 8 Nov 2012 07:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352388401; bh=2yhdt3NDI2DydwpeSeVTUBGvXea/QlcDilVQ2Chj+vg=; l=3203; h=Date:From:To:References:In-Reply-To; b=cW9HyOf9GWV4RWIMViNKnJzLVUy+I0V9HfOnXxCwnZWe61S9TIqtlrjJz4Lq7auKq KCsZkxZKFAcLWyxV7iKyLBDiImfcrdcN93oCwOA/GClbBJRUcmh+Fn6tQAtjtErlis QeN+r8o+NO9bxABGqr423MFxoifXGZIPZQJr3+rI= Received: from [130.129.23.14] (dhcp-170e.meeting.ietf.org [130.129.23.14]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 08 Nov 2012 16:26:40 +0100 id 00000000005DC035.00000000509BCF30.00005C8E Message-ID: <509BCF2D.3070307@tana.it> Date: Thu, 08 Nov 2012 10:26:37 -0500 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> <5097EA98.9050002@isdg.net> <509B9D56.3000509@isdg.net> In-Reply-To: <509B9D56.3000509@isdg.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:26:46 -0000 Hector, On Thu 08/Nov/2012 06:53:58 -0500 Hector Santos wrote: > > If we are adding stuff, like AUTH-RES in this reorganization, > deemphasizing Received-SPF and the FAIL (-ALL) policies with exclusive > rejection operations, then the scope is changing from both a publishing > standpoint (less confidence in -ALL usage) and a handling standpoint > (less reason, payoff to process SPF). I think that the main point of a well done specification is to, ehm, _specify_ the protocol. Specifying rejection is not the same thing as emphasizing it. That is undoubtedly one of the reasons why SPF is painful to implement: Mail admins find no precise indications, and when they try to make sense of some kind of behavior, they are told that rejection is not specified, because this is a /sender/ policy. You have probably been told so many many times. For example, recall Stuart's approach to rejection, described in http://www.ietf.org/mail-archive/web/spfbis/current/msg01268.html Alas, the SPF implementation I use doesn't support that technique: Doesn't that illustrate one weakness of emphasizing vs specifying? Each programmer is encouraged to sprout his/her own conception of policy regulation. No surprise that there's no match. Admins configuring different packages get different views. I'd not call that a standard. > SPF is a security protocol and we have yet to resolve or get agreement > on various issues such as Issue #29 which evolved to #33 and then #58 > regarding local policy. Separating issues should help resolve them (it was already suggested in Paris...) > If I am forced to support a non-rejecting form of -ALL policies, then we > can no longer support SPF BIS. Of course, no one is forcing anyone, but > we do FOLLOW specification and it must be made clear, reorganized or > not, -ALL does fundamentally includes SMTP REJECTION and ACCEPTANCE is > an local deployment option, and in my engineering opinion, the exception > to the expected behavior by the -ALL publisher. Agreed. A normative specification of behavior, however, seems to require its own document. Personally, I see no point in stuffing everything into a single RFC, also because there are people who is interested in just evaluating the check_host() function and it would be a considerable relief for them if they can do it without having to consider parts that don't concern them. > I just don't wish to see SPF relaxed to satisfy other integrated or > augmented protocols such as reporting and reputation mechanism because > IMV, it waters it down as a strong _deterministic_ ANTI-SPOOFING protocol. It may seem that moving some text to a later section diminishes its strength. In fact, RFC 2119 does not mention any relationship between the meaning of key words and their position in a document. Admittedly, it is important for emphasizing. I'd gladly exchange emphasis for clarity. > Due to time constraints, I doubt I will be able to get my input into the > remote meeting so I am hoping my concerns are heeded in the meeting. > Thanks for your consideration. Oh Hector, there are just a few hundred miles and time enough to get here... From prvs=6522d09b0=fmartin@linkedin.com Thu Nov 8 11:51: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 2695021F8507 for ; Thu, 8 Nov 2012 11:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbjuB+nBvJzL for ; Thu, 8 Nov 2012 11:50:59 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id AD8CE21F843F for ; Thu, 8 Nov 2012 11:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1352404259; x=1383940259; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NQoYzCFeN2d7i3F+XBzL9+4voB3zRKutSpbYLCfQz5A=; b=ysr3YoI3p0y+bs5M5CH4D84jmH6Rx307KIybW78yFvUE/3jRBcv17Ofi SnVOT0OT7ZN655T3U1sfxwOQRlK5i/V2NnjNChMUMkFJKmwiRyUxWIPiw UwcuUzpKWWVmLxeU4mwB6fwzwFjQA7VIf6HFD6FCHALG3xljrnEGN6q6w k=; X-IronPort-AV: E=Sophos;i="4.80,739,1344236400"; d="scan'208";a="30191109" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Thu, 8 Nov 2012 11:50:41 -0800 From: Franck Martin To: Hector Santos , Steve Jones Thread-Topic: [spfbis] A proposed reorganization Thread-Index: AQHNttUNkJyMnhoa00q/Lecf2zC85pfStPQAgAf1tICAAVSnAIAD2S8AgACPbAD///8gAA== Date: Thu, 8 Nov 2012 19:50:40 +0000 Message-ID: In-Reply-To: <509B9D56.3000509@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <58A17137D3D12F45B74B289381DB1D14@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:51:05 -0000 I prefer if we do not mix an authentication function from a policy function. These are two different layers. Some, will be happy to act on the policy hint immediately, some will take all the policy hints they can find, to make a decision to accept the message, or not. If you look at spamassassin http://spamassassin.apache.org/tests_3_3_x.html (not that it is a reference), you will see that a fail barely bring 1 point (our of 5), and funnily enough the soft fail brings more points than a fail! On 11/8/12 3:53 AM, "Hector Santos" wrote: >If we are adding stuff, like AUTH-RES in this reorganization, >deemphasizing Received-SPF and the FAIL (-ALL) policies with exclusive >rejection operations, then the scope is changing from both a >publishing standpoint (less confidence in -ALL usage) and a handling >standpoint (less reason, payoff to process SPF). > >SPF is a security protocol and we have yet to resolve or get agreement >on various issues such as Issue #29 which evolved to #33 and then #58 >regarding local policy. > >If I am forced to support a non-rejecting form of -ALL policies, then >we can no longer support SPF BIS. Of course, no one is forcing >anyone, but we do FOLLOW specification and it must be made clear, >reorganized or not, -ALL does fundamentally includes SMTP REJECTION >and ACCEPTANCE is an local deployment option, and in my engineering >opinion, the exception to the expected behavior by the -ALL publisher. > >I just don't wish to see SPF relaxed to satisfy other integrated or >augmented protocols such as reporting and reputation mechanism because >IMV, it waters it down as a strong _deterministic_ ANTI-SPOOFING protocol. > >Due to time constraints, I doubt I will be able to get my input into >the remote meeting so I am hoping my concerns are heeded in the >meeting. Thanks for your consideration. > >-- >Hector Santos, CEO/CTO >Santronics Software, Inc. >http://www.santronics.com > > >Steve Jones wrote: >> The goal of the working group is to have the SPF protocol adopted as an >> Internet Standard. I believe that any changes to the protocol itself >>have >> already been ruled as out of scope, and I'm fine with that. >>=20 >> With a working group full of concerned participants, I'm confident that >>no >> functional changes are going to be introduced, accidentally or >>otherwise. >> Though unlike Mr. Draegen I will not suggest that participants attempt >>to >> do so in order to test each others' vigilance... >>=20 >> This document has to meet the criteria and expectations for a mature >> standard, not an experiment. It has to have a clear and logical >> organization and not have various considerations and clarifications >> sprinkled throughout such that finding them all is an exercise. And the >> output of this WG should be in final form, not something that's known to >> need further refinement and revision. >>=20 >> +1 for reorganizing. My day job is messaging architect (among other >>roles) >> in the financial sector, we've relied on SPF since 2004, and it is >> beneficial to our industry and our customers for SPF to transition from >> Experimental to Standard status. >>=20 >> --Steve. >>=20 >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > >--=20 >HLS > > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Thu Nov 8 12:39: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 3286E21F868C for ; Thu, 8 Nov 2012 12:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ8x7U2Brrdd for ; Thu, 8 Nov 2012 12:39:04 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94221F868A for ; Thu, 8 Nov 2012 12:39:03 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so2678299lam.31 for ; Thu, 08 Nov 2012 12:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YZ8mq1wV40Nhpupk0s4Kn9DbvXiJcP/9EwruO1S1Tng=; b=H8vUAO0NYA4PkedlaokikWcE85AGoO0CJnhRFdoBe/8zWG37O5H0DjNRQ2mqFvb68Y dKfmVzqhJeSDRDX2HaHHsONnlvZoqshRl5V1c7xp9Q0pxI61OSkXxraV1EoysqMHbu5o FaN53uj1zS0xqVvLgcZAjkrsX8j00JK8Q4XH/fgmEvJIcz8gA7l6TJjBTxp4M7geVAMI h5fBYkabOEGt4K0CH7So3xHK2WTpP4zv1kuc32I2qlXhBMVOXB7fzWowtnoLr3ANF/dp A0t61OxOOLlH2V7t3+CyVR2TgRCKjDAbGycI08wOhhkKDtKm9aTDOlQoUbxLia4NBUQk sW4A== MIME-Version: 1.0 Received: by 10.152.47.97 with SMTP id c1mr8535668lan.37.1352407141748; Thu, 08 Nov 2012 12:39:01 -0800 (PST) Received: by 10.112.83.232 with HTTP; Thu, 8 Nov 2012 12:39:01 -0800 (PST) In-Reply-To: <3E6CC480-E11B-4304-857D-E8603206ADDC@yahoo-inc.com> References: <3E6CC480-E11B-4304-857D-E8603206ADDC@yahoo-inc.com> Date: Thu, 8 Nov 2012 15:39:01 -0500 Message-ID: From: "Murray S. Kucherawy" To: Elizabeth Zwicky Content-Type: multipart/alternative; boundary=bcaec554025a468e2704ce01d316 Cc: "spfbis@ietf.org" , Franck Martin , Tim Draegen , Hector Santos Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:39:05 -0000 --bcaec554025a468e2704ce01d316 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Elizabeth, A specific goal of the proposed reorganization was to make no changes to the bits on the wire. So your latter observation appears to mean that goal was met. Thanks for having a look at it. -MSK On Wed, Nov 7, 2012 at 4:28 PM, Elizabeth Zwicky wrot= e: > > As the person who would have to coordinate Yahoo's implementation if > we were just now implementing SPF, I can say that the reorganization > goes a long way towards making the RFC easier to use. I appreciate that > reorganizations are a technical challenge while they are in progress, > but optimizing for the process right now rather than the many readers > down the road seems to me to be the wrong decision. > > As a receiver with SPF support I don't see how the proposed changes > would cause us to change our implementation; could somebody clarify > that for me? > > Elizabeth Zwicky > > On Nov 7, 2012, at 10:26 AM, Franck Martin wrote: > > > Hector, > > > > Murray has stated and several people have stated, they do not seek > > protocol change in this reorganization, but to follow Best Current > > Practices in writing a RFC. > > > > > This needs to look like a proper RFC, rather than a babel tower=C5=A0 > > > > We have only one good shot in making SPF a standard, let's not fail due > to > > poor grammar. > > > > On 11/7/12 8:53 AM, "Hector Santos" wrote: > > > >> I have a hard time understanding the focus and goal here for > >> reorganization. Please state the main purpose and goal to adopt > >> Murray's proposed changes. What is the benefits? > >> > >> In my engineering and product development opinion, the proposed > >> changes does alter the scope of the SPF framework (relatively to how > >> we have been using it for 9+years) and we are living proof that if we > >> follow the proposed changes, it will be a very costly design change > >> endeavor to the point we would have to consider the pros and cons and > >> most likely ignore the new considerations emphasized in the proposed > >> changes. I don't think this can't be "fixed" but it will does > >> required accepting the policies already established in SPF and how > >> these are functional specifications are translated into standard > >> technical specifications fitting into the SMTP state machine as a 5321 > >> technology, not 5322 technology. If we are focusing on 5322 > >> material, then the scope is changing. > >> > >> -- > >> HLS > >> > >> > >> Tim Draegen wrote: > >>> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan > >>> wrote: > >>>> Before going further, I'd like for participants in this debate to > state > >>>> where they stand with respect to the above arguments, and to clarify > >>>> what trade-offs they think are acceptable as a result. > >>> > >>> Andrew et al, my aim is help produce a Standards-track draft that mee= ts > >>> the needs of people outside of the IETF in as little time as possible= , > >>> and no less. > >>> > >>> In response to 3 arguments for proposed reorganization: > >>> > >>> - As an implementor I can wade through 4408 with a yellow high-lighte= r > >>> and sticky-notes until I get it. > >>> - As someone responsible for teaching others, I would greatly > >>> appreciate adoption of Murray's proposed reorganization. > >>> - As a rare participant in IETF process, I agree with the stance of "= we > >>> should clean it up now and not later".. pushing through an editoriall= y > >>> unchanged 4408 seems to me to miss the point of why we're all here > >>> (regardless of Chartering). > >>> > >>> In response to counter-arguments: > >>> - After review, Murray's proposed reorganization does not change the > >>> protocol, it only makes it easier for non-experts to understand. > >>> Perhaps oddly, I don't see the counter-arguments as such. I see the > >>> "move SPF from the experimental to the standards track" to mean > "prepare > >>> the document so that it behaves like other standards track documents"= , > >>> which Murray's proposed reorganization gets us closer to. > >>> - I do not find the the "accidental protocol changes" argument > >>> compelling, due to the passion, expertise, and character-by-character > >>> review that all participants in this WG give to proposed changes. > >>> - Similarly, the need-for-side-by-side-comparison argument is lost on > >>> me. Optimizing for easy-review is not on my list of concerns. I > >>> understand that there is risk whenever change is introduced, but the > >>> time to make change is when everyone is paying attention, which is no= w. > >>> > >>> Trade-offs for an acceptable result: > >>> - Commit to not changing the protocol; warts, macros, and all. > >>> - Recognize that the current draft does too much and interleaves too > >>> many topics to make it a proper IETF standard. The risk of the IESG > >>> kicking the draft back is one thing, but we might as well go all in t= o > >>> meet perceived IESG requirements AND produce a doc that technology > >>> generalists can read w/o importing the entire history of SPF into the= ir > >>> heads. > >>> - Everyone must commit to trying to "sneak in" at least 1 change. Th= is > >>> will keep everyone on their toes. > >>> > >>> Finally, I'd like to submit that the existing draft has done an > >>> excellent job of producing interoperable technology within the > community > >>> of email anti-abuse developers. In the move from Experimental to > >>> standards-track, though, the community will get larger, and therefore > >>> the specification needs to be editorially easier to ingest. > >>> > >>> See y'all tomorrow, > >>> =3D- Tim > >>> > >> > >> > >> > >> _______________________________________________ > >> spfbis mailing list > >> spfbis@ietf.org > >> https://www.ietf.org/mailman/listinfo/spfbis > > > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --bcaec554025a468e2704ce01d316 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Elizabeth,

A specific goal of the proposed reorganization was to = make no changes to the bits on the wire.=C2=A0 So your latter observation a= ppears to mean that goal was met.

Thanks for having a look at it.
-MSK


On We= d, Nov 7, 2012 at 4:28 PM, Elizabeth Zwicky <zwicky@yahoo-inc.com= > wrote:

As the person who would have to coordinate Yahoo's implementation if we were just now implementing SPF, I can say that the reorganization
goes a long way towards making the RFC easier to use. I appreciate that
reorganizations are a technical challenge while they are in progress,
but optimizing for the process right now rather than the many readers
down the road seems to me to be the wrong decision.

As a receiver with SPF support I don't see how the proposed changes
would cause us to change our implementation; could somebody clarify
that for me?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Elizabeth Zwicky

On Nov 7, 2012, at 10:26 AM, Franck Martin wrote:

> Hector,
>
> Murray has stated and several people have stated, they do not seek
> protocol change in this reorganization, but to follow Best Current
> Practices in writing a RFC.

>
> This needs to look like a proper RFC, rather than a babel tower=C5=A0<= br> >
> We have only one good shot in making SPF a standard, let's not fai= l due to
> poor grammar.
>
> On 11/7/12 8:53 AM, "Hector Santos" <hsantos@isdg.net> wrote:
>
>> I have a hard time understanding the focus and goal here for
>> reorganization. =C2=A0Please state the main purpose and goal to ad= opt
>> Murray's proposed changes. What is the benefits?
>>
>> In my engineering and product development opinion, the proposed >> changes does alter the scope of the SPF framework (relatively to h= ow
>> we have been using it for 9+years) and we are living proof that if= we
>> follow the proposed changes, it will be a very costly design chang= e
>> endeavor to the point we would have to consider the pros and cons = and
>> most likely ignore the new considerations emphasized in the propos= ed
>> changes. =C2=A0I don't think this can't be "fixed&quo= t; but it will does
>> required accepting the policies already established in SPF and how=
>> these are functional specifications are translated into standard >> technical specifications fitting into the SMTP state machine as a = 5321
>> technology, not 5322 technology. =C2=A0 If we are focusing on 5322=
>> material, then the scope is changing.
>>
>> --
>> HLS
>>
>>
>> Tim Draegen wrote:
>>> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan <ajs@anvilwalrusden.com>
>>> wrote:
>>>> Before going further, I'd like for participants in thi= s debate to state
>>>> where they stand with respect to the above arguments, and = to clarify
>>>> what trade-offs they think are acceptable as a result.
>>>
>>> Andrew et al, my aim is help produce a Standards-track draft t= hat meets
>>> the needs of people outside of the IETF in as little time as p= ossible,
>>> and no less.
>>>
>>> In response to 3 arguments for proposed reorganization:
>>>
>>> - As an implementor I can wade through 4408 with a yellow high= -lighter
>>> and sticky-notes until I get it.
>>> - As someone responsible for teaching others, I would greatly<= br> >>> appreciate adoption of Murray's proposed reorganization. >>> - As a rare participant in IETF process, I agree with the stan= ce of "we
>>> should clean it up now and not later".. pushing through a= n editorially
>>> unchanged 4408 seems to me to miss the point of why we're = all here
>>> (regardless of Chartering).
>>>
>>> In response to counter-arguments:
>>> - After review, Murray's proposed reorganization does not = change the
>>> protocol, it only makes it easier for non-experts to understan= d.
>>> Perhaps oddly, I don't see the counter-arguments as such. = =C2=A0I see the
>>> "move SPF from the experimental to the standards track&qu= ot; to mean "prepare
>>> the document so that it behaves like other standards track doc= uments",
>>> which Murray's proposed reorganization gets us closer to.<= br> >>> - I do not find the the "accidental protocol changes"= ; argument
>>> compelling, due to the passion, expertise, and character-by-ch= aracter
>>> review that all participants in this WG give to proposed chang= es.
>>> - Similarly, the need-for-side-by-side-comparison argument is = lost on
>>> me. =C2=A0Optimizing for easy-review is not on my list of conc= erns. =C2=A0I
>>> understand that there is risk whenever change is introduced, b= ut the
>>> time to make change is when everyone is paying attention, whic= h is now.
>>>
>>> Trade-offs for an acceptable result:
>>> - Commit to not changing the protocol; warts, macros, and all.=
>>> - Recognize that the current draft does too much and interleav= es too
>>> many topics to make it a proper IETF standard. =C2=A0The risk = of the IESG
>>> kicking the draft back is one thing, but we might as well go a= ll in to
>>> meet perceived IESG requirements AND produce a doc that techno= logy
>>> generalists can read w/o importing the entire history of SPF i= nto their
>>> heads.
>>> - Everyone must commit to trying to "sneak in" at le= ast 1 change. =C2=A0This
>>> will keep everyone on their toes.
>>>
>>> Finally, I'd like to submit that the existing draft has do= ne an
>>> excellent job of producing interoperable technology within the= community
>>> of email anti-abuse developers. =C2=A0In the move from Experim= ental to
>>> standards-track, though, the community will get larger, and th= erefore
>>> the specification needs to be editorially easier to ingest. >>>
>>> See y'all tomorrow,
>>> =3D- Tim
>>>
>>
>>
>>
>> _______________________________________________
>> spfbis mailing list
>> spfbis@ietf.org
>> https://www.ietf.org/mailman/listinfo/spfbis
>
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis

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

--bcaec554025a468e2704ce01d316-- From hsantos@isdg.net Thu Nov 8 13:32:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AF721F89E5 for ; Thu, 8 Nov 2012 13:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.807 X-Spam-Level: X-Spam-Status: No, score=-101.807 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4114ut3uZDFR for ; Thu, 8 Nov 2012 13:32:49 -0800 (PST) Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7C321F89EB for ; Thu, 8 Nov 2012 13:32:49 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6612; t=1352410360; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=+HT0CWBhuxLzB0f4qZwbxQRDgo0=; b=EqkLi+hEWfrgLk2+tz4b 2OH+fBYGT7zbzDVHaJyv9YA55AvR7YeYjH+Bc5HGB7X7k6GL3jltkBqH6/Zu2jYF Mq2fGpp4mPiLMJ3iRiaAmKpeF6mjVkLoxsRoy4S4uBo8rqXFEuS1BvgKBPqrlxCt Xd5e5ohvbykWVwDtOYscvzg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 08 Nov 2012 16:32:40 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4137113890.1525.3716; Thu, 08 Nov 2012 16:32:39 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6612; t=1352410034; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=MzkMCip nxZoPK/XHyDv5DdFlOx97fxDZY4hGHtO2qkA=; b=cuFhmFaeSqR64NeSLWxg9mi Spp3ZQp/rZKn9aVGROwcbTq6qsBibgWjzzpVFO1x5KnEatTz+9VJyuamOe+2dUdT 7aaO1VES+Ztx1/svRkGjYJoF6tp6c1SnSHM0AUjvNEO8B6IBhES8EJJL8CKYMGrU 375LmqgUmwl5gNHfsMvA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 08 Nov 2012 16:27:14 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 440897616.9.8088; Thu, 08 Nov 2012 16:27:13 -0500 Message-ID: <509C251C.1080801@isdg.net> Date: Thu, 08 Nov 2012 16:33:16 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <3E6CC480-E11B-4304-857D-E8603206ADDC@yahoo-inc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "spfbis@ietf.org" , Franck Martin , Tim Draegen , Elizabeth Zwicky Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:32:50 -0000 I am those who are not convinced that any not bits will not disturb the current stable electronic steady state "bits" propagations on the wire. Murray S. Kucherawy wrote: > Hi Elizabeth, > > A specific goal of the proposed reorganization was to make no changes to > the bits on the wire. So your latter observation appears to mean that goal > was met. > > Thanks for having a look at it. > > -MSK > > > On Wed, Nov 7, 2012 at 4:28 PM, Elizabeth Zwicky wrote: > >> As the person who would have to coordinate Yahoo's implementation if >> we were just now implementing SPF, I can say that the reorganization >> goes a long way towards making the RFC easier to use. I appreciate that >> reorganizations are a technical challenge while they are in progress, >> but optimizing for the process right now rather than the many readers >> down the road seems to me to be the wrong decision. >> >> As a receiver with SPF support I don't see how the proposed changes >> would cause us to change our implementation; could somebody clarify >> that for me? >> >> Elizabeth Zwicky >> >> On Nov 7, 2012, at 10:26 AM, Franck Martin wrote: >> >>> Hector, >>> >>> Murray has stated and several people have stated, they do not seek >>> protocol change in this reorganization, but to follow Best Current >>> Practices in writing a RFC. >>> This needs to look like a proper RFC, rather than a babel towerŠ >>> >>> We have only one good shot in making SPF a standard, let's not fail due >> to >>> poor grammar. >>> >>> On 11/7/12 8:53 AM, "Hector Santos" wrote: >>> >>>> I have a hard time understanding the focus and goal here for >>>> reorganization. Please state the main purpose and goal to adopt >>>> Murray's proposed changes. What is the benefits? >>>> >>>> In my engineering and product development opinion, the proposed >>>> changes does alter the scope of the SPF framework (relatively to how >>>> we have been using it for 9+years) and we are living proof that if we >>>> follow the proposed changes, it will be a very costly design change >>>> endeavor to the point we would have to consider the pros and cons and >>>> most likely ignore the new considerations emphasized in the proposed >>>> changes. I don't think this can't be "fixed" but it will does >>>> required accepting the policies already established in SPF and how >>>> these are functional specifications are translated into standard >>>> technical specifications fitting into the SMTP state machine as a 5321 >>>> technology, not 5322 technology. If we are focusing on 5322 >>>> material, then the scope is changing. >>>> >>>> -- >>>> HLS >>>> >>>> >>>> Tim Draegen wrote: >>>>> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan >>>>> wrote: >>>>>> Before going further, I'd like for participants in this debate to >> state >>>>>> where they stand with respect to the above arguments, and to clarify >>>>>> what trade-offs they think are acceptable as a result. >>>>> Andrew et al, my aim is help produce a Standards-track draft that meets >>>>> the needs of people outside of the IETF in as little time as possible, >>>>> and no less. >>>>> >>>>> In response to 3 arguments for proposed reorganization: >>>>> >>>>> - As an implementor I can wade through 4408 with a yellow high-lighter >>>>> and sticky-notes until I get it. >>>>> - As someone responsible for teaching others, I would greatly >>>>> appreciate adoption of Murray's proposed reorganization. >>>>> - As a rare participant in IETF process, I agree with the stance of "we >>>>> should clean it up now and not later".. pushing through an editorially >>>>> unchanged 4408 seems to me to miss the point of why we're all here >>>>> (regardless of Chartering). >>>>> >>>>> In response to counter-arguments: >>>>> - After review, Murray's proposed reorganization does not change the >>>>> protocol, it only makes it easier for non-experts to understand. >>>>> Perhaps oddly, I don't see the counter-arguments as such. I see the >>>>> "move SPF from the experimental to the standards track" to mean >> "prepare >>>>> the document so that it behaves like other standards track documents", >>>>> which Murray's proposed reorganization gets us closer to. >>>>> - I do not find the the "accidental protocol changes" argument >>>>> compelling, due to the passion, expertise, and character-by-character >>>>> review that all participants in this WG give to proposed changes. >>>>> - Similarly, the need-for-side-by-side-comparison argument is lost on >>>>> me. Optimizing for easy-review is not on my list of concerns. I >>>>> understand that there is risk whenever change is introduced, but the >>>>> time to make change is when everyone is paying attention, which is now. >>>>> >>>>> Trade-offs for an acceptable result: >>>>> - Commit to not changing the protocol; warts, macros, and all. >>>>> - Recognize that the current draft does too much and interleaves too >>>>> many topics to make it a proper IETF standard. The risk of the IESG >>>>> kicking the draft back is one thing, but we might as well go all in to >>>>> meet perceived IESG requirements AND produce a doc that technology >>>>> generalists can read w/o importing the entire history of SPF into their >>>>> heads. >>>>> - Everyone must commit to trying to "sneak in" at least 1 change. This >>>>> will keep everyone on their toes. >>>>> >>>>> Finally, I'd like to submit that the existing draft has done an >>>>> excellent job of producing interoperable technology within the >> community >>>>> of email anti-abuse developers. In the move from Experimental to >>>>> standards-track, though, the community will get larger, and therefore >>>>> the specification needs to be editorially easier to ingest. >>>>> >>>>> See y'all tomorrow, >>>>> =- Tim >>>>> >>>> >>>> >>>> _______________________________________________ >>>> spfbis mailing list >>>> spfbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spfbis >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- HLS From hsantos@isdg.net Thu Nov 8 13:33: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 B39DA21F8A48 for ; Thu, 8 Nov 2012 13:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcsVGJzQxCYG for ; Thu, 8 Nov 2012 13:33:19 -0800 (PST) Received: from winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9562821F8685 for ; Thu, 8 Nov 2012 13:33:19 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6627; t=1352410396; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ear605fvRXRDla/pxxtKr5j2seM=; b=QdNpNJlzza8bD040PCM0 FtoW7AlZwniOhgv5REG3Yu+pwc0ExGbrUz46F+5quGu1YLVqsRXioAXUWgBbHDcZ ckKkudhzSdQcoWvEiHECXmPdsPTK1m47573V/H/vSfKYdWP9Sx2mJHUyt1uSiS8L Jxs/MFltJJy7W5i97an+pjg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 08 Nov 2012 16:33:16 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4137149474.1525.5896; Thu, 08 Nov 2012 16:33:15 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6627; t=1352410069; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=78Yp2bD cy4uI5rK2HyR35NsAz8Mtghot37Tl5MD3PkE=; b=0Ttc0cb+d9KsuSYhft2q5SK zk8TjOljhWLiCk7Kxx+J2NSdV7PQCxVenrzV/5c+BYMfayRlysS7Y50SiSRi59rA dvUfjD4p/FH2G1X9CD8ZV0hClFuYaBv0vKEQv9juUqEjS3OuOXuXMBJi717iDBjt ffjMB4GUxdGwbkfbjjCA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 08 Nov 2012 16:27:49 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 440932632.9.5336; Thu, 08 Nov 2012 16:27:48 -0500 Message-ID: <509C2540.8080705@isdg.net> Date: Thu, 08 Nov 2012 16:33:52 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <3E6CC480-E11B-4304-857D-E8603206ADDC@yahoo-inc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "spfbis@ietf.org" , Franck Martin , Tim Draegen , Elizabeth Zwicky Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:33:20 -0000 Typo fit: I am those who are not convinced that any [NEW] bits will not disturb the current stable electronic steady state "bits" propagations on the wire. Murray S. Kucherawy wrote: > Hi Elizabeth, > > A specific goal of the proposed reorganization was to make no changes to > the bits on the wire. So your latter observation appears to mean that goal > was met. > > Thanks for having a look at it. > > -MSK > > > On Wed, Nov 7, 2012 at 4:28 PM, Elizabeth Zwicky wrote: > >> As the person who would have to coordinate Yahoo's implementation if >> we were just now implementing SPF, I can say that the reorganization >> goes a long way towards making the RFC easier to use. I appreciate that >> reorganizations are a technical challenge while they are in progress, >> but optimizing for the process right now rather than the many readers >> down the road seems to me to be the wrong decision. >> >> As a receiver with SPF support I don't see how the proposed changes >> would cause us to change our implementation; could somebody clarify >> that for me? >> >> Elizabeth Zwicky >> >> On Nov 7, 2012, at 10:26 AM, Franck Martin wrote: >> >>> Hector, >>> >>> Murray has stated and several people have stated, they do not seek >>> protocol change in this reorganization, but to follow Best Current >>> Practices in writing a RFC. >>> This needs to look like a proper RFC, rather than a babel towerŠ >>> >>> We have only one good shot in making SPF a standard, let's not fail due >> to >>> poor grammar. >>> >>> On 11/7/12 8:53 AM, "Hector Santos" wrote: >>> >>>> I have a hard time understanding the focus and goal here for >>>> reorganization. Please state the main purpose and goal to adopt >>>> Murray's proposed changes. What is the benefits? >>>> >>>> In my engineering and product development opinion, the proposed >>>> changes does alter the scope of the SPF framework (relatively to how >>>> we have been using it for 9+years) and we are living proof that if we >>>> follow the proposed changes, it will be a very costly design change >>>> endeavor to the point we would have to consider the pros and cons and >>>> most likely ignore the new considerations emphasized in the proposed >>>> changes. I don't think this can't be "fixed" but it will does >>>> required accepting the policies already established in SPF and how >>>> these are functional specifications are translated into standard >>>> technical specifications fitting into the SMTP state machine as a 5321 >>>> technology, not 5322 technology. If we are focusing on 5322 >>>> material, then the scope is changing. >>>> >>>> -- >>>> HLS >>>> >>>> >>>> Tim Draegen wrote: >>>>> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan >>>>> wrote: >>>>>> Before going further, I'd like for participants in this debate to >> state >>>>>> where they stand with respect to the above arguments, and to clarify >>>>>> what trade-offs they think are acceptable as a result. >>>>> Andrew et al, my aim is help produce a Standards-track draft that meets >>>>> the needs of people outside of the IETF in as little time as possible, >>>>> and no less. >>>>> >>>>> In response to 3 arguments for proposed reorganization: >>>>> >>>>> - As an implementor I can wade through 4408 with a yellow high-lighter >>>>> and sticky-notes until I get it. >>>>> - As someone responsible for teaching others, I would greatly >>>>> appreciate adoption of Murray's proposed reorganization. >>>>> - As a rare participant in IETF process, I agree with the stance of "we >>>>> should clean it up now and not later".. pushing through an editorially >>>>> unchanged 4408 seems to me to miss the point of why we're all here >>>>> (regardless of Chartering). >>>>> >>>>> In response to counter-arguments: >>>>> - After review, Murray's proposed reorganization does not change the >>>>> protocol, it only makes it easier for non-experts to understand. >>>>> Perhaps oddly, I don't see the counter-arguments as such. I see the >>>>> "move SPF from the experimental to the standards track" to mean >> "prepare >>>>> the document so that it behaves like other standards track documents", >>>>> which Murray's proposed reorganization gets us closer to. >>>>> - I do not find the the "accidental protocol changes" argument >>>>> compelling, due to the passion, expertise, and character-by-character >>>>> review that all participants in this WG give to proposed changes. >>>>> - Similarly, the need-for-side-by-side-comparison argument is lost on >>>>> me. Optimizing for easy-review is not on my list of concerns. I >>>>> understand that there is risk whenever change is introduced, but the >>>>> time to make change is when everyone is paying attention, which is now. >>>>> >>>>> Trade-offs for an acceptable result: >>>>> - Commit to not changing the protocol; warts, macros, and all. >>>>> - Recognize that the current draft does too much and interleaves too >>>>> many topics to make it a proper IETF standard. The risk of the IESG >>>>> kicking the draft back is one thing, but we might as well go all in to >>>>> meet perceived IESG requirements AND produce a doc that technology >>>>> generalists can read w/o importing the entire history of SPF into their >>>>> heads. >>>>> - Everyone must commit to trying to "sneak in" at least 1 change. This >>>>> will keep everyone on their toes. >>>>> >>>>> Finally, I'd like to submit that the existing draft has done an >>>>> excellent job of producing interoperable technology within the >> community >>>>> of email anti-abuse developers. In the move from Experimental to >>>>> standards-track, though, the community will get larger, and therefore >>>>> the specification needs to be editorially easier to ingest. >>>>> >>>>> See y'all tomorrow, >>>>> =- Tim >>>>> >>>> >>>> >>>> _______________________________________________ >>>> spfbis mailing list >>>> spfbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spfbis >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- HLS From kurt.andersen@hp.com Thu Nov 8 14:31:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FCF21F894D for ; Thu, 8 Nov 2012 14:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm-wdNZCypXL for ; Thu, 8 Nov 2012 14:31:06 -0800 (PST) Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by ietfa.amsl.com (Postfix) with ESMTP id A188A21F88B4 for ; Thu, 8 Nov 2012 14:31:06 -0800 (PST) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id 3256614016 for ; Thu, 8 Nov 2012 22:31:04 +0000 (UTC) Received: from G9W2161G.americas.hpqcorp.net (16.216.113.179) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 8 Nov 2012 22:29:51 +0000 Received: from G9W0761.americas.hpqcorp.net ([169.254.1.56]) by G9W2161G.americas.hpqcorp.net ([16.216.113.179]) with mapi id 14.02.0283.004; Thu, 8 Nov 2012 22:29:51 +0000 From: "Andersen, Kurt" To: "spfbis@ietf.org" Thread-Topic: Meetecho seems overloaded; +1 for Tim Draegon opinion re restructuring Thread-Index: Ac2+AHMtuxfATPs2SXeivRlgcBWmFw== Date: Thu, 8 Nov 2012 22:29:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.210.48.13] Content-Type: multipart/alternative; boundary="_000_BC48C1C9D29CDF4FB048F42DE0D619CC4807F6AAG9W0761americas_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Nov 2012 14:38:15 -0800 Subject: [spfbis] Meetecho seems overloaded; +1 for Tim Draegon opinion re restructuring X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 22:31:07 -0000 --_000_BC48C1C9D29CDF4FB048F42DE0D619CC4807F6AAG9W0761americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In case I can't get into the remote participation system (it's not looking = good right now), +1 for restructuring based on Tim Draegon's position state= ment re. educational usage. --Kurt Andersen --_000_BC48C1C9D29CDF4FB048F42DE0D619CC4807F6AAG9W0761americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In case I can’t get into the remote participat= ion system (it’s not looking good right now), +1 for restructurin= g based on Tim Draegon’s position statement re. educational usage.

 

--Kurt Andersen

--_000_BC48C1C9D29CDF4FB048F42DE0D619CC4807F6AAG9W0761americas_-- From sm@elandsys.com Thu Nov 8 14:41:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADC621F88B4 for ; Thu, 8 Nov 2012 14:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Crd-Kdgvxk4W for ; Thu, 8 Nov 2012 14:41:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E0521F880A for ; Thu, 8 Nov 2012 14:41:21 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.146.33]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA8Mf27i008968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 14:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352414474; bh=SJ1rnQUrGmEzKuFPKVaSyQNFqEKOW93KsrZpYN9qQVY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=I2rD8yvZ476k+myFHUPR8gKm1EthpumABilyV6oMkcUCXqAL4ZzRl6szYw3Jf/1Ds Vn0kDYNHDEbZ0lEbRCO2iIjtNS2NiVqXs1JRMTUO/NIoO9u8eiRg+ZwkLvHsXOyrVK Y0Ph0LvppkArXooASpUHxd7kOxX38kKvtmI6Zc90= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352414474; i=@elandsys.com; bh=SJ1rnQUrGmEzKuFPKVaSyQNFqEKOW93KsrZpYN9qQVY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rYol2OexIzRL79XtHxpbB6939AsKvybrW/y1Gus6EukB66rMtumjOgUT0DhsuggWu jvU/dHn/I9vZh03Wv1kUAnZrSB7CDyyn+JeFT2mlYlq5ej9z6N4hX8t7bQFMwpkbFW slSeX/iMl9uqgsu7bKjxcCVq4I4tzRY2n70AjFmQ= Message-Id: <6.2.5.6.2.20121108143853.06428218@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Nov 2012 14:40:50 -0800 To: "Andersen, Kurt" From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Meetecho seems overloaded; +1 for Tim Draegon opinion re restructuring X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 22:41:22 -0000 Hi Kurt, At 14:29 08-11-2012, Andersen, Kurt wrote: >In case I can't get into the remote participation system (it's not >looking good right now), +1 for restructuring based on Tim Draegon's >position statement re. educational usage. Could you try Jabber ( xmpp:spfbis@jabber.ietf.org ) and the audio feed? You'll find the details at http://www.ietf.org/mail-archive/web/spfbis/current/msg02969.html Regards, S. Moonesamy From zwicky@yahoo-inc.com Thu Nov 8 16:18: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 F1D2621F8487 for ; Thu, 8 Nov 2012 16:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.8 X-Spam-Level: X-Spam-Status: No, score=-17.8 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYonoczxawSf for ; Thu, 8 Nov 2012 16:18:26 -0800 (PST) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id DBE3A21F853B for ; Thu, 8 Nov 2012 16:18:25 -0800 (PST) Received: from SP1-EX07CAS04.ds.corp.yahoo.com (sp1-ex07cas04.corp.sp1.yahoo.com [216.252.116.155]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id qA90Ht7t003829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 8 Nov 2012 16:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1352420277; bh=DhXKRjnaGeLRv2U025iE3w3GI5S4bnwg7ISNTUNgbqw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Zzsjhio1ukL9Q5jWONEWKUmEG4K6fj0M7+DvwCcCRLSYdGMBpsOf5gBr9vMBjgLUw 7wq3+RS5ANTJXtg7GKIfsoSaGWc8G3NmmrfDhZhqlTQfv0LAHYBCJEKs/k7htU/+YA UkCEZ/nEi2JNgAq32SIvGwXY1y30a/FXVsYE1e68= Received: from SP1-EX07VS01.ds.corp.yahoo.com ([216.252.116.136]) by SP1-EX07CAS04.ds.corp.yahoo.com ([216.252.116.158]) with mapi; Thu, 8 Nov 2012 16:17:55 -0800 From: Elizabeth Zwicky To: Hector Santos Date: Thu, 8 Nov 2012 16:17:53 -0800 Thread-Topic: [spfbis] Goals of this discussion Thread-Index: Ac2+D6mOkhHEuDqSRtOUxwd5Kazbfw== Message-ID: <9345F154-B1FD-4A82-94AD-D91A047ADE28@yahoo-inc.com> References: <3E6CC480-E11B-4304-857D-E8603206ADDC@yahoo-inc.com> <509C2540.8080705@isdg.net> In-Reply-To: <509C2540.8080705@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 420276001 Cc: "spfbis@ietf.org" , Franck Martin , Tim Draegen , "Murray S. Kucherawy" Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 09 Nov 2012 00:18:27 -0000 I'm still not clear here. Do you see changes I will need to make to my impl= ementation based on the reorganization, or is the concern that new implementations wil= l be different than the old ones? If the latter, different in incompatible ways,= or in undesirable ways? Elizabeth On Nov 8, 2012, at 1:33 PM, Hector Santos wrote: > Typo fit: >=20 > I am those who are not convinced that any [NEW] bits will not disturb > the current stable electronic steady state "bits" propagations on the > wire. >=20 > Murray S. Kucherawy wrote: >> Hi Elizabeth, >>=20 >> A specific goal of the proposed reorganization was to make no changes to >> the bits on the wire. So your latter observation appears to mean that g= oal >> was met. >>=20 >> Thanks for having a look at it. >>=20 >> -MSK >>=20 >>=20 >> On Wed, Nov 7, 2012 at 4:28 PM, Elizabeth Zwicky w= rote: >>=20 >>> As the person who would have to coordinate Yahoo's implementation if >>> we were just now implementing SPF, I can say that the reorganization >>> goes a long way towards making the RFC easier to use. I appreciate that >>> reorganizations are a technical challenge while they are in progress, >>> but optimizing for the process right now rather than the many readers >>> down the road seems to me to be the wrong decision. >>>=20 >>> As a receiver with SPF support I don't see how the proposed changes >>> would cause us to change our implementation; could somebody clarify >>> that for me? >>>=20 >>> Elizabeth Zwicky >>>=20 >>> On Nov 7, 2012, at 10:26 AM, Franck Martin wrote: >>>=20 >>>> Hector, >>>>=20 >>>> Murray has stated and several people have stated, they do not seek >>>> protocol change in this reorganization, but to follow Best Current >>>> Practices in writing a RFC. >>>> This needs to look like a proper RFC, rather than a babel tower=8A >>>>=20 >>>> We have only one good shot in making SPF a standard, let's not fail du= e >>> to >>>> poor grammar. >>>>=20 >>>> On 11/7/12 8:53 AM, "Hector Santos" wrote: >>>>=20 >>>>> I have a hard time understanding the focus and goal here for >>>>> reorganization. Please state the main purpose and goal to adopt >>>>> Murray's proposed changes. What is the benefits? >>>>>=20 >>>>> In my engineering and product development opinion, the proposed >>>>> changes does alter the scope of the SPF framework (relatively to how >>>>> we have been using it for 9+years) and we are living proof that if we >>>>> follow the proposed changes, it will be a very costly design change >>>>> endeavor to the point we would have to consider the pros and cons and >>>>> most likely ignore the new considerations emphasized in the proposed >>>>> changes. I don't think this can't be "fixed" but it will does >>>>> required accepting the policies already established in SPF and how >>>>> these are functional specifications are translated into standard >>>>> technical specifications fitting into the SMTP state machine as a 532= 1 >>>>> technology, not 5322 technology. If we are focusing on 5322 >>>>> material, then the scope is changing. >>>>>=20 >>>>> -- >>>>> HLS >>>>>=20 >>>>>=20 >>>>> Tim Draegen wrote: >>>>>> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan >>>>>> wrote: >>>>>>> Before going further, I'd like for participants in this debate to >>> state >>>>>>> where they stand with respect to the above arguments, and to clarif= y >>>>>>> what trade-offs they think are acceptable as a result. >>>>>> Andrew et al, my aim is help produce a Standards-track draft that me= ets >>>>>> the needs of people outside of the IETF in as little time as possibl= e, >>>>>> and no less. >>>>>>=20 >>>>>> In response to 3 arguments for proposed reorganization: >>>>>>=20 >>>>>> - As an implementor I can wade through 4408 with a yellow high-light= er >>>>>> and sticky-notes until I get it. >>>>>> - As someone responsible for teaching others, I would greatly >>>>>> appreciate adoption of Murray's proposed reorganization. >>>>>> - As a rare participant in IETF process, I agree with the stance of = "we >>>>>> should clean it up now and not later".. pushing through an editorial= ly >>>>>> unchanged 4408 seems to me to miss the point of why we're all here >>>>>> (regardless of Chartering). >>>>>>=20 >>>>>> In response to counter-arguments: >>>>>> - After review, Murray's proposed reorganization does not change the >>>>>> protocol, it only makes it easier for non-experts to understand. >>>>>> Perhaps oddly, I don't see the counter-arguments as such. I see the >>>>>> "move SPF from the experimental to the standards track" to mean >>> "prepare >>>>>> the document so that it behaves like other standards track documents= ", >>>>>> which Murray's proposed reorganization gets us closer to. >>>>>> - I do not find the the "accidental protocol changes" argument >>>>>> compelling, due to the passion, expertise, and character-by-characte= r >>>>>> review that all participants in this WG give to proposed changes. >>>>>> - Similarly, the need-for-side-by-side-comparison argument is lost o= n >>>>>> me. Optimizing for easy-review is not on my list of concerns. I >>>>>> understand that there is risk whenever change is introduced, but the >>>>>> time to make change is when everyone is paying attention, which is n= ow. >>>>>>=20 >>>>>> Trade-offs for an acceptable result: >>>>>> - Commit to not changing the protocol; warts, macros, and all. >>>>>> - Recognize that the current draft does too much and interleaves too >>>>>> many topics to make it a proper IETF standard. The risk of the IESG >>>>>> kicking the draft back is one thing, but we might as well go all in = to >>>>>> meet perceived IESG requirements AND produce a doc that technology >>>>>> generalists can read w/o importing the entire history of SPF into th= eir >>>>>> heads. >>>>>> - Everyone must commit to trying to "sneak in" at least 1 change. T= his >>>>>> will keep everyone on their toes. >>>>>>=20 >>>>>> Finally, I'd like to submit that the existing draft has done an >>>>>> excellent job of producing interoperable technology within the >>> community >>>>>> of email anti-abuse developers. In the move from Experimental to >>>>>> standards-track, though, the community will get larger, and therefor= e >>>>>> the specification needs to be editorially easier to ingest. >>>>>>=20 >>>>>> See y'all tomorrow, >>>>>> =3D- Tim >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> spfbis mailing list >>>>> spfbis@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spfbis >>>> _______________________________________________ >>>> spfbis mailing list >>>> spfbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spfbis >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >>>=20 >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >=20 > --=20 > HLS >=20 >=20 >=20 From spf2@kitterman.com Fri Nov 9 06:29:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B2721F8690 for ; Fri, 9 Nov 2012 06:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbpfWtyoeYKd for ; Fri, 9 Nov 2012 06:29:33 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8108321F868E for ; Fri, 9 Nov 2012 06:29:33 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A824F20E411E; Fri, 9 Nov 2012 09:29:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352471372; bh=B45NiuvgcG71KbSf4JWhclr3R8fpuJ6tk4/F8g3ZnF8=; h=From:To:Subject:Date:From; b=oy812n/neESSRjSDA5GiNwAqfvyFODdv+yOqsQ3ao1hmi2px/NehzGfOPVlOV2y+T W4VKdrR2qr2LnznxTBEU5h5GmNBC/EETN0bQkCI8nPH8Wc9X/YgVPfY/lMgb0H5Hvb 3SqGJTqqFdcPeC2IXk2g5XQdS2mw7FvBkD4+LQ88= Received: from scott-latitude-e6320.localnet (41.sub-70-193-131.myvzw.com [70.193.131.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0536F20E409E; Fri, 9 Nov 2012 09:29:31 -0500 (EST) From: Scott Kitterman To: "spfbis@ietf.org" Date: Fri, 09 Nov 2012 09:29:29 -0500 Message-ID: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-17-generic; KDE/4.9.2; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:29:34 -0000 We've discussed off and on the question of if people reject mail based on SPF. I thought I'd pass on this anecdote (I know it provides no statistical insight into the question, but found it sufficiently amusing to pass on). Microsoft is publishing an invalid DNS record (exceeds the DNS lookup limit). For reasons that are beyond me, they do this from time to time. This morning I was treated to an irate email from a Microsoft employee complaining that my SPF record validation tool (http://www.kitterman.com/spf/validate.html) was causing Microsoft email to be rejected and demanding I fix the problem with my system. My reply was probably not a polite as it could have been, but I did suggest that perhaps if Microsoft was having trouble sending mail due to SPF failures, they ought to look in the mirror. So this was a case of reject on permerror, which is the default for a lot of the open source implementations. Scott K From dhc@dcrocker.net Fri Nov 9 06:48:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D15621F848B for ; Fri, 9 Nov 2012 06:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfFkvtMgBWPy for ; Fri, 9 Nov 2012 06:48:50 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 685A921F8484 for ; Fri, 9 Nov 2012 06:48:50 -0800 (PST) Received: from [10.16.88.13] (65-50-0-4.ips.direcpath.com [65.50.0.4] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id qA9Emmcf015372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Nov 2012 06:48:49 -0800 Message-ID: <509D17C7.7050300@dcrocker.net> Date: Fri, 09 Nov 2012 09:48:39 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Scott Kitterman References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> In-Reply-To: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 09 Nov 2012 06:48:50 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:48:51 -0000 I'm not seeing a natural place for this issue in the spfbis specification organization that Murray has proposed, other than perhaps some general statements in the early input/output/context section that should warn that spf is "merely" a component of a larger engine. But maybe a more extended and even normative discuss in: Section 8: Details about Outputs, Pedagogy, Interpretation Or perhaps a separate operational considerations document? d/ On 11/9/2012 9:29 AM, Scott Kitterman wrote: > We've discussed off and on the question of if people reject mail based on SPF. > I thought I'd pass on this anecdote (I know it provides no statistical insight > into the question, but found it sufficiently amusing to pass on). > > Microsoft is publishing an invalid DNS record (exceeds the DNS lookup limit). > For reasons that are beyond me, they do this from time to time. This morning > I was treated to an irate email from a Microsoft employee complaining that my > SPF record validation tool (http://www.kitterman.com/spf/validate.html) was > causing Microsoft email to be rejected and demanding I fix the problem with my > system. > > My reply was probably not a polite as it could have been, but I did suggest > that perhaps if Microsoft was having trouble sending mail due to SPF failures, > they ought to look in the mirror. > > So this was a case of reject on permerror, which is the default for a lot of > the open source implementations. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Fri Nov 9 07:05:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C719421F885B for ; Fri, 9 Nov 2012 07:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.831 X-Spam-Level: X-Spam-Status: No, score=-0.831 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+i43Ta0+mLe for ; Fri, 9 Nov 2012 07:05:31 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5217F21F8857 for ; Fri, 9 Nov 2012 07:05:31 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id CC7628A031 for ; Fri, 9 Nov 2012 15:05:30 +0000 (UTC) Date: Fri, 9 Nov 2012 10:05:23 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20121109150523.GE79908@mx1.yitter.info> References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <509D17C7.7050300@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:05:31 -0000 A question from a puzzled chair: On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote: > I'm not seeing a natural place for this issue in the spfbis > specification organization that Murray has proposed, other than > perhaps some general statements in the early input/output/context > section that should warn that spf is "merely" a component of a > larger engine. I am inclined to think that this topic is part of the operational/applicability statement work for which we are not chartered, but that people have suggested as a natural thing to do once our current work is completed. I'd be very interested in arguments about why that is _not_ the case. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Fri Nov 9 07:26: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 23E4321F857C for ; Fri, 9 Nov 2012 07:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elzoWUtqd8u3 for ; Fri, 9 Nov 2012 07:26:00 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E192221F855E for ; Fri, 9 Nov 2012 07:25:59 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so3401380lbo.31 for ; Fri, 09 Nov 2012 07:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DGPVJRRR36zMB+MfpYPF2Jr+yyLeN/Me4MzNEKYrzDQ=; b=PtUmYwkDpz2QRnO+dikT9/U8LS1+JsZvYk6YQIrBmMSp5czlTP+zZYJ2BeZvDyYVcx lJY81AEP2yzV7wPAmvXNB0bqty6EzY2BbyPU5lkgNDSDjcbfWVhwBjwpXYWY+GgbY6JK v0RyBXYz7gK5LxjMlsshGM+4kBPiyGwRFns0D6XAbS+VH3nMeHtXY139L6Cpb1uaJQzs yYDVmrunxp7cbVFUJc6MfOxvknydtvBXc1gvjXJHaEqTqrGQ2TLdMh/Do2BU6ajuhKLP f97665xU8dBAbh31Cwx69Lo3aDwpRX9TvE98fRRm/jLle6j7YJuUVZe5fktxWj5MLlaL QohQ== MIME-Version: 1.0 Received: by 10.152.114.65 with SMTP id je1mr4843619lab.33.1352474758867; Fri, 09 Nov 2012 07:25:58 -0800 (PST) Received: by 10.112.83.232 with HTTP; Fri, 9 Nov 2012 07:25:58 -0800 (PST) In-Reply-To: <20121109150523.GE79908@mx1.yitter.info> References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> Date: Fri, 9 Nov 2012 10:25:58 -0500 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d0408386591ea4704ce1191a6 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:26:04 -0000 --f46d0408386591ea4704ce1191a6 Content-Type: text/plain; charset=ISO-8859-1 I agree, but I also think that if advice like this belongs outside our single current deliverable, then we need to revisit the split topic that received no support yesterday. To put it another way: Why should this topic go in an external document, while other what-to-do-with-a-given-result discussion stays in the main draft? -MSK On Fri, Nov 9, 2012 at 10:05 AM, Andrew Sullivan wrote: > A question from a puzzled chair: > > On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote: > > I'm not seeing a natural place for this issue in the spfbis > > specification organization that Murray has proposed, other than > > perhaps some general statements in the early input/output/context > > section that should warn that spf is "merely" a component of a > > larger engine. > > I am inclined to think that this topic is part of the > operational/applicability statement work for which we are not > chartered, but that people have suggested as a natural thing to do > once our current work is completed. > > I'd be very interested in arguments about why that is _not_ the case. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d0408386591ea4704ce1191a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree, but I also think that if advice like this belongs outside our sing= le current deliverable, then we need to revisit the split topic that receiv= ed no support yesterday.

To put it another way: Why should this topi= c go in an external document, while other what-to-do-with-a-given-result di= scussion stays in the main draft?

-MSK


O= n Fri, Nov 9, 2012 at 10:05 AM, Andrew Sullivan <ajs@anvilwalrusden.c= om> wrote:
A question from a puzzled chair:

On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote:
> I'm not seeing a natural place for this issue in the spfbis
> specification organization that Murray has proposed, other than
> perhaps some general statements in the early input/output/context
> section that should warn that spf is "merely" a component of= a
> larger engine.

I am inclined to think that this topic is part of the
operational/applicability statement work for which we are not
chartered, but that people have suggested as a natural thing to do
once our current work is completed.

I'd be very interested in arguments about why that is _not_ the case.
Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________= __________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d0408386591ea4704ce1191a6-- From superuser@gmail.com Fri Nov 9 07:26: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 EFFD421F8585 for ; Fri, 9 Nov 2012 07:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gymQjEKU8xlj for ; Fri, 9 Nov 2012 07:26:48 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C685A21F8583 for ; Fri, 9 Nov 2012 07:26:47 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so3345358lam.31 for ; Fri, 09 Nov 2012 07:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V4L+qMrvfzL+OmtxW1aFKQxwl0hE02TxvIjs5VeAQIQ=; b=qxZdq4zmBJOoFmVmMnLemDdm/GXNZ2GRRPILxcujC2kTQ6CFy/PPGuXvIRx0Va4AYg Vis39T77HcpFfmKYlj3jMIWEWLGU4SuRxrgbYA12H+REEi8DGzT+1G+SpEOoGK2yCNiu cr+gzsqk6WpxUo2n72qVW9HUQlwf3prpJi+PGLhwHGcjM2I0EY/yGmLvar60Z9eS3vXy bzq8NiMLTFXHTWqhwE8vmLU2q3lhokvTDKtSvnEZlx5DYs9wNt6EBFdUdAAgEGJaqx8w JnEVP9Abg3Gr18EgNZLZGmto2jWq8owU9YiH06J2AtxQR6pKxyCXXQifRt+y9QFr1pnc pbfQ== MIME-Version: 1.0 Received: by 10.152.102.234 with SMTP id fr10mr11050853lab.28.1352474806689; Fri, 09 Nov 2012 07:26:46 -0800 (PST) Received: by 10.112.83.232 with HTTP; Fri, 9 Nov 2012 07:26:46 -0800 (PST) In-Reply-To: References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> Date: Fri, 9 Nov 2012 10:26:46 -0500 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d040712596ba13c04ce119446 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:26:49 -0000 --f46d040712596ba13c04ce119446 Content-Type: text/plain; charset=ISO-8859-1 Just to clarify: I actually don't care which path we take, but we need to be consistent. -MSK On Fri, Nov 9, 2012 at 10:25 AM, Murray S. Kucherawy wrote: > I agree, but I also think that if advice like this belongs outside our > single current deliverable, then we need to revisit the split topic that > received no support yesterday. > > To put it another way: Why should this topic go in an external document, > while other what-to-do-with-a-given-result discussion stays in the main > draft? > > -MSK > > > > On Fri, Nov 9, 2012 at 10:05 AM, Andrew Sullivan wrote: > >> A question from a puzzled chair: >> >> On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote: >> > I'm not seeing a natural place for this issue in the spfbis >> > specification organization that Murray has proposed, other than >> > perhaps some general statements in the early input/output/context >> > section that should warn that spf is "merely" a component of a >> > larger engine. >> >> I am inclined to think that this topic is part of the >> operational/applicability statement work for which we are not >> chartered, but that people have suggested as a natural thing to do >> once our current work is completed. >> >> I'd be very interested in arguments about why that is _not_ the case. >> >> Best, >> >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > > --f46d040712596ba13c04ce119446 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just to clarify: I actually don't care which path we take, but we need = to be consistent.

-MSK


On Fri, Nov 9, 2012 at 10:25 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
I agree, but I also think that if advice lik= e this belongs outside our single current deliverable, then we need to revi= sit the split topic that received no support yesterday.

To put it another way: Why should this topic go in an external document= , while other what-to-do-with-a-given-result discussion stays in the main d= raft?

-MSK



On Fri, Nov 9, 2012 at= 10:05 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wro= te:
A question from a puzzled chair:

On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote:
> I'm not seeing a natural place for this issue in the spfbis
> specification organization that Murray has proposed, other than
> perhaps some general statements in the early input/output/context
> section that should warn that spf is "merely" a component of= a
> larger engine.

I am inclined to think that this topic is part of the
operational/applicability statement work for which we are not
chartered, but that people have suggested as a natural thing to do
once our current work is completed.

I'd be very interested in arguments about why that is _not_ the case.
Best,

A

--
Andrew Sullivan
ajs@anvilwalrus= den.com
_______________________________________________
spfbis mailing list
spfbis@ietf.org = https://www.ietf.org/mailman/listinfo/spfbis


--f46d040712596ba13c04ce119446-- From spf2@kitterman.com Fri Nov 9 07:30:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B0921F857C for ; Fri, 9 Nov 2012 07:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kdGCfkG3zof for ; Fri, 9 Nov 2012 07:30:58 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id AA62321F855E for ; Fri, 9 Nov 2012 07:30:58 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 57D14D04067; Fri, 9 Nov 2012 09:30:57 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352475057; bh=a5qCBw9ERa0COUhAyVmRDErLiJbf1xymxv9HkQm8jSg=; h=In-Reply-To:References:Subject:From:Date:To:From; b=VFRaBjkLUwQZo6P/+V5k3lp7zc5WdezQ17JrRmI7Kt1kv+lKbZ+QG+u+iEhAGSHeP FYe0gMmlqeeBoHXaEs1UZ1GCqNf7jRjuuTeFZ53o+sfzkZdqat+SGKV8+46iS0Sg5/ wZTBKq6k2FcaKQJVhX6b43CghnAlm/hacySM3gG4= Received: from [IPV6:2600:1005:b006:fb7a:8e5a:e360:37ef:232b] (unknown [IPv6:2600:1005:b006:fb7a:8e5a:e360:37ef:232b]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A1F9CD04058; Fri, 9 Nov 2012 09:30:55 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 09 Nov 2012 10:30:53 -0500 To: "spfbis@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:30:59 -0000 I think this is a case of the protocol operating as designed. It's not at all clear anything needs fixing. Scott K "Murray S. Kucherawy" wrote: >Just to clarify: I actually don't care which path we take, but we need >to >be consistent. > >-MSK > > >On Fri, Nov 9, 2012 at 10:25 AM, Murray S. Kucherawy >wrote: > >> I agree, but I also think that if advice like this belongs outside >our >> single current deliverable, then we need to revisit the split topic >that >> received no support yesterday. >> >> To put it another way: Why should this topic go in an external >document, >> while other what-to-do-with-a-given-result discussion stays in the >main >> draft? >> >> -MSK >> >> >> >> On Fri, Nov 9, 2012 at 10:05 AM, Andrew Sullivan >wrote: >> >>> A question from a puzzled chair: >>> >>> On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote: >>> > I'm not seeing a natural place for this issue in the spfbis >>> > specification organization that Murray has proposed, other than >>> > perhaps some general statements in the early input/output/context >>> > section that should warn that spf is "merely" a component of a >>> > larger engine. >>> >>> I am inclined to think that this topic is part of the >>> operational/applicability statement work for which we are not >>> chartered, but that people have suggested as a natural thing to do >>> once our current work is completed. >>> >>> I'd be very interested in arguments about why that is _not_ the >case. >>> >>> Best, >>> >>> A >>> >>> -- >>> Andrew Sullivan >>> ajs@anvilwalrusden.com >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >>> >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Fri Nov 9 07:33: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 1E08221F84FF for ; Fri, 9 Nov 2012 07:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9YcaoYuVwqp for ; Fri, 9 Nov 2012 07:33:26 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9DE121F84D3 for ; Fri, 9 Nov 2012 07:33:25 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so3350447lam.31 for ; Fri, 09 Nov 2012 07:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n46XtrtxkrKpNAgy4nXeT/QQniDlB1ovOH9CtwkTLfk=; b=BvMRS4Wm4GwUhbEm8MugFk4RGEHuQhuuqNI/GzYtf40h4IgDwqsd1gjP0z02biOff5 6wrlUSEAMND4D5QsTLx+4RSnkmrOhhbAi28thp0UJBmt2vVqqqqFVvvhACYA3JiVdpYC 2K+50EpOefcKGeTVc0rToFwmgBMaHHe5KTlqLVXmMSXIu3VlJirPePNcSdJWDAYCc8/1 aFIbNVNs0QfTkTY/VLj5VoSsnBSNUjHVr4sDva5dwM3r+JRntp4aBX0Y1hiOnx1VCDhf WluYfFCOqT3uBqlO6Dpsr+O2qLtZTmVOl1Bjp5cMdVieX4XvxBchE9Eihl51W81ytleq Aygg== MIME-Version: 1.0 Received: by 10.112.100.129 with SMTP id ey1mr4676819lbb.10.1352475204282; Fri, 09 Nov 2012 07:33:24 -0800 (PST) Received: by 10.112.83.232 with HTTP; Fri, 9 Nov 2012 07:33:24 -0800 (PST) In-Reply-To: References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> Date: Fri, 9 Nov 2012 10:33:24 -0500 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=14dae9d717241e6b2104ce11acea Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:33:27 -0000 --14dae9d717241e6b2104ce11acea Content-Type: text/plain; charset=ISO-8859-1 But if someone is confused by it operating as designed, wouldn't it be helpful to provide some pedagogical text? On Fri, Nov 9, 2012 at 10:30 AM, Scott Kitterman wrote: > I think this is a case of the protocol operating as designed. It's not at > all clear anything needs fixing. > > Scott K > > "Murray S. Kucherawy" wrote: > > >Just to clarify: I actually don't care which path we take, but we need > >to > >be consistent. > > > >-MSK > > > > > >On Fri, Nov 9, 2012 at 10:25 AM, Murray S. Kucherawy > >wrote: > > > >> I agree, but I also think that if advice like this belongs outside > >our > >> single current deliverable, then we need to revisit the split topic > >that > >> received no support yesterday. > >> > >> To put it another way: Why should this topic go in an external > >document, > >> while other what-to-do-with-a-given-result discussion stays in the > >main > >> draft? > >> > >> -MSK > >> > >> > >> > >> On Fri, Nov 9, 2012 at 10:05 AM, Andrew Sullivan > >wrote: > >> > >>> A question from a puzzled chair: > >>> > >>> On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote: > >>> > I'm not seeing a natural place for this issue in the spfbis > >>> > specification organization that Murray has proposed, other than > >>> > perhaps some general statements in the early input/output/context > >>> > section that should warn that spf is "merely" a component of a > >>> > larger engine. > >>> > >>> I am inclined to think that this topic is part of the > >>> operational/applicability statement work for which we are not > >>> chartered, but that people have suggested as a natural thing to do > >>> once our current work is completed. > >>> > >>> I'd be very interested in arguments about why that is _not_ the > >case. > >>> > >>> Best, > >>> > >>> A > >>> > >>> -- > >>> Andrew Sullivan > >>> ajs@anvilwalrusden.com > >>> _______________________________________________ > >>> spfbis mailing list > >>> spfbis@ietf.org > >>> https://www.ietf.org/mailman/listinfo/spfbis > >>> > >> > >> > > > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >spfbis mailing list > >spfbis@ietf.org > >https://www.ietf.org/mailman/listinfo/spfbis > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --14dae9d717241e6b2104ce11acea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable But if someone is confused by it operating as designed, wouldn't it be = helpful to provide some pedagogical text?

On Fri, Nov 9, 2012 at 10:30 AM, Scott Kitt= erman <spf2@kitterman.com> wrote:
I think this is a case of the protocol opera= ting as designed. =A0It's not at all clear anything needs fixing.

Scott K

"Murray S. Kucherawy" <= superuser@gmail.com> wrote:

>Just to clarify: I actually don't care which path we take, but we n= eed
>to
>be consistent.
>
>-MSK
>
>
>On Fri, Nov 9, 2012 at 10:25 AM, Murray S. Kucherawy
><superuser@gmail.com>w= rote:
>
>> I agree, but I also think that if advice like this belongs outside=
>our
>> single current deliverable, then we need to revisit the split topi= c
>that
>> received no support yesterday.
>>
>> To put it another way: Why should this topic go in an external
>document,
>> while other what-to-do-with-a-given-result discussion stays in the=
>main
>> draft?
>>
>> -MSK
>>
>>
>>
>> On Fri, Nov 9, 2012 at 10:05 AM, Andrew Sullivan
><ajs@anvilwalrusden.com>wrote:
>>
>>> A question from a puzzled chair:
>>>
>>> On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote:<= br> >>> > I'm not seeing a natural place for this issue in the = spfbis
>>> > specification organization that Murray has proposed, othe= r than
>>> > perhaps some general statements in the early input/output= /context
>>> > section that should warn that spf is "merely" a= component of a
>>> > larger engine.
>>>
>>> I am inclined to think that this topic is part of the
>>> operational/applicability statement work for which we are not<= br> >>> chartered, but that people have suggested as a natural thing t= o do
>>> once our current work is completed.
>>>
>>> I'd be very interested in arguments about why that is _not= _ the
>case.
>>>
>>> Best,
>>>
>>> A
>>>
>>> --
>>> Andrew Sullivan
>>> ajs@anvilwalrusden.c= om
>>> _______________________________________________
>>> spfbis mailing list
>>> spfbis@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spfbis
>>>
>>
>>
>
>
>-----------------------------------------------------------= -------------
>
>_______________________________________________
>spfbis mailing list
>spfbis@ietf.org
>https://www.ietf.org/mailman/listinfo/spfbis

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

--14dae9d717241e6b2104ce11acea-- From ajs@anvilwalrusden.com Fri Nov 9 07:37:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0321F86A8 for ; Fri, 9 Nov 2012 07:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xMiv1OEQlaj for ; Fri, 9 Nov 2012 07:37:50 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D09E221F8546 for ; Fri, 9 Nov 2012 07:37:50 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3C72D8A031 for ; Fri, 9 Nov 2012 15:37:50 +0000 (UTC) Date: Fri, 9 Nov 2012 10:37:43 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20121109153742.GG79908@mx1.yitter.info> References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:37:51 -0000 On Fri, Nov 09, 2012 at 10:25:58AM -0500, Murray S. Kucherawy wrote: > I agree, but I also think that if advice like this belongs outside our > single current deliverable, then we need to revisit the split topic that > received no support yesterday. That's an interesting argument. What about a document that was something like "BCP for SPF reciever processing"? That'd still be relevant to the case in question, but clearly a difference from any content in RFC 4408. Thoughts? Again, I'm just asking: I'm not trying to promote or discourage any particular option, just understand our options. A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Fri Nov 9 07:39: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 150FD21F85F0 for ; Fri, 9 Nov 2012 07:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDviYfjFAcYv for ; Fri, 9 Nov 2012 07:39:02 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D69421F85C2 for ; Fri, 9 Nov 2012 07:39:02 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9B369D04067; Fri, 9 Nov 2012 09:39:01 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352475541; bh=2maX7XhjCveO6mjxtV78KcVcm1Ms9b1JdAK5B570H3M=; h=In-Reply-To:References:Subject:From:Date:To:From; b=AfpncmJPga0DrFh6G14gVwPfJRf6gR0cNGXouI6t74dhlr0p0aNv35NdU1v0mX1yL keYQ/sco00kT4WMfqzrR6kn8r5qGIRkAjsPwU69qh0McGOIdBtHn1p1obvjQn5K2Hy H5368S36hoK8V2dCED9JX2U9ar4rYU+9HON0cZGg= Received: from [IPV6:2600:1005:b006:fb7a:8e5a:e360:37ef:232b] (unknown [IPv6:2600:1005:b006:fb7a:8e5a:e360:37ef:232b]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C8004D04058; Fri, 9 Nov 2012 09:38:57 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 09 Nov 2012 10:38:51 -0500 To: "spfbis@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:39:03 -0000 They were confused, but they'd never read 4408. Sorry for not being clear. No amount of text will help cases like this. Scott K "Murray S. Kucherawy" wrote: >But if someone is confused by it operating as designed, wouldn't it be >helpful to provide some pedagogical text? > > >On Fri, Nov 9, 2012 at 10:30 AM, Scott Kitterman >wrote: > >> I think this is a case of the protocol operating as designed. It's >not at >> all clear anything needs fixing. >> >> Scott K >> >> "Murray S. Kucherawy" wrote: >> >> >Just to clarify: I actually don't care which path we take, but we >need >> >to >> >be consistent. >> > >> >-MSK >> > >> > >> >On Fri, Nov 9, 2012 at 10:25 AM, Murray S. Kucherawy >> >wrote: >> > >> >> I agree, but I also think that if advice like this belongs outside >> >our >> >> single current deliverable, then we need to revisit the split >topic >> >that >> >> received no support yesterday. >> >> >> >> To put it another way: Why should this topic go in an external >> >document, >> >> while other what-to-do-with-a-given-result discussion stays in the >> >main >> >> draft? >> >> >> >> -MSK >> >> >> >> >> >> >> >> On Fri, Nov 9, 2012 at 10:05 AM, Andrew Sullivan >> >wrote: >> >> >> >>> A question from a puzzled chair: >> >>> >> >>> On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote: >> >>> > I'm not seeing a natural place for this issue in the spfbis >> >>> > specification organization that Murray has proposed, other than >> >>> > perhaps some general statements in the early >input/output/context >> >>> > section that should warn that spf is "merely" a component of a >> >>> > larger engine. >> >>> >> >>> I am inclined to think that this topic is part of the >> >>> operational/applicability statement work for which we are not >> >>> chartered, but that people have suggested as a natural thing to >do >> >>> once our current work is completed. >> >>> >> >>> I'd be very interested in arguments about why that is _not_ the >> >case. >> >>> >> >>> Best, >> >>> >> >>> A >> >>> >> >>> -- >> >>> Andrew Sullivan >> >>> ajs@anvilwalrusden.com >> >>> _______________________________________________ >> >>> spfbis mailing list >> >>> spfbis@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/spfbis >> >>> >> >> >> >> >> > >> > >> >>------------------------------------------------------------------------ >> > >> >_______________________________________________ >> >spfbis mailing list >> >spfbis@ietf.org >> >https://www.ietf.org/mailman/listinfo/spfbis >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> From kurta@drkurt.com Fri Nov 9 07:39:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2CC21F8613 for ; Fri, 9 Nov 2012 07:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0Mc8GyFkE3T for ; Fri, 9 Nov 2012 07:39:12 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5894921F85C2 for ; Fri, 9 Nov 2012 07:39:12 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so3412316lbo.31 for ; Fri, 09 Nov 2012 07:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20110616; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=/fA5M2VLhqBjgNoMD19Avouoo3exFKKCYDUes7wv1nA=; b=BAchKH65qYj+cXpbIQ9MO0AmHhLnGqgKuAE1fnETAjqE/ROjs6WEZ4jkdF3usAjcNA ZfihNA+azrMM5WDoyx13p5fbCst8ZKHPBSEVHd4b3A97ZcdFFWnUZY3HQNxBa1DyS10W DmYEDVhVPxy+KAeoNAmpZz8Ae0NAw8bBvagmo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=/fA5M2VLhqBjgNoMD19Avouoo3exFKKCYDUes7wv1nA=; b=hW+6U0e1rGWtr9fV6uiCWInGCukaj+ECC0R337/55vW39MGHMuwQtD0WGdv806v3V6 ZbwhQM/kyvWfU8W09HgGFF6KY0FEWiuFzi44UWfoMxZ7Ipuy5s8kRcRGU1+5WtaDTBHB +gzpWa5h/iEcRwDe4zYaVWvSdc93GuGwdpIu/ZvAmTnxBw3yrn85tPnEaGlEvHq8ie+7 oe5NykQNJZrIst/3DTfvksSh2EptYV+VjemBAYZrwMQBK8/GQrzASg6y3K5MlCieLWZo zb6D2U9cogh49qJcX3ty32Gi03WPkx9dfh2Or/Wb+k1dnnWkKuZuc42OFL9TW1CFhgZ8 2suA== MIME-Version: 1.0 Received: by 10.112.82.8 with SMTP id e8mr4732607lby.19.1352475551281; Fri, 09 Nov 2012 07:39:11 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.114.57.33 with HTTP; Fri, 9 Nov 2012 07:39:11 -0800 (PST) In-Reply-To: References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> Date: Fri, 9 Nov 2012 07:39:11 -0800 X-Google-Sender-Auth: Pb4quS_vYf3DwJ-GsOxd8nNRags Message-ID: From: Kurt Andersen To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=f46d04016d5bcd335e04ce11c090 X-Gm-Message-State: ALoCoQnRdWl4vcL8s5HPntVe/jGEQIeYytZsihA0bNwivV/R/v5mcX0/f4WBNkz8+AxpuJzSv86l Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:39:13 -0000 --f46d04016d5bcd335e04ce11c090 Content-Type: text/plain; charset=ISO-8859-1 I suspect that in this case it was an issue of team "left hand" not having any clue what was going on with team "right hand". Having worked with silo'd enterprise divisions for quite a while, this is far more common than not...I doubt that all the SPF pedagogy in the world won't penetrate such inter-departmental gaps. --Kurt Andersen On Fri, Nov 9, 2012 at 7:33 AM, Murray S. Kucherawy wrote: > But if someone is confused by it operating as designed, wouldn't it be > helpful to provide some pedagogical text? > > > > On Fri, Nov 9, 2012 at 10:30 AM, Scott Kitterman wrote: > >> I think this is a case of the protocol operating as designed. It's not >> at all clear anything needs fixing. >> >> Scott K >> >> "Murray S. Kucherawy" wrote: >> >> >Just to clarify: I actually don't care which path we take, but we need >> >to >> >be consistent. >> > >> >-MSK >> > >> > >> >On Fri, Nov 9, 2012 at 10:25 AM, Murray S. Kucherawy >> >wrote: >> > >> >> I agree, but I also think that if advice like this belongs outside >> >our >> >> single current deliverable, then we need to revisit the split topic >> >that >> >> received no support yesterday. >> >> >> >> To put it another way: Why should this topic go in an external >> >document, >> >> while other what-to-do-with-a-given-result discussion stays in the >> >main >> >> draft? >> >> >> >> -MSK >> >> >> >> >> >> >> >> On Fri, Nov 9, 2012 at 10:05 AM, Andrew Sullivan >> >wrote: >> >> >> >>> A question from a puzzled chair: >> >>> >> >>> On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote: >> >>> > I'm not seeing a natural place for this issue in the spfbis >> >>> > specification organization that Murray has proposed, other than >> >>> > perhaps some general statements in the early input/output/context >> >>> > section that should warn that spf is "merely" a component of a >> >>> > larger engine. >> >>> >> >>> I am inclined to think that this topic is part of the >> >>> operational/applicability statement work for which we are not >> >>> chartered, but that people have suggested as a natural thing to do >> >>> once our current work is completed. >> >>> >> >>> I'd be very interested in arguments about why that is _not_ the >> >case. >> >>> >> >>> Best, >> >>> >> >>> A >> >>> >> >>> -- >> >>> Andrew Sullivan >> >>> ajs@anvilwalrusden.com >> >>> _______________________________________________ >> >>> spfbis mailing list >> >>> spfbis@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/spfbis >> >>> >> >> >> >> >> > >> > >> >------------------------------------------------------------------------ >> > >> >_______________________________________________ >> >spfbis mailing list >> >spfbis@ietf.org >> >https://www.ietf.org/mailman/listinfo/spfbis >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > --f46d04016d5bcd335e04ce11c090 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I suspect that in this case it was an issue of team "left hand" n= ot having any clue what was going on with team "right hand". Havi= ng worked with silo'd enterprise divisions for quite a while, this is f= ar more common than not...I doubt that all the SPF pedagogy in the world wo= n't penetrate such inter-departmental gaps.

--Kurt Andersen


On Fri, Nov 9, 2012 at 7:33 AM, Murray S. Kucherawy <superuser= @gmail.com> wrote:
But if someone is confused by it operating a= s designed, wouldn't it be helpful to provide some pedagogical text?



On Fri, Nov 9, 2012 at 10:30 AM, Scott Kitterman <spf2@kitterman= .com> wrote:
I think this is a case of the protocol opera= ting as designed. =A0It's not at all clear anything needs fixing.

Scott K

"Murray S. Kucherawy" <superuser@gmail.com> wrote:

>Just to clarify: I actually don't care which path we take, but we n= eed
>to
>be consistent.
>
>-MSK
>
>
>On Fri, Nov 9, 2012 at 10:25 AM, Murray S. Kucherawy
><superuser@= gmail.com>wrote:
>
>> I agree, but I also think that if advice like this belongs outside=
>our
>> single current deliverable, then we need to revisit the split topi= c
>that
>> received no support yesterday.
>>
>> To put it another way: Why should this topic go in an external
>document,
>> while other what-to-do-with-a-given-result discussion stays in the=
>main
>> draft?
>>
>> -MSK
>>
>>
>>
>> On Fri, Nov 9, 2012 at 10:05 AM, Andrew Sullivan
><ajs@anv= ilwalrusden.com>wrote:
>>
>>> A question from a puzzled chair:
>>>
>>> On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote:<= br> >>> > I'm not seeing a natural place for this issue in the = spfbis
>>> > specification organization that Murray has proposed, othe= r than
>>> > perhaps some general statements in the early input/output= /context
>>> > section that should warn that spf is "merely" a= component of a
>>> > larger engine.
>>>
>>> I am inclined to think that this topic is part of the
>>> operational/applicability statement work for which we are not<= br> >>> chartered, but that people have suggested as a natural thing t= o do
>>> once our current work is completed.
>>>
>>> I'd be very interested in arguments about why that is _not= _ the
>case.
>>>
>>> Best,
>>>
>>> A
>>>
>>> --
>>> Andrew Sullivan
>>> aj= s@anvilwalrusden.com
>>> _______________________________________________
>>> spfbis mailing list
>>> spfbis@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/spfbis
>>>
>>
>>
>
>
>-----------------------------------------------------------= -------------
>
>_______________________________________________
>spfbis mailing list
>spfbis@ietf.org
>https://www.ietf.org/mailman/listinfo/spfbis

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


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


--f46d04016d5bcd335e04ce11c090-- From dhc@dcrocker.net Fri Nov 9 07:40:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E100621F860D for ; Fri, 9 Nov 2012 07:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJQkgYO68pXL for ; Fri, 9 Nov 2012 07:40:27 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE4D21F85C2 for ; Fri, 9 Nov 2012 07:40:27 -0800 (PST) Received: from [10.16.88.13] (65-50-0-4.ips.direcpath.com [65.50.0.4] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id qA9FeNSP016609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Nov 2012 07:40:24 -0800 Message-ID: <509D23E1.8000603@dcrocker.net> Date: Fri, 09 Nov 2012 10:40:17 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 09 Nov 2012 07:40:25 -0800 (PST) Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:40:28 -0000 On 11/9/2012 10:33 AM, Murray S. Kucherawy wrote: > But if someone is confused by it operating as designed, wouldn't it be > helpful to provide some pedagogical text? in case I needed to say it explicitly: I am assuming that handling this problem does /not/ require changing the protocol. No normative change at all. I assume it's merely a matter of documenting good practices. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Fri Nov 9 07:47:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB42421F8682 for ; Fri, 9 Nov 2012 07:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkS0twNZbf8c for ; Fri, 9 Nov 2012 07:47:46 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1E3021F8680 for ; Fri, 9 Nov 2012 07:47:45 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so3419593lbo.31 for ; Fri, 09 Nov 2012 07:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vmjKl2jLUYqI2MBiefRgO5bjkg/zO6rxLiHu8FRd7Gw=; b=oNmoXlMMdPiH9TIkGI9HabLUGWAPJTRLOzsV20CtGzMy3jg6b+pdSBMB1dri4bAM/t AlHQ3XF2tL/7LQlYdtP1oOPWz/R2BiciEDPc/2Fj3w6q/4BZKpyQR/0AA4ZDFLoCEWUc Z9SAHRtt0JC5MjchLDkVSEIkXkaPUdfjWa1kfw+zBRqduUqECPk6a4A6ik+DusfFL30z HqRL//X8OPiDTycKTaJI7qEOInP2+mxcnRuZG+/4d19CcfiScAN17wofUHeHYGsSJ9T/ 1SjBjsODaocc449h81oD4xnO0OavbzyOnhCcMwM+T6fvog9/B45MF+3jYMAW6qox50mZ ZRQg== MIME-Version: 1.0 Received: by 10.112.100.129 with SMTP id ey1mr4690729lbb.10.1352476064876; Fri, 09 Nov 2012 07:47:44 -0800 (PST) Received: by 10.112.83.232 with HTTP; Fri, 9 Nov 2012 07:47:44 -0800 (PST) In-Reply-To: <509D23E1.8000603@dcrocker.net> References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> <509D23E1.8000603@dcrocker.net> Date: Fri, 9 Nov 2012 10:47:44 -0500 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=14dae9d717246a08ec04ce11df78 Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:47:47 -0000 --14dae9d717246a08ec04ce11df78 Content-Type: text/plain; charset=ISO-8859-1 I agree that no normative changes are appropriate here. Maybe all we need to do is encourage adoption of RFC6652 by both senders and receivers? -MSK On Fri, Nov 9, 2012 at 10:40 AM, Dave Crocker wrote: > > > On 11/9/2012 10:33 AM, Murray S. Kucherawy wrote: > >> But if someone is confused by it operating as designed, wouldn't it be >> helpful to provide some pedagogical text? >> > > in case I needed to say it explicitly: I am assuming that handling this > problem does /not/ require changing the protocol. No normative change at > all. > > I assume it's merely a matter of documenting good practices. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --14dae9d717246a08ec04ce11df78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that no normative changes are appropriate here.

Maybe all we= need to do is encourage adoption of RFC6652 by both senders and receivers?=

-MSK


On Fri, Nov 9, 2012 at 10:40 AM, Dave Crocker <dhc@dcrocker.net> wrote:


On 11/9/2012 10:33 AM, Murray S. Kucherawy wrote:
But if someone is confused by it operating as designed, wouldn't it be<= br> helpful to provide some pedagogical text?

in case I needed to say it explicitly: =A0I am assuming that handling this = problem does /not/ require changing the protocol. =A0No normative change at= all.

I assume it's merely a matter of documenting good practices.

d/

--
=A0Dave Crocker
=A0Brandenburg InternetWorking
=A0bbiw.net

--14dae9d717246a08ec04ce11df78-- From superuser@gmail.com Fri Nov 9 07:50:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C9921F86C5 for ; Fri, 9 Nov 2012 07:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3Wq8-taK9iK for ; Fri, 9 Nov 2012 07:50:01 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB7D721F868B for ; Fri, 9 Nov 2012 07:50:00 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so3363234lam.31 for ; Fri, 09 Nov 2012 07:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NoIg+pClrFIihfhD3+thLaayDstBfYMvLb/U+XSyTaI=; b=tTIQYFcwLVRPQYDiKz/bQqNDA5wjZ1eRy0QgCsEFaxX7yVVMPuQlsF6WIhWDuWP9Z3 cUXKDMHfduN6iK0mU5iyXOyQtWA1r3zsCQw5B0CcEBiBv2pF6f4Zhd7arGEeMQYnL0lP PiTdI5rsZJ+ICu53YB1N1z+nINUdvFgmkIupw0kPjzCiSfEveoVTgylhE+VuBlFuA5iA SNys78GfHuWerxMNq49f+nIAmLTzmwoB4dofXYr+6c8kFgYzUmpX4P5yglrOsItzitw9 4ZpLU+8wqbptJCDpLachaTtLcZ20Yh9nQptdfR5Aa6hAvbAOyHdY7WPq4F4jxn302XK5 tWnA== MIME-Version: 1.0 Received: by 10.112.47.228 with SMTP id g4mr4465368lbn.21.1352476199738; Fri, 09 Nov 2012 07:49:59 -0800 (PST) Received: by 10.112.83.232 with HTTP; Fri, 9 Nov 2012 07:49:59 -0800 (PST) In-Reply-To: <20121109153742.GG79908@mx1.yitter.info> References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> <20121109153742.GG79908@mx1.yitter.info> Date: Fri, 9 Nov 2012 10:49:59 -0500 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=bcaec554ddfe73de5704ce11e711 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:50:02 -0000 --bcaec554ddfe73de5704ce11e711 Content-Type: text/plain; charset=ISO-8859-1 Are there operational cases besides this one that we would put in such a document, without also moving all the receiver advice from the main document? If there's only this one exceptional use case, I'd lean toward saying it's not worthwhile. But if we revisit the splitting decision, then there's enough meat to proceed. -MSK On Fri, Nov 9, 2012 at 10:37 AM, Andrew Sullivan wrote: > On Fri, Nov 09, 2012 at 10:25:58AM -0500, Murray S. Kucherawy wrote: > > I agree, but I also think that if advice like this belongs outside our > > single current deliverable, then we need to revisit the split topic that > > received no support yesterday. > > That's an interesting argument. What about a document that was > something like "BCP for SPF reciever processing"? That'd still be > relevant to the case in question, but clearly a difference from any > content in RFC 4408. Thoughts? > > Again, I'm just asking: I'm not trying to promote or discourage any > particular option, just understand our options. > > A > > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --bcaec554ddfe73de5704ce11e711 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are there operational cases besides this one that we would put in such a do= cument, without also moving all the receiver advice from the main document?=

If there's only this one exceptional use case, I'd lean tow= ard saying it's not worthwhile.=A0 But if we revisit the splitting deci= sion, then there's enough meat to proceed.

-MSK


O= n Fri, Nov 9, 2012 at 10:37 AM, Andrew Sullivan <ajs@anvilwalrusden.c= om> wrote:
On Fri, Nov 09, 2012 at 10= :25:58AM -0500, Murray S. Kucherawy wrote:
> I agree, but I also think that if advice like this belongs outside our=
> single current deliverable, then we need to revisit the split topic th= at
> received no support yesterday.

That's an interesting argument. =A0What about a document that was=
something like "BCP for SPF reciever processing"? =A0That'd s= till be
relevant to the case in question, but clearly a difference from any
content in RFC 4408. =A0Thoughts?

Again, I'm just asking: I'm not trying to promote or discourage any=
particular option, just understand our options.

A


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

--bcaec554ddfe73de5704ce11e711-- From hsantos@isdg.net Fri Nov 9 08:49:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4085321F8715 for ; Fri, 9 Nov 2012 08:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ueo2SMLXeJh for ; Fri, 9 Nov 2012 08:49:42 -0800 (PST) Received: from listserv.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 322E021F870E for ; Fri, 9 Nov 2012 08:49:41 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1722; t=1352479771; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Hpltns7U7FM+qKJ6O8Gum4fH/UM=; b=Jny/VoUZMemyPFTdyE9H 3Tc/8Gcsdhb3dkKikw5EQskRz9n3lW6TTHltQzvKVzgy5+axilH3VG7XcsKDjIHT jkSjw7fvLLi9/ChtsVMiMpO9l0AL7iq9I2uc1Jt6AZF1+YaTTpSKdroFSiJE/y2J t+2ktpBqw5J4sVHEcZdF7YA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 09 Nov 2012 11:49:31 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4206523696.2489.2092; Fri, 09 Nov 2012 11:49:30 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1722; t=1352479445; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+8vBMNx uljA8+CvjInnNoQP1Warjvp0TexALh93hmts=; b=UFFi/dVHS2mR2LaAKDYhQeg wZST9xE3vZjA1FKcS7VCGM69wwuhAWDvx6aPApynwujxtDVseizz8kFMn5eJhdVa BWOC2UKKt/lam3de1FKkU2nuMpPkjjdeXp0tO9JFzxom8+EB25/R9tRNwGijLhgP yjv/267FHZgkGOVidRJU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 09 Nov 2012 11:44:05 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 510308725.9.4276; Fri, 09 Nov 2012 11:44:04 -0500 Message-ID: <509D3470.6010704@isdg.net> Date: Fri, 09 Nov 2012 11:50:56 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> In-Reply-To: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Rejection Based On SPF (ERROR) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 09 Nov 2012 16:49:43 -0000 Scott Kitterman wrote: > We've discussed off and on the question of if people reject mail based on SPF. > I thought I'd pass on this anecdote (I know it provides no statistical insight > into the question, but found it sufficiently amusing to pass on). > > Microsoft is publishing an invalid DNS record (exceeds the DNS lookup limit). > For reasons that are beyond me, they do this from time to time. This morning > I was treated to an irate email from a Microsoft employee complaining that my > SPF record validation tool (http://www.kitterman.com/spf/validate.html) was > causing Microsoft email to be rejected and demanding I fix the problem with my > system. > > My reply was probably not a polite as it could have been, but I did suggest > that perhaps if Microsoft was having trouble sending mail due to SPF failures, > they ought to look in the mirror. > > So this was a case of reject on permerror, which is the default for a lot of > the open source implementations. Scott, Issues on how to handle errors was catalogged and I had proposed the language be to treat an error as NONE but also monitoring it, demote it to a failed state: result = NONE if error count > some_error_threshold then result = FAIL In other words, the receiver "SHOULD" have the right to control the abuse on his system even from good intention, but broken clients, by monitoring their frequency and burden on the system and changing a PASS status to REJECT. Not saying we are doing this for SPF, but its a consideration we are doing for our SPF implementation. But I think if SPF people are already doing this, then these insights should be documented in the protocol standard. -- HLS From hsantos@isdg.net Fri Nov 9 10:07: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 2F3D321F876C for ; Fri, 9 Nov 2012 10:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3yxk1UpJnZn for ; Fri, 9 Nov 2012 10:07:57 -0800 (PST) Received: from ftp.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD0C21F84B1 for ; Fri, 9 Nov 2012 10:07:56 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=9228; t=1352484466; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=4hxZKk/p/Vu1TXy6z9iOzzEE5mY=; b=vExo6570p8keGG+jhFlY B67LO3ZQwuaNFyG6MPzJrcb19hmfrDQ24/30ZVyD71S/dgetChcMFsG46nb/unMN ohKNSiQL7U/STmgHXupAZUE+4pQzmAOZxsIQdiMhirnf0a+CNRyy78twXG2MMLY5 LkJNaxHVfeHxsa94NT17VKw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 09 Nov 2012 13:07:46 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4211218905.2489.2148; Fri, 09 Nov 2012 13:07:45 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=9228; t=1352484138; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=YHz1eKB 2E8Xgq2aTvS7w+dJUTBVnxXpq2kDrOTQej1E=; b=KIdHRMoI2RT0dw1hyFzcDUB yypkq0OOFLAJA6iaEO2LLV6CkQq7MG+BB+C7IQk0pxr2j95e0cOcSCznVCyotMhT ZS8pcMCpwjcH/VIDDsNqdWb4uxlOiDqHObf0Qhj0erggIFUCrAqqsGlYopohY7ca t4i9lNf6khYehNBm6Law= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 09 Nov 2012 13:02:18 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 515001678.9.4248; Fri, 09 Nov 2012 13:02:17 -0500 Message-ID: <509D468A.9090107@isdg.net> Date: Fri, 09 Nov 2012 13:08:10 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Elizabeth Zwicky References: <3E6CC480-E11B-4304-857D-E8603206ADDC@yahoo-inc.com> <509C2540.8080705@isdg.net> <9345F154-B1FD-4A82-94AD-D91A047ADE28@yahoo-inc.com> In-Reply-To: <9345F154-B1FD-4A82-94AD-D91A047ADE28@yahoo-inc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "spfbis@ietf.org" , Franck Martin , Tim Draegen , "Murray S. Kucherawy" Subject: Re: [spfbis] Goals of this discussion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 09 Nov 2012 18:07:59 -0000 Hi, It depends on how you (SPF deployment) are handling -ALL policies. To make a long story relatively short, lets ask this: Is your SPF implementation or site deployment rejecting or accepting+marking the SPF failed message (failed per the Domain -ALL policy)? Unresolved issues that lead to the documentation impasse: Issue #29 - defining what "Mark the message" means. There is no RFC 2119 language for marking, but there is for Rejecting the message. Issue #33 - attempts to illustrate the security loophole when a receiver accepts the message but does not mark and/or separating the mail into a "Junk/Spam" user folder. In my view, the proposed BIS changes and now reorganization will emphasize accept and marking instead of rejecting the message operations to help support new/future RFC5322-based Reporting and Reputation Protocols. This is all good as a separate document. But need to be careful for what you ask for because it can be a source to continue with the required changes in BIS. The problem, I guess, at least one for our product, it currently only supports SPF rejection for -ALL policy. If we want to support BIS with any of the new goodies, then we need to change our software to separate the accepted, marked (issue #29) SPF failed mail otherwise we have the security loophole (issue #33). Thats not to suggest a lack of support for a BIS (reorganized or not), if not already understood, the concern is that rejection is not going to promoted anymore in the name of reporting/reputation. Again, as long as the option is there, we are still compatible. So BIS for me should first work out SPF itself as a pure protocol with none of the integrated protocols design semantics. Thanks -- HLS Elizabeth Zwicky wrote: > I'm still not clear here. Do you see changes I will need to make to my implementation > based on the reorganization, or is the concern that new implementations will be > different than the old ones? If the latter, different in incompatible ways, or > in undesirable ways? > > Elizabeth > > On Nov 8, 2012, at 1:33 PM, Hector Santos wrote: > >> Typo fit: >> >> I am those who are not convinced that any [NEW] bits will not disturb >> the current stable electronic steady state "bits" propagations on the >> wire. >> >> Murray S. Kucherawy wrote: >>> Hi Elizabeth, >>> >>> A specific goal of the proposed reorganization was to make no changes to >>> the bits on the wire. So your latter observation appears to mean that goal >>> was met. >>> >>> Thanks for having a look at it. >>> >>> -MSK >>> >>> >>> On Wed, Nov 7, 2012 at 4:28 PM, Elizabeth Zwicky wrote: >>> >>>> As the person who would have to coordinate Yahoo's implementation if >>>> we were just now implementing SPF, I can say that the reorganization >>>> goes a long way towards making the RFC easier to use. I appreciate that >>>> reorganizations are a technical challenge while they are in progress, >>>> but optimizing for the process right now rather than the many readers >>>> down the road seems to me to be the wrong decision. >>>> >>>> As a receiver with SPF support I don't see how the proposed changes >>>> would cause us to change our implementation; could somebody clarify >>>> that for me? >>>> >>>> Elizabeth Zwicky >>>> >>>> On Nov 7, 2012, at 10:26 AM, Franck Martin wrote: >>>> >>>>> Hector, >>>>> >>>>> Murray has stated and several people have stated, they do not seek >>>>> protocol change in this reorganization, but to follow Best Current >>>>> Practices in writing a RFC. >>>>> This needs to look like a proper RFC, rather than a babel tower� >>>>> >>>>> We have only one good shot in making SPF a standard, let's not fail due >>>> to >>>>> poor grammar. >>>>> >>>>> On 11/7/12 8:53 AM, "Hector Santos" wrote: >>>>> >>>>>> I have a hard time understanding the focus and goal here for >>>>>> reorganization. Please state the main purpose and goal to adopt >>>>>> Murray's proposed changes. What is the benefits? >>>>>> >>>>>> In my engineering and product development opinion, the proposed >>>>>> changes does alter the scope of the SPF framework (relatively to how >>>>>> we have been using it for 9+years) and we are living proof that if we >>>>>> follow the proposed changes, it will be a very costly design change >>>>>> endeavor to the point we would have to consider the pros and cons and >>>>>> most likely ignore the new considerations emphasized in the proposed >>>>>> changes. I don't think this can't be "fixed" but it will does >>>>>> required accepting the policies already established in SPF and how >>>>>> these are functional specifications are translated into standard >>>>>> technical specifications fitting into the SMTP state machine as a 5321 >>>>>> technology, not 5322 technology. If we are focusing on 5322 >>>>>> material, then the scope is changing. >>>>>> >>>>>> -- >>>>>> HLS >>>>>> >>>>>> >>>>>> Tim Draegen wrote: >>>>>>> On Sep 17, 2012, at 6:00 PM, Andrew Sullivan >>>>>>> wrote: >>>>>>>> Before going further, I'd like for participants in this debate to >>>> state >>>>>>>> where they stand with respect to the above arguments, and to clarify >>>>>>>> what trade-offs they think are acceptable as a result. >>>>>>> Andrew et al, my aim is help produce a Standards-track draft that meets >>>>>>> the needs of people outside of the IETF in as little time as possible, >>>>>>> and no less. >>>>>>> >>>>>>> In response to 3 arguments for proposed reorganization: >>>>>>> >>>>>>> - As an implementor I can wade through 4408 with a yellow high-lighter >>>>>>> and sticky-notes until I get it. >>>>>>> - As someone responsible for teaching others, I would greatly >>>>>>> appreciate adoption of Murray's proposed reorganization. >>>>>>> - As a rare participant in IETF process, I agree with the stance of "we >>>>>>> should clean it up now and not later".. pushing through an editorially >>>>>>> unchanged 4408 seems to me to miss the point of why we're all here >>>>>>> (regardless of Chartering). >>>>>>> >>>>>>> In response to counter-arguments: >>>>>>> - After review, Murray's proposed reorganization does not change the >>>>>>> protocol, it only makes it easier for non-experts to understand. >>>>>>> Perhaps oddly, I don't see the counter-arguments as such. I see the >>>>>>> "move SPF from the experimental to the standards track" to mean >>>> "prepare >>>>>>> the document so that it behaves like other standards track documents", >>>>>>> which Murray's proposed reorganization gets us closer to. >>>>>>> - I do not find the the "accidental protocol changes" argument >>>>>>> compelling, due to the passion, expertise, and character-by-character >>>>>>> review that all participants in this WG give to proposed changes. >>>>>>> - Similarly, the need-for-side-by-side-comparison argument is lost on >>>>>>> me. Optimizing for easy-review is not on my list of concerns. I >>>>>>> understand that there is risk whenever change is introduced, but the >>>>>>> time to make change is when everyone is paying attention, which is now. >>>>>>> >>>>>>> Trade-offs for an acceptable result: >>>>>>> - Commit to not changing the protocol; warts, macros, and all. >>>>>>> - Recognize that the current draft does too much and interleaves too >>>>>>> many topics to make it a proper IETF standard. The risk of the IESG >>>>>>> kicking the draft back is one thing, but we might as well go all in to >>>>>>> meet perceived IESG requirements AND produce a doc that technology >>>>>>> generalists can read w/o importing the entire history of SPF into their >>>>>>> heads. >>>>>>> - Everyone must commit to trying to "sneak in" at least 1 change. This >>>>>>> will keep everyone on their toes. >>>>>>> >>>>>>> Finally, I'd like to submit that the existing draft has done an >>>>>>> excellent job of producing interoperable technology within the >>>> community >>>>>>> of email anti-abuse developers. In the move from Experimental to >>>>>>> standards-track, though, the community will get larger, and therefore >>>>>>> the specification needs to be editorially easier to ingest. >>>>>>> >>>>>>> See y'all tomorrow, >>>>>>> =- Tim >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> spfbis mailing list >>>>>> spfbis@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spfbis >>>>> _______________________________________________ >>>>> spfbis mailing list >>>>> spfbis@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spfbis >>>> _______________________________________________ >>>> spfbis mailing list >>>> spfbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spfbis >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >> -- >> HLS >> >> >> > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From vesely@tana.it Fri Nov 9 12:48: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 68BFB21F8739 for ; Fri, 9 Nov 2012 12:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv8rSMjSeoPe for ; Fri, 9 Nov 2012 12:48:04 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 973D021F86F6 for ; Fri, 9 Nov 2012 12:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352494082; bh=poVY0p+oUUwEkBJ2ASg7QKk8Kgt2z1P4394ykb8lcE0=; l=911; h=Date:From:To:References:In-Reply-To; b=OHbLAFB+M/m+A+B/T9Vwy1QVLpT7h0DZoo5dgemVChRNEViTQIFcASpiBKPZkwB8S 7gPzCvYvADBJx7QMPUVrJs/eQDdZSMoCAJjtXesXCeFEgujEbHc2PC3a0YPmAJGqrw lf1SuF3PEfqMgW1CEQKvHScMBaXliKuIIRxqqxoQ= Received: from [172.16.66.109] ([70.158.103.10]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 09 Nov 2012 21:48:02 +0100 id 00000000005DC039.00000000509D6C02.000024A0 Message-ID: <509D6C01.4090708@tana.it> Date: Fri, 09 Nov 2012 15:48:01 -0500 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D17C7.7050300@dcrocker.net> <20121109150523.GE79908@mx1.yitter.info> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 20:48:05 -0000 On Fri 09/Nov/2012 10:30:53 -0500 Scott Kitterman wrote: > > I think this is a case of the protocol operating as designed. It's > not at all clear anything needs fixing. Something needs fixing, since it doesn't work as intended by the user. The way large organizations delegate responsibility is not matched by include mechanisms. Include covers mailing services. I guess domains that use them have an agreement with one such services, possibly two if they care about failure tolerance. We had this discussion already: http://www.ietf.org/mail-archive/web/spfbis/current/msg01777.html I know no software that implements SPF publishing for such companies. > "Murray S. Kucherawy" wrote: > >> Just to clarify: I actually don't care which path we take, but we need >> to be consistent. That can be relaxed even more: it is enough that we produce a consistent spec. From sm@elandsys.com Fri Nov 9 12:51: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 310F921F873F for ; Fri, 9 Nov 2012 12:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjh4USTeB9PL for ; Fri, 9 Nov 2012 12:51:03 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2195721F86E0 for ; Fri, 9 Nov 2012 12:51:02 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.152.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA9KokUH006565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Nov 2012 12:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352494261; bh=9trfDLkL6iFpcO95o6jgA6vjTC9hhmG1oe5Zss0n5Xo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=KHCjpqB0HEsROhzEjFQyFc5fyJdz60bMGsKuNTqvu8sw/HvxyWG19qsr4R1vBHb9l 8Olr+Kic7ibgB5S22k2iXMBh3+lyhooAsfMgze4747NoSERQVy5paovqz/u+Z3A6Y5 apwceHjTjZbEfa6u4xak8pwQWlNfU09mMMYcVrdg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352494261; i=@elandsys.com; bh=9trfDLkL6iFpcO95o6jgA6vjTC9hhmG1oe5Zss0n5Xo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=DulC988r/ROEBAbaKEcGJM6PhiKOkHD7vCmqV95B2y/GMbN97DRYDN7l0eVqHvlxF u6mjkCi1JOPGR1PMtXt70rjh3FvR8szYG4jWmbfaSmIlyp7xeixAjzkwSYhfk3UWlw qfL7HgwDNn12tzedJ1xZNsNkj/ZAttlycKhVS14M= Message-Id: <6.2.5.6.2.20121109124217.09af5790@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 09 Nov 2012 12:50:07 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <20121108200357.GB76167@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] spfbis minutes X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 09 Nov 2012 20:51:04 -0000 Hello, Thanks to John Levine for taking the minutes for IETF 85. If I am not mistaken, Tim Draegen was the Jabber scribe. Thanks for helping out. You can view it at http://www.ietf.org/proceedings/85/minutes/minutes-85-spfbis There are links to the audio recording and Jabber logs at http://www.ietf.org/proceedings/85/spfbis.html I'll go through the audio recording and I may post some further notes. There is also the Meetecho recording at http://ietf85.conf.meetecho.com/index.php/Recorded_Sessions Regards, S. Moonesamy From vesely@tana.it Fri Nov 9 13:10:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1121F8759 for ; Fri, 9 Nov 2012 13:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S+MHFBMqeXs for ; Fri, 9 Nov 2012 13:10:21 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7F121F86F3 for ; Fri, 9 Nov 2012 13:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352495420; bh=4otsfKXrenRMeIarRFp3uIrq0vkbIzgoVveVfrKAtB4=; l=578; h=Date:From:To:References:In-Reply-To; b=r3CQbrNd0IfW/ihi6p4G9Qrn5usXWtKO3jIhm/cSbVnGpp1qHXHurdNqsDraewK1K AtWm+by+u8suNSI8spuEQL6Rd8S/3zv6DjNvUpXwj62zOoQJ/vx3Dj2lsM/NkjCcy5 fltkglLJkCDK8/W+mjLeAMWdoG00frs8+uIcSe+Y= Received: from [172.16.66.109] ([70.158.103.10]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 09 Nov 2012 22:10:17 +0100 id 00000000005DC039.00000000509D713B.00000BF3 Message-ID: <509D7133.4010900@tana.it> Date: Fri, 09 Nov 2012 16:10:11 -0500 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20121108200357.GB76167@crankycanuck.ca> <6.2.5.6.2.20121109124217.09af5790@elandnews.com> In-Reply-To: <6.2.5.6.2.20121109124217.09af5790@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] spfbis minutes X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 09 Nov 2012 21:10:22 -0000 On Fri 09/Nov/2012 15:50:07 -0500 S Moonesamy wrote: > > You can view it at > http://www.ietf.org/proceedings/85/minutes/minutes-85-spfbis Do we want to split the document into a specification and an operations guide? Hum roughly even in the room, strong opposition on the jabber. I wish to clarify that the 2nd document of the split was meant to be an applicability statement, normative on receiver behavior, rather than an operations guide. I think that was fairly clear in the room, not sure about the jabber. (Would that explain the difference in volume?) From vesely@tana.it Fri Nov 9 14:29:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B3521F86AE for ; Fri, 9 Nov 2012 14:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yETXtRaEYYiN for ; Fri, 9 Nov 2012 14:29:24 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1B03B21F86A8 for ; Fri, 9 Nov 2012 14:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352500162; bh=0+Ugp404+Xsa5sz0pbzWvAdi0q+Vilx1D4dTTcVdItg=; l=1831; h=Date:From:To; b=wl9xDDmYtABVAkwE27OcS8bdZ0gtHUVl9ufvm8Xrgv8Kwxs98BpB1Ww3iDSn/oXWn p6YN1TWxP36En9aHkizVNO7PXCXoyAz+QqSVjqqAHrWNd9dggH2i5KKlnKpKcV+mbj gwvBbl0LTgRETVM3NYR9gjWOVN31xV9+BgQQDlIc= Received: from [172.16.66.109] ([70.158.103.10]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 09 Nov 2012 23:29:22 +0100 id 00000000005DC039.00000000509D83C2.00007616 Message-ID: <509D83C1.301@tana.it> Date: Fri, 09 Nov 2012 17:29:21 -0500 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 09 Nov 2012 22:29:25 -0000 Section 7, *Recording The Result* talks about results in general. The following sentence in 7.1, *The Received-SPF Header Field* might generate confusion, as it seems to imply that the "helo" identity is mandatory while "MAIL FROM" IS OPTIONAL: That is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from". The recommendation to use one field for each identity that was checked has disappeared. (Why?) It can only be inferred from the examples. The second paragraph of Section 2.2, *The MAIL FROM Identity* has a couple of issues. One is that it says: In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. The cited section of RFC 5321 says exactly the opposite. That is, if the message is a compliant notification, you can assume that the envelope sender is empty, not the other way around. Anyway,it is the next sentence that might cause some real states of confusion about identities: When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the local-part "postmaster" and the "HELO" identity (which might or might not have been checked separately before). If that were a definition, it should have been given in Section 1.3.3, *Mail From Definition*. Isn't that cumbersome? Does it make any real protocol difference if we simply say that when the "MAIL FROM" identity is empty, verifying helo raises from SHOULD to MUST? Consider: Received-SPF: fail (mybox.example.org: domain of myname@example.com does not designate 192.0.2.1 as permitted sender) identity=mailfrom; client-ip=192.0.2.1; envelope-from="postmaster@foo.example.com"; Does that apply the definition correctly? From spf2@kitterman.com Fri Nov 9 16:24:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DB321F85B2 for ; Fri, 9 Nov 2012 16:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhNF7JUsbWcS for ; Fri, 9 Nov 2012 16:24:47 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 78B7D21F85ED for ; Fri, 9 Nov 2012 16:24:47 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 60D2D20E40CF; Fri, 9 Nov 2012 19:24:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352507086; bh=LweMoBDrv0LCrgh7XPRm+1K9F8Eikp3KGDqmtCl7xGU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OpmVCMzizeIn3FHrjQdKkwvRJ+qIULyjW4mdL9qG5+T1daTpgSmOSKdba1V2Nggv1 o+31NvOj0RJleoMlhd9w/VYaLU7mYSDijYwqq4gIB9MI17+bp+c4OqOPstweDXzKrf BNHBZE7sHr2IBbZk4bJpZH2zUgVgAM2v4BZ3Ad0I= Received: from scott-latitude-e6320.localnet (108-212-65-220.lightspeed.sntcca.sbcglobal.net [108.212.65.220]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EEF3220E409E; Fri, 9 Nov 2012 19:24:45 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 09 Nov 2012 19:24:40 -0500 Message-ID: <3027913.dGi6CsUAo1@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-18-generic; KDE/4.9.2; i686; ; ) In-Reply-To: <509D83C1.301@tana.it> References: <509D83C1.301@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:24:49 -0000 On Friday, November 09, 2012 05:29:21 PM Alessandro Vesely wrote: > Section 7, *Recording The Result* talks about results in general. > > The following sentence in 7.1, *The Received-SPF Header Field* might > generate confusion, as it seems to imply that the "helo" identity is > mandatory while "MAIL FROM" IS OPTIONAL: > > That is, at least "client-ip", "helo", and, if the > "MAIL FROM" identity was checked, "envelope-from". > > The recommendation to use one field for each identity that was checked > has disappeared. (Why?) It can only be inferred from the examples. > > The second paragraph of Section 2.2, *The MAIL FROM Identity* has a > couple of issues. One is that it says: > > In this case, there is no explicit sender mailbox, and > such a message can be assumed to be a notification message from the > mail system itself. > > The cited section of RFC 5321 says exactly the opposite. That is, if > the message is a compliant notification, you can assume that the > envelope sender is empty, not the other way around. > > Anyway,it is the next sentence that might cause some real states of > confusion about identities: > > When the reverse-path is null, this document > defines the "MAIL FROM" identity to be the mailbox composed of the > local-part "postmaster" and the "HELO" identity (which might or might > not have been checked separately before). > > If that were a definition, it should have been given in Section 1.3.3, > *Mail From Definition*. Isn't that cumbersome? Does it make any real > protocol difference if we simply say that when the "MAIL FROM" identity > is empty, verifying helo raises from SHOULD to MUST? > > Consider: > > Received-SPF: fail (mybox.example.org: domain of > myname@example.com does not designate > 192.0.2.1 as permitted sender) > identity=mailfrom; client-ip=192.0.2.1; > envelope-from="postmaster@foo.example.com"; > > Does that apply the definition correctly? Where the current text is unclear, please provide a recommended alternative. Changing from "Use helo to construct an artificial mail from in this manner" to "If mail from is empty helo checking is mandatory" is a protocol change. It may usually (and perhaps always) achieve the same result, but I think it's precisely the kind of change we need to be careful about making due to risks of inadvertent consequences. Scott K From spf2@kitterman.com Fri Nov 9 16:27:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9245921F866E for ; Fri, 9 Nov 2012 16:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qXmjsBgjNZE for ; Fri, 9 Nov 2012 16:27:28 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F188221F8660 for ; Fri, 9 Nov 2012 16:27:27 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 83FAE20E40CF; Fri, 9 Nov 2012 19:27:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352507247; bh=Fewfo7S65L77+IqY0iQOZqh9dZgY1zX6uNWePEE+yX0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gOzKRaS9vVcY78ZkCfUs5w7bF+feFe68IEwHBJwuDe/3ZmNkmfYtFrOSEF5KQjuC1 ai2VddWw43kELv/3qWYIAaYFzgEvNcq+b29Nk7bt2Prbk5mW+lSNZq8eB4GRiX39t5 4qaifUCRtGgCF/N1W4d0NqHvitRmqaCHtJuO/vQE= Received: from scott-latitude-e6320.localnet (108-212-65-220.lightspeed.sntcca.sbcglobal.net [108.212.65.220]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3774A20E409E; Fri, 9 Nov 2012 19:27:26 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 09 Nov 2012 19:27:25 -0500 Message-ID: <2180121.TiyISiYL0H@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-18-generic; KDE/4.9.2; i686; ; ) In-Reply-To: <509D7133.4010900@tana.it> References: <20121108200357.GB76167@crankycanuck.ca> <6.2.5.6.2.20121109124217.09af5790@elandnews.com> <509D7133.4010900@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] spfbis minutes X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:27:29 -0000 On Friday, November 09, 2012 04:10:11 PM Alessandro Vesely wrote: > On Fri 09/Nov/2012 15:50:07 -0500 S Moonesamy wrote: > > You can view it at > > http://www.ietf.org/proceedings/85/minutes/minutes-85-spfbis > > Do we want to split the document into a specification and an > operations guide? Hum roughly even in the room, strong opposition on > the jabber. > > I wish to clarify that the 2nd document of the split was meant to be an > applicability statement, normative on receiver behavior, rather than an > operations guide. I think that was fairly clear in the room, not sure > about the jabber. (Would that explain the difference in volume?) I understood that from listening to the audio stream, so no it wouldn't have explained things, at least not for me. Scott K From spf2@kitterman.com Fri Nov 9 16:30: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 3C0C821F8652 for ; Fri, 9 Nov 2012 16:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZthKC93RDCw0 for ; Fri, 9 Nov 2012 16:30:15 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3DF21F8539 for ; Fri, 9 Nov 2012 16:30:15 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1C6D420E40CF; Fri, 9 Nov 2012 19:30:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352507415; bh=yBqblNH1ER42SpaIabOHzkby+l5rlDmkJuUMTkl+7Qs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WsVq22357WzQaPdEl3D3UgYcVVPryefMdKLNwB7uoxJYy8oUPiRh3iXMjLEXmx/di t2R3oDXNXpgcEDHuPGqkby13QtGWSUYfICczieqEPinFh4+4MdXTY8T0fQBDtUPE7D dJavicvuOIpGkzjVrOjYzw/xJXG24Czy/zNEUTIM= Received: from scott-latitude-e6320.localnet (108-212-65-220.lightspeed.sntcca.sbcglobal.net [108.212.65.220]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CF71E20E409E; Fri, 9 Nov 2012 19:30:14 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 09 Nov 2012 19:30:12 -0500 Message-ID: <10406074.ihGBF7TvX4@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-18-generic; KDE/4.9.2; i686; ; ) In-Reply-To: <509D6C01.4090708@tana.it> References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D6C01.4090708@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:30:16 -0000 On Friday, November 09, 2012 03:48:01 PM Alessandro Vesely wrote: > On Fri 09/Nov/2012 10:30:53 -0500 Scott Kitterman wrote: > > I think this is a case of the protocol operating as designed. It's > > not at all clear anything needs fixing. > > Something needs fixing, since it doesn't work as intended by the user. The user for SPF is the ADMD owner, not the individual mail sender/receiver so my anecdote offers no insight into if SPF is working as intended by the user. > The way large organizations delegate responsibility is not matched by > include mechanisms. Include covers mailing services. I guess domains > that use them have an agreement with one such services, possibly two if > they care about failure tolerance. We had this discussion already: > http://www.ietf.org/mail-archive/web/spfbis/current/msg01777.html > > I know no software that implements SPF publishing for such companies. There are many large organizations that have successfully implemented SPF, so I definitely don't understand what you're talking about here? Scott K From superuser@gmail.com Sat Nov 10 08:08:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB64721F847B for ; Sat, 10 Nov 2012 08:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlNUUlnOkj6G for ; Sat, 10 Nov 2012 08:08:44 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEE621F843B for ; Sat, 10 Nov 2012 08:08:37 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so4007481lam.31 for ; Sat, 10 Nov 2012 08:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wo8BFFIO7aHKOOpX1ixPIyZLUYOHT8Gwckt3bYqYT28=; b=qkX4DAwuUnkC6tUUjIN5p2D4kNL+tCv5iNhibvwE1Mjjt2W7+mjI4Mxt3GtHvk6FdG eW1PclwclJzJO8aTgtb1brKoeAN5X1iY49slR4wYKMeAbBN00QRjR1CCfN1klTbtpX/o GuEOY9pjjJXn6DiMkjXOuEny23O4DW341nCDkueDf7u9EHLm6/0eqeb8WpTtFcRE94+I lumXsQLdzH/2STscCrtjREGHNWumn1mtfUi+plk3jPETgkpUK7zR1kQBwprTCk3oHdXK V/Zst2ktj3hTv9JhNtXLMFn9IpL2L3FlBjqEPqDJH3vvMmBcwZ1SMZNYxLaO5gHMpnRt i3Eg== MIME-Version: 1.0 Received: by 10.152.102.234 with SMTP id fr10mr13731476lab.28.1352563716152; Sat, 10 Nov 2012 08:08:36 -0800 (PST) Received: by 10.112.83.232 with HTTP; Sat, 10 Nov 2012 08:08:35 -0800 (PST) In-Reply-To: <509D7133.4010900@tana.it> References: <20121108200357.GB76167@crankycanuck.ca> <6.2.5.6.2.20121109124217.09af5790@elandnews.com> <509D7133.4010900@tana.it> Date: Sat, 10 Nov 2012 08:08:35 -0800 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d04071259d65ca704ce2647cf Cc: "spfbis@ietf.org" Subject: Re: [spfbis] spfbis minutes X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 16:08:45 -0000 --f46d04071259d65ca704ce2647cf Content-Type: text/plain; charset=ISO-8859-1 I don't get the impression that there was even remote consensus for making a second document at this time, regardless of title or intended status. -MSK On Fri, Nov 9, 2012 at 1:10 PM, Alessandro Vesely wrote: > On Fri 09/Nov/2012 15:50:07 -0500 S Moonesamy wrote: > > > > You can view it at > > http://www.ietf.org/proceedings/85/minutes/minutes-85-spfbis > > Do we want to split the document into a specification and an > operations guide? Hum roughly even in the room, strong opposition on > the jabber. > > I wish to clarify that the 2nd document of the split was meant to be an > applicability statement, normative on receiver behavior, rather than an > operations guide. I think that was fairly clear in the room, not sure > about the jabber. (Would that explain the difference in volume?) > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d04071259d65ca704ce2647cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't get the impression that there was even remote consensus for mak= ing a second document at this time, regardless of title or intended status.=

-MSK


On Fri, Nov 9, 2012 at 1:10 PM, Alessandro Vesely <vesely@tana.it> wrote:
On Fri 09/Nov/2012 15:50:07 -0500 S Moonesamy wrote:
>
> You can view it at
> http://www.ietf.org/proceedings/85/minutes/minutes-85-= spfbis

=A0 =A0Do we want to split the document into a specification and an =A0 =A0operations guide? =A0Hum roughly even in the room, strong opposition= on
=A0 =A0the jabber.

I wish to clarify that the 2nd document of the split was meant to be an
applicability statement, normative on receiver behavior, rather than an
operations guide. =A0I think that was fairly clear in the room, not sure about the jabber. =A0(Would that explain the difference in volume?)
___________________________________= ____________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d04071259d65ca704ce2647cf-- From superuser@gmail.com Sat Nov 10 08:11:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD29121F847D for ; Sat, 10 Nov 2012 08:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy-zVaQRrxmQ for ; Sat, 10 Nov 2012 08:11:44 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68FF621F847B for ; Sat, 10 Nov 2012 08:11:44 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so416686lbk.31 for ; Sat, 10 Nov 2012 08:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qh+wl/bOrLGZv0kOehFgq9Kp/HdGJ4LZRCDD9XBPqJo=; b=Bx4rtzFF8/ybvNesqw8BXgPJoyWCvjpKvxPMXPd86fdSFrQzyNKpmO01tGEJ8Ifrbj lnB4EeWyptLB3VWyqUrRTQprKjA55nCJoLMMsbfVQYirAjOED57K0GTFXouvR6fzBKr+ cwLXw9NHRW4Tw6iGY1f8JNnIS7mZ9Scs8dLW8kUbG07EMClArYtDceQ+bQHBF5HyZ0e8 pYxzE7Zwom+zz6+4yQZMuNzwJ4WMXPYdB/8SdEuJ2YbN0oewGJyvCmZ4xZpYyCAGz/eR ov+GW+7wGIlLVGIfQmhwuHYUGI6obtrVEnrT2PUtXqnKxQHXfH2m7fMeRdbIhuIsejL4 1Xrw== MIME-Version: 1.0 Received: by 10.152.110.42 with SMTP id hx10mr13644689lab.0.1352563903345; Sat, 10 Nov 2012 08:11:43 -0800 (PST) Received: by 10.112.83.232 with HTTP; Sat, 10 Nov 2012 08:11:43 -0800 (PST) In-Reply-To: <3027913.dGi6CsUAo1@scott-latitude-e6320> References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> Date: Sat, 10 Nov 2012 08:11:43 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=bcaec54ee8a4feb49004ce2652e4 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 16:11:45 -0000 --bcaec54ee8a4feb49004ce2652e4 Content-Type: text/plain; charset=ISO-8859-1 I agree that the first "if" referring to MAIL FROM is a little odd, at least without the surrounding context. But I also agree with Scott: Please post some specific suggested changes, like: OLD: blah blah NEW: blah2 blah2 It's much easier to see what you have in mind then. -MSK On Fri, Nov 9, 2012 at 4:24 PM, Scott Kitterman wrote: > On Friday, November 09, 2012 05:29:21 PM Alessandro Vesely wrote: > > Section 7, *Recording The Result* talks about results in general. > > > > The following sentence in 7.1, *The Received-SPF Header Field* might > > generate confusion, as it seems to imply that the "helo" identity is > > mandatory while "MAIL FROM" IS OPTIONAL: > > > > That is, at least "client-ip", "helo", and, if the > > "MAIL FROM" identity was checked, "envelope-from". > > > > The recommendation to use one field for each identity that was checked > > has disappeared. (Why?) It can only be inferred from the examples. > > > > The second paragraph of Section 2.2, *The MAIL FROM Identity* has a > > couple of issues. One is that it says: > > > > In this case, there is no explicit sender mailbox, and > > such a message can be assumed to be a notification message from the > > mail system itself. > > > > The cited section of RFC 5321 says exactly the opposite. That is, if > > the message is a compliant notification, you can assume that the > > envelope sender is empty, not the other way around. > > > > Anyway,it is the next sentence that might cause some real states of > > confusion about identities: > > > > When the reverse-path is null, this document > > defines the "MAIL FROM" identity to be the mailbox composed of the > > local-part "postmaster" and the "HELO" identity (which might or might > > not have been checked separately before). > > > > If that were a definition, it should have been given in Section 1.3.3, > > *Mail From Definition*. Isn't that cumbersome? Does it make any real > > protocol difference if we simply say that when the "MAIL FROM" identity > > is empty, verifying helo raises from SHOULD to MUST? > > > > Consider: > > > > Received-SPF: fail (mybox.example.org: domain of > > myname@example.com does not designate > > 192.0.2.1 as permitted sender) > > identity=mailfrom; client-ip=192.0.2.1; > > envelope-from="postmaster@foo.example.com"; > > > > Does that apply the definition correctly? > > Where the current text is unclear, please provide a recommended > alternative. > > Changing from "Use helo to construct an artificial mail from in this > manner" to > "If mail from is empty helo checking is mandatory" is a protocol change. > It > may usually (and perhaps always) achieve the same result, but I think it's > precisely the kind of change we need to be careful about making due to > risks > of inadvertent consequences. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --bcaec54ee8a4feb49004ce2652e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that the first "if" referring to MAIL FROM is a little od= d, at least without the surrounding context.=A0 But I also agree with Scott= : Please post some specific suggested changes, like:

OLD:
blah bl= ah

NEW:
blah2 blah2

It's much easier to see what you have i= n mind then.

-MSK


On Fri, Nov 9, 2012 at 4:24 PM, Scott Kitterman <spf2@k= itterman.com> wrote:
On F= riday, November 09, 2012 05:29:21 PM Alessandro Vesely wrote:
> Section 7, *Recording The Result* talks about results in general.
>
> The following sentence in 7.1, *The Received-SPF Header Field* might > generate confusion, as it seems to imply that the "helo" ide= ntity is
> mandatory while "MAIL FROM" IS OPTIONAL:
>
> =A0 =A0That is, at least "client-ip", "helo", and,= if the
> =A0 =A0"MAIL FROM" identity was checked, "envelope-from= ".
>
> The recommendation to use one field for each identity that was checked=
> has disappeared. =A0(Why?) =A0It can only be inferred from the example= s.
>
> The second paragraph of Section 2.2, *The MAIL FROM Identity* has a > couple of issues. =A0One is that it says:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 In this case, there is no explicit sen= der mailbox, and
> =A0 =A0such a message can be assumed to be a notification message from= the
> =A0 =A0mail system itself.
>
> The cited section of RFC 5321 says exactly the opposite. =A0That is, i= f
> the message is a compliant notification, you can assume that the
> envelope sender is empty, not the other way around.
>
> Anyway,it is the next sentence that might cause some real states of > confusion about identities:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 When the reverse-path = is null, this document
> =A0 =A0defines the "MAIL FROM" identity to be the mailbox co= mposed of the
> =A0 =A0local-part "postmaster" and the "HELO" iden= tity (which might or might
> =A0 =A0not have been checked separately before).
>
> If that were a definition, it should have been given in Section 1.3.3,=
> *Mail From Definition*. =A0Isn't that cumbersome? =A0Does it make = any real
> protocol difference if we simply say that when the "MAIL FROM&quo= t; identity
> is empty, verifying helo raises from SHOULD to MUST?
>
> Consider:
>
> =A0 =A0Received-SPF: fail (mybox.example.org: domain of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0myname@example.com does not designate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0192.0.2.1 as permitted send= er)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0identity=3Dmailfrom; client= -ip=3D192.0.2.1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0envelope-from=3D"postmaster@foo.example.com&quo= t;;
>
> Does that apply the definition correctly?

Where the current text is unclear, please provide a recommended= alternative.

Changing from "Use helo to construct an artificial mail from in this m= anner" to
"If mail from is empty helo checking is mandatory" is a protocol = change. =A0It
may usually (and perhaps always) achieve the same result, but I think it= 9;s
precisely the kind of change we need to be careful about making due to risk= s
of inadvertent consequences.

Scott K
___________________________________= ____________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--bcaec54ee8a4feb49004ce2652e4-- From ietf@meetecho.com Sat Nov 10 12:15: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 D7AA121F850A for ; Sat, 10 Nov 2012 12:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP8+dy5dCCg7 for ; Sat, 10 Nov 2012 12:15:32 -0800 (PST) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id D534F21F8507 for ; Sat, 10 Nov 2012 12:15:31 -0800 (PST) Received: from [192.168.0.4] ([151.77.98.23]) by smtpcmd03.ad.aruba.it with bizsmtp id MwFS1k00H0WGHKK01wFUzK; Sat, 10 Nov 2012 21:15:29 +0100 Message-ID: <509EB5D9.6030306@meetecho.com> Date: Sat, 10 Nov 2012 21:15:21 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "spfbis@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Meetecho session recording X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 20:15:33 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From vesely@tana.it Sun Nov 11 12:15:04 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D2E21F84D1 for ; Sun, 11 Nov 2012 12:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-GIhymzpenb for ; Sun, 11 Nov 2012 12:15:03 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E324A21F84FE for ; Sun, 11 Nov 2012 12:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352664900; bh=bgWIYr9rLwA6PQkVp3lIskB1vcW6cc8f9mvunUJmdg8=; l=7494; h=Date:From:To:References:In-Reply-To; b=tiJ/HwF6KRMzkUaDkXg47NAHFzkOQ49Y3xXvvHyLffWWyV/4w+OGNVgYMPSXKlyOD g6DvWtfi14XDQh2p1oTZoBIWlZZUPWfhQMJgen2RCeLTXMDVWmqq9VZ5cWLdgearE3 taAW7hTv+UwTodoKN8i3Zqm0/JErm7Ggiw4E4HhM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 11 Nov 2012 21:15:00 +0100 id 00000000005DC039.0000000050A00744.00005F9B Message-ID: <50A00743.4000703@tana.it> Date: Sun, 11 Nov 2012 21:14:59 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-24475-1352664900-0001-2" To: spfbis@ietf.org References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> In-Reply-To: <3027913.dGi6CsUAo1@scott-latitude-e6320> Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 20:15:04 -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-24475-1352664900-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Sat 10/Nov/2012 01:24:40 +0100 Scott Kitterman wrote: > On Friday, November 09, 2012 05:29:21 PM Alessandro Vesely wrote: >> >> If that were a definition, it should have been given in Section 1.3.3, >> *Mail From Definition*. Isn't that cumbersome? Does it make any real >> protocol difference if we simply say that when the "MAIL FROM" identity >> is empty, verifying helo raises from SHOULD to MUST? >> >> Consider: >> >> Received-SPF: fail (mybox.example.org: domain of >> myname@example.com does not designate >> 192.0.2.1 as permitted sender) >> identity=mailfrom; client-ip=192.0.2.1; >> envelope-from="postmaster@foo.example.com"; >> >> Does that apply the definition correctly? > > Where the current text is unclear, please provide a recommended alternative. Changes are as follows (see also xml patch attached). I also reword the previous protocol change (exemption when useless) as with no commas the "by applying" might be associated to the helo check inside the "if". ORIGINAL (4408) [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in RFC 2821). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the localpart "postmaster" and the "HELO" identity (which may or may not have been checked separately before). SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the . OLD (bis-08): SPF verifiers MUST check the ""MAIL FROM" identity if a completed "HELO" check has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the . [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in [RFC5321]). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the local-part "postmaster" and the "HELO" identity (which might or might not have been checked separately before). NEW: SPF verifiers MUST check the "MAIL FROM" identity, by applying the check_host() function to the "MAIL FROM" identity as the , except for the two cases following: o A final policy decision has already been reached by completing a check on the "HELO" identity. In this case, unless its result will be recorded (Section 7), it is useless to check the "MAIL FROM" identity. o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in [RFC5321]). In this case, SPF verifiers MUST check the "HELO" identity instead. According to Section 4.3, that implies synthesizing a mailbox composed of the local-part "postmaster" and the "HELO" identity. Note that such check might have been carried out separately before. > Changing from "Use helo to construct an artificial mail from in > this manner" to "If mail from is empty helo checking is mandatory" > is a protocol change. It may usually (and perhaps always) achieve > the same result, An example where the achieved results differ is given above. The new wording doesn't allow unintended interpretations, hopefully: That's what I'm asking the list to verify. > but I think it's precisely the kind of change we need to be careful > about making due to risks of inadvertent consequences. Agreed. On the other hand, ill-defined rules bear the risk of latent misinterpretations, whose consequences may show up anytime. BTW, the "exemption when useless" isn't in RFC 4408 either. --=_north-24475-1352664900-0001-2 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-spfbis-4408bis-08.xml.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-08.xml.patch" LS0tIGRyYWZ0LWlldGYtc3BmYmlzLTQ0MDhiaXMtMDgueG1sCTIwMTItMTEtMTEgMTc6NDk6 MzEuMDAwMDAwMDAwICswMTAwCisrKyBkcmFmdC1pZXRmLXNwZmJpcy00NDA4YmlzLTA4Ky54 bWwJMjAxMi0xMS0xMSAyMDozMzoxMC4wMDAwMDAwMDAgKzAxMDAKQEAgLTIzMywyMCArMjMz LDI1IEBACiAgICAgICA8L3NlY3Rpb24+CiAgICAgICA8c2VjdGlvbiB0aXRsZT0iVGhlICZx dW90O01BSUwgRlJPTSZxdW90OyBJZGVudGl0eSIgYW5jaG9yPSJtZnJvbS1pZGVudCI+CiAg ICAgICAgIDx0PgotICAgICAgICAgIFNQRiB2ZXJpZmllcnMgTVVTVCBjaGVjayB0aGUgIiJN QUlMIEZST00iIGlkZW50aXR5IGlmIGEgY29tcGxldGVkCi0gICAgICAgICAgIkhFTE8iIGNo ZWNrIGhhcyBub3QgcmVhY2hlZCBhIGRlZmluaXRpdmUgcG9saWN5IHJlc3VsdCBieQotICAg ICAgICAgIGFwcGx5aW5nIHRoZSBjaGVja19ob3N0KCkgZnVuY3Rpb24gdG8gdGhlICJNQUlM IEZST00iIGlkZW50aXR5IGFzCi0gICAgICAgICAgdGhlICZsdDtzZW5kZXImZ3Q7LgotICAg ICAgICA8L3Q+Ci0gICAgICAgIDx0PgotICAgICAgICAgIDx4cmVmIHRhcmdldD0iUkZDNTMy MSIvPiBhbGxvd3MgdGhlIHJldmVyc2UtcGF0aCB0byBiZSBudWxsIChzZWUKLSAgICAgICAg ICBTZWN0aW9uIDQuNS41IGluIDx4cmVmIHRhcmdldD0iUkZDNTMyMSIvPikuICBJbiB0aGlz IGNhc2UsIHRoZXJlIGlzIG5vCi0gICAgICAgICAgZXhwbGljaXQgc2VuZGVyIG1haWxib3gs IGFuZCBzdWNoIGEgbWVzc2FnZSBjYW4gYmUgYXNzdW1lZCB0byBiZSBhCi0gICAgICAgICAg bm90aWZpY2F0aW9uIG1lc3NhZ2UgZnJvbSB0aGUgbWFpbCBzeXN0ZW0gaXRzZWxmLiAgV2hl biB0aGUKLSAgICAgICAgICByZXZlcnNlLXBhdGggaXMgbnVsbCwgdGhpcyBkb2N1bWVudCBk ZWZpbmVzIHRoZSAiTUFJTCBGUk9NIgotICAgICAgICAgIGlkZW50aXR5IHRvIGJlIHRoZSBt YWlsYm94IGNvbXBvc2VkIG9mIHRoZSBsb2NhbC1wYXJ0ICJwb3N0bWFzdGVyIgotICAgICAg ICAgIGFuZCB0aGUgIkhFTE8iIGlkZW50aXR5ICh3aGljaCBtaWdodCBvciBtaWdodCBub3Qg aGF2ZSBiZWVuCi0gICAgICAgICAgY2hlY2tlZCBzZXBhcmF0ZWx5IGJlZm9yZSkuCisgICAg ICAgICAgU1BGIHZlcmlmaWVycyBNVVNUIGNoZWNrIHRoZSAiTUFJTCBGUk9NIiBpZGVudGl0 eSwgYnkgYXBwbHlpbmcgdGhlCisgICAgICAgICAgY2hlY2tfaG9zdCgpIGZ1bmN0aW9uIHRv IHRoZSAiTUFJTCBGUk9NIiBpZGVudGl0eSBhcyB0aGUKKyAgICAgICAgICAmbHQ7c2VuZGVy Jmd0OywgZXhjZXB0IGZvciB0aGUgdHdvIGNhc2VzIGZvbGxvd2luZzoKKyAgICAgICAgPGxp c3Qgc3R5bGU9InN5bWJvbHMiPgorICAgICAgICAgIDx0PgorICAgICAgICAgICAgQSBmaW5h bCBwb2xpY3kgZGVjaXNpb24gaGFzIGFscmVhZHkgYmVlbiByZWFjaGVkIGJ5IGNvbXBsZXRp bmcgYQorICAgICAgICAgICAgY2hlY2sgb24gdGhlICJIRUxPIiBpZGVudGl0eS4gIEluIHRo aXMgY2FzZSwgdW5sZXNzIGl0cyByZXN1bHQKKyAgICAgICAgICAgIHdpbGwgYmUgcmVjb3Jk ZWQgKDx4cmVmIHRhcmdldD0icmVzdWx0cy1oZWFkZXJzIi8+KSwgaXQgaXMgdXNlbGVzcwor ICAgICAgICAgICAgdG8gY2hlY2sgdGhlICJNQUlMIEZST00iIGlkZW50aXR5LgorICAgICAg ICAgIDwvdD4KKyAgICAgICAgICA8dD4KKyAgICAgICAgICAgIFNNVFAgYWxsb3dzIHRoZSAi TUFJTCBGUk9NIiBpZGVudGl0eSB0byBiZSBudWxsIChTZWN0aW9uIDQuNS41IGluCisgICAg ICAgICAgICA8eHJlZiB0YXJnZXQ9IlJGQzUzMjEiLz4pLiAgSW4gdGhpcyBjYXNlLCBTUEYg dmVyaWZpZXJzIE1VU1QgY2hlY2sKKyAgICAgICAgICAgIHRoZSAiSEVMTyIgaWRlbnRpdHkg aW5zdGVhZC4gIEFjY29yZGluZyB0byA8eHJlZiB0YXJnZXQ9ImluaXRpYWwiLz4sCisgICAg ICAgICAgICB0aGF0IGltcGxpZXMgc3ludGhlc2l6aW5nIGEgbWFpbGJveCBjb21wb3NlZCBv ZiB0aGUgbG9jYWwtcGFydAorICAgICAgICAgICAgInBvc3RtYXN0ZXIiIGFuZCB0aGUgIkhF TE8iIGlkZW50aXR5LiAgTm90ZSB0aGF0IHN1Y2ggY2hlY2sgbWlnaHQKKyAgICAgICAgICAg IGhhdmUgYmVlbiBjYXJyaWVkIG91dCBzZXBhcmF0ZWx5IGJlZm9yZS4KKyAgICAgICAgICA8 L3Q+CisgICAgICAgIDwvbGlzdD4KICAgICAgICAgPC90PgogICAgICAgPC9zZWN0aW9uPgog ICAgICAgPHNlY3Rpb24gdGl0bGU9IlB1Ymxpc2hpbmcgQXV0aG9yaXphdGlvbiI+Cg== --=_north-24475-1352664900-0001-2-- From vesely@tana.it Sun Nov 11 12:18:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0294521F84C8 for ; Sun, 11 Nov 2012 12:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNlHVCiMjZs2 for ; Sun, 11 Nov 2012 12:18:44 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4174121F84C7 for ; Sun, 11 Nov 2012 12:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352665123; bh=wWer4kwES30Mj2KXPHDVhWC0gVIEp4tHQRwjDoG5etg=; l=901; h=Date:From:To:References:In-Reply-To; b=JfS7aKW6ErUeh3EiCukwF7dKAv6wLdRirdZYMZddabITRMFpsIJYU5ZlU/Fx2/7Bs 3He6P/B0w362Qqp4IobB251chfk1zdLhHZuoQzXxIjb6K8+jentBKW4ikj+BY0D6DV OLLY8XwpGtWleviEgDnGTXbqhsaM3RnVdSktC18c= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 11 Nov 2012 21:18:43 +0100 id 00000000005DC039.0000000050A00823.00007223 Message-ID: <50A00823.5010304@tana.it> Date: Sun, 11 Nov 2012 21:18:43 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <509D6C01.4090708@tana.it> <10406074.ihGBF7TvX4@scott-latitude-e6320> In-Reply-To: <10406074.ihGBF7TvX4@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 20:18:45 -0000 On Sat 10/Nov/2012 01:30:12 +0100 Scott Kitterman wrote: > On Friday, November 09, 2012 03:48:01 PM Alessandro Vesely wrote: >> I know no software that implements SPF publishing for such companies. > > There are many large organizations that have successfully > implemented SPF, so I definitely don't understand what you're > talking about here? I meant using "exists". That implies managing a DNS, or outsourcing to someone who does. I have no direct experience of how large companies structure authorizations to send out mail directly. Do they fully specify what are the procedures for granting send-permissions? Even if ISO 9000 compliance may require them to do so, by managing large blocks of addresses in included records they can be more flexible, and sloppy. I guess inhaus delegations are not quite comparable to RIRs management. Do they use specific software for that? From hsantos@isdg.net Sun Nov 11 13:21: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 98B0821F8490 for ; Sun, 11 Nov 2012 13:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-lcr66J4iJv for ; Sun, 11 Nov 2012 13:21:31 -0800 (PST) Received: from winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A002721F847D for ; Sun, 11 Nov 2012 13:21:30 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1367; t=1352668881; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=k6g2WihmRTEQx8BwjOQM3X4zmok=; b=j400DThxnlSX0Xc56SUo 6SBxWnkQhNepYpj5q0XwR4OVqgPFaeMn5n/V7rSyC+D7SASK/eRYuBxgz2LimEbD sYyuCyEzeodQ5K8EuJ3dNYd4HBnfr9uY/owNQcAL5G1Ds4oPjo9gzLPW0/8Hc2LI GdvnNpYEqn0v+VsPP/0lSZM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 11 Nov 2012 16:21:21 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 100664384.5087.284; Sun, 11 Nov 2012 16:21:20 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1367; t=1352668550; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yldVD/K a7MIQwCfx104Qum4/Bul3rnRF+6qs7XHQ+rQ=; b=VbcvV22O5Qiy788rNKQdECb zUBiry1xjv3cFtqfJEKu8s+rLVLWJIIg1TpZfbaseh9XlRDyESEzka1aAD+e5eVs vLRG00FJQDFEp24Ms22q20VE226pzVKEwExDOiM9L9YNd5O3CV5y0K/tVeSbRql6 B/55l8NbghBCIMTI74fw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 11 Nov 2012 16:15:50 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 699414350.9.5536; Sun, 11 Nov 2012 16:15:50 -0500 Message-ID: <50A016E7.2090208@isdg.net> Date: Sun, 11 Nov 2012 16:21:43 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> In-Reply-To: <50A00743.4000703@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 21:21:32 -0000 Alessandro Vesely wrote: > NEW: > SPF verifiers MUST check the "MAIL FROM" identity, by applying the > check_host() function to the "MAIL FROM" identity as the , > except for the two cases following: > > o A final policy decision has already been reached by completing a > check on the "HELO" identity. In this case, unless its result > will be recorded (Section 7), it is useless to check the "MAIL > FROM" identity. > > o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in > [RFC5321]). In this case, SPF verifiers MUST check the "HELO" > identity instead. According to Section 4.3, that implies > synthesizing a mailbox composed of the local-part "postmaster" and > the "HELO" identity. Note that such check might have been carried > out separately before. > I would add (with a text change above to indicate three cases): o Some other authentication/authorization check is made that does not require SPF to be applied any longer. A good example is checking the RCPT TO address for local user existence prior to performing SPF checks (or any other DNS related protocol check). In practice, this consideration can reduce DNS/SPF overhead by the same percentage as the RCPT TO rejections detected, in some field observations as high as 60% reduction in SPF necessity for the current session. -- HLS From hsantos@isdg.net Sun Nov 11 13:34: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 08CD821F84D1 for ; Sun, 11 Nov 2012 13:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.213 X-Spam-Level: X-Spam-Status: No, score=-101.213 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvim0qdhRmvg for ; Sun, 11 Nov 2012 13:34:32 -0800 (PST) Received: from winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F3A7521F84C7 for ; Sun, 11 Nov 2012 13:34:31 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2397; t=1352669662; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=EUDTykYiJXDWIIoB7tuBnvETALU=; b=rKV4VabpTkVLom5OQIBN KSfln1h+orQ5axtWcMQAnl2O9hsfPWz9QkYVruQHNAK5D1S1qQuFG8hpbw4UJvB7 W5iLzfcXti/rOxbjYIY/wUAsDtP6xGveA4vDbyLjJcCbLmtBUmll22GLz6RDlNFu joaKfqxATtqvgdssLVdtAL0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 11 Nov 2012 16:34:22 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 101444530.5087.2708; Sun, 11 Nov 2012 16:34:20 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2397; t=1352669331; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=xMZ3U1K pDiE5VK3z0FEEkU0KrkEswd0iB9MV8SyWXN8=; b=LzwZATeKuIR/W6NqFh6zlL3 jzts1y07CpBjzbHllf5GN1KXcI5kXLOPar7+nvd0Is7Y7fUegqU+LCXLORBdZK+2 TecC5iY9njFD9qx815XIGvLUNcPPM1VN49cyJ+wcpOQLcRolBfnMLm3MprtI1EU+ OZqCg7zIS8hheI6FE97o= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 11 Nov 2012 16:28:51 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 700194897.9.3876; Sun, 11 Nov 2012 16:28:50 -0500 Message-ID: <50A019F2.50905@isdg.net> Date: Sun, 11 Nov 2012 16:34:42 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> <50A016E7.2090208@isdg.net> In-Reply-To: <50A016E7.2090208@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Cc: spfbis@ietf.org, Alessandro Vesely Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 21:34:33 -0000 Hector Santos wrote: > Alessandro Vesely wrote: >> NEW: >> SPF verifiers MUST check the "MAIL FROM" identity, by applying the >> check_host() function to the "MAIL FROM" identity as the , >> except for the two cases following: >> >> o A final policy decision has already been reached by completing a >> check on the "HELO" identity. In this case, unless its result >> will be recorded (Section 7), it is useless to check the "MAIL >> FROM" identity. >> >> o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in >> [RFC5321]). In this case, SPF verifiers MUST check the "HELO" >> identity instead. According to Section 4.3, that implies >> synthesizing a mailbox composed of the local-part "postmaster" and >> the "HELO" identity. Note that such check might have been carried >> out separately before. >> > > I would add (with a text change above to indicate three cases): > > o Some other authentication/authorization check is made that does not > require SPF to be applied any longer. A good example is checking > the RCPT TO address for local user existence prior to performing > SPF checks (or any other DNS related protocol check). In practice, > this consideration can reduce DNS/SPF overhead by the same percentage > as the RCPT TO rejections detected, in some field observations as > high as 60% reduction in SPF necessity for the current session. Keep in mind this optimization suggestion is on par with RFC 2821/5321 section 3.3 regarding checking the acceptability of the reverse-path (5321.MAIL FROM). 3.3 Mail Transactions ..... Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. For example, if your SMTP site on average rejects RCPT TO 60% of the time, then delaying the SPF processing on MAIL FROM (and/or HELO) until RCPT TO is determined will reduce the SPF, thus the DNS overhead by 60% as well. These are the sort of insights accumulated from the 9+ years of experimenting that will benefit the BIS work item. -- HLS From spf2@kitterman.com Sun Nov 11 17:07:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A48521F8522 for ; Sun, 11 Nov 2012 17:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPJcJ8-Vupi6 for ; Sun, 11 Nov 2012 17:07:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 50A1221F851F for ; Sun, 11 Nov 2012 17:07:08 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 65B5520E40BB; Sun, 11 Nov 2012 20:07:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352682427; bh=fdseF5ZMT3jEEewNohEKGa2MK5tjMooPS07ntaSIFus=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cZHlYlVKuM0i1ccA05wwMAK0mK2PyLKdDnQ4/0jAxStHQWirryijLRMKBU7XNtUKA 1anZfZFeOFr8QTHX1mmL2MNufyAm0Qgo2jGQ7LMR5wZDcwSrQVcLv3Lxd0FycY4dyt 8N6xaFG2J/DRNYV2LQbs1XKJWYV+phhlcMHd7nOU= Received: from scott-latitude-e6320.localnet (unknown [50.0.192.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 188D020E40A4; Sun, 11 Nov 2012 20:07:06 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 11 Nov 2012 20:07:01 -0500 Message-ID: <1382496.9Ax2a0zViB@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-18-generic; KDE/4.9.2; i686; ; ) In-Reply-To: <50A00823.5010304@tana.it> References: <1515024.DJ7k3Z3zFX@scott-latitude-e6320> <10406074.ihGBF7TvX4@scott-latitude-e6320> <50A00823.5010304@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Rejection Based On SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 01:07:29 -0000 On Sunday, November 11, 2012 09:18:43 PM Alessandro Vesely wrote: > On Sat 10/Nov/2012 01:30:12 +0100 Scott Kitterman wrote: > > On Friday, November 09, 2012 03:48:01 PM Alessandro Vesely wrote: > >> I know no software that implements SPF publishing for such companies. > > > > There are many large organizations that have successfully > > implemented SPF, so I definitely don't understand what you're > > talking about here? > > I meant using "exists". That implies managing a DNS, or outsourcing > to someone who does. > > I have no direct experience of how large companies structure > authorizations to send out mail directly. Do they fully specify what > are the procedures for granting send-permissions? Even if ISO 9000 > compliance may require them to do so, by managing large blocks of > addresses in included records they can be more flexible, and sloppy. > > I guess inhaus delegations are not quite comparable to RIRs > management. Do they use specific software for that? My understanding is that in large organizations, the actual SPF records are typically managed by the DNS team like any other DNS record. The added complexity is that the messaging team needs to collect data on what domains are sent from what MTAs (including third parties) and coordinate with the DNS team to keep the DNS records up to date. In some cases they'll use include: to allow different segments of the the sending infrastructure to be managed independently. Scott K From spf2@kitterman.com Sun Nov 11 17:17:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D064A21F851F for ; Sun, 11 Nov 2012 17:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBvgtDaA+sVJ for ; Sun, 11 Nov 2012 17:17:49 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DC0FD21F84F3 for ; Sun, 11 Nov 2012 17:17:48 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DED520E40BB; Sun, 11 Nov 2012 20:17:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352683068; bh=CCPhyW7n/dVv+twGknq6WEW1RMXL0J1dl0mAYfFx/g8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fDS3RFJXgXbaYxw2yS0texjQG/B6eDuiZlCEH5BhGkwp229NANUW9nWtuh5Zmwogu SDN3dAFQ+EgYYKtJwVzh0TEDm87gld3vhKUVueKKi66IKknWpu49fjCmk1oqziXDx0 IFE5nq81h8PHhN6+G9XK6DlG2U52OToal8l2F1Js= Received: from scott-latitude-e6320.localnet (unknown [50.0.192.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0AF8820E40A4; Sun, 11 Nov 2012 20:17:47 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 11 Nov 2012 20:17:46 -0500 Message-ID: <7047432.kdVGSqzZE2@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-18-generic; KDE/4.9.2; i686; ; ) In-Reply-To: <50A00743.4000703@tana.it> References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 01:17:49 -0000 On Sunday, November 11, 2012 09:14:59 PM Alessandro Vesely wrote: > On Sat 10/Nov/2012 01:24:40 +0100 Scott Kitterman wrote: > > On Friday, November 09, 2012 05:29:21 PM Alessandro Vesely wrote: > >> If that were a definition, it should have been given in Section 1.3.3, > >> *Mail From Definition*. Isn't that cumbersome? Does it make any real > >> protocol difference if we simply say that when the "MAIL FROM" identity > >> is empty, verifying helo raises from SHOULD to MUST? > >> > >> Consider: > >> Received-SPF: fail (mybox.example.org: domain of > >> > >> myname@example.com does not designate > >> 192.0.2.1 as permitted sender) > >> identity=mailfrom; client-ip=192.0.2.1; > >> envelope-from="postmaster@foo.example.com"; > >> > >> Does that apply the definition correctly? > > > > Where the current text is unclear, please provide a recommended > > alternative. > Changes are as follows (see also xml patch attached). I also reword > the previous protocol change (exemption when useless) as with no > commas the "by applying" might be associated to the helo check inside > the "if". > > ORIGINAL (4408) > [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in > RFC 2821). In this case, there is no explicit sender mailbox, and > such a message can be assumed to be a notification message from the > mail system itself. When the reverse-path is null, this document > defines the "MAIL FROM" identity to be the mailbox composed of the > localpart "postmaster" and the "HELO" identity (which may or may not > have been checked separately before). > > SPF clients MUST check the "MAIL FROM" identity. SPF clients check > the "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the . > > OLD (bis-08): > SPF verifiers MUST check the ""MAIL FROM" identity if a completed > "HELO" check has not reached a definitive policy result by applying > the check_host() function to the "MAIL FROM" identity as the > . > > [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in > [RFC5321]). In this case, there is no explicit sender mailbox, and > such a message can be assumed to be a notification message from the > mail system itself. When the reverse-path is null, this document > defines the "MAIL FROM" identity to be the mailbox composed of the > local-part "postmaster" and the "HELO" identity (which might or might > not have been checked separately before). > > NEW: > SPF verifiers MUST check the "MAIL FROM" identity, by applying the > check_host() function to the "MAIL FROM" identity as the , > except for the two cases following: > > o A final policy decision has already been reached by completing a > check on the "HELO" identity. In this case, unless its result > will be recorded (Section 7), it is useless to check the "MAIL > FROM" identity. > > o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in > [RFC5321]). In this case, SPF verifiers MUST check the "HELO" > identity instead. According to Section 4.3, that implies > synthesizing a mailbox composed of the local-part "postmaster" and > the "HELO" identity. Note that such check might have been carried > out separately before. Your proposal does, in fact, change the protocol, if only slightly. A constructed "MAIL FROM" check (which is what's in RFC 4408 and the current 4408bis draft) is not, in my opinion, the same as a HELO check. How about this instead: If the is null (see Section 4.5.5 of [RFC5321]), such a message can be assumed to be a notification message from the mail system itself. The "MAIL FROM" in such cases is constructed using the local-part "postmaster" and the "HELO" name for the domain part of the "MAIL FROM". > > Changing from "Use helo to construct an artificial mail from in > > this manner" to "If mail from is empty helo checking is mandatory" > > is a protocol change. It may usually (and perhaps always) achieve > > the same result, > > An example where the achieved results differ is given above. The new > wording doesn't allow unintended interpretations, hopefully: That's > what I'm asking the list to verify. > > > but I think it's precisely the kind of change we need to be careful > > about making due to risks of inadvertent consequences. > > Agreed. On the other hand, ill-defined rules bear the risk of latent > misinterpretations, whose consequences may show up anytime. > > BTW, the "exemption when useless" isn't in RFC 4408 either. That's correct. This was discussed on the list before the change was made. Scott K From superuser@gmail.com Sun Nov 11 20:20: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 E65B221F8482 for ; Sun, 11 Nov 2012 20:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hf-EDH3+YNZE for ; Sun, 11 Nov 2012 20:19:59 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB67921F8476 for ; Sun, 11 Nov 2012 20:19:49 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1071128lbk.31 for ; Sun, 11 Nov 2012 20:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/lmK0IFLARemh4GQYua30NDF738Ryn3E2onXy1dAlZI=; b=yJU+wiqhreaql5l0VC6JnY0Eef5dTT2UGtqF/+5zysGkKIV/Q+kHPnlL3GxPxqJjBB ze72YBt80k74nO82ZQFS+fn7swiZCW2Pp60jdovnpJK6n9WmtbgTCondrvC9GBIElf6h +1lanLDqPMFWWmtL7qcev/byeCxyLBOzkM7Cyd4s/ERW/YyUxhTHPlftjNAQJkO7vkmk Q7+U3dEmUUGbA9GZ1aerzcy/xUd7Qn0fYHkWMCOEXqFvX/8XxVKgXnZExgkq0/DpqfQ3 PMMSPdD8c3QRNIMEB7CLJZZaREYIky7pIgzqf1SyAcISrt/l/cvxFWgbTTbvrFWu/BLx QbNw== MIME-Version: 1.0 Received: by 10.112.100.129 with SMTP id ey1mr7245253lbb.10.1352693988358; Sun, 11 Nov 2012 20:19:48 -0800 (PST) Received: by 10.112.83.232 with HTTP; Sun, 11 Nov 2012 20:19:48 -0800 (PST) In-Reply-To: <7047432.kdVGSqzZE2@scott-latitude-e6320> References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> <7047432.kdVGSqzZE2@scott-latitude-e6320> Date: Sun, 11 Nov 2012 20:19:48 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=14dae9d71724aa7d0e04ce449c3a Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 04:20:01 -0000 --14dae9d71724aa7d0e04ce449c3a Content-Type: text/plain; charset=ISO-8859-1 The second sentence sounds like it could be a description of something being done by the agent sending the message, rather than the module doing SPF evaluation. I suggest: If the is null (see Section 4.5.5 of [RFC5321]), such a message can be assumed to be an notification message from the mail system itself. The module doing SPF evaluation should instead act as if the "MAIL FROM" address consisted of the local-part "postmaster" and domain part set to the parameter that was passed with the "HELO" or "EHLO" command. -MSK On Sun, Nov 11, 2012 at 5:17 PM, Scott Kitterman wrote: > On Sunday, November 11, 2012 09:14:59 PM Alessandro Vesely wrote: > > On Sat 10/Nov/2012 01:24:40 +0100 Scott Kitterman wrote: > > > On Friday, November 09, 2012 05:29:21 PM Alessandro Vesely wrote: > > >> If that were a definition, it should have been given in Section 1.3.3, > > >> *Mail From Definition*. Isn't that cumbersome? Does it make any real > > >> protocol difference if we simply say that when the "MAIL FROM" > identity > > >> is empty, verifying helo raises from SHOULD to MUST? > > >> > > >> Consider: > > >> Received-SPF: fail (mybox.example.org: domain of > > >> > > >> myname@example.com does not designate > > >> 192.0.2.1 as permitted sender) > > >> identity=mailfrom; client-ip=192.0.2.1; > > >> envelope-from="postmaster@foo.example.com"; > > >> > > >> Does that apply the definition correctly? > > > > > > Where the current text is unclear, please provide a recommended > > > alternative. > > Changes are as follows (see also xml patch attached). I also reword > > the previous protocol change (exemption when useless) as with no > > commas the "by applying" might be associated to the helo check inside > > the "if". > > > > ORIGINAL (4408) > > [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in > > RFC 2821). In this case, there is no explicit sender mailbox, and > > such a message can be assumed to be a notification message from the > > mail system itself. When the reverse-path is null, this document > > defines the "MAIL FROM" identity to be the mailbox composed of the > > localpart "postmaster" and the "HELO" identity (which may or may not > > have been checked separately before). > > > > SPF clients MUST check the "MAIL FROM" identity. SPF clients check > > the "MAIL FROM" identity by applying the check_host() function to the > > "MAIL FROM" identity as the . > > > > OLD (bis-08): > > SPF verifiers MUST check the ""MAIL FROM" identity if a completed > > "HELO" check has not reached a definitive policy result by applying > > the check_host() function to the "MAIL FROM" identity as the > > . > > > > [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in > > [RFC5321]). In this case, there is no explicit sender mailbox, and > > such a message can be assumed to be a notification message from the > > mail system itself. When the reverse-path is null, this document > > defines the "MAIL FROM" identity to be the mailbox composed of the > > local-part "postmaster" and the "HELO" identity (which might or might > > not have been checked separately before). > > > > NEW: > > SPF verifiers MUST check the "MAIL FROM" identity, by applying the > > check_host() function to the "MAIL FROM" identity as the , > > except for the two cases following: > > > > o A final policy decision has already been reached by completing a > > check on the "HELO" identity. In this case, unless its result > > will be recorded (Section 7), it is useless to check the "MAIL > > FROM" identity. > > > > o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in > > [RFC5321]). In this case, SPF verifiers MUST check the "HELO" > > identity instead. According to Section 4.3, that implies > > synthesizing a mailbox composed of the local-part "postmaster" and > > the "HELO" identity. Note that such check might have been carried > > out separately before. > > Your proposal does, in fact, change the protocol, if only slightly. A > constructed "MAIL FROM" check (which is what's in RFC 4408 and the current > 4408bis draft) is not, in my opinion, the same as a HELO check. How about > this instead: > > If the is null (see Section 4.5.5 of [RFC5321]), such a > message > can be assumed to be a notification message from the mail system > itself. > The "MAIL FROM" in such cases is constructed using the local-part > "postmaster" and the "HELO" name for the domain part of the "MAIL > FROM". > > > > > Changing from "Use helo to construct an artificial mail from in > > > this manner" to "If mail from is empty helo checking is mandatory" > > > is a protocol change. It may usually (and perhaps always) achieve > > > the same result, > > > > An example where the achieved results differ is given above. The new > > wording doesn't allow unintended interpretations, hopefully: That's > > what I'm asking the list to verify. > > > > > but I think it's precisely the kind of change we need to be careful > > > about making due to risks of inadvertent consequences. > > > > Agreed. On the other hand, ill-defined rules bear the risk of latent > > misinterpretations, whose consequences may show up anytime. > > > > BTW, the "exemption when useless" isn't in RFC 4408 either. > > That's correct. This was discussed on the list before the change was made. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --14dae9d71724aa7d0e04ce449c3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The second sentence sounds like it could be a description of something bein= g done by the agent sending the message, rather than the module doing SPF e= valuation.

I suggest:

If the <sender> is null (see Sect= ion 4.5.5 of [RFC5321]), such a message can be assumed to be an notificatio= n message from the mail system itself.=A0 The module doing SPF evaluation s= hould instead act as if the "MAIL FROM" address consisted of the = local-part "postmaster" and domain part set to the parameter that= was passed with the "HELO" or "EHLO" command.

-MSK


O= n Sun, Nov 11, 2012 at 5:17 PM, Scott Kitterman <spf2@kitterman.com&g= t; wrote:
On S= unday, November 11, 2012 09:14:59 PM Alessandro Vesely wrote:
> On Sat 10/Nov/2012 01:24:40 +0100 Scott Kitterman wrote:
> > On Friday, November 09, 2012 05:29:21 PM Alessandro Vesely wrote:=
> >> If that were a definition, it should have been given in Secti= on 1.3.3,
> >> *Mail From Definition*. =A0Isn't that cumbersome? =A0Does= it make any real
> >> protocol difference if we simply say that when the "MAIL= FROM" identity
> >> is empty, verifying helo raises from SHOULD to MUST?
> >>
> >> Consider:
> >> =A0 =A0Received-SPF: fail (mybox.example.org: domain of
> >>
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0myname@example.com does not designate
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0192.0.2.1 as permi= tted sender)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0identity=3Dmailfro= m; client-ip=3D192.0.2.1;
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0envelope-from=3D&q= uot;postmaster@foo.example.co= m";
> >>
> >> Does that apply the definition correctly?
> >
> > Where the current text is unclear, please provide a recommended > > alternative.
> Changes are as follows (see also xml patch attached). =A0I also reword=
> the previous protocol change (exemption when useless) as with no
> commas the "by applying" might be associated to the helo che= ck inside
> the "if".
>
> ORIGINAL (4408)
> =A0[RFC2821] allows the reverse-path to be null (see Section 4.5.5 in<= br> > =A0RFC 2821). =A0In this case, there is no explicit sender mailbox, an= d
> =A0such a message can be assumed to be a notification message from the=
> =A0mail system itself. =A0When the reverse-path is null, this document=
> =A0defines the "MAIL FROM" identity to be the mailbox compos= ed of the
> =A0localpart "postmaster" and the "HELO" identity = (which may or may not
> =A0have been checked separately before).
>
> =A0SPF clients MUST check the "MAIL FROM" identity. =A0SPF c= lients check
> =A0the "MAIL FROM" identity by applying the check_host() fun= ction to the
> =A0"MAIL FROM" identity as the <sender>.
>
> OLD (bis-08):
> =A0SPF verifiers MUST check the ""MAIL FROM" identity i= f a completed
> =A0"HELO" check has not reached a definitive policy result b= y applying
> =A0the check_host() function to the "MAIL FROM" identity as = the
> =A0<sender>.
>
> =A0[RFC5321] allows the reverse-path to be null (see Section 4.5.5 in<= br> > =A0[RFC5321]). =A0In this case, there is no explicit sender mailbox, a= nd
> =A0such a message can be assumed to be a notification message from the=
> =A0mail system itself. =A0When the reverse-path is null, this document=
> =A0defines the "MAIL FROM" identity to be the mailbox compos= ed of the
> =A0local-part "postmaster" and the "HELO" identity= (which might or might
> =A0not have been checked separately before).
>
> NEW:
> =A0SPF verifiers MUST check the "MAIL FROM" identity, by app= lying the
> =A0check_host() function to the "MAIL FROM" identity as the = <sender>,
> =A0except for the two cases following:
>
> =A0o =A0A final policy decision has already been reached by completing= a
> =A0 =A0 check on the "HELO" identity. =A0In this case, unles= s its result
> =A0 =A0 will be recorded (Section 7), it is useless to check the "= ;MAIL
> =A0 =A0 FROM" identity.
>
> =A0o =A0SMTP allows the "MAIL FROM" identity to be null (Sec= tion 4.5.5 in
> =A0 =A0 [RFC5321]). =A0In this case, SPF verifiers MUST check the &quo= t;HELO"
> =A0 =A0 identity instead. =A0According to Section 4.3, that implies > =A0 =A0 synthesizing a mailbox composed of the local-part "postma= ster" and
> =A0 =A0 the "HELO" identity. =A0Note that such check might h= ave been carried
> =A0 =A0 out separately before.

Your proposal does, in fact, change the protocol, if only sligh= tly. =A0A
constructed "MAIL FROM" check (which is what's in RFC 4408 an= d the current
4408bis draft) is not, in my opinion, the same as a HELO check. =A0How abou= t
this instead:

=A0 =A0 If the <sender> is null (see Section 4.5.5 of [RFC5321]), =A0= such a message
=A0 =A0 can be assumed to be a notification message from = the mail system itself.
=A0 =A0 The "MAIL FROM" in such cases is constructed using = the local-part
=A0 =A0 "postmaster" and the "HELO" name for the domain= part of the "MAIL FROM".


> > Changing from "Use helo to construct an artificial mail from= in
> > this manner" to "If mail from is empty helo checking is= mandatory"
> > is a protocol change. =A0It may usually (and perhaps always) achi= eve
> > the same result,
>
> An example where the achieved results differ is given above. =A0The ne= w
> wording doesn't allow unintended interpretations, hopefully: =A0Th= at's
> what I'm asking the list to verify.
>
> > but I think it's precisely the kind of change we need to be c= areful
> > about making due to risks of inadvertent consequences.
>
> Agreed. =A0On the other hand, ill-defined rules bear the risk of laten= t
> misinterpretations, whose consequences may show up anytime.
>
> BTW, the "exemption when useless" isn't in RFC 4408 eith= er.

That's correct. =A0This was discussed on the list before the chan= ge was made.

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

--14dae9d71724aa7d0e04ce449c3a-- From superuser@gmail.com Sun Nov 11 20: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 3670721F8476 for ; Sun, 11 Nov 2012 20:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-epaSHX-wKz for ; Sun, 11 Nov 2012 20:25:47 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED25B21F8462 for ; Sun, 11 Nov 2012 20:25:46 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so632562lah.31 for ; Sun, 11 Nov 2012 20:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DryrJ8KJvJJLyOLJzlcYzmNcKPNQjpqrYSJNbNhG0fA=; b=Adk6kdN0FFtPeP6rCO5xGjs5B3S2Ob+IMPSob9Nh5KJBH8xDN9mzvt1FucKzvWR3xM ObxiG01hZ8x121YSkm7RyLowgBf2DbFH3k+ZERANT7veYcN++woptExMFFB5qLVyd+Gx TqFOPqMcVybvFr5W4ilz0e7NPbyHRCNWUriujTB4f2mzUigjXSV0wmVkRctyPsbesICN EffKWnX5T+shPJ8c3D1J83ITv8PTtQtbq94Z3AekaQkTkhtcFjhpIAlo8zt+E1jemzkx zZedMjeXNxCuWhQKzPNJ4NJBIxoG3IHwibN5gVxb2N9jOmgH//LpqV7Z168JGRNq1/Kl ZLnA== MIME-Version: 1.0 Received: by 10.152.47.97 with SMTP id c1mr16751527lan.37.1352694345705; Sun, 11 Nov 2012 20:25:45 -0800 (PST) Received: by 10.112.83.232 with HTTP; Sun, 11 Nov 2012 20:25:45 -0800 (PST) In-Reply-To: <50A00743.4000703@tana.it> References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> Date: Sun, 11 Nov 2012 20:25:45 -0800 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=bcaec554025af72a4a04ce44b175 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 04:25:48 -0000 --bcaec554025af72a4a04ce44b175 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 11, 2012 at 12:14 PM, Alessandro Vesely wrote: > ORIGINAL (4408) > [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in > RFC 2821). In this case, there is no explicit sender mailbox, and > such a message can be assumed to be a notification message from the > mail system itself. When the reverse-path is null, this document > defines the "MAIL FROM" identity to be the mailbox composed of the > localpart "postmaster" and the "HELO" identity (which may or may not > have been checked separately before). > > SPF clients MUST check the "MAIL FROM" identity. SPF clients check > the "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the . > > OLD (bis-08): > SPF verifiers MUST check the ""MAIL FROM" identity if a completed > "HELO" check has not reached a definitive policy result by applying > the check_host() function to the "MAIL FROM" identity as the > . > This could probably be fixed just by sticking commas after "identity" and "result". > > [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in > [RFC5321]). In this case, there is no explicit sender mailbox, and > such a message can be assumed to be a notification message from the > mail system itself. When the reverse-path is null, this document > defines the "MAIL FROM" identity to be the mailbox composed of the > local-part "postmaster" and the "HELO" identity (which might or might > not have been checked separately before). > > NEW: > SPF verifiers MUST check the "MAIL FROM" identity, by applying the > check_host() function to the "MAIL FROM" identity as the , > except for the two cases following: > > o A final policy decision has already been reached by completing a > check on the "HELO" identity. In this case, unless its result > will be recorded (Section 7), it is useless to check the "MAIL > FROM" identity. > I would strike the last sentence: "A final policy decision has already been reached by completing a check on the "HELO" identity, unless the result of this check is to be recorded (see Section 7)." It's not necessary to make the "useless" point. > > o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in > [RFC5321]). In this case, SPF verifiers MUST check the "HELO" > identity instead. According to Section 4.3, that implies > synthesizing a mailbox composed of the local-part "postmaster" and > the "HELO" identity. Note that such check might have been carried > Can you give an example of a possible interpretation of the OLD text that is not possible with the NEW text? I'm still having trouble seeing the problem we're trying to fix here. In particular, this bullet point does not describe a case in which the MAIL FROM check would be skipped; rather it describes how to go about doing it for the "null" case, which doesn't flow from the proposed earlier paragraph. -MSK --bcaec554025af72a4a04ce44b175 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Nov 11, 2012 at 12:14 PM, Alessandro Vesely <<= a href=3D"mailto:vesely@tana.it" target=3D"_blank">vesely@tana.it> wrote:
ORIGINAL (4408)
=A0[RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
=A0RFC 2821). =A0In this case, there is no explicit sender mailbox, and
=A0such a message can be assumed to be a notification mes= sage from the
=A0mail system itself. =A0When the reverse-path is null, this documen= t
=A0defines the "MAIL FROM" identity to be the m= ailbox composed of the
=A0localpart "postmaster" and the "HELO" identity= (which may or may not
=A0have been checked separately before).

=A0SPF clients MUST check the "MAIL FROM" identity. =A0SPF = clients check
=A0the "MAIL FROM" identity by applying the check_host() function= to the
=A0"MAIL FROM" identity as the <sender>.

OLD (bis-08):
=A0SPF verifiers MUST check the ""MAIL FROM" identity if a c= ompleted
=A0"HELO" check has not reached a definitive policy result by app= lying
=A0the check_host() function to the "MAIL FROM" identity as the =A0<sender>.

This could probably be fixed ju= st by sticking commas after "identity" and "result".=A0

=A0[RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
=A0[RFC5321]). =A0In this case, there is no explicit sender mailbox, and
=A0such a message can be assumed to be a notification mes= sage from the
=A0mail system itself. =A0When the reverse-path is null, this documen= t
=A0defines the "MAIL FROM" identity to be the m= ailbox composed of the
=A0local-part "postmaster" and the "HELO" identity (whi= ch might or might
=A0not have been checked separately before).

NEW:
=A0SPF verifiers MUST check the "MAIL FROM" identity, by applying= the
=A0check_host() function to the "MAIL FROM" identity as the <s= ender>,
=A0except for the two cases following:

=A0o =A0A final policy decision has already been reached by completing a =A0 =A0 check on the "HELO" identity. =A0In this case, unless its= result
=A0 =A0 will be recorded (Section 7), it is useless to check the "MAIL=
=A0 =A0 FROM" identity.

I would strike the la= st sentence:

"A final policy decision has already been reached = by completing a check on the "HELO" identity, unless the result o= f this check is to be recorded (see Section 7)."

It's not necessary to make the "useless" point.
=A0

=A0o =A0SMTP allows the "MAIL FROM" identity to be null (Section = 4.5.5 in
=A0 =A0 [RFC5321]). =A0In this case, SPF verifiers MUST check the "HEL= O"
=A0 =A0 identity instead. =A0According to Section 4.3, that implies
=A0 =A0 synthesizing a mailbox composed of the local-part "postmaster&= quot; and
=A0 =A0 the "HELO" identity. =A0Note that such check might have b= een carried

Can you give an example of a possible = interpretation of the OLD text that is not possible with the NEW text?=A0 I= 'm still having trouble seeing the problem we're trying to fix here= .

In particular, this bullet point does not describe a case in which the = MAIL FROM check would be skipped; rather it describes how to go about doing= it for the "null" case, which doesn't flow from the proposed= earlier paragraph.

-MSK

--bcaec554025af72a4a04ce44b175-- From superuser@gmail.com Sun Nov 11 21:57: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 CB9EC21F851B for ; Sun, 11 Nov 2012 21:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQXLOsW7jgyw for ; Sun, 11 Nov 2012 21:57:51 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 888B221F850C for ; Sun, 11 Nov 2012 21:57:47 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so673008lah.31 for ; Sun, 11 Nov 2012 21:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BhmWVWr35iuASF66RVcZICoy+IkbPmboVLW9hUEtDgs=; b=GkDdKkEGxMVmDLW07ndQIYFIkkJ5xqTekutahB+2ArY3JltaAYqAtTfGVdMQrrnr48 sToYh+Kr4VCrS0IGZz34nXy1T/xM64KP4HGwK/2veAFt9xktZyBpxYP2gTFUtpAP3Z7U x+fD+HDmdRlARdAtstrMhtiT9XGVm8SuSdp1xHRNfzPxs5rMR4MEf1cQZGtWbD/GpoYD W6ahHz3DDilJMLOZpvhOneanYnJI+PF/aX7Fs/v/t6MI9UAko67dRc2ILiGJBOPUQz/0 iURnXbPrxKtovClEJXjh+A0xpMi9JcdmgqymL+RnGvHiBYzdf2Bmn60ayGBMSeeQS6ni 6XPw== MIME-Version: 1.0 Received: by 10.112.100.129 with SMTP id ey1mr7316937lbb.10.1352699866178; Sun, 11 Nov 2012 21:57:46 -0800 (PST) Received: by 10.112.83.232 with HTTP; Sun, 11 Nov 2012 21:57:46 -0800 (PST) In-Reply-To: <50A016E7.2090208@isdg.net> References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> <50A016E7.2090208@isdg.net> Date: Sun, 11 Nov 2012 21:57:46 -0800 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=14dae9d7172402e4e404ce45fb3d Cc: "spfbis@ietf.org" , Alessandro Vesely Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 05:57:51 -0000 --14dae9d7172402e4e404ce45fb3d Content-Type: text/plain; charset=ISO-8859-1 This suggestion made me go back and do some reading. Others should pipe up if I'm wrong, but it seems to me that although RFC4408 and the current bis document probably imply that rejection is meant to be done inline with the HELO or MAIL FROM command, it doesn't actually say that anywhere. For all we know, the proposed rejection replies come in response to any of HELO, MAIL FROM, one or more of the RCPT TOs, or even DATA, and still meets the spec(s). Should we say explicitly that although inline rejection is common, the rejection can be done anywhere in the sequence based on local policy requirements (i.e., other checks)? Or is being ambiguous actually appropriate here? I'm not certain this is the right place to put this paragraph or one like it, but it does seem to be a reasonable suggestion, especially if other operators on this list have similar practices and data to share. -MSK On Sun, Nov 11, 2012 at 1:21 PM, Hector Santos wrote: > Alessandro Vesely wrote: > >> NEW: >> SPF verifiers MUST check the "MAIL FROM" identity, by applying the >> check_host() function to the "MAIL FROM" identity as the , >> except for the two cases following: >> >> o A final policy decision has already been reached by completing a >> check on the "HELO" identity. In this case, unless its result >> will be recorded (Section 7), it is useless to check the "MAIL >> FROM" identity. >> >> o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in >> [RFC5321]). In this case, SPF verifiers MUST check the "HELO" >> identity instead. According to Section 4.3, that implies >> synthesizing a mailbox composed of the local-part "postmaster" and >> the "HELO" identity. Note that such check might have been carried >> out separately before. >> >> > I would add (with a text change above to indicate three cases): > > o Some other authentication/authorization check is made that does not > require SPF to be applied any longer. A good example is checking > the RCPT TO address for local user existence prior to performing > SPF checks (or any other DNS related protocol check). In practice, > this > consideration can reduce DNS/SPF overhead by the same percentage as > the RCPT TO rejections detected, in some field observations as high > as 60% reduction in SPF necessity for the current session. > > -- > HLS > > > > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --14dae9d7172402e4e404ce45fb3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This suggestion made me go back and do some reading.=A0 Others should pipe = up if I'm wrong, but it seems to me that although RFC4408 and the curre= nt bis document probably imply that rejection is meant to be done inline wi= th the HELO or MAIL FROM command, it doesn't actually say that anywhere= .=A0 For all we know, the proposed rejection replies come in response to an= y of HELO, MAIL FROM, one or more of the RCPT TOs, or even DATA, and still = meets the spec(s).

Should we say explicitly that although inline rejection is common, the = rejection can be done anywhere in the sequence based on local policy requir= ements (i.e., other checks)?=A0 Or is being ambiguous actually appropriate = here?

I'm not certain this is the right place to put this paragraph or on= e like it, but it does seem to be a reasonable suggestion, especially if ot= her operators on this list have similar practices and data to share.

-MSK


O= n Sun, Nov 11, 2012 at 1:21 PM, Hector Santos <hsantos@isdg.net> wrote:
Alessandro Vesely wrote:
NEW:
=A0SPF verifiers MUST check the "MAIL FROM" identity, by applying= the
=A0check_host() function to the "MAIL FROM" identity as the <s= ender>,
=A0except for the two cases following:

=A0o =A0A final policy decision has already been reached by completing a =A0 =A0 check on the "HELO" identity. =A0In this case, unless its= result
=A0 =A0 will be recorded (Section 7), it is useless to check the "MAIL=
=A0 =A0 FROM" identity.

=A0o =A0SMTP allows the "MAIL FROM" identity to be null (Section = 4.5.5 in
=A0 =A0 [RFC5321]). =A0In this case, SPF verifiers MUST check the "HEL= O"
=A0 =A0 identity instead. =A0According to Section 4.3, that implies
=A0 =A0 synthesizing a mailbox composed of the local-part "postmaster&= quot; and
=A0 =A0 the "HELO" identity. =A0Note that such check might have b= een carried
=A0 =A0 out separately before.


I would add (with a text change above to indicate three cases):

=A0 =A0o =A0Some other authentication/authorization check is made that does= not
=A0 =A0 =A0 require SPF to be applied any longer. =A0A good example is chec= king
=A0 =A0 =A0 the RCPT TO address for local user existence prior to performin= g
=A0 =A0 =A0 SPF checks (or any other DNS related protocol check). In practi= ce, this
=A0 =A0 =A0 consideration can reduce DNS/SPF overhead by the same percentag= e as
=A0 =A0 =A0 the RCPT TO rejections detected, in some field observations as = high
=A0 =A0 =A0 as 60% reduction in SPF necessity for the current session.

--
HLS



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

--14dae9d7172402e4e404ce45fb3d-- From vesely@tana.it Mon Nov 12 02:12:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA51021F846D for ; Mon, 12 Nov 2012 02:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrCW-vwlxDa1 for ; Mon, 12 Nov 2012 02:12:18 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2D921F846A for ; Mon, 12 Nov 2012 02:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352715136; bh=jtqO42VQEAZH7lO7OdCXMPY29iNWsBX8/OzOy3/w7KM=; l=2511; h=Date:From:To:References:In-Reply-To; b=Huxkb09vt6SRTTtIghQoGodxlSKhXb9hDf7r5CalVllSKe5nuU17BGeVWZNl0eSiS 7Ic8P7rPbWuzA7xKWkxDXd76TZIXpNb6TtByoYizM89itaWQ7v4Gs1uTzuu42lmPZf BfyPsKpV1Dc7el9y/j22zuqUSkOAtwKzxp50r3mA= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 12 Nov 2012 11:12:16 +0100 id 00000000005DC033.0000000050A0CB80.00007377 Message-ID: <50A0CB7F.2010907@tana.it> Date: Mon, 12 Nov 2012 11:12:15 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> <7047432.kdVGSqzZE2@scott-latitude-e6320> In-Reply-To: <7047432.kdVGSqzZE2@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 10:12:20 -0000 On Mon 12/Nov/2012 02:17:46 +0100 Scott Kitterman wrote: > On Sunday, November 11, 2012 09:14:59 PM Alessandro Vesely wrote: >> >> o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in >> [RFC5321]). In this case, SPF verifiers MUST check the "HELO" >> identity instead. According to Section 4.3, that implies >> synthesizing a mailbox composed of the local-part "postmaster" and >> the "HELO" identity. Note that such check might have been carried >> out separately before. > > Your proposal does, in fact, change the protocol, if only slightly. A > constructed "MAIL FROM" check (which is what's in RFC 4408 and the current > 4408bis draft) is not, in my opinion, the same as a HELO check. How about > this instead: > > If the is null (see Section 4.5.5 of [RFC5321]), such a message > can be assumed to be a notification message from the mail system itself. > The "MAIL FROM" in such cases is constructed using the local-part > "postmaster" and the "HELO" name for the domain part of the "MAIL FROM". MAIL FROM and should be swapped, in that text. is the argument of check_host(), and can never be null. MAIL FROM can be null, or can be constructed otherwise by the SMTP client. BTW, rather than repeating the following for each identity, we should state once, in Section 2.0, that: Checking the "X" identity means applying the check_host() function to the "X" identity as the , for "X" = "MAIL FROM", "HELO". Now for that spurious definition. Since we apply a function, its parameter is a dummy variable. Thus, to say define MAIL FROM := HELO; MF-result = check_host(MAIL FROM); is the same as saying MF-result = check_host(HELO); except for the silent dropping of the spurious definition before reporting the SPF result --which is what I'm trying to correct. Thus, what remains is to say that that result is what should be used to make policy decisions. We /have/ to be ambiguous here, because we don't specify that part. In no case we could prevent a receiver from behaving specially when MAIL FROM is null. So what we really would have said is that for simplistic policies that just consider a single SPF result, such result, which is normally check_host(MAIL FROM), is check_host(HELO) when MAIL FROM is null. Correct? How about: If the "MAIL FROM" identity is null (see Section 4.5.5 of [RFC5321]) the principal SPF result is obtained by checking the "HELO" identity instead. From vesely@tana.it Mon Nov 12 02:58:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758C221F8557 for ; Mon, 12 Nov 2012 02:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.718 X-Spam-Level: X-Spam-Status: No, score=-4.718 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mY7cT4p+Vtc for ; Mon, 12 Nov 2012 02:58:45 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 409BC21F8539 for ; Mon, 12 Nov 2012 02:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352717924; bh=Dp4mUfIocDaC/E8sCDt+wURxLJHH5zzaLlY5zQDOR3c=; l=5032; h=Date:From:To:References:In-Reply-To; b=IhCD/31cLQRvLMWtvSB73HD6qx0vjEZruFrbJsxCl7v7jNML9kA2OaQpa6bfnDd9O OV88qlad5B5QdaKlTP2mL81l8hl8NhdLoOUikx3/2neQ8oc1IgNiA9v88/msCL0nlK /bdnfO8npV5cMlxXPv0P3roZdJbG1ntT2BV1wRJ8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 12 Nov 2012 11:58:44 +0100 id 00000000005DC033.0000000050A0D664.00004ABF Message-ID: <50A0D663.1090208@tana.it> Date: Mon, 12 Nov 2012 11:58:43 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000900080105060701060902" Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 10:58:46 -0000 This is a multi-part message in MIME format. --------------000900080105060701060902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Mon 12/Nov/2012 05:25:45 +0100 Murray S. Kucherawy wrote: > On Sun, Nov 11, 2012 at 12:14 PM, Alessandro Vesely > wrote: > > o A final policy decision has already been reached by > completing a > check on the "HELO" identity. In this case, unless its result > will be recorded (Section 7), it is useless to check the "MAIL > FROM" identity. > > > I would strike the last sentence: > > "A final policy decision has already been reached by completing a > check on the "HELO" identity, unless the result of this check is to > be recorded (see Section 7)." > > It's not necessary to make the "useless" point. Agreed, we could put such kind of explanations to the /changes/ appendix, whenever we write it. > o SMTP allows the "MAIL FROM" identity to be null (Section > 4.5.5 in > [RFC5321]). In this case, SPF verifiers MUST check the "HELO" > identity instead. According to Section 4.3, that implies > synthesizing a mailbox composed of the local-part > "postmaster" and > the "HELO" identity. Note that such check might have been > carried > > > Can you give an example of a possible interpretation of the OLD text > that is not possible with the NEW text? I'm still having trouble > seeing the problem we're trying to fix here. On reporting the result, according to the existing definition, the verifier shall tag it as the result of checking the "MAIL FROM" identity. > In particular, this bullet point does not describe a case in which > the MAIL FROM check would be skipped; rather it describes how to go > about doing it for the "null" case, which doesn't flow from the > proposed earlier paragraph. Correct. --------------000900080105060701060902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On Mon 12/Nov/2012 05:25:45 +0100 Murray S. Kucherawy wrote:
On Sun, Nov 11, 2012 at 12:14 PM, Alessandro Vesely <vesely@tana.it> wrote:

  o  A final policy decision has already been reached by completing a
    check on the "HELO" identity.  In this case, unless its result
    will be recorded (Section 7), it is useless to check the "MAIL
    FROM" identity.

I would strike the last sentence:

"A final policy decision has already been reached by completing a check on the "HELO" identity, unless the result of this check is to be recorded (see Section 7)."

It's not necessary to make the "useless" point.

Agreed, we could put such kind of explanations to the changes appendix, whenever we write it.

  o  SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in
    [RFC5321]).  In this case, SPF verifiers MUST check the "HELO"
    identity instead.  According to Section 4.3, that implies
    synthesizing a mailbox composed of the local-part "postmaster" and
    the "HELO" identity.  Note that such check might have been carried

Can you give an example of a possible interpretation of the OLD text that is not possible with the NEW text?  I'm still having trouble seeing the problem we're trying to fix here.

On reporting the result, according to the existing definition, the verifier shall tag it as the result of checking the "MAIL FROM" identity.

In particular, this bullet point does not describe a case in which the MAIL FROM check would be skipped; rather it describes how to go about doing it for the "null" case, which doesn't flow from the proposed earlier paragraph.

Correct.

--------------000900080105060701060902-- From vesely@tana.it Mon Nov 12 03:24:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6240E21F84DD for ; Mon, 12 Nov 2012 03:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOHLtB0SMWP5 for ; Mon, 12 Nov 2012 03:24:48 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8473E21F84CD for ; Mon, 12 Nov 2012 03:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352719487; bh=jz7bjmeZX3VBOxol7hrqTuukeqn5fjXCTFZAYsSgNFE=; l=1181; h=Date:From:To:References:In-Reply-To; b=fis2+1ePOAyzzM4dGPkPVoeVkx9CepnPUlgfoJrr0oBOhlFreUOLoiPTd0FxJSZ9o uwkObr3CRTrAoyTQ1LFnsYX17/47czgo5qc788fnDnDC8DjculLxS2lFtlaTfmh8Oj /1HvTAB4vsBLwMtPrtH0vByCdHDOvH1IVQMRBwNc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 12 Nov 2012 12:24:47 +0100 id 00000000005DC03F.0000000050A0DC7F.0000437D Message-ID: <50A0DC7E.70906@tana.it> Date: Mon, 12 Nov 2012 12:24:46 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> <50A016E7.2090208@isdg.net> In-Reply-To: <50A016E7.2090208@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 11:24:49 -0000 On Sun 11/Nov/2012 22:21:43 +0100 Hector Santos wrote: > Alessandro Vesely wrote: >> NEW: >> SPF verifiers MUST check the "MAIL FROM" identity, by applying the >> check_host() function to the "MAIL FROM" identity as the , >> except for the two cases following: >> >> [...] >> > > I would add (with a text change above to indicate three cases): > > o Some other authentication/authorization check is made that does not > require SPF to be applied any longer. A good example is checking > the RCPT TO address for local user existence prior to performing > SPF checks (or any other DNS related protocol check). In practice, this > consideration can reduce DNS/SPF overhead by the same percentage as > the RCPT TO rejections detected, in some field observations as high > as 60% reduction in SPF necessity for the current session. Albeit correct, that is outside SPF. We could as well say that SPF can be checked after DNSBLs. It sounds like uselessly complicating the subject, since we don't actually specify receiver policy. Recall http://www.ietf.org/mail-archive/web/spfbis/current/msg00494.html (part of the "exemption when useless" discussion). From hsantos@isdg.net Mon Nov 12 07:56:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC8F21F8625 for ; Mon, 12 Nov 2012 07:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.306 X-Spam-Level: X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciTn0ubFCY+O for ; Mon, 12 Nov 2012 07:56:13 -0800 (PST) Received: from news.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6B421F8612 for ; Mon, 12 Nov 2012 07:56:11 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1957; t=1352735767; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=0D/2asTYFAEKl07Az2M+MOG/v8E=; b=pmP8b3SGfGIsnxFx7US/ W+C07M94bv3VkoObWh7jS/mvA3GwLwEjL1tHmeZGQjSEBkFnCNSHOuDJH51ERoxf w+p+Wuw3zxhzCt6u1zL9YbvEmYsgYWV069klrXYa+5Mw+knUTfcgKStmQn3z0CLf ywc+D1nC9HswPN+MTr7A1o0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 12 Nov 2012 10:56:07 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 167550515.6164.4900; Mon, 12 Nov 2012 10:56:07 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1957; t=1352735435; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bZwxucD fZiQ8f6EP69qYTKk46Yv8etCxgig1FJPHBuA=; b=YatUoOOHprxJqpUQR5/j23g gYVaFzWJcvS3DxaYTwS+of+J5eSuKl7PkW5TJnrHhMYej/8wga64avzIzcKiRLB8 m0fLaxzu4pWqyjRYZt9HGfK5B4gGMqiyTnFqd/p5qKAVSggZym5ovfLlGXXnjkBZ 0qFx/J3qw6ZfHUUU9Hm4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 12 Nov 2012 10:50:35 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 766298647.9.4120; Mon, 12 Nov 2012 10:50:34 -0500 Message-ID: <50A11C3E.4090804@isdg.net> Date: Mon, 12 Nov 2012 10:56:46 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <509D83C1.301@tana.it> <3027913.dGi6CsUAo1@scott-latitude-e6320> <50A00743.4000703@tana.it> <50A016E7.2090208@isdg.net> <50A0DC7E.70906@tana.it> In-Reply-To: <50A0DC7E.70906@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:56:14 -0000 I never did agree or buy into the lack of a receiver policy argument. This is a protocol. You can do a State Machine flow chart! There are boundary conditions and limits and very little options at each state that one can do. You can literally write down a SPF process model with its input arguments and expected outputs - plug and play black box function generator! Reminder, SPF is a significant DNS overhead protocol with continued unknown query waste of domains. If SPF implementations can reduce the need to query DNS by 60% (each site will vary), then it would be prudent to leverage this potential reduction in overhead and SPF waste. This benefits the SPF network as a whole. -- HLS Alessandro Vesely wrote: > On Sun 11/Nov/2012 22:21:43 +0100 Hector Santos wrote: >> Alessandro Vesely wrote: >>> NEW: >>> SPF verifiers MUST check the "MAIL FROM" identity, by applying the >>> check_host() function to the "MAIL FROM" identity as the , >>> except for the two cases following: >>> >>> [...] >>> >> I would add (with a text change above to indicate three cases): >> >> o Some other authentication/authorization check is made that does not >> require SPF to be applied any longer. A good example is checking >> the RCPT TO address for local user existence prior to performing >> SPF checks (or any other DNS related protocol check). In practice, this >> consideration can reduce DNS/SPF overhead by the same percentage as >> the RCPT TO rejections detected, in some field observations as high >> as 60% reduction in SPF necessity for the current session. > > Albeit correct, that is outside SPF. We could as well say that SPF > can be checked after DNSBLs. It sounds like uselessly complicating > the subject, since we don't actually specify receiver policy. Recall > http://www.ietf.org/mail-archive/web/spfbis/current/msg00494.html > (part of the "exemption when useless" discussion). -- HLS From prvs=656c14667=fmartin@linkedin.com Mon Nov 12 10:40:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BD621F857C for ; Mon, 12 Nov 2012 10:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueKKVRpgQ4V9 for ; Mon, 12 Nov 2012 10:40:20 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id CD82221F8536 for ; Mon, 12 Nov 2012 10:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1352745620; x=1384281620; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=dE5vHoLnLVXuG0W8TFvHHS1jegeCzY7YdOoFAMcPP3E=; b=Hwcpf6q6L/ZDlmRa3BQscZ9x8vgRK9Dc8i7BIkNEW2ulSdX+dxx4J8IA WSDmOeqwT1YDYQenp7Y9PeHEBzQ7e2GJM1hPc1L63+z4pm0M0hgmp0Syt firglQqbLp/TAK9P1YASmefMsQeI968MZiNKzZNddGyjo6ADX8FwmYdKx s=; X-IronPort-AV: E=Sophos;i="4.80,764,1344236400"; d="scan'208,217";a="30486457" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Mon, 12 Nov 2012 10:40:04 -0800 From: Franck Martin To: "Murray S. Kucherawy" , Hector Santos Thread-Topic: [spfbis] New issue? What identity is being reported/checked? Thread-Index: AQHNwJquLghpvI80MU+VPjsH+8J18JfmiRkA Date: Mon, 12 Nov 2012 18:40:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/alternative; boundary="_000_CCC681BC8DB5Afmartinlinkedincom_" MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Alessandro Vesely Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:40:21 -0000 --_000_CCC681BC8DB5Afmartinlinkedincom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The document would gain clarity if the MAIL FROM was called something else.= It entertains confusion with the mail from aka RFC5321from. Can't we call it something like the spf identity and defines what it is: rf= c5321from if present otherwise postmaster@ ? From: "Murray S. Kucherawy" > Date: Sunday, November 11, 2012 9:57 PM To: Hector Santos > Cc: "spfbis@ietf.org" >, Alessandro Vesely > Subject: Re: [spfbis] New issue? What identity is being reported/checked? This suggestion made me go back and do some reading. Others should pipe up= if I'm wrong, but it seems to me that although RFC4408 and the current bis= document probably imply that rejection is meant to be done inline with the= HELO or MAIL FROM command, it doesn't actually say that anywhere. For all= we know, the proposed rejection replies come in response to any of HELO, M= AIL FROM, one or more of the RCPT TOs, or even DATA, and still meets the sp= ec(s). Should we say explicitly that although inline rejection is common, the reje= ction can be done anywhere in the sequence based on local policy requiremen= ts (i.e., other checks)? Or is being ambiguous actually appropriate here? I'm not certain this is the right place to put this paragraph or one like i= t, but it does seem to be a reasonable suggestion, especially if other oper= ators on this list have similar practices and data to share. -MSK On Sun, Nov 11, 2012 at 1:21 PM, Hector Santos > wrote: Alessandro Vesely wrote: NEW: SPF verifiers MUST check the "MAIL FROM" identity, by applying the check_host() function to the "MAIL FROM" identity as the , except for the two cases following: o A final policy decision has already been reached by completing a check on the "HELO" identity. In this case, unless its result will be recorded (Section 7), it is useless to check the "MAIL FROM" identity. o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in [RFC5321]). In this case, SPF verifiers MUST check the "HELO" identity instead. According to Section 4.3, that implies synthesizing a mailbox composed of the local-part "postmaster" and the "HELO" identity. Note that such check might have been carried out separately before. I would add (with a text change above to indicate three cases): o Some other authentication/authorization check is made that does not require SPF to be applied any longer. A good example is checking the RCPT TO address for local user existence prior to performing SPF checks (or any other DNS related protocol check). In practice, th= is consideration can reduce DNS/SPF overhead by the same percentage as the RCPT TO rejections detected, in some field observations as high as 60% reduction in SPF necessity for the current session. -- HLS _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis --_000_CCC681BC8DB5Afmartinlinkedincom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1855655489278A43BFA42915BC4B0B5A@linkedin.com> Content-Transfer-Encoding: quoted-printable
The document would gain clarity if the MAIL FROM was called something = else. It entertains confusion with the mail from aka RFC5321from. 

Can't we call it something like the spf identity and defines what it i= s: rfc5321from if present otherwise postmaster@<helo string> ?

From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Sunday, November 11, 2012 9:5= 7 PM
To: Hector Santos <hsantos@isdg.net>
Cc: "spfbis@ietf.org" <= spfbis@ietf.org>, Alessandro Vesely <vesely@tana.it>
Subject: Re: [spfbis] New issue? Wh= at identity is being reported/checked?

This suggestion made me go back and do some reading.  Others shou= ld pipe up if I'm wrong, but it seems to me that although RFC4408 and the c= urrent bis document probably imply that rejection is meant to be done inlin= e with the HELO or MAIL FROM command, it doesn't actually say that anywhere.  For all we know, the proposed= rejection replies come in response to any of HELO, MAIL FROM, one or more = of the RCPT TOs, or even DATA, and still meets the spec(s).

Should we say explicitly that although inline rejection is common, the reje= ction can be done anywhere in the sequence based on local policy requiremen= ts (i.e., other checks)?  Or is being ambiguous actually appropriate h= ere?

I'm not certain this is the right place to put this paragraph or one like i= t, but it does seem to be a reasonable suggestion, especially if other oper= ators on this list have similar practices and data to share.

-MSK


On Sun, Nov 11, 2012 at 1:21 PM, Hector Santos <= span dir=3D"ltr"> <hsantos@isdg.net<= /a>> wrote:
Alessandro Vesely wrote:
NEW:
 SPF verifiers MUST check the "MAIL FROM" identity, by apply= ing the
 check_host() function to the "MAIL FROM" identity as the &l= t;sender>,
 except for the two cases following:

 o  A final policy decision has already been reached by completin= g a
    check on the "HELO" identity.  In this case, u= nless its result
    will be recorded (Section 7), it is useless to check the &quo= t;MAIL
    FROM" identity.

 o  SMTP allows the "MAIL FROM" identity to be null (Se= ction 4.5.5 in
    [RFC5321]).  In this case, SPF verifiers MUST check the = "HELO"
    identity instead.  According to Section 4.3, that implie= s
    synthesizing a mailbox composed of the local-part "postm= aster" and
    the "HELO" identity.  Note that such check mig= ht have been carried
    out separately before.


I would add (with a text change above to indicate three cases):

   o  Some other authentication/authorization check is made = that does not
      require SPF to be applied any longer.  A good exa= mple is checking
      the RCPT TO address for local user existence prior to = performing
      SPF checks (or any other DNS related protocol check). = In practice, this
      consideration can reduce DNS/SPF overhead by the same = percentage as
      the RCPT TO rejections detected, in some field observa= tions as high
      as 60% reduction in SPF necessity for the current sess= ion.

--
HLS



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

 --_000_CCC681BC8DB5Afmartinlinkedincom_-- From hsantos@isdg.net Mon Nov 12 11:05: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 E423621F8587 for ; Mon, 12 Nov 2012 11:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buKurFGk6rUp for ; Mon, 12 Nov 2012 11:05:20 -0800 (PST) Received: from groups.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BC13821F854C for ; Mon, 12 Nov 2012 11:05:19 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3621; t=1352747110; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=DOcOyTpx1cnK755JxmbYO81vHEk=; b=LPcLmczqOIxWVRVWhoNc w72CKPvKIeqfv0tyxXNB50jeJHa3f8R084x5h35sRDIWzlhgUMlWDNPNPiqQM54a BKpAJ5Qp3Am8gZ2J/GW/S4y+jovk7oA6qbazkYmrI5a88vBEIdSw/QmP9W6z1B40 br2AnDZ2hVFwpz4kbuU2Qk8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 12 Nov 2012 14:05:10 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 178891881.6164.4548; Mon, 12 Nov 2012 14:05:08 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3621; t=1352746776; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=I5fMHfT Gg2fCU4qU8BhPjxXU3e+AiDdntJceDMeojuE=; b=WMuOva9W111xZE3iyD9ybv4 aALzjCD9Hrm6wPC1y5i+9iY/r5R5Mjwyz+02Ymg0HFsvZhNBp13M4mHtyMsNAe3s vJXnD9SrIgTPwH2VHXemqUaHGD4IPj0B50f6jJ1OlaYYTPRBmo2bQ06YMl4VfxK0 R6kH5P4ojawMs7l0FRkI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 12 Nov 2012 13:59:36 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 777638975.9.4508; Mon, 12 Nov 2012 13:59:34 -0500 Message-ID: <50A14892.1030305@isdg.net> Date: Mon, 12 Nov 2012 14:05:54 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Franck Martin References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" , Alessandro Vesely Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:05:21 -0000 reverse-path/address, return-path/address are well understood SMTP terms. Franck Martin wrote: > The document would gain clarity if the MAIL FROM was called something else. It entertains confusion with the mail from aka RFC5321from. > > Can't we call it something like the spf identity and defines what it is: rfc5321from if present otherwise postmaster@ ? > > From: "Murray S. Kucherawy" > > Date: Sunday, November 11, 2012 9:57 PM > To: Hector Santos > > Cc: "spfbis@ietf.org" >, Alessandro Vesely > > Subject: Re: [spfbis] New issue? What identity is being reported/checked? > > This suggestion made me go back and do some reading. Others should pipe up if I'm wrong, but it seems to me that although RFC4408 and the current bis document probably imply that rejection is meant to be done inline with the HELO or MAIL FROM command, it doesn't actually say that anywhere. For all we know, the proposed rejection replies come in response to any of HELO, MAIL FROM, one or more of the RCPT TOs, or even DATA, and still meets the spec(s). > > Should we say explicitly that although inline rejection is common, the rejection can be done anywhere in the sequence based on local policy requirements (i.e., other checks)? Or is being ambiguous actually appropriate here? > > I'm not certain this is the right place to put this paragraph or one like it, but it does seem to be a reasonable suggestion, especially if other operators on this list have similar practices and data to share. > > -MSK > > > On Sun, Nov 11, 2012 at 1:21 PM, Hector Santos > wrote: > Alessandro Vesely wrote: > NEW: > SPF verifiers MUST check the "MAIL FROM" identity, by applying the > check_host() function to the "MAIL FROM" identity as the , > except for the two cases following: > > o A final policy decision has already been reached by completing a > check on the "HELO" identity. In this case, unless its result > will be recorded (Section 7), it is useless to check the "MAIL > FROM" identity. > > o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in > [RFC5321]). In this case, SPF verifiers MUST check the "HELO" > identity instead. According to Section 4.3, that implies > synthesizing a mailbox composed of the local-part "postmaster" and > the "HELO" identity. Note that such check might have been carried > out separately before. > > > I would add (with a text change above to indicate three cases): > > o Some other authentication/authorization check is made that does not > require SPF to be applied any longer. A good example is checking > the RCPT TO address for local user existence prior to performing > SPF checks (or any other DNS related protocol check). In practice, this > consideration can reduce DNS/SPF overhead by the same percentage as > the RCPT TO rejections detected, in some field observations as high > as 60% reduction in SPF necessity for the current session. > > -- > HLS > > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- HLS From spf2@kitterman.com Mon Nov 12 12:37:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3821F875C for ; Mon, 12 Nov 2012 12:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7WLlR87pZXF for ; Mon, 12 Nov 2012 12:37:26 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CB78821F86EC for ; Mon, 12 Nov 2012 12:37:25 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DBE0F20E40BB; Mon, 12 Nov 2012 15:37:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352752644; bh=swBozA0J12lTDW6kJ8JKePkqua2++Wx4nzTtMON+zj0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZrrA82nrtCVwsiwVw9AJm/cOmtvBeZMWF6KwJQAdOuwWq6VpOEWZM2ft9HUqrx4Cr Px93UTcSzsqql+ofBLftgeXSgjjA7aQyy3l5+6j4blTy/H60o2EPF6NkO0rmpROXAU 78DT4pBxLAulTMS2FbwZtMFRpRbeZO1qvhu3b6oc= Received: from scott-latitude-e6320.localnet (unknown [184.169.27.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C6D2120E406B; Mon, 12 Nov 2012 15:37:23 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 12 Nov 2012 15:34:18 -0500 Message-ID: <3140829.EyTn1P8QFD@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-18-generic; KDE/4.9.2; i686; ; ) In-Reply-To: References: <509D83C1.301@tana.it> <50A016E7.2090208@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:37:26 -0000 I've always assumed it could be done at any time and I think when you do it is really a local configuration matter and not something we need to explicitly discuss. Postfix, as an example, will, by default, not reject until after Mail >From even if it's based on data from connect or HELO as a work around for interoperability issues seen with other MTAs (I don't know what issues or what MTAs). Scott K On Sunday, November 11, 2012 09:57:46 PM Murray S. Kucherawy wrote: > This suggestion made me go back and do some reading. Others should pipe up > if I'm wrong, but it seems to me that although RFC4408 and the current bis > document probably imply that rejection is meant to be done inline with the > HELO or MAIL FROM command, it doesn't actually say that anywhere. For all > we know, the proposed rejection replies come in response to any of HELO, > MAIL FROM, one or more of the RCPT TOs, or even DATA, and still meets the > spec(s). > > Should we say explicitly that although inline rejection is common, the > rejection can be done anywhere in the sequence based on local policy > requirements (i.e., other checks)? Or is being ambiguous actually > appropriate here? > > I'm not certain this is the right place to put this paragraph or one like > it, but it does seem to be a reasonable suggestion, especially if other > operators on this list have similar practices and data to share. > > -MSK > > On Sun, Nov 11, 2012 at 1:21 PM, Hector Santos wrote: > > Alessandro Vesely wrote: > >> NEW: > >> SPF verifiers MUST check the "MAIL FROM" identity, by applying the > >> check_host() function to the "MAIL FROM" identity as the , > >> except for the two cases following: > >> > >> o A final policy decision has already been reached by completing a > >> > >> check on the "HELO" identity. In this case, unless its result > >> will be recorded (Section 7), it is useless to check the "MAIL > >> FROM" identity. > >> > >> o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in > >> > >> [RFC5321]). In this case, SPF verifiers MUST check the "HELO" > >> identity instead. According to Section 4.3, that implies > >> synthesizing a mailbox composed of the local-part "postmaster" and > >> the "HELO" identity. Note that such check might have been carried > >> out separately before. > > > > I would add (with a text change above to indicate three cases): > > o Some other authentication/authorization check is made that does not > > > > require SPF to be applied any longer. A good example is checking > > the RCPT TO address for local user existence prior to performing > > SPF checks (or any other DNS related protocol check). In practice, > > > > this > > > > consideration can reduce DNS/SPF overhead by the same percentage as > > the RCPT TO rejections detected, in some field observations as high > > as 60% reduction in SPF necessity for the current session. > > > > -- > > HLS > > > > > > > > ______________________________**_________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/**listinfo/spfbis > n/listinfo/spfbis> From spf2@kitterman.com Mon Nov 12 12:39:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEED21F875C for ; Mon, 12 Nov 2012 12:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppU9pKiQpSqU for ; Mon, 12 Nov 2012 12:39:46 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C8EF721F86EC for ; Mon, 12 Nov 2012 12:39:45 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5811920E40BB; Mon, 12 Nov 2012 15:39:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352752785; bh=EALMO9iTNo6GbY8rEY2RL2IXTuxxbQG7YFMEnAQdxhg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WzOirNqy59YlNnYJp1vZxZkK+oB22zpJrVI5OZna8yNc6LJrxpkPwbbTMA3yOliL2 qXF3b9UdgRJS7Rl9F8bPeCTvwmDUBFVpGK6fhxv5rcANcP3c/hJuJ1T+29glXUYqwI QtDe1jkCpJ9F4zJI4I71deeFs92cSVmJ/lKyQIxg= Received: from scott-latitude-e6320.localnet (unknown [184.169.27.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DE67220E406B; Mon, 12 Nov 2012 15:39:43 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 12 Nov 2012 15:39:28 -0500 Message-ID: <1518731.Q0ziJF4iok@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-18-generic; KDE/4.9.2; i686; ; ) In-Reply-To: <50A0CB7F.2010907@tana.it> References: <509D83C1.301@tana.it> <7047432.kdVGSqzZE2@scott-latitude-e6320> <50A0CB7F.2010907@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:39:46 -0000 On Monday, November 12, 2012 11:12:15 AM Alessandro Vesely wrote: > On Mon 12/Nov/2012 02:17:46 +0100 Scott Kitterman wrote: > > On Sunday, November 11, 2012 09:14:59 PM Alessandro Vesely wrote: > >> o SMTP allows the "MAIL FROM" identity to be null (Section 4.5.5 in > >> > >> [RFC5321]). In this case, SPF verifiers MUST check the "HELO" > >> identity instead. According to Section 4.3, that implies > >> synthesizing a mailbox composed of the local-part "postmaster" and > >> the "HELO" identity. Note that such check might have been carried > >> out separately before. > > > > Your proposal does, in fact, change the protocol, if only slightly. A > > constructed "MAIL FROM" check (which is what's in RFC 4408 and the current > > 4408bis draft) is not, in my opinion, the same as a HELO check. How about > > > > this instead: > > If the is null (see Section 4.5.5 of [RFC5321]), such a > > message > > can be assumed to be a notification message from the mail system > > itself. > > The "MAIL FROM" in such cases is constructed using the local-part > > "postmaster" and the "HELO" name for the domain part of the "MAIL > > FROM". > > MAIL FROM and should be swapped, in that text. is > the argument of check_host(), and can never be null. MAIL FROM can be > null, or can be constructed otherwise by the SMTP client. > > BTW, rather than repeating the following for each identity, we should > state once, in Section 2.0, that: > > Checking the "X" identity means applying the check_host() function > to the "X" identity as the , for "X" = "MAIL FROM", "HELO". > > Now for that spurious definition. Since we apply a function, its > parameter is a dummy variable. Thus, to say > > define MAIL FROM := HELO; > MF-result = check_host(MAIL FROM); > > is the same as saying > > MF-result = check_host(HELO); > > except for the silent dropping of the spurious definition before > reporting the SPF result --which is what I'm trying to correct. > > Thus, what remains is to say that that result is what should be used > to make policy decisions. We /have/ to be ambiguous here, because we > don't specify that part. In no case we could prevent a receiver from > behaving specially when MAIL FROM is null. So what we really would > have said is that for simplistic policies that just consider a single > SPF result, such result, which is normally check_host(MAIL FROM), is > check_host(HELO) when MAIL FROM is null. Correct? > > How about: > > If the "MAIL FROM" identity is null (see Section 4.5.5 of > [RFC5321]) the principal SPF result is obtained by checking the > "HELO" identity instead. No, because I don't think "Check HELO" is the same thing as "Check Mail From constructed from postmaster and HELO" Scott K From spf2@kitterman.com Mon Nov 12 12:41:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA7421F8765 for ; Mon, 12 Nov 2012 12:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZZ68+QHWZUh for ; Mon, 12 Nov 2012 12:41:47 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC6E21F875C for ; Mon, 12 Nov 2012 12:41:47 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0127920E40BB; Mon, 12 Nov 2012 15:41:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352752907; bh=YeHqXPvPMl06yJ6qeIs5n95xQc0nKgnFq2m5rUTmWI0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FXx5sokknP784e/ho7d5rvW4QfjX0Eu0fSy9pJ+7YBsRaRKmKO/tokrGqb+yLCNGV zoPmjzN/QQvo+SZQlLTb73BfHyuqrxS/2Re8OrO4B/xzMu2J8XXoPRq4Z8AQEj+uKC +6Ho8N89rP7G6apJs60P7r5Ae0q2vgRWmUQ88VTU= Received: from scott-latitude-e6320.localnet (unknown [184.169.27.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 98D6820E406B; Mon, 12 Nov 2012 15:41:44 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 12 Nov 2012 15:41:32 -0500 Message-ID: <1420172.sex1oLtxOF@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-18-generic; KDE/4.9.2; i686; ; ) In-Reply-To: <50A11C3E.4090804@isdg.net> References: <509D83C1.301@tana.it> <50A0DC7E.70906@tana.it> <50A11C3E.4090804@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:41:48 -0000 On Monday, November 12, 2012 10:56:46 AM Hector Santos wrote: ... > I never did agree or buy into the lack of a receiver policy argument. ... It doesn't matter. With some VERY limited exceptions that's what's documented in RFC 4408 and what we are chartered to update. Let's hold discussions about expanded scope until we have 4408bis done. Scott K From spf2@kitterman.com Mon Nov 12 12:43:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D3621F8765 for ; Mon, 12 Nov 2012 12:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4vwdXnmmrhU for ; Mon, 12 Nov 2012 12:43:47 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9FACF21F857C for ; Mon, 12 Nov 2012 12:43:36 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2068220E40BB; Mon, 12 Nov 2012 15:43:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1352753016; bh=0jUvcyv8QdUrtQUyG/9aXdVv/TnZVYQgFpYAplGT/mI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EajbQLrFAQmhxd/jKqGQPg7dAgAdZp84Khv5juJx0FZZREKaDt4c3irMaKHbk5BEn YWrDarQ6DoGjeJJPbIVXJ2/HcM7mE7cY7/TlDWpJzK1w8Mf4lmUxP7GuDWRdk24xAq pzEzokWSdLHiYyLb5jWP14cg3Hbjhy6pkSQ05y7w= Received: from scott-latitude-e6320.localnet (unknown [184.169.27.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 67DBF20E406B; Mon, 12 Nov 2012 15:43:33 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 12 Nov 2012 15:43:12 -0500 Message-ID: <2559382.JE7t6vYUVK@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-18-generic; KDE/4.9.2; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:43:47 -0000 On Monday, November 12, 2012 06:40:03 PM Franck Martin wrote: > The document would gain clarity if the MAIL FROM was called something else. > It entertains confusion with the mail from aka RFC5321from. > > Can't we call it something like the spf identity and defines what it is: > rfc5321from if present otherwise postmaster@ ? We did take a stab at doing something like this in one draft and it turned out to be more confusing. Mail From is reasonably well understood and we have a definition in the document. I think that is sufficient. Scott K From ajs@anvilwalrusden.com Mon Nov 12 13:14: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 7F2F121F86EA for ; Mon, 12 Nov 2012 13:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3W4ORm2AQESR for ; Mon, 12 Nov 2012 13:14:26 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 133D421F86D3 for ; Mon, 12 Nov 2012 13:14:25 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C1EA58A031 for ; Mon, 12 Nov 2012 21:14:24 +0000 (UTC) Date: Mon, 12 Nov 2012 16:14:23 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20121112211422.GE82038@mx1.yitter.info> References: <509D83C1.301@tana.it> <50A0DC7E.70906@tana.it> <50A11C3E.4090804@isdg.net> <1420172.sex1oLtxOF@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1420172.sex1oLtxOF@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:14:26 -0000 With my chair hat on, On Mon, Nov 12, 2012 at 03:41:32PM -0500, Scott Kitterman wrote: > It doesn't matter. With some VERY limited exceptions that's what's documented > in RFC 4408 and what we are chartered to update. Let's hold discussions about > expanded scope until we have 4408bis done. I couldn't have said this better myself. What Scott said, please. A -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Mon Nov 12 15:16: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 40EA821F85AC for ; Mon, 12 Nov 2012 15:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W46sWxu6gbNE for ; Mon, 12 Nov 2012 15:16:33 -0800 (PST) Received: from ntbbs.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 392DB21F847D for ; Mon, 12 Nov 2012 15:16:32 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=495; t=1352762184; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=OBbIcpliIdbACxYqAmWbTiMOJZE=; b=uGNEUCRIGcFhj/KIPUIb x9v9WHUR0EBqOArc9G2kfZIk7HZan+rWbb+o9W1anXn9ZEt3sekAlsuzS0JsH5C/ Mf6Vh2qJNDfnCglGArFJHjqBPpRM3MeortkHJstlrXeFllTZWCcga5xjBh0w56h0 We82+6mX4kqkIdnoeH+aY+4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 12 Nov 2012 18:16:24 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 193967350.6164.3848; Mon, 12 Nov 2012 18:16:24 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=495; t=1352761851; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kk+Xfdg N9qREP37bE5pk17vTnnlqv42wOTCokUerV3A=; b=PH/ow1AxbPTe29xoQNuBTlZ xp6j2xgdWkMyJfQChuOFwzn6ajV6MjamAdY7of0xSNcvXGZLUA6sOelCqdmAwNM9 YtNEE36D7b+I3rzrHhyALRiv52Toj6J5MD9+jIjccjc5FSP3y9WbQql6wtv7N3pL 6H1pm1iWggXRDpC1qIo8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 12 Nov 2012 18:10:51 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 792715428.9.4340; Mon, 12 Nov 2012 18:10:51 -0500 Message-ID: <50A1838D.9090400@isdg.net> Date: Mon, 12 Nov 2012 18:17:33 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <509D83C1.301@tana.it> <50A0DC7E.70906@tana.it> <50A11C3E.4090804@isdg.net> <1420172.sex1oLtxOF@scott-latitude-e6320> <20121112211422.GE82038@mx1.yitter.info> In-Reply-To: <20121112211422.GE82038@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:16:34 -0000 Which is what? I'm lost again in what the WGCs are looking for. Andrew Sullivan wrote: > With my chair hat on, > > On Mon, Nov 12, 2012 at 03:41:32PM -0500, Scott Kitterman wrote: > >> It doesn't matter. With some VERY limited exceptions that's what's documented >> in RFC 4408 and what we are chartered to update. Let's hold discussions about >> expanded scope until we have 4408bis done. > > I couldn't have said this better myself. What Scott said, please. > > A > -- HLS From ajs@anvilwalrusden.com Mon Nov 12 15:29:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0F021F869C for ; Mon, 12 Nov 2012 15:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAWi6I0W6Wii for ; Mon, 12 Nov 2012 15:29:08 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4555321F861C for ; Mon, 12 Nov 2012 15:29:08 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id CF72A8A031; Mon, 12 Nov 2012 23:29:05 +0000 (UTC) Date: Mon, 12 Nov 2012 18:29:03 -0500 From: Andrew Sullivan To: Hector Santos Message-ID: <20121112232903.GI82038@mx1.yitter.info> References: <509D83C1.301@tana.it> <50A0DC7E.70906@tana.it> <50A11C3E.4090804@isdg.net> <1420172.sex1oLtxOF@scott-latitude-e6320> <20121112211422.GE82038@mx1.yitter.info> <50A1838D.9090400@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50A1838D.9090400@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:29:09 -0000 On Mon, Nov 12, 2012 at 06:17:33PM -0500, Hector Santos wrote: > Which is what? I'm lost again in what the WGCs are looking for. No expanded scope, please. That means that talking about things outside what's in 4408 is not part of our charter. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From vesely@tana.it Tue Nov 13 00:49: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 B87FB21F8488 for ; Tue, 13 Nov 2012 00:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHA0ZTPzocWO for ; Tue, 13 Nov 2012 00:49:39 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F156D21F85EB for ; Tue, 13 Nov 2012 00:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352796574; bh=PtuVTQ8pO9axfw289IrQ+jLCpQo7QpdphVZ6tFGj01s=; l=468; h=Date:From:To:References:In-Reply-To; b=E4KK6enviV2Hf7uMTX1b67R/cAsg0uvRuXtyyVMv0A2TPI4jv9QPq2vNsa6axdmj4 xqq0ifyNS7b+R1i3r0mFBKD7lc5s1IzJSrSOOIOFiLKWLZcncwcprrB18QPdztxVR8 3ZFB7rq+RaLSg5XTMHzSVtDMl4r5LglVzsXwgxzM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 13 Nov 2012 09:49:34 +0100 id 00000000005DC049.0000000050A2099E.00005EB3 Message-ID: <50A2099D.6070902@tana.it> Date: Tue, 13 Nov 2012 09:49:33 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <509D83C1.301@tana.it> <7047432.kdVGSqzZE2@scott-latitude-e6320> <50A0CB7F.2010907@tana.it> <1518731.Q0ziJF4iok@scott-latitude-e6320> In-Reply-To: <1518731.Q0ziJF4iok@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:49:42 -0000 On Mon 12/Nov/2012 21:39:28 +0100 Scott Kitterman wrote: > On Monday, November 12, 2012 11:12:15 AM Alessandro Vesely wrote: >> How about: >> >> If the "MAIL FROM" identity is null (see Section 4.5.5 of >> [RFC5321]) the principal SPF result is obtained by checking the >> "HELO" identity instead. > > No, because I don't think "Check HELO" is the same thing as "Check Mail From > constructed from postmaster and HELO" And the difference between them is? From hsantos@isdg.net Tue Nov 13 02:54:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6780821F86A3 for ; Tue, 13 Nov 2012 02:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRQAimZHy0rm for ; Tue, 13 Nov 2012 02:54:23 -0800 (PST) Received: from listserv.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A046021F8695 for ; Tue, 13 Nov 2012 02:54:20 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=688; t=1352804051; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BcjEYiKGMyIsHn5Ec23wt7VQAvk=; b=lxkyOuCZ1GGxivobXdI1 7V/rYq1F8A0/WyEp+VSgxnH/2GSWuEslpL3Q/xLpaT/MDPDWtgnDK7yXkzIgB0hE UEnQ7abWi5iBTuF3M3NQIuwFdtFR3hfaxbzOhu7ORo6bQLRCEfXGAT6YVDzoQZqi u3QuL7eDgefqZ7x/ad3rA0g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 13 Nov 2012 05:54:11 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 235832995.7146.536; Tue, 13 Nov 2012 05:54:10 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=688; t=1352803716; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=n2sTyl5 /6fhguUvJBMHRVHznC6hrLqiSHmk+oUGGAsg=; b=SqPHu6mt87d5ZWcJ4OaVmPw ITx02KLOFySRuM5U6gAesltq35hKeB7C4OLJGcj3t1YaLQD0IOoxKpo6PTiqAslA 8qA31SEjs9wPtcWyVUAh/7H1uFpDs+Rlpf7lALwxys2JKnnGbwrLMljuSQox8DlX jQJF7WhvhOxrGHsaoRxU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 13 Nov 2012 05:48:36 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 834580163.9.1704; Tue, 13 Nov 2012 05:48:35 -0500 Message-ID: <50A226E4.7000201@isdg.net> Date: Tue, 13 Nov 2012 05:54:28 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <509D83C1.301@tana.it> <50A0DC7E.70906@tana.it> <50A11C3E.4090804@isdg.net> <1420172.sex1oLtxOF@scott-latitude-e6320> <20121112211422.GE82038@mx1.yitter.info> <50A1838D.9090400@isdg.net> <20121112232903.GI82038@mx1.yitter.info> In-Reply-To: <20121112232903.GI82038@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 10:54:28 -0000 Andrew Sullivan wrote: > On Mon, Nov 12, 2012 at 06:17:33PM -0500, Hector Santos wrote: >> Which is what? I'm lost again in what the WGCs are looking for. > > No expanded scope, please. That means that talking about things > outside what's in 4408 is not part of our charter. Does that include AUTH-RES? DKIM? DMARC? and anything related to reporting and reputation, like SPAMHAUS or gearing up for it? IOW, the Reorganization? I believe I have been advocating nothing but the pure codification of this SPF protocol and implementation insights based on the 9+ years of field operations for the BIS which I believe is on par for standard (or typical) BIS work. -- HLS From sm@elandsys.com Tue Nov 13 13:01:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF0921F8563 for ; Tue, 13 Nov 2012 13:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SAVELE=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Buy+7pprl6g for ; Tue, 13 Nov 2012 13:01:30 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD2C21F8525 for ; Tue, 13 Nov 2012 13:01:30 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.136.160]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qADL1GY1027043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Nov 2012 13:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352840488; bh=F88xv+fd+2T+xXsnBmL73Y9m9iMm23FjqNTsl5ybfMs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gbUIIkU2ahe2dJsDrRfLOjBuXr3ptimGxgNVCnkoq+f8SNfW47j/VVjTJNMZwVaie WzcqzopkzcffwACprZUNOdAjcNXEiEAHEzD9vMwF7bzTWYXD4vi27bsp7IGBVUZCOy EoSYFmuHTXLe25b+WknyzhM55yo37RULNH9e2zDo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352840488; i=@elandsys.com; bh=F88xv+fd+2T+xXsnBmL73Y9m9iMm23FjqNTsl5ybfMs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eoGrDC5K9iraLBTnOO3ErbWoe7CTgdXAjk+ZMlWR4i+mfRvx9+HYL2e/sclhgWsK4 wE6PTWwOiuAtBYqsysPFuSHwp89IcEx6QMk49qno3Yglp6vIDCZNgzfEHqnfkkaoaQ ZrA3Dup/Wv1ClLD/l6bW9ryBZwfdWdVVU8GoKmu0= Message-Id: <6.2.5.6.2.20121113122157.0982a3e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Nov 2012 12:26:57 -0800 To: Hector Santos From: S Moonesamy In-Reply-To: <50A226E4.7000201@isdg.net> References: <509D83C1.301@tana.it> <50A0DC7E.70906@tana.it> <50A11C3E.4090804@isdg.net> <1420172.sex1oLtxOF@scott-latitude-e6320> <20121112211422.GE82038@mx1.yitter.info> <50A1838D.9090400@isdg.net> <20121112232903.GI82038@mx1.yitter.info> <50A226E4.7000201@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 21:01:31 -0000 Hi Hector, At 02:54 13-11-2012, Hector Santos wrote: >Does that include AUTH-RES? DKIM? DMARC? and anything related to >reporting and reputation, like SPAMHAUS or gearing up for it? IOW, >the Reorganization? DKIM is not part of the 4408bis work. DMARC is not part of the 4408bis work. I haven't seen any messages on the SPFBIS mailing list about doing reputation work. Regards, S. Moonesamy From hsantos@santronics.com Tue Nov 13 13:12: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 4B74921F8950 for ; Tue, 13 Nov 2012 13:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SAVELE=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G78vPjlFyj3w for ; Tue, 13 Nov 2012 13:12:33 -0800 (PST) Received: from mail.santronics.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 47C1F21F88B2 for ; Tue, 13 Nov 2012 13:12:32 -0800 (PST) DKIM-Signature: v=1; d=santronics.com; s=tms1; a=rsa-sha1; c=simple/relaxed; l=571; t=1352841145; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=NnfEOtu l05hqgrUEitseJk3zTWU=; b=k85fgjNx8/ryrZfwPtei0Ev7SquGI4oFER+nFu/ ube7H4P3Orhv+I2ueozN5CEbWug+lQxC6AtZlE++UCdjKJ15FlJc5MP5aRIoi8AE 805ERKgq8iHj4JqV+jToFF9v2w1NE7miaOBL8EtORrmNFidS2xfhyYqA4vI8y/bs 9Ctg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 13 Nov 2012 16:12:25 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 272927240.7146.508; Tue, 13 Nov 2012 16:12:25 -0500 Message-ID: <50A2B7FC.5040901@santronics.com> Date: Tue, 13 Nov 2012 16:13:32 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <509D83C1.301@tana.it> <50A0DC7E.70906@tana.it> <50A11C3E.4090804@isdg.net> <1420172.sex1oLtxOF@scott-latitude-e6320> <20121112211422.GE82038@mx1.yitter.info> <50A1838D.9090400@isdg.net> <20121112232903.GI82038@mx1.yitter.info> <50A226E4.7000201@isdg.net> <6.2.5.6.2.20121113122157.0982a3e8@resistor.net> In-Reply-To: <6.2.5.6.2.20121113122157.0982a3e8@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 13 Nov 2012 13:18:25 -0800 Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue? What identity is being reported/checked? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 21:12:34 -0000 S Moonesamy wrote: > Hi Hector, > At 02:54 13-11-2012, Hector Santos wrote: >> Does that include AUTH-RES? DKIM? DMARC? and anything related to >> reporting and reputation, like SPAMHAUS or gearing up for it? IOW, the >> Reorganization? > > DKIM is not part of the 4408bis work. DMARC is not part of > the 4408bis work. I haven't seen any messages on the > SPFBIS mailing list about doing reputation work. Nevertheless, they are there. Its good to know we are getting focused on BIS. Thanks -- Sincerely Hector Santos http://www.santronics.com From ajs@anvilwalrusden.com Fri Nov 23 12:47: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 4DF2221F8625 for ; Fri, 23 Nov 2012 12:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_05=-1.11, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYljlLji37fi for ; Fri, 23 Nov 2012 12:47:50 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6152021F8622 for ; Fri, 23 Nov 2012 12:47:48 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 24C618A031 for ; Fri, 23 Nov 2012 20:47:47 +0000 (UTC) Date: Fri, 23 Nov 2012 15:47:45 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20121123204745.GB56042@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 20:47:51 -0000 Dear colleagues, At IETF 85, the WG met and rapidly came to what appeared to your chairs as consensus on next steps. They are these: 1. Perform a diff between the most recent WG document (08) and RFC 4408. This allows us to document precisely any differences between the current state of work and the starting point of the WG. This is a step we undertake for defensive purposes only, in case later people ask us about the steps in the reorganization. We ask the editor, Scott Kitterman, to perform this and send the output to the mailing list (for the archives). 2. Scott, in collaboration with Murray Kucherawy (who proposed the original reorganization), undertakes the reorganization and creates the next WG document. This reorganization should have _no_ text changes in it apart from moving text around. A note should be added to that version of the draft to indicate that it only reorganizes the text of 08. This will form the WG draft 09. This version must be uploaded as 09 in order to provide the necessary chain in the tracking tools, so that we can demonstrate that the reorganization did not change the substance of 08. 3. Scott updates the 09 immediately with any pending substantive changes he has lined up. This forms the WG draft 10, and is the basis for any further work. There was extremely little support for splitting the draft or in any way taking on another document right now. Given that and the WG charter, the chairs believe that there is no reason to split the draft, and we do not intend to follow that course. Since there was no active decision at IETF 85 to split the draft, there is no confirmation of this decision needed here (we're continuing with our existing path); but in the spirit of confirming meeting decisions on the list, if you have strong arguments in favour of splitting the draft you need to make them right now. While you're doing it, you need to demonstrate that others are willing to work on such a split and to demonstrate that there is someone with the required skill, time, and interest in working on a split. This demonstration needs to include support from the editor of the current WG draft, since he will inevitably need to do work as well. This message confirms our impression of what transpired in the WG meeting. We ask the editor to proceed on the above lines. Best regards, SM/AS, as chairs. -- Andrew Sullivan ajs@anvilwalrusden.com