From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Dec 1 00:32:35 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76D721F8B78 for ; Thu, 1 Dec 2011 00:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEI+4T6sZUQD for ; Thu, 1 Dec 2011 00:32:35 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2D221F8B70 for ; Thu, 1 Dec 2011 00:32:34 -0800 (PST) Received: by eabm6 with SMTP id m6so2073230eab.31 for ; Thu, 01 Dec 2011 00:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YNg+ziGYzsq/Jfb+gYAa/tCYYdhziZDaL9WPnV5HDk8=; b=RCJYgMbBVeo8XOAlcHCwkbDBYS3X31Yv2W3VgmkNCuSgv5OfTKDPmEVNKrzmsFuiG+ XZt7wcCFB0FbRDJ7mcfTHD0YAiO0xsPPjGv/KDPCFm4Ym79mWTyqfWEkE2BJJW6AtmyR HIbKJ3MckHjKTTv699C85JnpKthA3ctF8AHGo= Received: by 10.227.203.131 with SMTP id fi3mr3186394wbb.17.1322728354277; Thu, 01 Dec 2011 00:32:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.255.70 with HTTP; Thu, 1 Dec 2011 00:31:53 -0800 (PST) In-Reply-To: References: From: Frank Ellermann Date: Thu, 1 Dec 2011 09:31:53 +0100 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 08:32:35 -0000 On 1 December 2011 07:37, Murray S. Kucherawy wrote: > This level of hostility will kill this work before it gets off the ground. Apropos, it could help to note in the Charter that 4408bis shall work for most valid existing published 4408 policies (syntax and semantics) "as is". It could be good if some rarely used features are identified and "unrecommended" or similar, but it would be bad if many policies have to be upgraded for 4408bis implementations. Likewise, ideally 4408 SPF implementations are "automagically" 4408bis implementations (excluding errata, obviously). There was some magic in this direction in the DKIM Charter wrt Domainkeys, therefore it might be good to mention "compatibility" explicitly. And no, of course I intend no "hostile take over" of this work, if folks don't wish to talk about EAI, or at least not now and here, that's fine with me. And yes, there was an attempt to take over "v=spf1" policies some years ago. I'm very much in favour of all statements in your proposed Charter that this will be "out of scope" here. -Frank From msk@cloudmark.com Thu Dec 1 00:40:35 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622F621F8BB7 for ; Thu, 1 Dec 2011 00:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.746 X-Spam-Level: X-Spam-Status: No, score=-102.746 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DRQM6DMqJQC for ; Thu, 1 Dec 2011 00:40:34 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id EC88121F8B8A for ; Thu, 1 Dec 2011 00:40:34 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by spite.corp.cloudmark.com (172.22.10.72) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 1 Dec 2011 00:40:30 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 1 Dec 2011 00:40:30 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Thu, 1 Dec 2011 00:40:33 -0800 Thread-Topic: [spfbis] SPFBIS proposed charter Thread-Index: AcywA8ccFD4wTqaZRXWkI0BwVByIOAAANsOQ Message-ID: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 08:40:35 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Thursday, December 01, 2011 12:32 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] SPFBIS proposed charter >=20 > Apropos, it could help to note in the Charter that 4408bis shall work > for most valid existing published 4408 policies (syntax and semantics) > "as is". It could be good if some rarely used features are identified > and "unrecommended" or similar, but it would be bad if many policies > have to be upgraded for 4408bis implementations. It already says: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. > Likewise, ideally 4408 SPF implementations are "automagically" 4408bis > implementations (excluding errata, obviously). There was some magic in > this direction in the DKIM Charter wrt Domainkeys, therefore it might > be good to mention "compatibility" explicitly. I think what I cited above covers backward compatibility, but I have no obj= ection to actually saying so if there's consensus that it's necessary. > And no, of course I intend no "hostile take over" of this work, if > folks don't wish to talk about EAI, or at least not now and here, > that's fine with me. That isn't the hostility to which I was referring. From msk@cloudmark.com Thu Dec 1 15:18:21 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9D421F85CE for ; Thu, 1 Dec 2011 15:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.731 X-Spam-Level: X-Spam-Status: No, score=-102.731 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdhh1CQGV4Ft for ; Thu, 1 Dec 2011 15:18:20 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6169821F8564 for ; Thu, 1 Dec 2011 15:18:17 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 1 Dec 2011 15:18:16 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Thu, 1 Dec 2011 15:18:15 -0800 Thread-Topic: I-D Action: draft-mehnle-spf-scope-00.txt Thread-Index: Acyweh+Xy6sJfxMASzGpYpBKtJSjLgABVpZg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [spfbis] FW: I-D Action: draft-mehnle-spf-scope-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 23:18:21 -0000 The missing draft has surfaced. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Thursday, December 01, 2011 2:40 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-mehnle-spf-scope-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : "From" and other Message Header Fields as SPF Policy Sco= pes Author(s) : Julian Mehnle Filename : draft-mehnle-spf-scope-00.txt Pages : 7 Date : 2011-12-01 This document defines a new modifier for the SPF e-mail authentication protocol allowing the SPF record for a domain to be declared as being applicable to message identities other than the MAIL FROM identity, such as the "From" or "Sender" message header identities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mehnle-spf-scope-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-mehnle-spf-scope-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From sm@resistor.net Thu Dec 1 21:42:58 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EC621F8663 for ; Thu, 1 Dec 2011 21:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEvIuq9QxJyj for ; Thu, 1 Dec 2011 21:42:56 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A61621F85F2 for ; Thu, 1 Dec 2011 21:42:56 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB25gcFp010797 for ; Thu, 1 Dec 2011 21:42:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1322804565; bh=RpkSPoZtSqAncFf2nKKh/SLHPG3pPUltzC83XGT47E8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=kVikzEpc6ij7XMxs8VLCRrwcAftZ/Iowe9244elD7LeGJ+QNONOLEZPzdptWW4663 L1v35NBHTgiel28xc6IKoKcJVthMdT80PbshQU60qfToSKO+wgRcJs3X+DS52oO+eK SiJ8qmiggYcxF0vVSeNmUbT+/u3sbfi4k0VGxTLI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1322804565; bh=RpkSPoZtSqAncFf2nKKh/SLHPG3pPUltzC83XGT47E8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=TajPGR67p0GHqwnzdqkMCWGXWh4Givn8sb73tbULsNn+fRpVeHkhyuVoh5MVLNmf8 3plb05LwAMcb84WsUse3p1WzalZYEsVZidZ2jAiYDSOewuOpI6NOsbvF+nREZP//un 3eSnaGk/o/dFUI2bXobegIw1DzjrYvFyQjokR+gI= Message-Id: <6.2.5.6.2.20111201211727.0a155128@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Dec 2011 21:41:59 -0800 To: spfbis@ietf.org From: SM In-Reply-To: References: <6.2.5.6.2.20111130134620.0caeabd0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 05:42:58 -0000 At 13:56 30-11-2011, Murray S. Kucherawy wrote: >I've contacted the author, and now his boss, to remind him to post it. :-) Commenting on the proposed charter: 'Finally, the working group will develop the proposed "scope" extension found in draft-mehnle-spfbis-scope. Specifically out-of-scope for this working group:' draft-mehnle-spfbis-scope is new work. As there isn't any operational experience for it, I suggest not to limit the scope except for discussions about the merits of SPF. I suggest deleting the following sentences: 'Finally, the working group will develop the proposed "scope" extension found in draft-mehnle-spfbis-scope.' 'Extensions to SPF other than the one specified above.' 'MMM YYYY: A standards track document creating the "scope" extension to the IESG for publication.' and re-chartering to take on draft-mehnle-spfbis-scope. Regards, -sm From msk@cloudmark.com Thu Dec 1 22:31:57 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5151F0C40 for ; Thu, 1 Dec 2011 22:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3OvrkA8sR+R for ; Thu, 1 Dec 2011 22:31:57 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2B93B1F0C35 for ; Thu, 1 Dec 2011 22:31:57 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 1 Dec 2011 22:31:56 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Thu, 1 Dec 2011 22:31:59 -0800 Thread-Topic: [spfbis] SPFBIS proposed charter Thread-Index: AcywtUo7vL/4Isr6SQWjF9VxuFRFrgABVFbA Message-ID: References: <6.2.5.6.2.20111130134620.0caeabd0@resistor.net> <6.2.5.6.2.20111201211727.0a155128@resistor.net> In-Reply-To: <6.2.5.6.2.20111201211727.0a155128@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 06:31:57 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of SM > Sent: Thursday, December 01, 2011 9:42 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] SPFBIS proposed charter >=20 > At 13:56 30-11-2011, Murray S. Kucherawy wrote: > >I've contacted the author, and now his boss, to remind him to post it. > >:-) >=20 > Commenting on the proposed charter: >=20 > 'Finally, the working group will develop the proposed "scope" > extension found in draft-mehnle-spfbis-scope. >=20 > Specifically out-of-scope for this working group:' >=20 > draft-mehnle-spfbis-scope is new work. As there isn't any operational > experience for it, I suggest not to limit the scope except for > discussions about the merits of SPF. The idea of the charter's current language is to prevent rat-holing on any = of the contentious stuff regarding what parts of SPF are better or what's w= rong with other mechanisms. There's clear consensus that we as a community= want to move forward with SPF to the exclusion of other things in its fami= ly, so anything else is a distraction. We're hoping this language will hel= p to maintain focus. The "reasonably warranted based on operational experience" bit further cons= trains the discussion, limiting any tweaks to SPF such that they have to be= based on what we've actually seen in operation rather than anything hypoth= etical. "Reasonably", of course, is subjective, and the working group and = its co-chairs would need to gauge what things are safe to reopen based on t= hose criteria and what things are also rat-holes. The extension draft you're talking about doesn't fit into that category, an= d there's a community that wants to develop and implement it now. Given th= at level of extant support for it, I believe it makes sense to allow for it= in this first charter as well. We've called out a single, specific extens= ion as a candidate for consideration rather than "extensions", which would = be far too general. > I suggest deleting the following sentences: > [...] > and re-chartering to take on draft-mehnle-spfbis-scope. If the re-chartering process is as painless as I've heard it is, then I sup= pose this is an option. How do others feel? -MSK From sm@resistor.net Thu Dec 1 22:41:13 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0936221F8E65 for ; Thu, 1 Dec 2011 22:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FSn62yNbKMx for ; Thu, 1 Dec 2011 22:41:10 -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 E202E21F8E58 for ; Thu, 1 Dec 2011 22:41:10 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB26f5sc023256 for ; Thu, 1 Dec 2011 22:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1322808070; bh=CQDiwHor8qhMThHQk8xaZTJsntdZqXc90EHCmkOwLxA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=nxMh1shCsU3Oj9vJR0RPRDqFjoBwLCgwVT8Afios+5a249wWoYWiiJbDjwl9dlMp4 dPddICbX6WnKyiY738lDKgftH+qW8WTGqL3stVrmmPrRGCKIXqbGSP84Lu3VJaUwqo hHFvkE/Q+ynl4Mn+ZlGXEcNjcszzmNG2bSNOCek8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1322808070; bh=CQDiwHor8qhMThHQk8xaZTJsntdZqXc90EHCmkOwLxA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=rUCaQbRnxFyQGqBKj+J7b5vljtxdNM7jizIG+VPu4HMzyYkDqGFpfTXCCijkO7o/D UBKh6XEb4C8ZjI0dtBYOlyCz77r3mhVzImAIc80GqNohME+C9f5BFLpBidknFYaZYK M/djTVWluwsxPRaWmof45glkk7SB0HyCFlGmPzxY= Message-Id: <6.2.5.6.2.20111201223320.09054ff8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Dec 2011 22:40:52 -0800 To: spfbis@ietf.org From: SM In-Reply-To: References: <6.2.5.6.2.20111130134620.0caeabd0@resistor.net> <6.2.5.6.2.20111201211727.0a155128@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 06:41:13 -0000 Hi Murray, At 22:31 01-12-2011, Murray S. Kucherawy wrote: >The extension draft you're talking about doesn't fit into that >category, and there's a community that wants to develop and >implement it now. Given that level of extant support for it, I >believe it makes sense to allow for it in this first charter as >well. We've called out a single, specific extension as a candidate >for consideration rather than "extensions", which would be far too general. [snip] >If the re-chartering process is as painless as I've heard it is, >then I suppose this is an option. How do others feel? I am ok with any of the two alternatives you commented about. Regards, -sm From sm@resistor.net Thu Dec 1 23:01:09 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A371F0C6D for ; Thu, 1 Dec 2011 23:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk+k+Lcb7yCa for ; Thu, 1 Dec 2011 23:01:08 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B78911F0C6C for ; Thu, 1 Dec 2011 23:01:07 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB2712aE010187 for ; Thu, 1 Dec 2011 23:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1322809267; bh=opkP0JNnAk8FwIJ5CyYQyTasIkPr7pEsTRZ3WQaTHaQ=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=NECcITfwr22LhD98IprJ7S9aMn+485MnLHGb7cTlsYLKjqDi3eKgi8ksP83LSOor/ DCR0kjhujNsLsrHrQpxWcfdTjJVggZvMLQS4LsXCSavAUu5RSPfmGznLj8Cg2Ne79u qKsZDgK7CRULJWjqI/PqkBU9UhCOBWNW1QL1lXYE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1322809267; bh=opkP0JNnAk8FwIJ5CyYQyTasIkPr7pEsTRZ3WQaTHaQ=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=STeXgqyr7lm+NWBmL9sBf7EAo3lLTA3sLkTRuuQf81Cq/zsWyttbKptWQpldMJtV8 vbnQ+1wsWWop+PTlzBoM1m+L+Nzr/Y3TiCaKR1w9TwGUp0dp5GPU1w7bPc3J+NHNRK r1FnmTvfKDDC3haDtp1wrtI+2jKekwF8bVrTyWxY= Message-Id: <6.2.5.6.2.20111201224817.0a11b140@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Dec 2011 22:58:21 -0800 To: spfbis@ietf.org From: SM In-Reply-To: <4ED6C443.20107@dcrocker.net> References: <6.2.5.6.2.20111130134620.0caeabd0@resistor.net> <4ED6C443.20107@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 07:01:09 -0000 At 16:03 30-11-2011, Dave CROCKER wrote: >We need to leave Sender-ID alone for this round of effort. Touching >it is inviting distraction and delay from producing an SPF >specification on standards track. I'll volunteer to edit the document that concludes the experiments. I can resurrect an amended version of an expired draft as a starting point. I suggest working on 4408bis first to avoid any distraction. Regards, -sm From pmidge@microsoft.com Thu Dec 1 23:05:58 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E059221F8922 for ; Thu, 1 Dec 2011 23:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX7HAp-n7J7D for ; Thu, 1 Dec 2011 23:05:57 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9232721F9454 for ; Thu, 1 Dec 2011 23:04:11 -0800 (PST) Received: from mail109-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Dec 2011 07:04:07 +0000 Received: from mail109-db3 (localhost [127.0.0.1]) by mail109-db3-R.bigfish.com (Postfix) with ESMTP id 295664E03B8; Fri, 2 Dec 2011 07:04:07 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz9371K936eK542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail109-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail109-db3 (localhost.localdomain [127.0.0.1]) by mail109-db3 (MessageSwitch) id 132280944737206_15574; Fri, 2 Dec 2011 07:04:07 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.242]) by mail109-db3.bigfish.com (Postfix) with ESMTP id EEB82580043; Fri, 2 Dec 2011 07:04:06 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 2 Dec 2011 07:04:06 +0000 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.192]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0247.005; Thu, 1 Dec 2011 23:03:54 -0800 From: Paul Midgen To: SM , "spfbis@ietf.org" Thread-Topic: [spfbis] SPFBIS proposed charter Thread-Index: AQHMsL1VYeCrdB1TSK+TVqOt6HBf7JXIGccQ Date: Fri, 2 Dec 2011 07:03:54 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E2042B0E4@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <6.2.5.6.2.20111130134620.0caeabd0@resistor.net> <6.2.5.6.2.20111201211727.0a155128@resistor.net> <6.2.5.6.2.20111201223320.09054ff8@resistor.net> In-Reply-To: <6.2.5.6.2.20111201223320.09054ff8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 07:05:58 -0000 I'm still relatively inexperienced in the standards process, so keep that i= n mind when reading my comments. I'm treating SPFbis as the effort that will bring a path authorization mech= anism to internet standards status. We currently have two path authorizatio= n mechanisms in experimental status. Over the last 6 months it's become evi= dent (to me) that in the last 5+ years a de facto consensus for the operati= on of path authorization mechanisms has emerged. One of SPFbis' efforts will be to publish data detailing current operationa= l characteristics of SPF & SenderID (the document Dave Crocker mentioned), = and said data will inform SPFbis. As has been mentioned, it's not terribly = interesting (to me, anyway) what happens with RFCs 4406 & 4407. Having now given draft-mehnle-spf-scope a first read, my hope that what it = essentially proposes (inclusion of some number of RFC5322 headers as authen= ticatable identities) finds its way into SPFbis, and that doing so is suppo= rted by operational data. I've seen this to be true anecdotally, but want i= t out there in published form with data from multiple receivers, senders, e= tc. included in the analysis. -p > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > Of SM > Sent: Thursday, December 01, 2011 10:41 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] SPFBIS proposed charter >=20 > Hi Murray, > At 22:31 01-12-2011, Murray S. Kucherawy wrote: > >The extension draft you're talking about doesn't fit into that > >category, and there's a community that wants to develop and implement > >it now. Given that level of extant support for it, I believe it makes > >sense to allow for it in this first charter as well. We've called out > >a single, specific extension as a candidate for consideration rather > >than "extensions", which would be far too general. >=20 > [snip] >=20 > >If the re-chartering process is as painless as I've heard it is, then I > >suppose this is an option. How do others feel? >=20 > I am ok with any of the two alternatives you commented about. >=20 > Regards, > -sm >=20 > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From pmidge@microsoft.com Thu Dec 1 23:06:00 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9DF21F9752 for ; Thu, 1 Dec 2011 23:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUUFTz+bJbsM for ; Thu, 1 Dec 2011 23:05:59 -0800 (PST) Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0C10E21F97B7 for ; Thu, 1 Dec 2011 23:05:31 -0800 (PST) Received: from mail190-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Dec 2011 07:05:27 +0000 Received: from mail190-va3 (localhost [127.0.0.1]) by mail190-va3-R.bigfish.com (Postfix) with ESMTP id 39DCC4E035A; Fri, 2 Dec 2011 07:05:27 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz9371K936eK542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail190-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail190-va3 (localhost.localdomain [127.0.0.1]) by mail190-va3 (MessageSwitch) id 132280952791949_23570; Fri, 2 Dec 2011 07:05:27 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.240]) by mail190-va3.bigfish.com (Postfix) with ESMTP id 1061E20046; Fri, 2 Dec 2011 07:05:27 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 2 Dec 2011 07:05:26 +0000 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.192]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0247.005; Thu, 1 Dec 2011 23:05:27 -0800 From: Paul Midgen To: SM , "spfbis@ietf.org" Thread-Topic: [spfbis] SPFBIS proposed charter Thread-Index: AQHMr6plPwnTiIbujEyI1U9a30x2NJXGoAaAgAIGT4D//3uCUA== Date: Fri, 2 Dec 2011 07:05:27 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E2042B0F5@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <6.2.5.6.2.20111130134620.0caeabd0@resistor.net> <4ED6C443.20107@dcrocker.net> <6.2.5.6.2.20111201224817.0a11b140@resistor.net> In-Reply-To: <6.2.5.6.2.20111201224817.0a11b140@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 07:06:00 -0000 Murray and I have had some discussion on this prior to starting SPFbis, and= the work is already in progress - though my contribution to it won't be re= ady for some months, since I'm constrained by my current ability to gather = all the data I want. So - before we start editing and circulating documents, we should first hav= e a discussion on what all our thoughts/expectations are. > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > Of SM > Sent: Thursday, December 01, 2011 10:58 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] SPFBIS proposed charter >=20 > At 16:03 30-11-2011, Dave CROCKER wrote: > >We need to leave Sender-ID alone for this round of effort. Touching it > >is inviting distraction and delay from producing an SPF specification > >on standards track. >=20 > I'll volunteer to edit the document that concludes the experiments. I ca= n > resurrect an amended version of an expired draft as a starting point. I > suggest working on 4408bis first to avoid any distraction. >=20 > Regards, > -sm >=20 > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From sm@resistor.net Thu Dec 1 23:54:57 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F198811E809A for ; Thu, 1 Dec 2011 23:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yR8hWHubtHZ for ; Thu, 1 Dec 2011 23:54:56 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4493811E8094 for ; Thu, 1 Dec 2011 23:54:56 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB27snqS009890; Thu, 1 Dec 2011 23:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1322812495; bh=S3RQSCPnub8reFAbUKI7JWeGP5v1IwZM5KTSiB8MPx4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=nN+ylrdxOxC0ZuR2jFM9DylFuAisOUhAeXO8kJ2niisWTwl5kYBVSq2icQ8kSdgqG 4UVlDyjgt2Knoxs7zGr4Ij9oUKpbyfixtaiEuqxs5Rh6WHtzIR2huiRNU8/P+0E7u7 sIki3dOZHj5j5kGs+ywdTIDQU0K0WVErQoJZH/Po= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1322812495; bh=S3RQSCPnub8reFAbUKI7JWeGP5v1IwZM5KTSiB8MPx4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=NY8TXRHknmfdTs2/KMtEpXP0/tCrg0nOs4Xx1THvmgNtCM1Hfi1xVEJz8n6MIN9TR /G3+SGg0iXXG9cCiVkOGy0Fpj444zKsQaB7ULw0IVr/wIjzUIXaxjTDzP7arcuvOkO sAW5ZxLRxH4TEKw4DiS2Qh4MPQtr817D7EYZ3lyg= Message-Id: <6.2.5.6.2.20111201231730.09055288@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Dec 2011 23:54:32 -0800 To: Paul Midgen From: SM In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E2042B0E4@TK5EX14MBXC202.re dmond.corp.microsoft.com> References: <6.2.5.6.2.20111130134620.0caeabd0@resistor.net> <6.2.5.6.2.20111201211727.0a155128@resistor.net> <6.2.5.6.2.20111201223320.09054ff8@resistor.net> <7F7F36E50398F84DBAF25C9D51732F1E2042B0E4@TK5EX14MBXC202.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 07:54:57 -0000 Hi Paul, At 23:03 01-12-2011, Paul Midgen wrote: >I'm still relatively inexperienced in the standards process, so keep >that in mind when reading my comments. If my comments are unclear, please let me know and I'll elaborate. >One of SPFbis' efforts will be to publish data detailing current >operational characteristics of SPF & SenderID (the document Dave >Crocker mentioned), and said data will inform SPFbis. As has been >mentioned, it's not terribly interesting (to me, anyway) what >happens with RFCs 4406 & 4407. draft-kitterman-4408bis will obsolete RFC 4408 and according to the proposed charter will be published as a Proposed Standard. >Having now given draft-mehnle-spf-scope a first read, my hope that >what it essentially proposes (inclusion of some number of RFC5322 >headers as authenticatable identities) Yes. > finds its way into SPFbis, and that doing so is supported by > operational data. I've seen this to be true anecdotally, but want > it out there in published form with data from multiple receivers, > senders, etc. included in the analysis. I prefer not to comment on this during the chartering discussion as it might end up being controversial. At 23:05 01-12-2011, Paul Midgen wrote: >Murray and I have had some discussion on this prior to starting >SPFbis, and the work is already in progress - though my contribution >to it won't be ready for some months, since I'm constrained by my >current ability to gather all the data I want. > >So - before we start editing and circulating documents, we should >first have a discussion on what all our thoughts/expectations are. Good idea. I am ok with whatever the consensus is for the "conclusions" draft. This mailing list has been quiet which is unusual for a fora where SPF and Sender-ID is mentioned. It's better to have the above-mentioned discussion after the working group is chartered as there will be a WG chair to deal with the controversies. Regards, -sm From julian@mehnle.net Fri Dec 2 16:58:29 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9606311E80C3 for ; Fri, 2 Dec 2011 16:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-z6rykHtlLe for ; Fri, 2 Dec 2011 16:58:29 -0800 (PST) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1599111E8083 for ; Fri, 2 Dec 2011 16:58:28 -0800 (PST) Received: from [10.0.2.15] (50-0-128-85.dsl.dynamic.sonic.net [::ffff:50.0.128.85]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Sat, 03 Dec 2011 00:58:27 +0000 id 000000000061BE3D.000000004ED97433.00006FA1 From: Julian Mehnle To: spfbis@ietf.org Date: Sat, 3 Dec 2011 00:58:24 +0000 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2003367.RdaCWD7RrF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112030058.24946.julian@mehnle.net> Subject: [spfbis] draft-mehnle-spf(bis)-scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 00:58:29 -0000 --nextPart2003367.RdaCWD7RrF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, let me introduce the "draft-mehnle-spf(bis)-scope" document. The document's introduction section should make the intent sufficiently=20 clear, but in very few words: SPF does not prevent the most relevant types e-mail phishing because it=20 protects only the MAIL FROM identity, which is usually not exposed to the=20 user by MUAs. Sender ID tried to accomplish this by making the "From"=20 header field subject of the authentication, but made two grave mistakes:=20 (1) it allowed other identities that also aren't exposed to the user=20 =E2=80=94 "Resent-{From,Sender}" =E2=80=94 to take precedence over "From", = opening up a=20 loophole, and (2) it broke compatibility with existing "v=3Dspf1" policies= =20 by reusing them in an unexpected context. The proposed "scope" extension avoids both of these mistakes, allowing=20 domain owners to *opt in* to authentication of their domain in the "From"=20 header field against "v=3Dspf1" policies. The importance of this extension lies in the need of large e-mail senders=20 and receivers (secret cabal alert! the background will become public in a few days!) for a path-based mechanism for authenticating the "From" header field for certain (typically customer communication) types of e-mail=20 domains. SPF is widely deployed at these large e-mail senders and=20 receivers and lends itself well to the problem =E2=80=94 except for the fac= t that=20 there is no standards-compliant and compatible way to apply it to the "From" header field. This extension seeks to provide it. I unconsciously submitted the document as draft-mehnle-spf-scope rather than draft-mehnle-spfbis-scope Should I resubmit it under the latter name, which it is also being=20 referred to as by the draft charter? =2DJulian --nextPart2003367.RdaCWD7RrF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk7ZdDAACgkQwL7PKlBZWjuC1gCgmR3RdbnI7/mrsfh5puaiSB18 P2cAn2PmOveXCLWGAKAFgkoe8a7FHu+u =NqCJ -----END PGP SIGNATURE----- --nextPart2003367.RdaCWD7RrF-- From julian@mehnle.net Fri Dec 2 17:03:13 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005A111E80C8 for ; Fri, 2 Dec 2011 17:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoEXd3fjnyqk for ; Fri, 2 Dec 2011 17:03:12 -0800 (PST) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA6311E8083 for ; Fri, 2 Dec 2011 17:03:12 -0800 (PST) Received: from [10.0.2.15] (50-0-128-85.dsl.dynamic.sonic.net [::ffff:50.0.128.85]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Sat, 03 Dec 2011 01:03:10 +0000 id 000000000009908F.000000004ED9754E.000070A9 From: Julian Mehnle To: spfbis@ietf.org Date: Sat, 3 Dec 2011 01:03:08 +0000 User-Agent: KMail/1.9.9 References: <6.2.5.6.2.20111130134620.0caeabd0@resistor.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12485014.1iJgqzHnjJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112030103.08140.julian@mehnle.net> Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 01:03:13 -0000 --nextPart12485014.1iJgqzHnjJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Murray S. Kucherawy wrote: > SM wrote: > > > BTW, where's the draft-mehnle-spfbis-scope document? > > I've contacted the author, and now his boss, to remind him to post it.=20 > :-) As usual, I'm participating in the IETF as an individual and am not acting= =20 on behalf of my employer. They're not even paying me to do this. =2DJulian --nextPart12485014.1iJgqzHnjJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk7ZdUwACgkQwL7PKlBZWjsxYgCfRVRmdS2UrE9JkcOQt7vboF+H 5CMAn0yxmbf0Yf3iX2TgMZ1GbAhpPYj1 =L//6 -----END PGP SIGNATURE----- --nextPart12485014.1iJgqzHnjJ-- From julian@mehnle.net Fri Dec 2 17:14:19 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C191911E80AE for ; Fri, 2 Dec 2011 17:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lsDszcdIq0V for ; Fri, 2 Dec 2011 17:14:19 -0800 (PST) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id 40CE811E8083 for ; Fri, 2 Dec 2011 17:14:19 -0800 (PST) Received: from [10.0.2.15] (50-0-128-85.dsl.dynamic.sonic.net [::ffff:50.0.128.85]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Sat, 03 Dec 2011 01:14:17 +0000 id 000000000009908F.000000004ED977E9.00007185 From: Julian Mehnle To: spfbis@ietf.org Date: Sat, 3 Dec 2011 01:14:15 +0000 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4904605.Pspc2JYshF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112030114.15300.julian@mehnle.net> Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 01:14:19 -0000 --nextPart4904605.Pspc2JYshF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Murray S. Kucherawy wrote: > Hello all, and welcome to the SPFbis mailing list. > > As usual, our first order of business is to hash out a charter for the > working group. Many of you have already seen it privately, and it was > circulated and discussed briefly within the APPS area working group > session in Taipei and its mailing list. Attached is the latest > version, a product of all of the above. Thanks for setting up the list and organizing the effort so far, Murray! > So the usual questions: > > - Does this charter capture an accurate description of the problem to be > solved (in our case, it's really the work to be done)?=20 > > - Is the charter appropriately broad and/or limited in scope? I agree with the version of the charter that Murray posted on 2011-11-30. > - Who is willing to review and comment on documents in the working > group?=20 I'm willing to review, and comment on, all documents that this WG=20 produces. > - Who is willing to act as document editor(s)? If the "scope" modifier doc ends up being in-scope (haha! sorry!) for this= =20 WG, I'm willing to act as an editor for it. I'm willing to act as a co-editor for the main 4408bis document as well,=20 but I'm severely time-constrained, so I will commit to it only if there=20 aren't enough volunteers. (Whatever it takes, but not a lot more.) > - Who is likely to implement (or, since SPF is already out there, who is > likely to update their implementations to match any changes in the > specs) and participate in interoperability testing? I will update the Mail::SPF Perl library (which I wrote and which has no=20 known deviations from RFC 4408) as necessary as this WG progresses. Like Scott Kitterman, I'm also willing to work on updating the SPF test=20 suite. =2DJulian --nextPart4904605.Pspc2JYshF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk7Zd+cACgkQwL7PKlBZWjtXoACdHzpJi9jSZWRS/ys8TkPw+wJX eFEAn0DYFyzKktSiZARNV654bQt8jJSS =Ukcu -----END PGP SIGNATURE----- --nextPart4904605.Pspc2JYshF-- From sm@resistor.net Fri Dec 2 20:42:09 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A36D1F0C52 for ; Fri, 2 Dec 2011 20:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWRMwJeOAeHj for ; Fri, 2 Dec 2011 20:42:08 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7065E1F0C4E for ; Fri, 2 Dec 2011 20:42:08 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB34fraE007652; Fri, 2 Dec 2011 20:41:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1322887321; bh=zTxaVLGpnwSQy6zf+5SuDyjpKEyQtuywvIOoGZglaGI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=oPK8CF2IlsPBnGW/ZUumWgnZy8Gk6CKiBmXT+5C4eq3D+l8vlgUkSiVNIwgQ7Wn0U YEXy/6KBSzeY1EB2DwBbOoal8d/i/Qd42akHhs06/ootEmPzr/FsTOaI9xg7pQgw9I lXlrjFJuNs+fOH0PreeIZLAylxjO49rCCXun+u84= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1322887321; bh=zTxaVLGpnwSQy6zf+5SuDyjpKEyQtuywvIOoGZglaGI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=zYdtQ3kkqhma2EsOlrYMG6eotVaxgpEUg+Ecrco+bh/0zkeLlUDoZ+/vP22cG2ieH eA1JynxfsK27Rr7oAUh9eDNVUQ84uiq8zBSpgTSQ90R4vp8bnEUXY7oqNglcdxmVSc P51v0tsfCYjpc1ChekJcMnUqpMO0ALescP46vtGw= Message-Id: <6.2.5.6.2.20111202200818.0a770c20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 02 Dec 2011 20:12:58 -0800 To: Julian Mehnle From: SM In-Reply-To: <201112030058.24946.julian@mehnle.net> References: <201112030058.24946.julian@mehnle.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 04:42:09 -0000 Hi Julian, At 16:58 02-12-2011, Julian Mehnle wrote: >let me introduce the "draft-mehnle-spf(bis)-scope" document. > >The document's introduction section should make the intent sufficiently >clear, but in very few words: > >SPF does not prevent the most relevant types e-mail phishing because it >protects only the MAIL FROM identity, which is usually not exposed to the >user by MUAs. Sender ID tried to accomplish this by making the "From" >header field subject of the authentication, but made two grave mistakes: >(1) it allowed other identities that also aren't exposed to the user >=97 "Resent-{From,Sender}" =97 to take precedence over "From", ", opening= up a >loophole, and (2) it broke compatibility with existing "v=3Dspf1" policies >by reusing them in an unexpected context. Thanks for the clarifications about the=20 document. I suggest not getting into a=20 discussion about the technical content while the charter is being discussed. >I unconsciously submitted the document as > > draft-mehnle-spf-scope > >rather than > > draft-mehnle-spfbis-scope > >Should I resubmit it under the latter name, which it is also being >referred to as by the draft charter? The draft will be renamed once is it is adopted=20 as a working group document. The name could be changed then. Regards, -sm=20 From dhc2@dcrocker.net Fri Dec 2 22:43:09 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351FA11E8081 for ; Fri, 2 Dec 2011 22:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlYPQBzBfVkl for ; Fri, 2 Dec 2011 22:43:08 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52811E8073 for ; Fri, 2 Dec 2011 22:43:08 -0800 (PST) Received: from [192.168.2.75] (rrcs-76-79-242-189.west.biz.rr.com [76.79.242.189]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pB36h0bo020297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 22:43:07 -0800 Message-ID: <4ED9C4E4.5020309@dcrocker.net> Date: Fri, 02 Dec 2011 22:42:44 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <201112030058.24946.julian@mehnle.net> <6.2.5.6.2.20111202200818.0a770c20@resistor.net> In-Reply-To: <6.2.5.6.2.20111202200818.0a770c20@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 02 Dec 2011 22:43:07 -0800 (PST) Cc: Julian Mehnle Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 06:43:09 -0000 Folks, On 12/2/2011 8:12 PM, SM wrote: > The draft will be renamed once is it is adopted as a working group document. > The name could be changed then. If the working group's initial goal is to develop a standards-track version of SPF, then it needs to focus on this task and vigorously avoid activities that distract from the goal. For an existing specification with widespread deployment, the standards effort needs the focus to be on stabilizing and refining specification for what is already deployed. It should not simultaneously enhance the functionality provided in the specification. As a consequence the working group charter should not provide for enhancements. Once the initial standards-track specification is approved, the working group can recharter for pursuing enhancements. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pmidge@microsoft.com Sat Dec 3 00:25:59 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9099021F8E3A for ; Sat, 3 Dec 2011 00:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7R-qDBIELkf for ; Sat, 3 Dec 2011 00:25:58 -0800 (PST) Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1021F8E4F for ; Sat, 3 Dec 2011 00:25:58 -0800 (PST) Received: from mail138-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Sat, 3 Dec 2011 08:25:57 +0000 Received: from mail138-va3 (localhost [127.0.0.1]) by mail138-va3-R.bigfish.com (Postfix) with ESMTP id 1C9744C060D; Sat, 3 Dec 2011 08:25:57 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zzbb2dK9371K542M1432N98dKzz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail138-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail138-va3 (localhost.localdomain [127.0.0.1]) by mail138-va3 (MessageSwitch) id 1322900756879993_31169; Sat, 3 Dec 2011 08:25:56 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.249]) by mail138-va3.bigfish.com (Postfix) with ESMTP id C58DC600044; Sat, 3 Dec 2011 08:25:56 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sat, 3 Dec 2011 08:25:57 +0000 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.192]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Sat, 3 Dec 2011 00:25:54 -0800 From: Paul Midgen To: "dcrocker@bbiw.net" , "spfbis@ietf.org" Thread-Topic: [spfbis] draft-mehnle-spf(bis)-scope Thread-Index: AQHMsVauFTvSub3Bz0SCXkfICEK525XKBxwAgAAp2AD//5Fy0A== Date: Sat, 3 Dec 2011 08:25:53 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E2042BF0C@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <201112030058.24946.julian@mehnle.net> <6.2.5.6.2.20111202200818.0a770c20@resistor.net> <4ED9C4E4.5020309@dcrocker.net> In-Reply-To: <4ED9C4E4.5020309@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Julian Mehnle Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 08:25:59 -0000 We need to align on our definition of "standards track SPF". def #1: clean up 4408, making deletions or clarifications only (I'm opting = for brevity over 100% correctness) def #2: clean up 4408, making whatever modifications are necessary to refle= ct path authorization as it is done in practice. This implies additions as = well as the deletions/clarifications in #1. I'm more attracted to #2 because (from a receiver/webmail provider POV) I n= eed the standard to enable me to legally test path authorization of the RFC= 5322.From domain, and I feel this gets us there sooner. I do understand that from an IETF process perspective this may be the wrong= way to do it, so in the spirit of "vision over implementation" I'm open to= a WG charter that explicitly states #2 or commits us to #1, followed by th= e work to achieve #2 in whatever manner supported by operational data. > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > Of Dave CROCKER > Sent: Friday, December 02, 2011 10:43 PM > To: spfbis@ietf.org > Cc: Julian Mehnle > Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope >=20 > Folks, >=20 > On 12/2/2011 8:12 PM, SM wrote: > > The draft will be renamed once is it is adopted as a working group > document. > > The name could be changed then. >=20 >=20 > If the working group's initial goal is to develop a standards-track versi= on of > SPF, then it needs to focus on this task and vigorously avoid activities = that > distract from the goal. >=20 > For an existing specification with widespread deployment, the standards > effort needs the focus to be on stabilizing and refining specification fo= r what > is already deployed. It should not simultaneously enhance the functional= ity > provided in the specification. >=20 > As a consequence the working group charter should not provide for > enhancements. >=20 > Once the initial standards-track specification is approved, the working g= roup > can recharter for pursuing enhancements. >=20 > d/ > -- >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From msk@cloudmark.com Sat Dec 3 00:36:08 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0635321F8F5D for ; Sat, 3 Dec 2011 00:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq7YvuBfmAC8 for ; Sat, 3 Dec 2011 00:36:07 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5A221F8F57 for ; Sat, 3 Dec 2011 00:36:07 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 3 Dec 2011 00:36:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 3 Dec 2011 00:36:06 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Sat, 3 Dec 2011 00:36:10 -0800 Thread-Topic: [spfbis] draft-mehnle-spf(bis)-scope Thread-Index: AcyxVq0dnqrswkiOSOqqQW4ml3HcZQAP92bw Message-ID: References: <201112030058.24946.julian@mehnle.net> In-Reply-To: <201112030058.24946.julian@mehnle.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 08:36:08 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcGZiaXMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVsaWFu IE1laG5sZQ0KPiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDAyLCAyMDExIDQ6NTggUE0NCj4gVG86 IHNwZmJpc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbc3BmYmlzXSBkcmFmdC1tZWhubGUtc3BmKGJp cyktc2NvcGUNCj4gDQo+IEkgdW5jb25zY2lvdXNseSBzdWJtaXR0ZWQgdGhlIGRvY3VtZW50IGFz DQo+IA0KPiAgICAgZHJhZnQtbWVobmxlLXNwZi1zY29wZQ0KPiANCj4gcmF0aGVyIHRoYW4NCj4g DQo+ICAgICBkcmFmdC1tZWhubGUtc3BmYmlzLXNjb3BlDQo+IA0KPiBTaG91bGQgSSByZXN1Ym1p dCBpdCB1bmRlciB0aGUgbGF0dGVyIG5hbWUsIHdoaWNoIGl0IGlzIGFsc28gYmVpbmcNCj4gcmVm ZXJyZWQgdG8gYXMgYnkgdGhlIGRyYWZ0IGNoYXJ0ZXI/DQoNCk5vIG5lZWQ7IGlmL3doZW4gaXQg YmVjb21lcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbSwgaXQgd2lsbCBiZSByZW5hbWVkIGFueXdheS4N Cg== From msk@cloudmark.com Sat Dec 3 00:48:59 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B4121F9118 for ; Sat, 3 Dec 2011 00:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.678 X-Spam-Level: X-Spam-Status: No, score=-102.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-fTg8T7XEDF for ; Sat, 3 Dec 2011 00:48:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 49BEA21F8DA8 for ; Sat, 3 Dec 2011 00:48:59 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 3 Dec 2011 00:48:59 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 3 Dec 2011 00:48:58 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Sat, 3 Dec 2011 00:49:02 -0800 Thread-Topic: [spfbis] draft-mehnle-spf(bis)-scope Thread-Index: AcyxhtrOV2AZm2M3Ro+h5CRx3HMB6wAD9kUg Message-ID: References: <201112030058.24946.julian@mehnle.net> <6.2.5.6.2.20111202200818.0a770c20@resistor.net> <4ED9C4E4.5020309@dcrocker.net> In-Reply-To: <4ED9C4E4.5020309@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 08:48:59 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dave CROCKER > Sent: Friday, December 02, 2011 10:43 PM > To: spfbis@ietf.org > Cc: Julian Mehnle > Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope >=20 > As a consequence the working group charter should not provide for > enhancements. >=20 > Once the initial standards-track specification is approved, the working > group can recharter for pursuing enhancements. This appears to contradict your earlier [1] sentiments that the proposed ch= arter, which does include Julian's draft, is satisfactory. It is, however,= the only extension in scope for the initial charter we're discussing; the = proposed charter proscribes all others. As I've said before, I don't know how painful or painless a re-chartering c= an be. If it's "easy", then I'd be fine with removing it for now. But sin= ce it has some momentum behind it, we can possibly save ourselves that step= simply by leaving the charter as-is and being diligent about tackling our = few deliverables in sequence as much as possible. I'm up for it. -MSK [1] http://www.ietf.org/mail-archive/web/spfbis/current/msg00009.html From vesely@tana.it Sat Dec 3 11:26:22 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEA121F9309 for ; Sat, 3 Dec 2011 11:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSeeTHY+XApK for ; Sat, 3 Dec 2011 11:26:21 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B40ED21F9307 for ; Sat, 3 Dec 2011 11:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1322940379; bh=N2nPr0jsMUlkK2a/03q+OFMXoGKIG0Y43Y3VhUKwQm4=; l=1000; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=d8q6zApYsJIgk79P9KnUIglTtY8yW87XtfbmsDA4EDXFAyHtQOzFKApG0ObuV5X68 SCH1F4cXUikWqE516a0aa7M4ElZYoh37Jt1OWXJ9ZOvLIGNn6GICkMXhY40m6zYUe9 tzY2VG+1Krzmse1D9DSI0hTnnLTgxrzNEkoomWJM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 03 Dec 2011 20:26:19 +0100 id 00000000005DC03F.000000004EDA77DB.00005BD7 Message-ID: <4EDA77DB.704@tana.it> Date: Sat, 03 Dec 2011 20:26:19 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 19:26:22 -0000 On 30/Nov/11 21:01, Murray S. Kucherawy wrote: > > - Does this charter capture an accurate description of the > problem to be solved (in our case, it’s really the work to be done)? > > - Is the charter appropriately broad and/or limited in scope? One way to further constrain the charter would be to explicitly mention "v=spf1" either in the relevant milestone or in the "Changes to the SPF specification" paragraph. For the scope document, IMHO it would be better to concentrate on checking and enforcing rather than extending the syntax. Some receivers already check 5322.from either as a further restriction or inclusively, e.g. http://www.courier-mta.org/courier.html#SPF By allowing this point to be managed by domain owners, we limit what receivers can do. I also heard of verifiers who assume an MX/24 for domains that have no SPF record. Should these uses be documented? jm2c > - Who is willing to review and comment on documents in the > working group? +1 From dotzero@gmail.com Sat Dec 3 12:02:06 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5805821F939B for ; Sat, 3 Dec 2011 12:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8Y4FsUGFNMm for ; Sat, 3 Dec 2011 12:02:05 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCF1E21F9398 for ; Sat, 3 Dec 2011 12:02:05 -0800 (PST) Received: by dadv40 with SMTP id v40so3652140dad.31 for ; Sat, 03 Dec 2011 12:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=E6iBSeEBeOxnrXenz+9nYOvVQTvP2bBKnRNdRfFePuY=; b=Q3hVmgKYklOVHOVYEx9/MrGeeowdQid0HDvkDLN6u3OUB7G5EQDmq2CMkMFHCdAER4 Z62EuecRdv7JKn8O/nKdK8dYWI/EhOm3CiNqCO2IIPHvtHZ8pTSEvH8i1KW0TGnX7A/s TRp35HvPdN6DaBSddJUW94iHF1oQ0qutkrZDE= MIME-Version: 1.0 Received: by 10.68.37.2 with SMTP id u2mr8053544pbj.56.1322942523600; Sat, 03 Dec 2011 12:02:03 -0800 (PST) Received: by 10.142.223.5 with HTTP; Sat, 3 Dec 2011 12:02:03 -0800 (PST) In-Reply-To: References: <201112030058.24946.julian@mehnle.net> <6.2.5.6.2.20111202200818.0a770c20@resistor.net> <4ED9C4E4.5020309@dcrocker.net> Date: Sat, 3 Dec 2011 15:02:03 -0500 Message-ID: From: Dotzero To: "spfbis@ietf.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 20:02:06 -0000 On Sat, Dec 3, 2011 at 3:49 AM, Murray S. Kucherawy wro= te: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf= Of Dave CROCKER >> Sent: Friday, December 02, 2011 10:43 PM >> To: spfbis@ietf.org >> Cc: Julian Mehnle >> Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope >> >> As a consequence the working group charter should not provide for >> enhancements. >> >> Once the initial standards-track specification is approved, the working >> group can recharter for pursuing enhancements. > > This appears to contradict your earlier [1] sentiments that the proposed = charter, which does include Julian's draft, is satisfactory. =A0It is, howe= ver, the only extension in scope for the initial charter we're discussing; = the proposed charter proscribes all others. > > As I've said before, I don't know how painful or painless a re-chartering= can be. =A0If it's "easy", then I'd be fine with removing it for now. =A0B= ut since it has some momentum behind it, we can possibly save ourselves tha= t step simply by leaving the charter as-is and being diligent about tacklin= g our few deliverables in sequence as much as possible. =A0I'm up for it. > > -MSK > > [1] http://www.ietf.org/mail-archive/web/spfbis/current/msg00009.html > I don't know if this is considered an enhncement or a refinement but someone from US Cert recently passed the following comment to me regarding SPF: "When the RFC is revised for the next version of SPF, would you mind asking them to include language that specifies what delimiters are appropriate for use in an SPF record? I=92ve seen tabs, spaces, cr, lf, and pipes while scanning some domains." -Mike From julian@mehnle.net Sat Dec 3 14:13:39 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFE021F8DA0 for ; Sat, 3 Dec 2011 14:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34dqpgm7gz-T for ; Sat, 3 Dec 2011 14:13:39 -0800 (PST) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2688321F8D88 for ; Sat, 3 Dec 2011 14:13:38 -0800 (PST) Received: from [10.0.2.15] (50-0-128-85.dsl.dynamic.sonic.net [::ffff:50.0.128.85]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Sat, 03 Dec 2011 22:13:37 +0000 id 00000000203C7EF9.000000004EDA9F11.00006C89 From: Julian Mehnle To: spfbis@ietf.org Date: Sat, 3 Dec 2011 22:13:31 +0000 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1654633.7kmelXlMlz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112032213.35169.julian@mehnle.net> Subject: [spfbis] 4408bis clarifications (was: draft-mehnle-spf(bis)-scope) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 22:13:39 -0000 --nextPart1654633.7kmelXlMlz Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dotzero wrote: > I don't know if this is considered an enhncement or a refinement but > someone from US Cert recently passed the following comment to me > regarding SPF: > > "When the RFC is revised for the next version of SPF, would you mind > asking them to include language that specifies what delimiters are > appropriate for use in an SPF record? I=92ve seen tabs, spaces, cr, lf, > and pipes while scanning some domains." It would be a clarification, most likely in scope of SPFbis. However, RFC= =20 4408 already specifies=20 this: record =3D version terms *SP version =3D "v=3Dspf1" terms =3D *( 1*SP ( directive / modifier ) ) So terms (mechanisms or modifiers) are separated by one or more SP, which=20 is defined by RFC 4234 : SP =3D %x20 It could be made clearer in 4408bis, of course. =2DJulian --nextPart1654633.7kmelXlMlz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk7anwsACgkQwL7PKlBZWjsJIACg1Pu4zOvrFFeSiUx4GMTJjVvP T/0An15GupPRqCYZlu/FEwCs95DxD4cn =iprP -----END PGP SIGNATURE----- --nextPart1654633.7kmelXlMlz-- From julian@mehnle.net Sat Dec 3 14:49:52 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4036621F93A3 for ; Sat, 3 Dec 2011 14:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt4e8N0wnbom for ; Sat, 3 Dec 2011 14:49:51 -0800 (PST) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA9321F939F for ; Sat, 3 Dec 2011 14:49:51 -0800 (PST) Received: from [10.0.2.15] (50-0-128-85.dsl.dynamic.sonic.net [::ffff:50.0.128.85]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Sat, 03 Dec 2011 22:49:47 +0000 id 00000000203C7EC1.000000004EDAA78B.00006FC0 From: Julian Mehnle To: spfbis@ietf.org Date: Sat, 3 Dec 2011 22:49:45 +0000 User-Agent: KMail/1.9.9 References: <4EDA77DB.704@tana.it> In-Reply-To: <4EDA77DB.704@tana.it> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2609306.E3XqOESKff"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112032249.45316.julian@mehnle.net> Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 22:49:52 -0000 --nextPart2609306.E3XqOESKff Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Alessandro Vesely wrote: > For the scope document, IMHO it would be better to concentrate on > checking and enforcing rather than extending the syntax. Some > receivers already check 5322.from either as a further restriction or > inclusively, e.g. http://www.courier-mta.org/courier.html#SPF By > allowing this point to be managed by domain owners, we limit what > receivers can do. Receivers will always do whatever they want. A standards document like=20 4408bis, however, must consider compatibility and predictability. As an analog, RFCs 974/1035 clearly define the semantics of DNS "MX"=20 records, with good reason. Would you claim this (unduly) limits what=20 users of MX records can do? Should RFCs 974/1035 be revised to allow=20 frequent abuses of MX records, such as ignoring the MX preference value=20 and submitting mail (spam) only to the MX with the *highest* preference,=20 just so these RFCs don't limit what users of MX records can do? > I also heard of verifiers who assume an MX/24 for domains that have no > SPF record. Should these uses be documented? This is known as "best guess" and is non-standard practice =E2=80=94 probab= ly not=20 even best practice: =2DJulian --nextPart2609306.E3XqOESKff Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk7ap4kACgkQwL7PKlBZWjt2ywCglraoM5KPYwXiBiv241tnd4+L yUoAoPLCoKJiWU5uNnOmos7Y+Siie4DC =dk77 -----END PGP SIGNATURE----- --nextPart2609306.E3XqOESKff-- From spf2@kitterman.com Sat Dec 3 16:04:02 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905D51F0C35 for ; Sat, 3 Dec 2011 16:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lhUPo865f06 for ; Sat, 3 Dec 2011 16:04:01 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id D219521F9387 for ; Sat, 3 Dec 2011 16:04:01 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 515F8D04091; Sat, 3 Dec 2011 18:03:59 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1322957039; bh=LfAJLQscO/KoPwqJ4Cl/oPab6pxmLU25JuSgpQKU85M=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=pwOat5AbwgwoSGN4+1BQV8XDNGR1xBlgN3vv6ySVoSeUDWVEbvpi4F0LN8Tqc6RUO 5/ocP5FgaL1l30/z5cHXTM39gp9fgkcvso3qANU3h8OAmIvZutQft2X1Psd23macaL /yv2eVQ80WNMHG+ooxLNQG59dR+l5heL14j0MJCE= Received: from 52.sub-97-10-129.myvzw.com (52.sub-97-10-129.myvzw.com [97.10.129.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D4440D0404D; Sat, 3 Dec 2011 18:03:58 -0600 (CST) References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> User-Agent: K-9 Mail for Android In-Reply-To: <201112032249.45316.julian@mehnle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 03 Dec 2011 19:03:57 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 00:04:02 -0000 Julian Mehnle wrote: >Alessandro Vesely wrote: > >> For the scope document, IMHO it would be better to concentrate on >> checking and enforcing rather than extending the syntax. Some >> receivers already check 5322.from either as a further restriction or >> inclusively, e.g. http://www.courier-mta.org/courier.html#SPF By >> allowing this point to be managed by domain owners, we limit what >> receivers can do. > >Receivers will always do whatever they want. A standards document like > >4408bis, however, must consider compatibility and predictability. > >As an analog, RFCs 974/1035 clearly define the semantics of DNS "MX" >records, with good reason. Would you claim this (unduly) limits what >users of MX records can do? Should RFCs 974/1035 be revised to allow >frequent abuses of MX records, such as ignoring the MX preference value > >and submitting mail (spam) only to the MX with the *highest* >preference, >just so these RFCs don't limit what users of MX records can do? > >> I also heard of verifiers who assume an MX/24 for domains that have >no >> SPF record. Should these uses be documented? > >This is known as "best guess" and is non-standard practice — probably >not >even best practice: . This practice was known when RFC 4408 was developed and there was a strong consensus that it was not appropriate to standardize it. I can't think of a good reason to consider it differently now. Scott K From spf2@kitterman.com Sat Dec 3 18:52:52 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7AB11E807F for ; Sat, 3 Dec 2011 18:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqcZqauI78qn for ; Sat, 3 Dec 2011 18:52:52 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 48A3821F8DAD for ; Sat, 3 Dec 2011 18:52:52 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4EDC020E409F; Sat, 3 Dec 2011 21:52:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1322967170; bh=C4C3zmM6t6jnDxyoqNmWrJ2HAORKLsJ7IhH7PqKL+DQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NDssUzBv59tRGs2XLZz2X1/4LvqlCKdcqCBoiAP/f7D16yXWsUtx3NWy5ytAsBAIt ixe+UOkQTgEP4BLL8RDKwpV+df9i9ulX9/aUizJVsXuHjEec3Wa1dAZ2ePmPSMUC+u Mvdp+WA4zrfUd3rjEEQ/Pz8a8qZnrUPieGSSAMks= Received: from [192.168.111.113] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2EBB320E4084; Sat, 3 Dec 2011 21:52:50 -0500 (EST) Message-ID: <4EDAE081.4070208@kitterman.com> Date: Sat, 03 Dec 2011 21:52:49 -0500 From: Scott Kitterman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <201112030058.24946.julian@mehnle.net> <6.2.5.6.2.20111202200818.0a770c20@resistor.net> <4ED9C4E4.5020309@dcrocker.net> In-Reply-To: <4ED9C4E4.5020309@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 02:52:53 -0000 On 12/03/2011 01:42 AM, Dave CROCKER wrote: > Folks, > > On 12/2/2011 8:12 PM, SM wrote: >> The draft will be renamed once is it is adopted as a working group >> document. >> The name could be changed then. > > > If the working group's initial goal is to develop a standards-track > version of SPF, then it needs to focus on this task and vigorously avoid > activities that distract from the goal. > > For an existing specification with widespread deployment, the standards > effort needs the focus to be on stabilizing and refining specification > for what is already deployed. It should not simultaneously enhance the > functionality provided in the specification. > > As a consequence the working group charter should not provide for > enhancements. > > Once the initial standards-track specification is approved, the working > group can recharter for pursuing enhancements. I think we can manage the prioritization of the work by giving the one proposed extension a spot on the schedule enough after 4408bis to make it clear where the priority is. I think there is enough interest in both efforts that we can afford some degree of parallelism in the process. Scott K From msk@cloudmark.com Sun Dec 4 11:10:35 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D7C21F8507 for ; Sun, 4 Dec 2011 11:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.672 X-Spam-Level: X-Spam-Status: No, score=-102.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZLE5O2Q3lKJ for ; Sun, 4 Dec 2011 11:10:34 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6A11321F84F9 for ; Sun, 4 Dec 2011 11:10:34 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 4 Dec 2011 11:09:59 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Sun, 4 Dec 2011 11:10:03 -0800 Thread-Topic: [spfbis] SPFBIS proposed charter Thread-Index: AcyyDeLhKLDXdWgTTviwIonbhjiUfgAqlJOQ Message-ID: References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> In-Reply-To: <201112032249.45316.julian@mehnle.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 19:10:35 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcGZiaXMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVsaWFu IE1laG5sZQ0KPiBTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMDMsIDIwMTEgMjo1MCBQTQ0KPiBU bzogc3BmYmlzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc3BmYmlzXSBTUEZCSVMgcHJvcG9z ZWQgY2hhcnRlcg0KPiANCj4gPiBJIGFsc28gaGVhcmQgb2YgdmVyaWZpZXJzIHdobyBhc3N1bWUg YW4gTVgvMjQgZm9yIGRvbWFpbnMgdGhhdCBoYXZlIG5vDQo+ID4gU1BGIHJlY29yZC4gIFNob3Vs ZCB0aGVzZSB1c2VzIGJlIGRvY3VtZW50ZWQ/DQo+IA0KPiBUaGlzIGlzIGtub3duIGFzICJiZXN0 IGd1ZXNzIiBhbmQgaXMgbm9uLXN0YW5kYXJkIHByYWN0aWNlIOKAlCBwcm9iYWJseQ0KPiBub3Qg ZXZlbiBiZXN0IHByYWN0aWNlOiA8aHR0cDovL3d3dy5vcGVuc3BmLm5ldC9GQVEvQmVzdF9ndWVz c19yZWNvcmQ+DQoNCkkgd291bGQgYmUgY29tZm9ydGFibGUgd2l0aCBkb2N1bWVudGluZyAiQmVz dCBQcmFjdGljZSBTUEYiIGluIGEgbm9uLW5vcm1hdGl2ZSBhcHBlbmRpeC4gIEl0J3MgY29tbW9u IGVub3VnaCB0aGF0IGl0IHNob3VsZCBiZSB3cml0dGVuIGRvd24gc29tZXBsYWNlIHBlcm1hbmVu dCwgbGlrZSB0aGUgYmFjayBvZiBhbiBSRkMuDQo= From SRS0=2ufxB=6R==stuart@gathman.org Sun Dec 4 18:16:37 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CC621F84CD for ; Sun, 4 Dec 2011 18:16: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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLlZJpIJNnt4 for ; Sun, 4 Dec 2011 18:16:36 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4021F84AD for ; Sun, 4 Dec 2011 18:16:36 -0800 (PST) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id pB52FtGU018405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 4 Dec 2011 21:16:00 -0500 Message-ID: <4EDC297C.6030209@gathman.org> Date: Sun, 04 Dec 2011 21:16:28 -0500 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 02:34:22 -0000 Long ago, Nostradamus foresaw that on 12/04/2011 02:10 PM, Murray S. Kucherawy would write: >>> I also heard of verifiers who assume an MX/24 for domains that have no >>> SPF record. Should these uses be documented? >> This is known as "best guess" and is non-standard practice — probably >> not even best practice: > I would be comfortable with documenting "Best Practice SPF" in a non-normative appendix. It's common enough that it should be written down someplace permanent, like the back of an RFC. I use "best guess", and find it very useful, *however* spfbis should explicitly mention that such results should not be reported as SPF results in Received-SPF or Authentication-Results headers. I report them as x-bestguess= in Received-SPF. From tim@eudaemon.net Sun Dec 4 21:44:29 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED1A1F0C47 for ; Sun, 4 Dec 2011 21:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGkdKu4ZYYXj for ; Sun, 4 Dec 2011 21:44:29 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 97FE31F0C34 for ; Sun, 4 Dec 2011 21:44:27 -0800 (PST) Received: from [192.168.0.102] (c-76-102-21-44.hsd1.ca.comcast.net [76.102.21.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id AEA10CB62 for ; Mon, 5 Dec 2011 00:44:27 -0500 (EST) From: Tim Draegen Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_828CBCE8-49B0-4092-825B-805BC8F7CC4B" Date: Sun, 4 Dec 2011 10:02:56 -0500 In-Reply-To: To: spfbis@ietf.org References: Message-Id: <6288C116-CF23-4A94-9878-DF5C3416A2AB@eudaemon.net> X-Mailer: Apple Mail (2.1251.1) Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 05:44:30 -0000 --Apple-Mail=_828CBCE8-49B0-4092-825B-805BC8F7CC4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I'm writing in support of, and to support, this work. Comments = in-line.. On Nov 30, 2011, at 3:01 PM, Murray S. Kucherawy wrote: > So the usual questions: > =20 > - Does this charter capture an accurate description of the = problem to be solved (in our case, it=92s really the work to be done)? In my professional life, the fact that SPF is Experimental acts as a = minor deployment barrier. Changing this would be most helpful as I = travel around attempting to get more folks to deploy. > - Is the charter appropriately broad and/or limited in scope? The charter looks just right to me, including Julian's extension. You = can take my view with a grain of salt, though, as Julian and I work at = the same company. > - Who is willing to review and comment on documents in the = working group? Glad to. > - Who is willing to act as document editor(s)? Can't be me, as I'm limited in time and hope to contribute in a = different area... see below. > - Who is likely to implement (or, since SPF is already out = there, who is likely to update their implementations to match any = changes in the specs) and participate in interoperability testing? I'd like to bring to the Working Group a different resource. My = company, Agari - formerly Authentication Metrics - has amassed a = significant amount of real-world data pertaining to SPF and SenderID -- = including sources of messages, verification-check results, SPF records, = the domains under verification.. HELO, MFROM, = header-From/Sender/Resent-From/Resent-Sender fields, from many different = sites across the internet. I'd like to make this data available to answer questions, inform = discussion, and to help produce the best spec possible. Some examples: = How much of Sender-ID-veriified email is checking From: vs Sender: vs = Resent-From: vs Resent-Sender:? Categorically, where does the MFROM = diverge from the header-From.. and how many senders are responsible for = 90%, 50%, 25%, 10 %, etc of this behavior? What are the most common = errors found in SPF records? What happens when SPF records exceed the = size of a UDP packet? IMO, good questions directed at real-world data should go a long way in = helping move SPF out of Experimental. > - Who is willing to co-chair a working group? I can't do a good job at this due to other commitments and a desire to = participate as a contributor. Cheers, =3D- Tim --Apple-Mail=_828CBCE8-49B0-4092-825B-805BC8F7CC4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
So the usual questions:
 
          Does this = charter capture an accurate description of the problem to be solved (in = our case, it=92s really the work to be = done)?

In my professional = life, the fact that SPF is Experimental acts as a minor deployment = barrier.  Changing this would be most helpful as I travel around = attempting to get more folks to deploy.

- Is the = charter appropriately broad and/or limited in = scope?

The charter looks = just right to me, including Julian's extension.  You can take my = view with a grain of salt, though, as Julian and I work at the same = company.

- Who is = willing to review and comment on documents in the working = group?

Glad = to.

- Who is = willing to act as document = editor(s)?

Can't be me, as = I'm limited in time and hope to contribute in a different area... see = below.

- Who is likely = to implement (or, since SPF is already out there, who is likely to = update their implementations to match any changes in the specs) and = participate in interoperability = testing?

I'd like to bring = to the Working Group a different resource.  My company, Agari = - formerly Authentication Metrics - has amassed a significant = amount of real-world data pertaining to SPF and SenderID -- including = sources of messages, verification-check results, SPF records, the = domains under verification.. HELO, MFROM, = header-From/Sender/Resent-From/Resent-Sender fields, from many different = sites across the internet.

I'd like to make = this data available to answer questions, inform discussion, and to help = produce the best spec possible.  Some examples: How much of = Sender-ID-veriified email is checking From: vs Sender: vs Resent-From: = vs Resent-Sender:?  Categorically, where does the MFROM diverge = from the header-From.. and how many senders are responsible for 90%, = 50%, 25%, 10 %, etc of this behavior?  What are the most common = errors found in SPF records?  What happens when SPF records exceed = the size of a UDP packet?

IMO, good questions = directed at real-world data should go a long way in helping move SPF out = of Experimental.

- Who is = willing to co-chair a working = group?

I can't do a good job at = this due to other commitments and a desire to participate as a = contributor.

Cheers,
=3D- = Tim

= --Apple-Mail=_828CBCE8-49B0-4092-825B-805BC8F7CC4B-- From tim@eudaemon.net Sun Dec 4 21:51:31 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6BF21F84C1 for ; Sun, 4 Dec 2011 21:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY7C01+GvKFr for ; Sun, 4 Dec 2011 21:51:30 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 462FA21F84BD for ; Sun, 4 Dec 2011 21:51:30 -0800 (PST) Received: from [192.168.0.102] (c-76-102-21-44.hsd1.ca.comcast.net [76.102.21.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 652ADCB62 for ; Mon, 5 Dec 2011 00:44:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Tim Draegen In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E2042B0E4@TK5EX14MBXC202.redmond.corp.microsoft.com> Date: Sun, 4 Dec 2011 10:19:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20111130134620.0caeabd0@resistor.net> <6.2.5.6.2.20111201211727.0a155128@resistor.net> <6.2.5.6.2.20111201223320.09054ff8@resistor.net> <7F7F36E50398F84DBAF25C9D51732F1E2042B0E4@TK5EX14MBXC202.redmond.corp.microsoft.com> To: spfbis@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 05:51:31 -0000 On Dec 2, 2011, at 2:03 AM, Paul Midgen wrote: > One of SPFbis' efforts will be to publish data detailing current = operational characteristics of SPF & SenderID (the document Dave Crocker = mentioned), and said data will inform SPFbis. As has been mentioned, = it's not terribly interesting (to me, anyway) what happens with RFCs = 4406 & 4407. I can commit to working on, and providing data to back, this effort. In = my opinion, moving both SPF & SenderID in any direction out of = Experimental should leave behind documentation that describes "The = Experiment is now over, here is what we've learned". There's clearly a = lot of experience to capture and relate. =3D- Tim From vesely@tana.it Mon Dec 5 09:30:34 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4CD11E80BB for ; Mon, 5 Dec 2011 09:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IBP208wL5PJ for ; Mon, 5 Dec 2011 09:30:33 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 860B211E80BD for ; Mon, 5 Dec 2011 09:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323106231; bh=woV6LfIs3qdyDjkGuaVpa1F5MzzzumIQvpPNZQ7+AO8=; l=1303; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=AnuPOJDnWvo4FNwcV0qmm7BZeCIx+VlxAK8ZdofLK2nvkYpUzSkiTAxZghJtyAwIl v8/bXucaccuSUYHCuJkadeie7CBHK/mQMQKpLnCszdWpZDr7P9yJx/Mvr0PBWNortJ 0LiMuvWdk6b5t7tJqrnNcos1icv5M+y5mT7NCWMg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 05 Dec 2011 18:30:31 +0100 id 00000000005DC033.000000004EDCFFB7.00003F23 Message-ID: <4EDCFFB7.5050007@tana.it> Date: Mon, 05 Dec 2011 18:30:31 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> <4EDC297C.6030209@gathman.org> In-Reply-To: <4EDC297C.6030209@gathman.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 17:30:35 -0000 On 05/Dec/11 03:16, Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 12/04/2011 02:10 PM, Murray S. > Kucherawy would write: >>>> I also heard of verifiers who assume an MX/24 for domains that have no >>>> SPF record. Should these uses be documented? >>> This is known as "best guess" and is non-standard practice — probably >>> not even best practice: >> I would be comfortable with documenting "Best Practice SPF" in a >> non-normative appendix. It's common enough that it should be >> written down someplace permanent, like the back of an RFC. How about adding an SPF BCP to the milestones? > I use "best guess", and find it very useful, *however* spfbis should > explicitly mention that such results should not be reported as SPF > results in Received-SPF or Authentication-Results headers. I report > them as x-bestguess= in Received-SPF. Hm... I'm not following you. Do you mean that one would write the following if ietf.org didn't have an SPF record? Received-SPF: pass identity=mailfrom; envelope-from=spfbis-bounces@ietf.org; client-ip=12.22.58.30; x-bestguess=a BTW, the production rule for identity seems to be orphaned, in Section 7. Cannot connect for www.openspf.org/RFC_4408/Errata ... From dhc2@dcrocker.net Mon Dec 5 09:45:46 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9303F21F8BAD for ; Mon, 5 Dec 2011 09:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wtV8QJk0yQS for ; Mon, 5 Dec 2011 09:45:46 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0733421F8B3A for ; Mon, 5 Dec 2011 09:45:46 -0800 (PST) Received: from [10.39.172.45] ([205.248.100.252]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pB5Hjevi007862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 09:45:45 -0800 Message-ID: <4EDD033D.2070607@dcrocker.net> Date: Mon, 05 Dec 2011 09:45:33 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alessandro Vesely References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> <4EDC297C.6030209@gathman.org> <4EDCFFB7.5050007@tana.it> In-Reply-To: <4EDCFFB7.5050007@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 05 Dec 2011 09:45:45 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:45:46 -0000 On 12/5/2011 9:30 AM, Alessandro Vesely wrote: > How about adding an SPF BCP to the milestones? What, exactly, would it cover? That is, what's the scope of the task that permits achieving the milestone? What problem will it solve? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From SRS0=2ufxB=6R==stuart@gathman.org Mon Dec 5 10:36:54 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4011E8082 for ; Mon, 5 Dec 2011 10:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCVtvt9dqrQT for ; Mon, 5 Dec 2011 10:36:53 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id A469D11E80BC for ; Mon, 5 Dec 2011 10:36:53 -0800 (PST) Received: from fairfax.gathman.org (gathman [192.168.10.1]) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id pB5Ia8bh032317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 13:36:10 -0500 Date: Mon, 5 Dec 2011 13:36:42 -0500 (EST) From: "Stuart D. Gathman" To: Alessandro Vesely In-Reply-To: <4EDCFFB7.5050007@tana.it> Message-ID: References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> <4EDC297C.6030209@gathman.org> <4EDCFFB7.5050007@tana.it> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 18:36:54 -0000 On Mon, 5 Dec 2011, Alessandro Vesely wrote: >> I use "best guess", and find it very useful, *however* spfbis should >> explicitly mention that such results should not be reported as SPF >> results in Received-SPF or Authentication-Results headers. I report >> them as x-bestguess= in Received-SPF. > > Hm... I'm not following you. Do you mean that one would write the > following if ietf.org didn't have an SPF record? > > Received-SPF: pass > identity=mailfrom; > envelope-from=spfbis-bounces@ietf.org; > client-ip=12.22.58.30; > x-bestguess=a No. SPF result is none where there is no SPF record: Received-SPF: None (mail.bmsi.com: 98.139.91.92 is neither permitted nor denied by domain of yahoo.com) client-ip=98.139.91.92; envelope-from="redacted@yahoo.com"; helo=nm22.bullet.mail.sp2.yahoo.com; receiver=mail.bmsi.com; mechanism=ptr; x-bestguess=pass; x-helo-spf=pass; identity=mailfrom -- Stuart D. Gathman "Confutatis maledictis, flamis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial. From spf2@kitterman.com Mon Dec 5 10:37:59 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB7E11E80BF for ; Mon, 5 Dec 2011 10:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncxH2TvQ-L-o for ; Mon, 5 Dec 2011 10:37:58 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 872DA11E8082 for ; Mon, 5 Dec 2011 10:37:45 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 779B8D04081; Mon, 5 Dec 2011 12:37:44 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1323110264; bh=f1oKJz5K5uC0YaXeIfiEHtVTW4b5Mvju2kjNrK3eK7Q=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=qCPEsnGHYwMs/Er3ZH99mTEbwvHLOHIhSKyXR+tBj2oh8cazR5ttQzyXKXBmUqgQL ABPFfSRWWyShXju24tRHAp5FKUwty5+dkWUJmu+KYq62eOSORAfiXaerloyU97UoEX 0yMqkZuQX3Wf0PNu/sUxZdjMdOtcfS0TSe8wK/mQ= Received: from 218.sub-97-241-221.myvzw.com (218.sub-97-241-221.myvzw.com [97.241.221.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E215CD04053; Mon, 5 Dec 2011 12:37:43 -0600 (CST) References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> <4EDC297C.6030209@gathman.org> <4EDCFFB7.5050007@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <4EDCFFB7.5050007@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 05 Dec 2011 13:37:52 -0500 To: Alessandro Vesely ,spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 18:37:59 -0000 Alessandro Vesely wrote: ... >BTW, the production rule for identity seems to be orphaned, in Section >7. Cannot connect for www.openspf.org/RFC_4408/Errata ... Use openspf.net instead. Scott K From msk@cloudmark.com Mon Dec 5 10:39:37 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D2D11E80A1 for ; Mon, 5 Dec 2011 10:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.66 X-Spam-Level: X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6I5LSiuj8Z9 for ; Mon, 5 Dec 2011 10:39:36 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id DF42321F8BA9 for ; Mon, 5 Dec 2011 10:39:36 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 5 Dec 2011 10:39:36 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 5 Dec 2011 10:39:34 -0800 Thread-Topic: [spfbis] SPFBIS proposed charter Thread-Index: AcyyDeLhKLDXdWgTTviwIonbhjiUfgAqlJOQADE6OoA= Message-ID: References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 18:39:37 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcGZiaXMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTXVycmF5 IFMuIEt1Y2hlcmF3eQ0KPiBTZW50OiBTdW5kYXksIERlY2VtYmVyIDA0LCAyMDExIDExOjEwIEFN DQo+IFRvOiBzcGZiaXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzcGZiaXNdIFNQRkJJUyBw cm9wb3NlZCBjaGFydGVyDQo+IA0KPiBJIHdvdWxkIGJlIGNvbWZvcnRhYmxlIHdpdGggZG9jdW1l bnRpbmcgIkJlc3QgUHJhY3RpY2UgU1BGIiBpbiBhIG5vbi0NCj4gbm9ybWF0aXZlIGFwcGVuZGl4 LiAgSXQncyBjb21tb24gZW5vdWdoIHRoYXQgaXQgc2hvdWxkIGJlIHdyaXR0ZW4gZG93bg0KPiBz b21lcGxhY2UgcGVybWFuZW50LCBsaWtlIHRoZSBiYWNrIG9mIGFuIFJGQy4NCg0KSnVzdCB0byBi ZSBjbGVhcjogSWYgdGhlIHdvcmtpbmcgZ3JvdXAgYWdyZWVzLCBpdCBpcyBhbHNvIGZyZWUgdG8g ZXhwbGFpbiB3aHkgaXQgdGhpbmtzIHVzZSBvZiBCZXN0IEd1ZXNzIFNQRiBpcyBhIGJhZCBpZGVh LiAgVGhlIGdvYWwgaGVyZSBpcyBlZHVjYXRpb24sIGFmdGVyIGFsbC4NCg== From dotzero@gmail.com Mon Dec 5 11:07:34 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9FD11E80AF for ; Mon, 5 Dec 2011 11:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7lZnGxJR11y for ; Mon, 5 Dec 2011 11:07:34 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29B5221F8C74 for ; Mon, 5 Dec 2011 11:07:34 -0800 (PST) Received: by dadv40 with SMTP id v40so6087393dad.31 for ; Mon, 05 Dec 2011 11:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VsXUvuRfduCC15tfFnXOnbYseDoqFqdR6lUyMT4d43k=; b=lchSNwQgAra3iV/xqYmQI/UDroOdAcCnQvmOY7/uAn+s7yW+KmFU3ryvUN1N929KWR ZnIYP9NR0YWkhSBWKCgWxvaNlB4dXlXw2+HHEedz4xh7ANsOe0UgQz/SmoSlFPpcwYf5 ZLE0m0QucQVbfSrNmesyDkPxTRXER80sZ/LmM= MIME-Version: 1.0 Received: by 10.68.51.70 with SMTP id i6mr4590986pbo.39.1323112053742; Mon, 05 Dec 2011 11:07:33 -0800 (PST) Received: by 10.142.223.5 with HTTP; Mon, 5 Dec 2011 11:07:33 -0800 (PST) In-Reply-To: References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> Date: Mon, 5 Dec 2011 14:07:33 -0500 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 19:07:34 -0000 On Mon, Dec 5, 2011 at 1:39 PM, Murray S. Kucherawy wro= te: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf= Of Murray S. Kucherawy >> Sent: Sunday, December 04, 2011 11:10 AM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] SPFBIS proposed charter >> >> I would be comfortable with documenting "Best Practice SPF" in a non- >> normative appendix. =A0It's common enough that it should be written down >> someplace permanent, like the back of an RFC. > > Just to be clear: If the working group agrees, it is also free to explain= why it thinks use of Best Guess SPF is a bad idea. =A0The goal here is edu= cation, after all. > _______________________________________________ If we are talking standards track I think we would need more information on "Best Practice SPF" for the RFC to say good/bad/indifferent. It has basically been out of scope for the existing RFC. From dhc2@dcrocker.net Mon Dec 5 15:03:14 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39C31F0C96 for ; Mon, 5 Dec 2011 15:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yLIBJdgjtL0 for ; Mon, 5 Dec 2011 15:03:13 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE42C1F0C97 for ; Mon, 5 Dec 2011 15:03:13 -0800 (PST) Received: from [10.39.172.45] ([205.248.100.252]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pB5N385n015715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 15:03:13 -0800 Message-ID: <4EDD4DA5.3090003@dcrocker.net> Date: Mon, 05 Dec 2011 15:03:01 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <201112030058.24946.julian@mehnle.net> <6.2.5.6.2.20111202200818.0a770c20@resistor.net> <4ED9C4E4.5020309@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 05 Dec 2011 15:03:13 -0800 (PST) Cc: "spfbis@ietf.org" Subject: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 23:03:14 -0000 This note discusses some principles driving my views on the charter's scope and for some reason, higher-level constructs seem to require verbosity (for me, at least.) On 12/3/2011 12:49 AM, Murray S. Kucherawy wrote: >> Once the initial standards-track specification is approved, the working >> group can recharter for pursuing enhancements. > > This appears to contradict your earlier [1] sentiments that the proposed > charter, which does include Julian's draft, is satisfactory. It is, however, > the only extension in scope for the initial charter we're discussing; the > proposed charter proscribes all others. Well, self-contradiction isn't a goal. If it's happening, it probably reflects more thought on the topic... > As I've said before, I don't know how painful or painless a re-chartering can > be. It's subject to the vagaries of working group charter-writing tension and IESG charter-review tension. I believe that a well-functioning working group that has so far been productive, typically has a reasonably easy time. Unlike financial statements, past performance /is/ (usually) taken to be a predictor of future performance. > If it's "easy", then I'd be fine with removing it for now. But since it > has some momentum behind it, we can possibly save ourselves that step simply > by leaving the charter as-is and being diligent about tackling our few > deliverables in sequence as much as possible. I'm up for it. It's clear it has some momentum on this list, as a topic. That ought to be necessary for anything added to the charter, but I'll suggest strongly that it's not sufficient... In case it is not clear, let me stress that nothing I'm posting on the topic of the charter has anything to do with my own technical opinions. I am offering no comment on any feature, new or old, in terms of whether I 'like' it. I am solely concerned with what process is the most likely to produce a successful document. I measure success in two way. One is timely production of a document that gains standards status. The second is that the document gains widespread use by the community. The challenge in achieving that success is guessing the right balance of specification details to match what the market wants/needs. In the case of an effort like SPFbis, it needs to hit the operational vector that the market has /already/ established. That is, spf already is in use and this working group needs align with that reality very carefully. Certainly that sometimes requires adding features not in the existing specification, if the market is already using those features. This is an example of that oft-touted and oft-forgotten -- yes, both, simultaneously -- documenting existing practice. Where risk increases dramatically, for something that already has a significant installed base, is when the charter claims that the market wants something not yet in widespread use. And to be clear, if it is not already in use /for the specific mechanism being discussed/, it does not qualify as being in widespread use for this discussion, no matter where else it might be in use; integration to a mechanism is inherently risky. The assessment of the enhancement's need and efficacy might be entirely valid -- it might be a really good idea -- but I claim that the simple fact that the feature is not yet in widespread use makes adding it to an initial working group effort risky. The principle reason for this is that it does not have objective data to dictate the details or the market demand. It has guesses. No matter how excellent the idea and insightful the guesses, they are still guesses. Guesses invite debate and they invite errors. That's called risk. In contrast, to justify its content, a document that is based strictly on existing practice only has the requirement to /document/ the existing practice; it does not have to figure out what will work. The 'risk' is in observing existing practice, not guessing the vector to desired practice. Assessing existing practice is not automatically trivial. We have to be careful even with that modest requirement. Assessing "desire" however is always a challenge, absent overwhelming market clarity and I am pretty sure we don't have that here. So my strong recommendation is that we defer anything that is not already in widespread use, specifically for SPF. (And for the purposes of the current discussion, I believe Sender-ID needs to be treated as independent of SPF.) We will have enough challenges in debating what to retain versus was to remove. Once we have done that and achieved the very notable success of a standards-track document, it will be massively easier to pursue an enhancement, IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From vesely@tana.it Tue Dec 6 04:05:51 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453DC21F8AD2 for ; Tue, 6 Dec 2011 04:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.619 X-Spam-Level: X-Spam-Status: No, score=-4.619 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WYW-HN4hG0n for ; Tue, 6 Dec 2011 04:05:50 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C616721F8A7D for ; Tue, 6 Dec 2011 04:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323173141; bh=ENMfJseQ3+bLyz5i18+9ZygBK6SWEgkviWrOk1jkzLg=; l=1118; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MxukH71z3mAgpBipbzOQtWET8xhTjyMgQgomr5PFpIEl1oxDgtfB7nrgG9qUYZ7S/ UQqPirCEfW/6a62DHRzCqKF6+QqjAXLmAPyNQOpFui2BwcM6W6KpgUdpAHET3+uvsH etMjP5lRffNN5nmmEcuPzns7aMGouWDfRoCuvsV0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 06 Dec 2011 13:05:41 +0100 id 00000000005DC044.000000004EDE0515.00005F99 Message-ID: <4EDE0515.90404@tana.it> Date: Tue, 06 Dec 2011 13:05:41 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EDA77DB.704@tana.it> <201112032249.45316.julian@mehnle.net> <4EDC297C.6030209@gathman.org> <4EDCFFB7.5050007@tana.it> <4EDD033D.2070607@dcrocker.net> In-Reply-To: <4EDD033D.2070607@dcrocker.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFBIS proposed charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 12:05:51 -0000 On 05/Dec/11 18:45, Dave CROCKER wrote: > On 12/5/2011 9:30 AM, Alessandro Vesely wrote: >> How about adding an SPF BCP to the milestones? > > What, exactly, would it cover? That is, what's the scope of the task > that permits achieving the milestone? What problem will it solve? There's quite some FAQs, approaches, tricks, recommendations, similar to bestguess. For example, publishing "v=spf1 -all" for some hosts that have an A record, use of _spf.example.com and other include/ redirect strategies. Quite often we'll ask ourselves what to do with this or that issue, and decide for non-normative, educational text. Two alternative destinations for such material are an appendix and web sites like openspf.NET --thanks Scott, I should have recalled that. While both of them have their own merits, the former is more demanding on the editor and the resulting document will be somewhat less tight; the latter is better for ongoing developments than for bottom line statements made at a definite time. As for whether to mention it in the charter, and BCP vs informational rank, I don't know. From vesely@tana.it Wed Dec 14 11:14:14 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FEF11E8083 for ; Wed, 14 Dec 2011 11:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.584 X-Spam-Level: X-Spam-Status: No, score=-4.584 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx-voCN6m27j for ; Wed, 14 Dec 2011 11:14:13 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 46E4311E8089 for ; Wed, 14 Dec 2011 11:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323890050; bh=HUf0V55xvUZ10HXON/ZAanEeTMyVJ3W9dX6eVxnfSeo=; l=1793; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=AoIh2EaDWL3nLUPx5bCsHQJxPi/X6hmAQXA1mY066aE//bTS7YzWg4VOVgfvB9J+K 7UG3m5/fxADoSPBCwiDR/w6sbLt9V9fDZ9X41pu6H0E6fhSi965u+8WDOXS+WnDKwZ GlNqTGWuxQoP4CC1q0ekwQ0k6sNotacpbdAvF3gU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 14 Dec 2011 20:14:10 +0100 id 00000000005DC045.000000004EE8F582.00004B6B Message-ID: <4EE8F582.6060906@tana.it> Date: Wed, 14 Dec 2011 20:14:10 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <809B4F2F-5E17-4A56-B1E5-DCC545B646BB@eudaemon.net> <4D4205E5.7050807@gladstonefamily.net> In-Reply-To: <4D4205E5.7050807@gladstonefamily.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] Poll: "tracking exists:" mechanisms and local macros vs SPF reporting X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 19:14:14 -0000 All, as we known, the %{s} and %{l} SPF macros allow to publish records that include a "tracking exists:" mechanism. The quoted message below contains a live example. RFC 4408 says "it can be useful" (Section 9.1). However, these tracking mechanisms don't work well with DNS caches, may be unavailable for domains that outsource DNS, and may be considered unfair inasmuch as they force verifiers to also provide feedback. OTOH, a different kind of mechanism can provide for delivering SPF failure reports separately from compliant SPF verification. That might be easier to both set up and understand. * Could decoupling feedback from verification gain more adoptions? * Would it be feasible to consider making tracking mechanisms optional and/or deprecated in SPFbis? TIA for any response. On 28/Jan/11 00:55, Philip Gladstone wrote to spf-discuss: > In many cases, you can do reporting today with SPF. If you have a > stunt DNS, then you can make the receiver do specific lookups and > thereby you can track what is going on. > > In particular, this was much of the motivation behind the macro > language in SPF. > > I have a fairly nasty SPF record -- including things like > '-exists:%{i}.%{l1r-}.user.%{d}' This allows me to drop any mail > that doesn't come from a valid user in my domain. Because of where > this comes in my SPF record (after the allows for my normal servers), > I get to see what is going on. > > For example, I see: > > 213.244.228.130.ga6uhifg.user.spf.gladstonefamily.net > 140.177.205.131.ostmaster.user.spf.gladstonefamily.net > > I suspect that in the second case, either there is an incompetent > forger who can spell postmaster, or there is a buggy spf > implementation that leaves off the first character! From SRS0=f1pBS=62==stuart@gathman.org Wed Dec 14 14:22:07 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B7311E80AA for ; Wed, 14 Dec 2011 14:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wutmuMCBfVi for ; Wed, 14 Dec 2011 14:22:07 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 16F8311E809F for ; Wed, 14 Dec 2011 14:22:07 -0800 (PST) Received: from sdg.bmsi.com ([192.168.9.34]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id pBEMLVPW005315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Dec 2011 17:21:31 -0500 Message-ID: <4EE92179.1090103@gathman.org> Date: Wed, 14 Dec 2011 17:21:45 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <809B4F2F-5E17-4A56-B1E5-DCC545B646BB@eudaemon.net> <4D4205E5.7050807@gladstonefamily.net> <4EE8F582.6060906@tana.it> In-Reply-To: <4EE8F582.6060906@tana.it> Content-Type: multipart/alternative; boundary="------------070905050102040802020307" Subject: Re: [spfbis] Poll: "tracking exists:" mechanisms and local macros vs SPF reporting X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 22:23:52 -0000 This is a multi-part message in MIME format. --------------070905050102040802020307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Centuries ago, Nostradamus foresaw that on 12/14/2011 02:14 PM, Alessandro Vesely would write: > OTOH, a different kind of mechanism can provide for delivering SPF > failure reports separately from compliant SPF verification. That > might be easier to both set up and understand. > > * Could decoupling feedback from verification gain more adoptions? Possibly for spfv3. You would have to be more specific on exactly what a tracking specific mechanism would do, but having it optional for verification purposes (in case a checker wants to opt out of tracking) is a great idea. For spfv3. This idea should go on the spf-discuss list, as spfbis is not designing spfv3. > * Would it be feasible to consider making tracking mechanisms > optional and/or deprecated in SPFbis? No. This is a no brainer. No functional changes for SPFbis. --------------070905050102040802020307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Centuries ago, Nostradamus foresaw that on 12/14/2011 02:14 PM, Alessandro Vesely would write:
OTOH, a different kind of mechanism can provide for delivering SPF
failure reports separately from compliant SPF verification.  That
might be easier to both set up and understand.

* Could decoupling feedback from verification gain more adoptions?
Possibly for spfv3.  You would have to be more specific on exactly what a tracking specific mechanism would do, but having it optional for verification purposes (in case a checker wants to opt out of tracking) is a great idea.  For spfv3.  This idea should go on the spf-discuss list, as spfbis is not designing spfv3.
* Would it be feasible to consider making tracking mechanisms
   optional and/or deprecated in SPFbis?
No.  This is a no brainer.  No functional changes for SPFbis.


--------------070905050102040802020307-- From vesely@tana.it Thu Dec 15 07:16:49 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFD621F8678 for ; Thu, 15 Dec 2011 07:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reRX8FGdr1r1 for ; Thu, 15 Dec 2011 07:16:48 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA6821F846B for ; Thu, 15 Dec 2011 07:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323962206; bh=tsinB7RPTVCur8bteS3yAddFbT5KCh24y4nLCd4NIqo=; l=1170; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=goMbq1g+ndcQNvWV57RVBSQJkRnNmMZ3j3NNoXHzyQElhhuQHCPbucnVhCoJPKhuD 39j06ZEFe+TCFsiYy/nR1DOBpTHxYWzbdjW/hCj8c8P6oNbc+UTa0aGyPXImGEN7z7 Wh+QU9mK6t1oLPcLGd+dnd3UPbE6FgRpaBpVh+Ac= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 15 Dec 2011 16:16:46 +0100 id 00000000005DC044.000000004EEA0F5E.00007BB0 Message-ID: <4EEA0F5F.2040003@tana.it> Date: Thu, 15 Dec 2011 16:16:47 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <809B4F2F-5E17-4A56-B1E5-DCC545B646BB@eudaemon.net> <4D4205E5.7050807@gladstonefamily.net> <4EE8F582.6060906@tana.it> <4EE92179.1090103@gathman.org> In-Reply-To: <4EE92179.1090103@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Poll: "tracking exists:" mechanisms and local macros vs SPF reporting X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 15:16:49 -0000 On 14/Dec/11 23:21, Stuart D Gathman wrote: > Centuries ago, Nostradamus foresaw that on 12/14/2011 02:14 PM, > Alessandro Vesely would write: >> OTOH, a different kind of mechanism can provide for delivering SPF >> failure reports separately from compliant SPF verification. That >> might be easier to both set up and understand. >> >> * Could decoupling feedback from verification gain more adoptions? > Possibly for spfv3. You would have to be more specific on exactly > what a tracking specific mechanism would do, but having it optional > for verification purposes (in case a checker wants to opt out of > tracking) is a great idea. Sorry, I thought it was clear which mechanism I alluded to. Scott is writing it withing MARF. I was wandering if and how it would correlate with SPFbis and Julian's scope. http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ > For spfv3. This idea should go on the > spf-discuss list, as spfbis is not designing spfv3. >> * Would it be feasible to consider making tracking mechanisms >> optional and/or deprecated in SPFbis? > No. This is a no brainer. No functional changes for SPFbis. Thanks From spf2@kitterman.com Thu Dec 15 16:02:36 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFA11F0C4D for ; Thu, 15 Dec 2011 16:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+o29W4jrFpu for ; Thu, 15 Dec 2011 16:02:35 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B1BED1F0C38 for ; Thu, 15 Dec 2011 16:02:35 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8878D20E40E8; Thu, 15 Dec 2011 19:02:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1323993753; bh=waqtf111blIoQ46msk7U3BTekGvN2r5qgQFwfRHa86E=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=F7P8Ld+06eRYH9//5QRpl+HTTho+vljM/AQa18dxQWrCN+MPlwCGburCZ2knl+50a 8tqPQSAks50T8M+3ojlILxiFJgEMGGpkGJazlFUJNZqTxYRth8lhRgJfkvsX84mcuh sl/PELRGWUbDkDxyxJk7DAXtPg+EV/Np4ymmrsKI= Received: from scott-latitude-e6320.localnet (unknown [209.144.63.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2A35C20E4091; Thu, 15 Dec 2011 19:02:32 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 15 Dec 2011 19:02:26 -0500 Message-ID: <6853168.XbdCDJWYu7@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4EEA0F5F.2040003@tana.it> References: <809B4F2F-5E17-4A56-B1E5-DCC545B646BB@eudaemon.net> <4EE92179.1090103@gathman.org> <4EEA0F5F.2040003@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] Poll: "tracking exists:" mechanisms and local macros vs SPF reporting X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 00:02:36 -0000 On Thursday, December 15, 2011 04:16:47 PM Alessandro Vesely wrote: > On 14/Dec/11 23:21, Stuart D Gathman wrote: > > Centuries ago, Nostradamus foresaw that on 12/14/2011 02:14 PM, > > > > Alessandro Vesely would write: > >> OTOH, a different kind of mechanism can provide for delivering SPF > >> failure reports separately from compliant SPF verification. That > >> might be easier to both set up and understand. > >> > >> * Could decoupling feedback from verification gain more adoptions? > > > > Possibly for spfv3. You would have to be more specific on exactly > > what a tracking specific mechanism would do, but having it optional > > for verification purposes (in case a checker wants to opt out of > > tracking) is a great idea. > > Sorry, I thought it was clear which mechanism I alluded to. Scott is > writing it withing MARF. I was wandering if and how it would > correlate with SPFbis and Julian's scope. > http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ I think that they are largely independent. The exists: trick has been known since 2003 or 2004, but is very rarely used because it's complex. Including SPF as part of a more general authentication failure feedback mechanism (which is what we are doing in MARF) will provide a technically more simple mechanism that's common with that used by other related technoglies such as DKIM. The MARF effort will, however, produce an approach that requires two willing parties to work, so it doesn't entirely replace the exists: trick for domains interested in using it. In any case, the features used for the exists: trick are in use, so I don't see them being removed as part of the SPFbis effort. Will it gain more adoptions? I think so, but I think it targets a slightly difference audience than using exists:, so the efforts should proceed independently. Scott K From vesely@tana.it Fri Dec 16 04:36:29 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B289D21F8B66 for ; Fri, 16 Dec 2011 04:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.617 X-Spam-Level: X-Spam-Status: No, score=-4.617 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjVyHWKxG9S8 for ; Fri, 16 Dec 2011 04:36:29 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B956D21F8B62 for ; Fri, 16 Dec 2011 04:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324038987; bh=7XqciR6uRXisJTrGIrdr6QnMofFpKGqDJskvBKLlnpk=; l=1413; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=O+0iJ4zCzqDmshKZ28JdaPhjmPthlBWxq2c/z1nurEnn9o7dtGsFjI1LnTSTrLptV QPaIg/P8wzDNFBMJr9QNs4Uze0rVMb492Hw3iVuhjZUn/hh7YZN/iznb28WfOYGqz5 7icgVxFFasry/l/IIhN12TOw3Rjbr+gj3+bpuEds= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 16 Dec 2011 13:36:27 +0100 id 00000000005DC033.000000004EEB3B4B.00001CB0 Message-ID: <4EEB3B4B.3070602@tana.it> Date: Fri, 16 Dec 2011 13:36:27 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <809B4F2F-5E17-4A56-B1E5-DCC545B646BB@eudaemon.net> <4EE92179.1090103@gathman.org> <4EEA0F5F.2040003@tana.it> <6853168.XbdCDJWYu7@scott-latitude-e6320> In-Reply-To: <6853168.XbdCDJWYu7@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Poll: "tracking exists:" mechanisms and local macros vs SPF reporting X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 12:36:29 -0000 On 16/Dec/11 01:02, Scott Kitterman wrote: > On Thursday, December 15, 2011 04:16:47 PM Alessandro Vesely wrote: >> >> Sorry, I thought it was clear which mechanism I alluded to. Scott is >> writing it withing MARF. I was wandering if and how it would >> correlate with SPFbis and Julian's scope. >> http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ > > I think that they are largely independent. Ok, at this point I agree. > The exists: trick has been known since 2003 or 2004, but is very rarely used > because it's complex. > > The MARF effort will, however, produce an approach that requires two willing > parties to work, so it doesn't entirely replace the exists: trick for domains > interested in using it. > > In any case, the features used for the exists: trick are in use, so I don't > see them being removed as part of the SPFbis effort. There was much discussion about evilness of local macros. In theory, a hairy SPF implementation could provide for (optionally) disabling them. If we were aware of such an implementation, we could add an informative paragraph in SPFbis to discourage local macros in favor of spf-reporting. That's where I saw the possibility of a connection. Since neither us nor any implementation we know of wish to treat local macros differently from what RFC 4408 says, I see no (other) reason to bundle spf-reporting and SPFbis. From dotzero@gmail.com Fri Dec 16 06:18:14 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1921E21F8BA4 for ; Fri, 16 Dec 2011 06:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aO37q7BQfkv for ; Fri, 16 Dec 2011 06:18:13 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9B21F8BA0 for ; Fri, 16 Dec 2011 06:18:13 -0800 (PST) Received: by dajz8 with SMTP id z8so3075187daj.31 for ; Fri, 16 Dec 2011 06:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZZLwPLt1Ge5yDGUO/KTlxVMN+l4ucccmzpN2/x6FWSk=; b=nWiJVKnZ9wMfWpcRMmvttrlcKd5DW/YAK2tcmn2QbI6Aq4UH+c8nR/UsmS6Af32m0U T9qTp08E9dXluyRUjK4NrJmnMSJX9nk7xyz3FEJTs65LzuYjVsQShu5nFj8u5FL3yjKX 8DaMmdQc++PnVNTI803U3FM+WiMRdnghQrafc= MIME-Version: 1.0 Received: by 10.68.73.104 with SMTP id k8mr16250232pbv.104.1324045091852; Fri, 16 Dec 2011 06:18:11 -0800 (PST) Received: by 10.143.82.20 with HTTP; Fri, 16 Dec 2011 06:18:11 -0800 (PST) In-Reply-To: <4EEB3B4B.3070602@tana.it> References: <809B4F2F-5E17-4A56-B1E5-DCC545B646BB@eudaemon.net> <4EE92179.1090103@gathman.org> <4EEA0F5F.2040003@tana.it> <6853168.XbdCDJWYu7@scott-latitude-e6320> <4EEB3B4B.3070602@tana.it> Date: Fri, 16 Dec 2011 09:18:11 -0500 Message-ID: From: Dotzero To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Poll: "tracking exists:" mechanisms and local macros vs SPF reporting X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 14:18:14 -0000 On Fri, Dec 16, 2011 at 7:36 AM, Alessandro Vesely wrote: > On 16/Dec/11 01:02, Scott Kitterman wrote: >> On Thursday, December 15, 2011 04:16:47 PM Alessandro Vesely wrote: >>> >>> Sorry, I thought it was clear which mechanism I alluded to. =A0Scott is >>> writing it withing MARF. =A0I was wandering if and how it would >>> correlate with SPFbis and Julian's scope. >>> http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ >> >> I think that they are largely independent. > > Ok, at this point I agree. > >> The exists: trick has been known since 2003 or 2004, but is very rarely = used >> because it's complex. >> >> The MARF effort will, however, produce an approach that requires two wil= ling >> parties to work, so it doesn't entirely replace the exists: trick for do= mains >> interested in using it. >> >> In any case, the features used for the exists: trick are in use, so I do= n't >> see them being removed as part of the SPFbis effort. > > There was much discussion about evilness of local macros. =A0In theory, > a hairy SPF implementation could provide for (optionally) disabling > them. =A0If we were aware of such an implementation, we could add an > informative paragraph in SPFbis to discourage local macros in favor of > spf-reporting. =A0That's where I saw the possibility of a connection. > This might appropriately be addressed in a BCP. > Since neither us nor any implementation we know of wish to treat local > macros differently from what RFC 4408 says, I see no (other) reason to > bundle spf-reporting and SPFbis. > _______________________________________________ > From dotis@mail-abuse.org Fri Dec 16 19:52:38 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F105B11E808A for ; Fri, 16 Dec 2011 19:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9sraqytvpE2 for ; Fri, 16 Dec 2011 19:52:38 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAA711E8080 for ; Fri, 16 Dec 2011 19:52:38 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 3F66B17401C7 for ; Sat, 17 Dec 2011 03:52:37 +0000 (UTC) Message-ID: <4EEC1204.2000707@mail-abuse.org> Date: Fri, 16 Dec 2011 19:52:36 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: SPFbis discussion list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 03:52:39 -0000 Attempts to elevate SPF to a standards track document just as Carrier Grade or Large Scale NATs appear distracts from a greater need to provide scalable cryptographic validation for SMTP servers. SPF provides little protection against spoofing since MAILFROM is not seen. Efforts to extend SPF to include PRA suffers from similar problems since malefactors can use unseen PRA header fields as well. The macro expansion required for SPF processing risks DDoS threats with little justification. For example, SPF evaluation may require subsequent transactions formed by email-address local-parts. Since most spam campaigns already modify source address local-parts, any targeted attack against a domain (which may not be present within these messages) will not burden malefactor's DNS since SPF records referenced by the domain portion of the email address will have been cached. This permits both spamming and DDoS to occur simultaneously that exploits SPF's burden placed upon recipient resources. Use of "exists" macros is equally nonsensical. Any message with an email address pointing to existing resource records as dictated by SPF macros reveals absolutely nothing about who sent the message! The 10 mechanism macro limit must include subsequent transactions necessary to resolve authorized IP address lists. Even this seemingly low limit can result in significant levels of network amplification oweing to processing burdens placed upon recipients. While email providers are unlikely targets, and processing complex SPF macros are seldom logged, there would be few clues regarding this attack from a victims perspective. Assumptions that a valid authorization confirms the action of a domain is also wrong. Often these authorizations are essential to ensure delivery can be accomplished by various email providers. Rather than expecting recipients to discern whether an entire sequence of email deliveries properly executed the "who's it" handshake and that no one is lying all depends upon the last provider in the sequence. Recipients should be allowed to either trust the last provider or not, where authentication of this last provider represents the only scalable solution. http://tools.ietf.org/html/draft-kucherawy-dkim-atps-11 provides a "single" transaction method for DKIM signers to authorize all last in sequence providers. There is no reason to muddle with the return path for DSNs since this will further lower email integrity. -Doug From julian@mehnle.net Fri Dec 16 20:55:13 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A5911E809B for ; Fri, 16 Dec 2011 20:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEDYNAzh6PLJ for ; Fri, 16 Dec 2011 20:55:13 -0800 (PST) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE6C11E8080 for ; Fri, 16 Dec 2011 20:55:12 -0800 (PST) Received: from [10.0.2.15] (50-0-128-85.dsl.dynamic.sonic.net [::ffff:50.0.128.85]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Sat, 17 Dec 2011 04:55:10 +0000 id 00000000203B4EC9.000000004EEC20AE.00002DE9 From: Julian Mehnle To: spfbis@ietf.org Date: Sat, 17 Dec 2011 04:56:33 +0000 User-Agent: KMail/1.9.9 References: <4EEC1204.2000707@mail-abuse.org> In-Reply-To: <4EEC1204.2000707@mail-abuse.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13944536.zrdNXgiLXF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112170456.36790.julian@mehnle.net> Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 04:55:13 -0000 --nextPart13944536.zrdNXgiLXF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Oh dear. Douglas Otis wrote: > Efforts to extend SPF to include PRA suffers from similar problems > since malefactors can use unseen PRA header fields as well. There are no such efforts. BTW, you failed to clarify your concerns about the SPFbis WG scope as=20 indicated by your subject line. Are you saying this WG should not exist? =2DJulian --nextPart13944536.zrdNXgiLXF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk7sIQEACgkQwL7PKlBZWjtIVQCbBwbs2G0FF0HVsN4Bod4y0KqH gPkAoJieRqZrQ5sbpb8QaQw3NXJ2gzdZ =or8u -----END PGP SIGNATURE----- --nextPart13944536.zrdNXgiLXF-- From msk@cloudmark.com Sat Dec 17 21:08:04 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A9911E8094 for ; Sat, 17 Dec 2011 21:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPVCtR9u+wTn for ; Sat, 17 Dec 2011 21:08:03 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id CBA4511E807F for ; Sat, 17 Dec 2011 21:08:00 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 17 Dec 2011 21:07:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 17 Dec 2011 21:07:59 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Sat, 17 Dec 2011 21:07:58 -0800 Thread-Topic: [spfbis] SPFbis WG scope Thread-Index: Acy8eBhaePB8KwZ/R4aGR1XoTuy1wAAynVTQ Message-ID: References: <4EEC1204.2000707@mail-abuse.org> <201112170456.36790.julian@mehnle.net> In-Reply-To: <201112170456.36790.julian@mehnle.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Dec 2011 05:08:04 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Julian Mehnle > Sent: Friday, December 16, 2011 8:57 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] SPFbis WG scope >=20 > Oh dear. >=20 > Douglas Otis wrote: >=20 > > Efforts to extend SPF to include PRA suffers from similar problems > > since malefactors can use unseen PRA header fields as well. >=20 > There are no such efforts. +1. I would also add that all of the other points raised are explicitly out of = scope per the proposed charter. The discussion then needs to be about whet= her the scope should change to include them, or whether there's objection t= o creation of the working group altogether. -MSK From vesely@tana.it Mon Dec 19 02:23:40 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4C621F8B59 for ; Mon, 19 Dec 2011 02:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwPGTxCyYybd for ; Mon, 19 Dec 2011 02:23:40 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABD621F8B58 for ; Mon, 19 Dec 2011 02:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324290218; bh=FaslMWRBA9ObEGYdZMT6eLvRd/BNe9J8HHZ24mVSP+s=; l=1679; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=RX0IA5JpdiNqMp5YUos83iMVT1v0WNj1Xdhz9H+2aGZKWJsdkMH77jYlH0x99B9O1 rQgAl0GHP1O/BLQ5eK4R7i7wkvPcFUh+Lb8iE56W+MaLP99w3teBKTFS0FWpQEwrXX JEg8W8xOlNP81miSvSAr3Kb4qsGZjaqVcX9cXFVk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 19 Dec 2011 11:23:38 +0100 id 00000000005DC035.000000004EEF10AA.000078AF Message-ID: <4EEF10A9.2030808@tana.it> Date: Mon, 19 Dec 2011 11:23:37 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <201112170456.36790.julian@mehnle.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 10:23:41 -0000 On 18/Dec/11 06:07, Murray S. Kucherawy wrote: > > I would also add that all of the other points raised are explicitly > out of scope per the proposed charter. The discussion then needs > to be about whether the scope should change to include them, or > whether there's objection to creation of the working group > altogether. Well, a point that does look somewhat obscure is the extension mechanism itself. It is necessary to read Julian's draft until the final paragraph in order to find a NOTE that explicitly states how extensions work in general. Recent discussion on dpf-discuss shows that it is not obvious how (not) supporting an extension may affect SPF compliance. It sounds undoubtedly self-appointing of an extension to specify the extension mechanism itself. I'd rather have a section about the possibility of extensions in SPFbis. However, that apparently conflicts with the fifth paragraph of the charter, "Changes to the SPF specification will be limited to..." In any case, an extension mechanism is something different from the first of its possible instances. I'd propose to merge the seventh paragraph into the fifth, for example like so: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, addition of clarifying language, and possibly the addition of an extension mechanism. The extension mechanism will be developed along with the proposed "scope" extension found in draft-mehnle-spf-scope, and its specification may end up in either document. (Note the draft's name is different.) From julian@mehnle.net Mon Dec 19 02:49:55 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20D921F8B63 for ; Mon, 19 Dec 2011 02:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEkmHxra7cmE for ; Mon, 19 Dec 2011 02:49:54 -0800 (PST) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id EF5DD21F84FA for ; Mon, 19 Dec 2011 02:49:53 -0800 (PST) Received: from [10.0.2.15] (50-0-128-85.dsl.dynamic.sonic.net [::ffff:50.0.128.85]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Mon, 19 Dec 2011 10:49:51 +0000 id 00000000203C47BB.000000004EEF16D0.00000CF9 From: Julian Mehnle To: spfbis@ietf.org Date: Mon, 19 Dec 2011 10:51:39 +0000 User-Agent: KMail/1.9.9 References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> In-Reply-To: <4EEF10A9.2030808@tana.it> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5347802.7gOJ3eGp4r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112191051.42604.julian@mehnle.net> Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 10:49:55 -0000 --nextPart5347802.7gOJ3eGp4r Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Alessandro Vesely wrote: > Well, a point that does look somewhat obscure is the extension > mechanism itself. It is necessary to read Julian's draft until the > final paragraph in order to find a NOTE that explicitly states how > extensions work in general. Recent discussion on dpf-discuss shows > that it is not obvious how (not) supporting an extension may affect > SPF compliance. > > It sounds undoubtedly self-appointing of an extension to specify the > extension mechanism itself. It's not like draft-mehnle-spf-scope creates new extension modifier=20 semantics. http://tools.ietf.org/html/rfc4408#section-6 says: Unrecognized modifiers MUST be ignored no matter where in a record, or how often. This allows implementations of this document to gracefully handle records with modifiers that are defined in other specifications. So extension modifier semantics are already clearly specified in RFC 4408. = =20 I.e., "If you don't support a non-core modifier, don't worry." Of course a non-core modifier has to ensure that its semantics remain=20 comaptible with SPF implementations that don't implement it. =20 draft-mehnle-spf-scope takes care of that by explicitly stating that "v=3Dspf1" records with "scope=3D" modifiers will always be applicable to=20 checks against the helo/mfrom identities in addition to any identities=20 listed in the "scope=3D" modifier. I don't see an issue here. > I'd rather have a section about the possibility of extensions in SPFbis. I have no objections to clarifying the modifier semantics that are already= =20 defined in RFC 4408. =2DJulian --nextPart5347802.7gOJ3eGp4r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk7vFzsACgkQwL7PKlBZWjsWiwCeOzX3Vc6aZpBXt/1BHI0Tl33X JZMAn3d3e8zQ4ABVdtImsvu5gzNrJtNi =4rC4 -----END PGP SIGNATURE----- --nextPart5347802.7gOJ3eGp4r-- From vesely@tana.it Mon Dec 19 04:26:19 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6FE21F8B5E for ; Mon, 19 Dec 2011 04:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2Q5fz0Auda8 for ; Mon, 19 Dec 2011 04:26:18 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9064321F8B5A for ; Mon, 19 Dec 2011 04:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324297577; bh=VyFw/l8q/jkl4Uhw1jRKRHpldEUMqKjs9YYOLymqqVc=; l=2161; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=KTPHsnjPyvM8VzAgTZguKlzpFGwKZvXsepnRVEPEKVzqALGP9yhidzBWKq4Qk+vbr 3db9fN0hBYRyW52OmthCRZqYT+2+hqzO1g259IhtInUrxj4lY5TWyjF2PjrbOtqIca f0DK9Dhdza0UHiDtIYGKzs3widdkF66CCGuPcqjA= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 19 Dec 2011 13:26:17 +0100 id 00000000005DC033.000000004EEF2D69.00003028 Message-ID: <4EEF2D69.9030700@tana.it> Date: Mon, 19 Dec 2011 13:26:17 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> In-Reply-To: <201112191051.42604.julian@mehnle.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 12:26:19 -0000 On 19/Dec/11 11:51, Julian Mehnle wrote: > > It's not like draft-mehnle-spf-scope creates new extension modifier > semantics. http://tools.ietf.org/html/rfc4408#section-6 says: > > Unrecognized modifiers MUST be ignored no matter where in a record, > or how often. This allows implementations of this document to > gracefully handle records with modifiers that are defined in other > specifications. > > So extension modifier semantics are already clearly specified in RFC 4408. > I.e., "If you don't support a non-core modifier, don't worry." Yes, that it said. But not loudly enough if discussion turned on what 2119-language should be able to ram extensions down somewhere. There are different extension mechanisms that provide for flagging what extensions are supported or required. The one for v=spf1 is not one of those. It doesn't seem to be worth for domain owners to know whether a given recipient supports a certain SPF extension, since currently they even ignore if that recipient supports SPF at all. Yet, it may be worth to make it known to consumers of the outcome --both policy rejections and Authentication-Results. And what about included records? What if v3 will want to introduce the possibility of required extensions? > Of course a non-core modifier has to ensure that its semantics remain > comaptible with SPF implementations that don't implement it. > draft-mehnle-spf-scope takes care of that by explicitly stating that > "v=spf1" records with "scope=" modifiers will always be applicable to > checks against the helo/mfrom identities in addition to any identities > listed in the "scope=" modifier. > > I don't see an issue here. Suppose someone will conceive an extension that addresses, say, the display-name or comments in a "From:" field. Should they reuse the "scope=" construct? >> I'd rather have a section about the possibility of extensions in SPFbis. > > I have no objections to clarifying the modifier semantics that are already > defined in RFC 4408. Failing that, I'd suggest that it be clarified in a prominent section of your draft, rather than in the last paragraph. From msk@cloudmark.com Mon Dec 19 11:05:13 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E048411E8081 for ; Mon, 19 Dec 2011 11:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nELoF0kOembA for ; Mon, 19 Dec 2011 11:05:13 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 888EE21F85A7 for ; Mon, 19 Dec 2011 11:05:13 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 19 Dec 2011 11:05:11 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 19 Dec 2011 11:05:12 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 19 Dec 2011 11:05:11 -0800 Thread-Topic: [spfbis] SPFbis WG scope Thread-Index: Acy+SW72PohhZgkISTCYd1U65mofJwANw1kg Message-ID: References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> <4EEF2D69.9030700@tana.it> In-Reply-To: <4EEF2D69.9030700@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 19:05:14 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Monday, December 19, 2011 4:26 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] SPFbis WG scope >=20 > Yes, that it said. But not loudly enough if discussion turned on what > 2119-language should be able to ram extensions down somewhere. I'm at a loss to understand where all this rhetoric about forced extensions= comes from. A mandatory extension isn't an extension anymore, it becomes = part of the base protocol, and I think the charter makes it clear that this= isn't a goal of the working group. > There are different extension mechanisms that provide for flagging what > extensions are supported or required. I don't know what a "required extension" is. If you add something that is = mandatory for interoperability, you haven't created an extension, you have = revised the protocol. That would require a new version of SPF altogether. > >> I'd rather have a section about the possibility of extensions in SPFbi= s. > > > > I have no objections to clarifying the modifier semantics that are > > already defined in RFC 4408. >=20 > Failing that, I'd suggest that it be clarified in a prominent section > of your draft, rather than in the last paragraph. That's fine, and probably a good idea, but that doesn't strike me as eviden= ce of a problem with the charter. -MSK From vesely@tana.it Mon Dec 19 12:04:04 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37A021F850B for ; Mon, 19 Dec 2011 12:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.347 X-Spam-Level: X-Spam-Status: No, score=-4.347 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zF8P1WXQLgW for ; Mon, 19 Dec 2011 12:04:01 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D356821F84B0 for ; Mon, 19 Dec 2011 12:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324325039; bh=Rc60dh46bKbwwWA6Yfzg71AiAsGIFg7g/14pqK6m+XQ=; l=2045; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Yr6Jt0QNWB4uzL2oKz2WOXYo1V04W7ipbtPD2g8+Xa8BgqSA2FJtLHPxXCmJx6La1 Kw63jUnV3yk+OVi4BkhliC8JiSUSIyepw+WjyQehuwyvMUn/sAURCtVopds4EICeJg h2lIQkQzdLmolMUpR9lnZEkfEkkK01dqEH246ryk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 19 Dec 2011 21:03:59 +0100 id 00000000005DC035.000000004EEF98AF.0000765F Message-ID: <4EEF98AE.1030102@tana.it> Date: Mon, 19 Dec 2011 21:03:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> <4EEF2D69.9030700@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:04:05 -0000 On 19/Dec/11 20:05, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > > I'm at a loss to understand where all this rhetoric about forced > extensions comes from. I just meant it is not stated clearly enough. > A mandatory extension isn't an extension anymore, it becomes part > of the base protocol, and I think the charter makes it clear that > this isn't a goal of the working group. It is not a goal for spfbis. However, discussions on what is the most suitable extension syntax so as not to preclude future changes should not be off-topic. >> There are different extension mechanisms that provide for flagging what >> extensions are supported or required. > > I don't know what a "required extension" is. Something that means "you must support extension X in order to evaluate Y, if you don't support X then assume Z." > If you add something that is mandatory for interoperability, you > haven't created an extension, you have revised the protocol. That > would require a new version of SPF altogether. We cannot do that for version 1. However, version 3 could provide for a feature that allows new extensions, even mandatory ones, without requiring a new version of the protocol each time. >>>> I'd rather have a section about the possibility of extensions in SPFbis. >>> >>> I have no objections to clarifying the modifier semantics that are >>> already defined in RFC 4408. >> >> Failing that, I'd suggest that it be clarified in a prominent section >> of your draft, rather than in the last paragraph. > > That's fine, and probably a good idea, but that doesn't strike me > as evidence of a problem with the charter. The only nit with the charter is that it introduces the concept of SPF extension, which is totally new AFAIK, /by example/, i.e. producing a proposed extension and banning any other one, without referring what an SPF extension actually is. (Googling for "SPF extension" I found some SQR Portable Format whose file names end that way.) From msk@cloudmark.com Mon Dec 19 12:12:28 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F73221F854E for ; Mon, 19 Dec 2011 12:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.733 X-Spam-Level: X-Spam-Status: No, score=-101.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT6NF3wsR9N6 for ; Mon, 19 Dec 2011 12:12:27 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAB921F8507 for ; Mon, 19 Dec 2011 12:12:27 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 19 Dec 2011 12:12:25 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 19 Dec 2011 12:12:26 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Mon, 19 Dec 2011 12:12:25 -0800 Thread-Topic: [spfbis] SPFbis WG scope Thread-Index: Acy+iVz1wm8TSWmgSJynl7fde57r8gAAE3BA Message-ID: References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> <4EEF2D69.9030700@tana.it> <4EEF98AE.1030102@tana.it> In-Reply-To: <4EEF98AE.1030102@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:12:28 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Monday, December 19, 2011 12:04 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] SPFbis WG scope >=20 > >> There are different extension mechanisms that provide for flagging > >> what extensions are supported or required. > > > > I don't know what a "required extension" is. >=20 > Something that means "you must support extension X in order to evaluate > Y, if you don't support X then assume Z." This is a totally foreign idea to me. Can you point me to an existing exam= ple in any protocol? > We cannot do that for version 1. However, version 3 could provide for > a feature that allows new extensions, even mandatory ones, without > requiring a new version of the protocol each time. Possibly, but do we need to spell out SPFv3 in an SPFbis charter? > The only nit with the charter is that it introduces the concept of SPF > extension, which is totally new AFAIK, /by example/, i.e. producing a > proposed extension and banning any other one, without referring what an > SPF extension actually is. (Googling for "SPF extension" I found some > SQR Portable Format whose file names end that way.) Section 6 of RFC4408 creates the extension mechanism by allowing for extens= ion modifiers (which "scope" is), though it doesn't create an IANA registry= for them. I believe SPFbis intends to fix that. -MSK From spf2@kitterman.com Mon Dec 19 12:44:38 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3B021F852E for ; Mon, 19 Dec 2011 12:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY5MTEvzXVXp for ; Mon, 19 Dec 2011 12:44:38 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E780A21F851F for ; Mon, 19 Dec 2011 12:44:37 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7CA5920E40A4; Mon, 19 Dec 2011 15:44:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324327477; bh=7qo4l9po/bU+64zLpOeuUxF3FcDnihVC4ufXVfhovho=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=mk4ZHyrDCMamfD/Qw938GOLJjMOy9aWBmE5P6qQK4EYuplRI/MZADQqBnyQCJzrkQ vFfhYcYAQ8lCf3MniHHPQW0jQZ3lxUrjW0xHaMgdnHuecwl9N2qAtEzPsxhTjXqToI IP0zItplX5glAdFBRTnoMbitcIQLFAlcg0Pm6+xI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 70A6420E4083; Mon, 19 Dec 2011 15:44:37 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 19 Dec 2011 15:44:36 -0500 Message-ID: <2338641.l5LxIQdltG@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4EEF98AE.1030102@tana.it> References: <4EEC1204.2000707@mail-abuse.org> <4EEF98AE.1030102@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 WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:44:38 -0000 On Monday, December 19, 2011 09:03:58 PM Alessandro Vesely wrote: > The only nit with the charter is that it introduces the concept of SPF > extension, which is totally new AFAIK, /by example/, i.e. producing a > proposed extension and banning any other one, without referring what > an SPF extension actually is. (Googling for "SPF extension" I found > some SQR Portable Format whose file names end that way.) It's not new at all. RFC 4408 anticipates such things via it's unknown modifier rule. There have been a number of proposals for such extensions over the years. There is one in progress in the MARF WG at the moment that looks likely to be the first one to make it to be an RFC. Scott K From dotis@mail-abuse.org Mon Dec 19 13:52:56 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D136311E809D for ; Mon, 19 Dec 2011 13:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5un78EiVH-o for ; Mon, 19 Dec 2011 13:52:55 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1599D11E8080 for ; Mon, 19 Dec 2011 13:52:54 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 81508174016F for ; Mon, 19 Dec 2011 21:52:53 +0000 (UTC) Message-ID: <4EEFB235.1040004@mail-abuse.org> Date: Mon, 19 Dec 2011 13:52:53 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> In-Reply-To: <201112191051.42604.julian@mehnle.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:52:57 -0000 On 12/19/11 2:51 AM, Julian Mehnle wrote: > Alessandro Vesely wrote: > >> Well, a point that does look somewhat obscure is the extension >> mechanism itself. It is necessary to read Julian's draft until the >> final paragraph in order to find a NOTE that explicitly states how >> extensions work in general. Recent discussion on dpf-discuss shows >> that it is not obvious how (not) supporting an extension may affect >> SPF compliance. >> >> It sounds undoubtedly self-appointing of an extension to specify the >> extension mechanism itself. > It's not like draft-mehnle-spf-scope creates new extension modifier > semantics. http://tools.ietf.org/html/rfc4408#section-6 says: > > Unrecognized modifiers MUST be ignored no matter where in a record, > or how often. This allows implementations of this document to > gracefully handle records with modifiers that are defined in other > specifications. > > So extension modifier semantics are already clearly specified in RFC 4408. > I.e., "If you don't support a non-core modifier, don't worry." > > Of course a non-core modifier has to ensure that its semantics remain > comaptible with SPF implementations that don't implement it. > draft-mehnle-spf-scope takes care of that by explicitly stating that > "v=spf1" records with "scope=" modifiers will always be applicable to > checks against the helo/mfrom identities in addition to any identities > listed in the "scope=" modifier. > > I don't see an issue here. > >> I'd rather have a section about the possibility of extensions in SPFbis. > I have no objections to clarifying the modifier semantics that are already > defined in RFC 4408. The scope of the charter should have recommended changes to better mitigate SPF related threats, especially when mechanisms posing greater concerns are seldom used. Potential incompatibilities should be weighed against added security. Even Schlitt's SPF library used reduced limits for subsequent mechanism transactions in view of potential network amplifications (x300 with 512 byte message restrictions). As such, eliminating the local-part "l" macro component, the "exists" mechanism, and separate limits on no server or no domain errors would better limit overall risks. Handling of email is highly automated where DNS plays an essential role. The volume of DNS traffic makes abuse monitoring difficult both from sourcing and mitigation perspectives. Mitigation incurs greater difficulty when a protocol can turn otherwise legitimate resolvers into DDoS agents. Such threats increase with greater DNSsec use. SPF seems unlikely to soon play an increased role. Excessive overhead is caused by combining all hosts using either IPv4 or IPv6 into resolving a common set just to potentially validate authorization of a Delivery Status Notification path. Such validation neither protects SMTP servers from abuse, users from spoofing, nor the Internet as a whole. To achieve the desired protections, cryptographic methods to authenticate SMTP servers is needed instead. IMHO, the authorization role of SPF can be safely replaced by ATSP. -Doug From dhc2@dcrocker.net Mon Dec 19 15:24:24 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CCA11E80A0 for ; Mon, 19 Dec 2011 15:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-8bawPhxmsY for ; Mon, 19 Dec 2011 15:24:23 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 92B6E11E8080 for ; Mon, 19 Dec 2011 15:24:23 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBJNOGwN020506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 15:24:22 -0800 Message-ID: <4EEFC795.4030800@dcrocker.net> Date: Mon, 19 Dec 2011 15:24:05 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> <4EEF2D69.9030700@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 19 Dec 2011 15:24:22 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 23:24:24 -0000 On 12/19/2011 11:05 AM, Murray S. Kucherawy wrote: >> -----Original Message----- From: spfbis-bounces@ietf.org >> [mailto:spfbis-bounces@ietf.org] On Behalf Of Alessandro Vesely Sent: >> Monday, December 19, 2011 4:26 AM To: spfbis@ietf.org Subject: Re: [spfbis] >> SPFbis WG scope >> >> Yes, that it said. But not loudly enough if discussion turned on what >> 2119-language should be able to ram extensions down somewhere. > > I'm at a loss to understand where all this rhetoric about forced extensions > comes from. A mandatory extension isn't an extension anymore, it becomes > part of the base protocol, and I think the charter makes it clear that this > isn't a goal of the working group. An extension can certain declare normative behavior... if the extension is in force. And the behavior can actual define modifications or new behaviors to the base protocol... if the extension is in force. Beyond that, +1 to both the distinction between 'extension' vs. change of the base, as well as the clear intent to have spfbis avoid any additions to the protocol. I believe that it is not (yet) out of scope to consider /simplifications/ to the protocol, by /removing/ features. But of course, that's a matter for group consensus. >>>> I'd rather have a section about the possibility of extensions in >>>> SPFbis. >>> >>> I have no objections to clarifying the modifier semantics that are >>> already defined in RFC 4408. >> >> Failing that, I'd suggest that it be clarified in a prominent section of >> your draft, rather than in the last paragraph. > > That's fine, and probably a good idea, but that doesn't strike me as evidence > of a problem with the charter. +1 I do think it's worth querying folks about specific items to /remove/ from SPF. I think this thread has introduced some possibilities. I suggest that folks who believe something should be removed should post a fresh note about only that one item and with its own Subject: line. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Mon Dec 19 19:31:00 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAA021F84FD for ; Mon, 19 Dec 2011 19:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBzrXvBX4WKd for ; Mon, 19 Dec 2011 19:30:59 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 82D4B21F84FC for ; Mon, 19 Dec 2011 19:30:59 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBK3UROx024259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 19:30:33 -0800 Message-ID: <4EF00147.8030509@dcrocker.net> Date: Mon, 19 Dec 2011 19:30:15 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Douglas Otis References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> <4EEFB235.1040004@mail-abuse.org> In-Reply-To: <4EEFB235.1040004@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 19 Dec 2011 19:30:43 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 03:31:00 -0000 On 12/19/2011 1:52 PM, Douglas Otis wrote: > On 12/19/11 2:51 AM, Julian Mehnle wrote: > The scope of the charter should have recommended changes to better mitigate SPF > related threats, Document them. Get community consensus about the need to 'fix' SPF. Specify candidate changes to cover them. Get community consensus that they are reasonable fixes or, at least, approaches to fixing the problems. Then deal with the fact that such changes will be enhancements and therefore will slow down standardization of SPF. Absent the above, you are, as usual, merely repeating the vague concerns that you've been expressing in many venues for many months. Perhaps I've missed the groundswell of community support for your concerns? Goodness knows there has been plenty of opportunity for it to be expressed. Absent that groundswell, this continual posting on the deficiencies of these technology looks an awful lot like a denial of service attack. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tim@eudaemon.net Mon Dec 19 20:30:37 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB8111E80C2 for ; Mon, 19 Dec 2011 20:30: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZuf7dpDuJeB for ; Mon, 19 Dec 2011 20:30:36 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id D9AC311E80B6 for ; Mon, 19 Dec 2011 20:30:36 -0800 (PST) Received: from [10.0.1.17] (adsl-98-94-128-46.ard.bellsouth.net [98.94.128.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 9F567CB46 for ; Mon, 19 Dec 2011 23:30:39 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Tim Draegen In-Reply-To: Date: Mon, 19 Dec 2011 23:30:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <74F86505-A2EF-45C0-B7FA-177F7470F07F@eudaemon.net> References: <4EEC1204.2000707@mail-abuse.org> <201112170456.36790.julian@mehnle.net> To: spfbis@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 04:30:37 -0000 On Dec 18, 2011, at 12:07 AM, Murray S. Kucherawy wrote: >> Douglas Otis wrote: >>=20 >>> Efforts to extend SPF to include PRA suffers from similar problems >>> since malefactors can use unseen PRA header fields as well. >>=20 >> There are no such efforts. >=20 > +1. >=20 > I would also add that all of the other points raised are explicitly = out of scope per the proposed charter. The discussion then needs to be = about whether the scope should change to include them, or whether = there's objection to creation of the working group altogether. As of now I'm current on this thread, and I'd like to reiterate support = for the proposed charter (I've previously published my support and = reasoning for it). I see no reason for the scope of the charter to expand to include any of = the bits in this thread. The only charter-changing proposal I could = find is: On Dec 19, 2011, at 4:52 PM, Douglas Otis wrote: > The scope of the charter should have recommended changes to better = mitigate SPF related threats, especially when mechanisms posing greater = concerns are seldom used. I'm of the mind to relegate an effort to "better mitigate SPF related = threats" to a proper research project - outside of the IETF - where "SPF = related threats" can be defined, measured, and demonstrated. To use = risk-management language -- such an effort will likely yield scenarios = that are both extremely low in probability of occurring and extremely = low cost in terms of damage. Sans real data showing otherwise, it doesn't make sense to me to change = the charter to introduce work that may or may not fix a problem that = hasn't been shown to exist yet. I'd like to reiterate my support for = the existing scope of the WG as presented in the proposed charter. -=3D Tim= From spf2@kitterman.com Mon Dec 19 21:52:48 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5B421F84A0 for ; Mon, 19 Dec 2011 21:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWhWLA2HtM1I for ; Mon, 19 Dec 2011 21:52:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 119CF21F849E for ; Mon, 19 Dec 2011 21:52:47 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9165820E4089; Tue, 20 Dec 2011 00:52:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324360365; bh=BUiEE3HkXuUz0JrFWpDf7Ya2zM4YuX+b4pDaQU3+Cm8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=F6rMYNypUAZEK6DQT4j7na/ARb6U5dw2gguQxuxyWnVWh4xY5rskqGkzVEe8Yr056 p25aCaYhnzKjAKtGxsSIQYivUzbHgv75/t01SebSwnYUheC3uOE53iNwYRr81Rj5xa EUfuJdPl3WtHPuRRjXC77nU/VM+OHQcGQYiAZIfM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6357820E4083; Tue, 20 Dec 2011 00:52:45 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 20 Dec 2011 00:52:44 -0500 Message-ID: <2068531.1KQ3N04jjg@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4EEFC795.4030800@dcrocker.net> References: <4EEC1204.2000707@mail-abuse.org> <4EEFC795.4030800@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] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 05:52:49 -0000 On Monday, December 19, 2011 03:24:05 PM Dave CROCKER wrote: > I believe that it is not (yet) out of scope to consider simplifications to > the protocol, by removing features. But of course, that's a matter for > group consensus. I think it's only in scope for features that aren't used or to resolve demonstrated operational problems. I don't think it's in scope to remove something based on theorizing that features which are in use may be in some way harmful. Scott K From hsantos@isdg.net Tue Dec 20 01:00:53 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6798521F8B17 for ; Tue, 20 Dec 2011 01:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsOFdwzChx5F for ; Tue, 20 Dec 2011 01:00:52 -0800 (PST) Received: from dkim.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 799B121F8B1A for ; Tue, 20 Dec 2011 01:00:52 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1082; t=1324371644; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ddjyOvpjQsGa//pKrWzHZHFmhlQ=; b=OdGRAmPqPrOPvI7iI71K eRc3wohtcO964Vo9YjYzTUwhdhTxsukLY/ogEhhBZ+zCEwh/GH/PXZ6lYZUa495q 2MCbMsxFP0kP/wfm22NjxoDYNa3PoOusAPWXbRocIl1/2wwFpX4bRPPx5r5bQW1I jOcEwC5F8QhtAAJQNfeyqDo= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 20 Dec 2011 04:00:44 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1868518762.15653.2904; Tue, 20 Dec 2011 04:00:43 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1082; t=1324371508; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vbxNq9P MuwIXeYZEYIny26ovoTXuR/6gYrrm1tYb98w=; b=SO4X+NqwIhzuOz5Z41ub2mM i4KG4GqvfQb8KVk0yfzUuM322d9L5EYtp0cSPZQQgNrDnHeJtdcBPyreelU66S/q dd7aU1OxlGwV3zb4g9qbgnp8L6wQTAALURmKpD6p47cet9aoDLCpbwQh60nLUrvx Jw99fOGy7PD7ZJDq9zaM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.3) for spfbis@ietf.org; Tue, 20 Dec 2011 03:58:28 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.3) with ESMTP id 2467497532.2.6948; Tue, 20 Dec 2011 03:58:26 -0500 Message-ID: <4EF04EBB.9010801@isdg.net> Date: Tue, 20 Dec 2011 04:00:43 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> <4EEFB235.1040004@mail-abuse.org> In-Reply-To: <4EEFB235.1040004@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:00:53 -0000 Douglas Otis wrote: > IMHO, the authorization role of SPF can be safely replaced by ATSP. DKIM/ADSP+ (w/ extensions) can only help non SPF setups or SPF setups with SOFT FAIL results (~ALL), not for HARD FAIL (-ALL) SPF policies. The SPF -ALL policies 100% reduces the effectiveness and need for DKIM or its related technologies. SPF still helps address the legacy abuse of NON-DKIM mail abusers and if the Author-Domain is different, it doesn't help. We need to remember the #1 benefit of SPF and DKIM technologies - you can only 100% get with false positives results with your own DOMAINS - not others. So that is the #1 need all SPF and DKIM setups must first address in their setups - first protect your own domains. While: SPF HARD FAIL policy is effectively the same as ADSP DISCARDABLE policy. SPF SOFT FAIL policy is effectively the same as ADSP ALL policy. In short, you still need both because receivers may support SPF and/or ADSP+ or both (or none). -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Tue Dec 20 01:10:08 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C99221F8AF7 for ; Tue, 20 Dec 2011 01:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej1XgXL2po4u for ; Tue, 20 Dec 2011 01:10:07 -0800 (PST) Received: from dkim.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C8D9D21F8B1A for ; Tue, 20 Dec 2011 01:10:06 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1552; t=1324372199; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lAseroyJocbZ4br9vmOzlluVNPE=; b=LHu7NxDb6Gr4sg4n75Rg BUZfoZ+XJzHq9c6zBBB9Quyr4TWVsCtlnLtjFj2hy/jE3sMDetuHrResLpGExTnF LBNxJtO9aCPFIoeBNkCiziXR9+TDCzmZsWQOfAp0/IHjmoNLBx7+VoOlFQzRwfDI 11aX7/7c1RHIUZzLAtdkA18= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 20 Dec 2011 04:09:59 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1869073892.15653.2692; Tue, 20 Dec 2011 04:09:58 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1552; t=1324372059; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DEjh6yT CgiviMUHiT4GaweTmw5BiFsTCRYNjwNk7PN4=; b=tHo9rRKdJiPTPP0c1GEz0PM VFxQrCcxQk2DxMnRyzrQfxbGWR8Y28CGtCQqh2ZBQEoGYhEIlgV5umX4F1g2XmvC Z5iYT8ynnTj8Eh9dxXEK+ok1HhQcPHxmiVwWs9G8xnaGcbKQj9mewqyrsvuEEyHW AJFMzwaDYq+ZLvMhbIyY= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.3) for spfbis@ietf.org; Tue, 20 Dec 2011 04:07:39 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.3) with ESMTP id 2468049110.2.4036; Tue, 20 Dec 2011 04:07:38 -0500 Message-ID: <4EF050E2.200@isdg.net> Date: Tue, 20 Dec 2011 04:09:54 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <201112170456.36790.julian@mehnle.net> In-Reply-To: <201112170456.36790.julian@mehnle.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 09:10:08 -0000 Julian Mehnle wrote: > Oh dear. > > Douglas Otis wrote: > >> Efforts to extend SPF to include PRA suffers from similar problems >> since malefactors can use unseen PRA header fields as well. > > There are no such efforts. > > BTW, you failed to clarify your concerns about the SPFbis WG scope as > indicated by your subject line. Are you saying this WG should not exist? Julian, in IMO, Doug's main point was missed and its one of my problems with the proposed charter. SPF is a not a payload technology and any idea that attempts to promote payload processing MUST BE carefully scrutinize for the same reasons SENDER-ID had problems. Any idea that promotes PAYLOAD transfers is going to have a problem out of the gate. Again, don't under estimate this problem and concern with the scope extension. Microsoft had to produce the SUBMITTER protocol as a compromising solution to pass the PRA to 5321 level only SPF processing. IMO, this solves the same problem you are trying to address, so I have a problem why this scope= extension is needed if SUBMITTER is already available and supported by many SPF receivers. AGAIN, whatever is consider, you are not sympathetic to the sensitive nature of avoiding payload transfers, then the adoption of this scope= extension will have a barrier and even even higher if comes with semantics that mandate any form of behavior change to preempt the SMTP processing and download the payload. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From vesely@tana.it Tue Dec 20 04:50:04 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DC121F8ADC for ; Tue, 20 Dec 2011 04:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fu8cu15YtlB for ; Tue, 20 Dec 2011 04:50:03 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 481C321F8AC9 for ; Tue, 20 Dec 2011 04:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324385401; bh=yYebFNdcO2PEagxkflbzgljc+xijKHXmEpNqIFV4kHc=; l=644; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=jzrM0yG5U3x3PDHu80rSY4gVaXHshhr54Tvzck0iGFcll2P9Av+CmKPrnyVMf4MWV RtVFq3A33D8UC7D/NejzIoz/juh8PW16i1H1T/XLbe9/8Bj1Pk+anLp6BZqslyB1FU tASeUzftQgoft2RteB5F2nVKbDJj6MWHby4ViFpM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 20 Dec 2011 13:50:01 +0100 id 00000000005DC033.000000004EF08479.00001F82 Message-ID: <4EF08478.9090704@tana.it> Date: Tue, 20 Dec 2011 13:50:00 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> <4EEF2D69.9030700@tana.it> <4EEF98AE.1030102@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 12:50:04 -0000 On 19/Dec/11 21:12, Murray S. Kucherawy wrote: > > Section 6 of RFC4408 creates the extension mechanism by allowing > for extension modifiers (which "scope" is), though it doesn't > create an IANA registry for them. I believe SPFbis intends to fix > that. I welcome the IANA registry. For the charter, I just noted that the term "extension", consistently with the wording of RFC 4408, does not appear in Julian's draft (although the short title mentions "extended scopes"). OTOH, I see no occurrence of the term "modifier" in the charter's text --the version posted on 30 Nov. I assume that's something that we can live with... From spf2@kitterman.com Tue Dec 20 08:50:30 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13621F8B70 for ; Tue, 20 Dec 2011 08:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52jQQLwTcWRx for ; Tue, 20 Dec 2011 08:50:29 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8B711E807F for ; Tue, 20 Dec 2011 08:50:29 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9F02C20E40A4; Tue, 20 Dec 2011 11:50:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324399828; bh=x+kACI198kxKCjEz6ngaOsC+5zSydZw0f/peAFYX3CA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=e20ofMyKdOOhru+utSXwYBvwIQu0OfVN8kQ0WPGERmfLaP/ZB3tQSPo0ZKap1VGFc HbulNqOzd6waiNsLWA0TXPQe+lqHiOo59LbDrlcx0KVqocdkwis3vJYyn9LZpL4xpl hzkpNENgYLh9Uk0IBpi2klmVV+cgtmCWeIPVb1wA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 859BE20E409F; Tue, 20 Dec 2011 11:50:28 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 20 Dec 2011 11:50:27 -0500 Message-ID: <1813532.at0JqPbgdg@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4EF050E2.200@isdg.net> References: <4EEC1204.2000707@mail-abuse.org> <201112170456.36790.julian@mehnle.net> <4EF050E2.200@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] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:50:30 -0000 On Tuesday, December 20, 2011 04:09:54 AM Hector Santos wrote: > Julian Mehnle wrote: > > Oh dear. > > > > Douglas Otis wrote: > >> Efforts to extend SPF to include PRA suffers from similar problems > >> since malefactors can use unseen PRA header fields as well. > > > > There are no such efforts. > > > > BTW, you failed to clarify your concerns about the SPFbis WG scope as > > indicated by your subject line. Are you saying this WG should not > > exist? > > Julian, in IMO, Doug's main point was missed and its one of my > problems with the proposed charter. > > SPF is a not a payload technology and any idea that attempts to > promote payload processing MUST BE carefully scrutinize for the same > reasons SENDER-ID had problems. I don't think that was Doug's main point at all (I'm not sure he had one, but I'm pretty sure that this isn't it). Sender ID tried to do a number of things and did many of them wrong (IMO). > Any idea that promotes PAYLOAD transfers is going to have a problem > out of the gate. The idea isn't to promote payload transfers, but if you are going to go to DATA and eat the payload anyway, is there something useful you can do. Since this is a totally opt-in approach (unlike Sender ID), I don't see an issue. > Again, don't under estimate this problem and concern with the scope > extension. Microsoft had to produce the SUBMITTER protocol as a > compromising solution to pass the PRA to 5321 level only SPF > processing. IMO, this solves the same problem you are trying to > address, so I have a problem why this scope= extension is needed if > SUBMITTER is already available and supported by many SPF receivers. None of the SPF implementations I'm aware of support it (I'm not saying there aren't implementations that do, but that the primary open source implementations don't). Since the extension being proposed for the charter doesn't use PRA, I think Submitter is irrelevant. In the end, Sender ID/PRA/Submitter can be trivially made to select an identity other than the one the user sees. The proposed extension tries to do something much narrower and I think more likely to be useful. > AGAIN, whatever is consider, you are not sympathetic to the sensitive > nature of avoiding payload transfers, then the adoption of this scope= > extension will have a barrier and even even higher if comes with > semantics that mandate any form of behavior change to preempt the SMTP > processing and download the payload. I don't think anyone is arguing anything different. Nothing in the proposed extension mandates anything about receiver policy (RFC 4408 itself is almost void of receiver policy mandates by design). Receivers will determine if they want to accept the payload or not and this extension won't affect that. Scott K From dhc2@dcrocker.net Tue Dec 20 09:17:56 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2EF21F8AB9 for ; Tue, 20 Dec 2011 09:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2U36jD+ztU9 for ; Tue, 20 Dec 2011 09:17:55 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E0EEF21F84AC for ; Tue, 20 Dec 2011 09:17:55 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBKHHnfO011855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 09:17:55 -0800 Message-ID: <4EF0C330.1000102@dcrocker.net> Date: Tue, 20 Dec 2011 09:17:36 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Scott Kitterman References: <4EEC1204.2000707@mail-abuse.org> <4EEFC795.4030800@dcrocker.net> <2068531.1KQ3N04jjg@scott-latitude-e6320> In-Reply-To: <2068531.1KQ3N04jjg@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 20 Dec 2011 09:17:55 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:17:56 -0000 On 12/19/2011 9:52 PM, Scott Kitterman wrote: > I think it's only in scope for features that aren't used or to resolve > demonstrated operational problems. I don't think it's in scope to remove > something based on theorizing that features which are in use may be in some > way harmful. Scott, the above is helpful. It suggests criteria and that's what I think we should discuss and agree on. Determining factual points, such as what is or is not used, can be a challenge, but at least the question is about objective points rather than opinions about wonderfulness. My own view of criteria: 1. Unused A feature that has not yet received a significant degree of use should be dropped. For a feature that creates significant complexity, it is actually important to drop it, since complexity invites programming and operations errors. Examples of complexity are recursion, indirection or complicated decision-trees. 2. Problematic Features that have established a pattern of causing significant, widespread problems for which there are no obvious fixes. 3. Specification Clarity This is /not/ a basis for removing something, unless we find that we cannot figure out how to write a clear specification. Improving specification clarity is, in fact, the primary constructive work of this phase in a specification's life. I don't know how Scott's above second sentence relates to the list. I'm not sure what is meant by 'theorizing', but I'll take a guess: Something has not yet established a pattern of causing problems (or benefit) but a static analysis points in the direction that it will or should. My own opinion is that if something is used and has not already demonstrated a pattern of being problematic, it is not a reasonable candidate for removal, no matter how much some folk might wish to remove it. The particular basis for retention is stability: we need to make as few changes to the operational base as we can reasonably get away with. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From wwwrun@ietfa.amsl.com Tue Dec 20 09:18:05 2011 Return-Path: X-Original-To: spfbis@ietf.org Delivered-To: spfbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id D69BA21F8ABD; Tue, 20 Dec 2011 09:18:05 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> Date: Tue, 20 Dec 2011 09:18:05 -0800 (PST) Cc: spfbis@ietf.org Subject: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iesg@ietf.org List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:18:06 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, December 27, 2011 SPF Update (spfbis) ----------------------------------------- Status: Proposed Working Group Last Updated: 2011-12-09 Chair(s): TBD Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion:spfbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis Archive: http://www.ietf.org/mail-archive/web/spfbis/ Description of Working Group: The Sender Policy Framework (SPF, RFC4408) specifies the publication of a DNS record which states that a listed IP address is authorized to send mail on behalf of the listing domain name's owner. SMTP servers extract the domain name in the SMTP "MAIL FROM" or "HELO" command for confirming this authorization. The protocol has had Experimental status for some years and has become widely deployed. This working group will revise the specification, based on deployment experience and listed errata, and will seek Standards Track status for the protocol. The MARID working group created two specifications for publication of email-sending authorization: Sender-ID (RFFC4405, RFC4406 and RFC4407) and SPF (RFC4408), with both having Experimental status. By using IP addresses, both protocols specify authorization in terms of path, though unlike SPF, Sender-ID uses domain names found in the header of the message rather than the envelope. The two protocols rely on the same policy publication mechanism, namely a specific TXT resource record in the DNS. This creates a basic ambiguity about the interpretation of any specific instance of the TXT record. Because of this, there were concerns about conflicts between the two in concurrent operation. The IESG Note added to each invited an expression of community consensus in the period following these publications. Both enjoyed initially large deployments. Broad SPF use continues, and its linkage to the envelope -- rather than Sender-ID's linkage to identifiers in the message content -- has proven sufficient among operators. This concludes the experiment. Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. The working group will also produce a document describing the course of the SPF/Sender-ID experiment (defined in the IESG note on the RFCs in question), bringing that experiment to a formal conclusion. No other work on Sender-ID will be done. Finally, the working group will develop the proposed "scope" extension found in draft-mehnle-spfbis-scope. Specifically out-of-scope for this working group: * Revisiting past technical arguments that were covered in the MARID working group, except where review is reasonably warranted based on operational experience. * Discussion of the merits of SPF. * Discussion of the merits of Sender-ID in preference to SPF. * Extensions to SPF other than the one specified above. The working group will re-charter to process other specific proposed extensions as they are identified. The initial draft set: draft-kitterman-4408bis draft-mehnle-spfbis-scope Goals and Milestones: MMM YYYY: A standards track document defining SPF, based on RFC4408 and as amended above, to the IESG for publication. MMM YYYY: A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication. MMM YYYY: A standards track document creating the "scope" extension to the IESG for publication. From dhc2@dcrocker.net Tue Dec 20 09:19:30 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0A521F8AD3 for ; Tue, 20 Dec 2011 09:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYZW4lGI8Rnr for ; Tue, 20 Dec 2011 09:19:30 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0435221F8ABB for ; Tue, 20 Dec 2011 09:19:30 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBKHJOea011919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Dec 2011 09:19:29 -0800 Message-ID: <4EF0C38E.8040709@dcrocker.net> Date: Tue, 20 Dec 2011 09:19:10 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <201112170456.36790.julian@mehnle.net> <4EF050E2.200@isdg.net> <1813532.at0JqPbgdg@scott-latitude-e6320> In-Reply-To: <1813532.at0JqPbgdg@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 20 Dec 2011 09:19:29 -0800 (PST) Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:19:30 -0000 On 12/20/2011 8:50 AM, Scott Kitterman wrote: > I don't think that was Doug's main point at all (I'm not sure he had one, but > I'm pretty sure that this isn't it). Trying to guess or assert what someone else meant is almost never productive. In fact, it's often the path down a rathole. Either they've said things clearly or they haven't. It's their responsibility to offer clear statements and to recruit support for them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Tue Dec 20 09:24:48 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9146B21F8A66; Tue, 20 Dec 2011 09:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf93ItEC8JLs; Tue, 20 Dec 2011 09:24:48 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 01AF121F8888; Tue, 20 Dec 2011 09:24:47 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBKHOgxj012107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 09:24:47 -0800 Message-ID: <4EF0C4CC.7030204@dcrocker.net> Date: Tue, 20 Dec 2011 09:24:28 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: iesg@ietf.org References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> In-Reply-To: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 20 Dec 2011 09:24:47 -0800 (PST) Cc: spfbis@ietf.org, Murray Kucherawy Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:24:48 -0000 On 12/20/2011 9:18 AM, IESG Secretary wrote: > A new IETF working group has been proposed in the Applications Area. > The IESG has not made any determination as yet. The following draft > charter was submitted, and is provided for informational purposes only. > Please send your comments to the IESG mailing list (iesg@ietf.org) SPF is very widely used. It has become a critical component in the anti-spam toolchest. It's documentation needs refining and its technical details probably need refining. An open, consensus-based process is needed for making these changes. The IETF is by far the most reasonable place for this work. I say the above in spite of not liking SPF and of having frequently criticized it quite publicly, due to it's path-based approach and the limitations this imposes. However the reality is that it's wide use mandates having a good spec and the demonstrable community consensus around it; and I'm willing to contribute to that effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Tue Dec 20 09:46:14 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4BD11E808C for ; Tue, 20 Dec 2011 09:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lsqtrt+oF3uD for ; Tue, 20 Dec 2011 09:46:13 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 938DC11E8073 for ; Tue, 20 Dec 2011 09:46:13 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1747220E40A4; Tue, 20 Dec 2011 12:46:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324403173; bh=GEJUxk59iDPN0Wy5JmhCcMMwLBvkJDZaxbBnlNLVPJg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=emN+hdCSO06aloAWa5AK76V+BUEJrU54GuVFh7oQ0W2ieWjEB9tF4sDxJgsKvUW+Z 5PCCvmGS7geLdJeIhczFjIQykYitS6gsoJFy3uXxGJgiDS2y+VaoST1bop2JeggLY3 TVKQiW6TKWpPDlBOuwuOUx9Pu/GLwyDGbRVNWKHg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F1C1320E409F; Tue, 20 Dec 2011 12:46:12 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 20 Dec 2011 12:46:12 -0500 Message-ID: <8548779.Vr1unqaOTE@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4EF0C330.1000102@dcrocker.net> References: <4EEC1204.2000707@mail-abuse.org> <2068531.1KQ3N04jjg@scott-latitude-e6320> <4EF0C330.1000102@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] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:46:14 -0000 On Tuesday, December 20, 2011 09:17:36 AM Dave CROCKER wrote: > On 12/19/2011 9:52 PM, Scott Kitterman wrote: > > I think it's only in scope for features that aren't used or to resolve > > demonstrated operational problems. I don't think it's in scope to > > remove > > something based on theorizing that features which are in use may be in > > some way harmful. > > Scott, the above is helpful. It suggests criteria and that's what I think > we should discuss and agree on. Thanks. > Determining factual points, such as what is or is not used, can be a > challenge, but at least the question is about objective points rather than > opinions about wonderfulness. Agreed. > > My own view of criteria: > > > 1. Unused > > A feature that has not yet received a significant degree of use should > be dropped. > > For a feature that creates significant complexity, it is actually > important to drop it, since complexity invites programming and operations > errors. Examples of complexity are recursion, indirection or complicated > decision-trees. Fortunately, for SPF, I think most of the questions around feature use can be resolved by examining SPF records published in DNS, so there's no need to guess about what people are using. We do need to keep in mind that sometimes a feature might be not used broadly, but very significant for specific use cases. Since there are multiple independent implementations that are available for inspection, I think determining if features are problematic to implement is a tractable problem. > 2. Problematic > > Features that have established a pattern of causing significant, > widespread problems for which there are no obvious fixes. Agreed. > > 3. Specification Clarity > > This is /not/ a basis for removing something, unless we find that we > cannot figure out how to write a clear specification. Improving > specification clarity is, in fact, the primary constructive work of this > phase in a specification's life. Fortunately a lot of work around this has been done already. Based on a paragraph by paragraph (and in some cases line by line) review of RFC 4408, the people active in SPF development at the time produced a test suite: http://www.openspf.net/Test_Suite This is meant to provide data inputs and outputs for protocol compliance. Where there were differing opinions about the specified output, they were documented and a preferred result defined based on the rough consensus of the people doing the work. This test suite has been used by at least three independent SPF library implementations (for Perl, Python, and Java). Based on that body of work, there is already a good basis for consideration of where the specification needs refinement. > I don't know how Scott's above second sentence relates to the list. I'm not > sure what is meant by 'theorizing', but I'll take a guess: Something has > not yet established a pattern of causing problems (or benefit) but a static > analysis points in the direction that it will or should. Or that some people think it will. SPF has been in widespread use long enough now that I believe that the potential for major operational suprises with the current protocol is small. > My own opinion is that if something is used and has not already demonstrated > a pattern of being problematic, it is not a reasonable candidate for > removal, no matter how much some folk might wish to remove it. The > particular basis for retention is stability: we need to make as few > changes to the operational base as we can reasonably get away with. Agreed. Scott K From spf2@kitterman.com Tue Dec 20 09:51:35 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB85C11E80C3; Tue, 20 Dec 2011 09:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1NKNaXP1W-u; Tue, 20 Dec 2011 09:51:35 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE1D11E80A2; Tue, 20 Dec 2011 09:51:34 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4CF7920E40A4; Tue, 20 Dec 2011 12:51:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324403494; bh=AejhiO7ecSbK7EYkuSArsySEpWNh07gVHe3F8shBZ1w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=AIrhWzhAQOIMd/y+uUoQ2iuG07cJI9io9narzLGfjlxC4o49vV6yLFQdqy/H6dVyv 6/EqpWcHY4/OBfWnLL+9rQtKIYVs/2mU1eX0UdezVxWPhVAhWzAYT2vO6lN5p2Hhlj jN3wbmR0i8XXp22k+MnswraHWpjv05zcPJDvX75U= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 33E2120E409F; Tue, 20 Dec 2011 12:51:28 -0500 (EST) From: Scott Kitterman To: iesg@ietf.org Date: Tue, 20 Dec 2011 12:51:27 -0500 Message-ID: <1937678.bI8tqt9cuB@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:51:36 -0000 On Tuesday, December 20, 2011 09:18:05 AM IESG Secretary wrote: > A new IETF working group has been proposed in the Applications Area. > The IESG has not made any determination as yet. The following draft > charter was submitted, and is provided for informational purposes only. > Please send your comments to the IESG mailing list (iesg@ietf.org) by > Tuesday, December 27, 2011 > > SPF Update (spfbis) > ----------------------------------------- > Status: Proposed Working Group > Last Updated: 2011-12-09 ... I support the proposed charter. I prepared one of the proposed input documents for the working ground and am interested in continuing this work. Scott Kitterman From hsantos@isdg.net Tue Dec 20 09:52:39 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9286B21F8A71 for ; Tue, 20 Dec 2011 09:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tabMdk1oieUK for ; Tue, 20 Dec 2011 09:52:38 -0800 (PST) Received: from mail.santronics.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 47F6521F84FA for ; Tue, 20 Dec 2011 09:52:37 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3875; t=1324403551; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=tJVOtrGR05o9dlt8AIbPLdi6SUY=; b=u4jSHn/8+rYPvI68mFyF tqVeGbr7orEbhTC/5HSCngVxQX/6rxvnPDmPaGsf1gxjNbGp7NuwoihysJymynNf /fzNP0tULHl4TyD2Jz22SeOE4n6j0aZTr/hbrjb2a0MtckcFmPGlNi+evi6ZaTy8 23B17jMO8hXJtz+XHy5VnCk= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 20 Dec 2011 12:52:31 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1900425288.15653.1372; Tue, 20 Dec 2011 12:52:30 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3875; t=1324403414; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=t5DTC2a rSMbW1XzNrpR5dSpalHBN55ee+UND2UGiqZo=; b=uZTDts8NVljTwi6f5Gf47lJ 9u8OTIeG7HQdebEKNSx/XahQbUOJIGassHuta3KBMtKmFlYgagOC9TD521mL+JC2 6wjZkVcUuun6acNfIbD0fiLpJPRFc9slcQiq2tivdeeABJsX5dV68dTuq5FTpFZh i3IhHfgeLPSZD7ZrXO7E= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.3) for spfbis@ietf.org; Tue, 20 Dec 2011 12:50:14 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.3) with ESMTP id 2499403985.9.2076; Tue, 20 Dec 2011 12:50:13 -0500 Message-ID: <4EF0CB5C.5020009@isdg.net> Date: Tue, 20 Dec 2011 12:52:28 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <201112170456.36790.julian@mehnle.net> <4EF050E2.200@isdg.net> <1813532.at0JqPbgdg@scott-latitude-e6320> In-Reply-To: <1813532.at0JqPbgdg@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:52:39 -0000 Scott Kitterman wrote: >> Any idea that promotes PAYLOAD transfers is going to have a problem >> out of the gate. > > The idea isn't to promote payload transfers, but if you are going to go to > DATA and eat the payload anyway, is there something useful you can do. Since > this is a totally opt-in approach (unlike Sender ID), I don't see an issue. It's an issue depending on the RFC 2119 language that will be used and a new market of people using something that will not be supported widely unless there is a strong "recommendation" to support it. In other words, will people depend on scope= tag usage and prepare correct author-domain::ip associations and will ignore correct return-path-domain::ip associations? I say that is exactly what is going to happen and high likelihood of experiencing more failures. > None of the SPF implementations I'm aware of support it (I'm not saying there > aren't implementations that do, but that the primary open source > implementations don't). We supported SUBMITTER since the beginning and I have years of logs that show clients are indeed sending the SUBMITTER= keyword with the 5321.Mail From command. In fact, it is so prevalent that we have to make sure it recorded and remains persistent in any sort of forwarding with additional mail software. > Since the extension being proposed for the charter > doesn't use PRA, I think Submitter is irrelevant. And thats another concern of mine where we begin to decide things because if one owns knowledge of what's happening and doesn't reflect the total market. The PRA "Purported Responsible Author" for the most part is the AUTHOR-DOMAIN. > In the end, Sender > ID/PRA/Submitter can be trivially made to select an identity other than the > one the user sees. The proposed extension tries to do something much narrower > and I think more likely to be useful. I disagree its more narrower because it will only work by pushing a PAYLOAD download requirement. Otherwise it is useless, and that fact is very troublesome and material for an appeal. Opt-in or not, its changes the SPF protocol and if you have options like this, it will be used and that changes the framework of the protocol unlike what SPF + SUBMITTER did. >> AGAIN, whatever is consider, you are not sympathetic to the sensitive >> nature of avoiding payload transfers, then the adoption of this scope= >> extension will have a barrier and even even higher if comes with >> semantics that mandate any form of behavior change to preempt the SMTP >> processing and download the payload. > > I don't think anyone is arguing anything different. Nothing in the proposed > extension mandates anything about receiver policy (RFC 4408 itself is almost > void of receiver policy mandates by design). Receivers will determine if they > want to accept the payload or not and this extension won't affect that. I disagree. If you put something in the spec that will only work by requiring the payload, then that inherently begins to change the fundamental framework of SPF. Many systems will reject at the SMTP level and not allow the DATA state to be reached. This extension is proposing to change that and thats very troublesome and I don't think this is BIS work. You will have to use an v=SP3 and if SP3 is stronger in mandating the payload download, not because you are not saying it is, but rather it is the only purpose to make it work, we now have compliancy issues with those that may want to use the clean BIS improvements and ignore this scope extension. At the end of the day, this is violating the boundary layers and it will certainly be problematic and indicating its "opt-in" is not an excuse for breaking the SPF protocol fundamentally. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dhc2@dcrocker.net Tue Dec 20 10:01:06 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3081B21F8ABD for ; Tue, 20 Dec 2011 10:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROJ6BGFXSB7O for ; Tue, 20 Dec 2011 10:01:05 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 82EB321F8AB9 for ; Tue, 20 Dec 2011 10:01:05 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBKI0wT5012815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 10:01:04 -0800 Message-ID: <4EF0CD4C.7090701@dcrocker.net> Date: Tue, 20 Dec 2011 10:00:44 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Scott Kitterman References: <4EEC1204.2000707@mail-abuse.org> <2068531.1KQ3N04jjg@scott-latitude-e6320> <4EF0C330.1000102@dcrocker.net> <8548779.Vr1unqaOTE@scott-latitude-e6320> In-Reply-To: <8548779.Vr1unqaOTE@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 20 Dec 2011 10:01:05 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:01:06 -0000 On 12/20/2011 9:46 AM, Scott Kitterman wrote: > On Tuesday, December 20, 2011 09:17:36 AM Dave CROCKER wrote: > Fortunately, for SPF, I think most of the questions around feature use can be > resolved by examining SPF records published in DNS, so there's no need to > guess about what people are using. Hmmm. That's certainly the best place to start. I'm wondering whether it is always definitive? Often choices are made by default rather than intent, such as copying someone else's files. In addition, there's the small question of whether the receive-side pays attention to the usage. If something is widely used by publishers but widely /ignored/ by receivers, what is the justification for retaining it? > We do need to keep in mind that sometimes > a feature might be not used broadly, but very significant for specific use > cases. Right. And trying to understand market /segments/ can be a challenge. But it's certainly important to try, for the reason you cite. >> 3. Specification Clarity >> >> This is /not/ a basis for removing something, unless we find that we >> cannot figure out how to write a clear specification. Improving >> specification clarity is, in fact, the primary constructive work of this >> phase in a specification's life. > > Fortunately a lot of work around this has been done already. Ack. My list was for due-diligence on the question of criteria, not to imply anything about SPF particulars (yet...) >> I don't know how Scott's above second sentence relates to the list. I'm not >> sure what is meant by 'theorizing', but I'll take a guess: Something has >> not yet established a pattern of causing problems (or benefit) but a static >> analysis points in the direction that it will or should. > > Or that some people think it will. SPF has been in widespread use long enough > now that I believe that the potential for major operational suprises with the > current protocol is small. The mere passage of time and even the mere fact of widespread use are not necessarily definitive proof that there will be no new surprises. Certainly extensive time and use provide a prima facie case, but we should explore any concerns that do get raised for plausible dangers. Anyone believing there are new surprising lurking has the responsibility to make their case and make it compelling. The rest of us have the responsibility to consider the concern constructively, rather than be too quick to dismiss the concern. Again, I'm being formally diligent here, not claiming any expectation about SPF. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Tue Dec 20 10:01:08 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC1611E808C for ; Tue, 20 Dec 2011 10:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Sv0Tp3WTI9U for ; Tue, 20 Dec 2011 10:01:07 -0800 (PST) Received: from mail.santronics.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 52AB811E8089 for ; Tue, 20 Dec 2011 10:01:07 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1023; t=1324404057; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=N86IzNeiIXEq/9M2biraUmrKnCQ=; b=kV9qYrD+bpn+3Gz1wqpa 4WLyrVEKT5Ceh978e/SlQ5bUrOl+8sowfpS7pzNIQCBb732E81gH2dIHaoggGlwo ihdDYk1HUFJZK7fuuT8ybT5UCdV7sTmmdrjyc9Hk25LQiWRZLeOgH6IWkCn7qK54 Zv/j/DhMajjFbZqmrJ7sj50= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 20 Dec 2011 13:00:57 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1900931246.15653.1864; Tue, 20 Dec 2011 13:00:55 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1023; t=1324403916; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=QB7Hfpq CBz5Em17gJi66P9bIL7UGL131p13u/sGbLA8=; b=X2oGYdwVPwtfYODXMtpcL+t 6MXE+Niz8st8Ws2cBnoD/GIoZxkuj4DG6JEoIOc+L4pVL3mt7ePWPVVipjsBVdlS C/kpSpUE0FvS/z1c/Q8Bu1EVe5i97YiSg5Ai3iy/45nB5x2AVB1ZpwmMAJDGGHuA oEQj8t4wKDvb2QXGh/cw= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.3) for spfbis@ietf.org; Tue, 20 Dec 2011 12:58:36 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.3) with ESMTP id 2499905625.9.3744; Tue, 20 Dec 2011 12:58:34 -0500 Message-ID: <4EF0CD53.2000909@isdg.net> Date: Tue, 20 Dec 2011 13:00:51 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: iesg@ietf.org References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> In-Reply-To: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:01:08 -0000 IESG Secretary wrote: > A new IETF working group has been proposed in the Applications Area. > The IESG has not made any determination as yet. The following draft > charter was submitted, and is provided for informational purposes only. > Please send your comments to the IESG mailing list (iesg@ietf.org) by > Tuesday, December 27, 2011 I support a SPF BIS project effort to codify RFC 4408 but I have a fundamental problem with new extension ideas that will fundamentally change the SPF protocol from a SMTP level only protocol to a RFC5322 payload download requirement protocol. Something that is not required in SPF and was specifically design not to have since the MARID days. This new protocol introduction violates the boundary layer, increases overhead and redundancy concerns and increases security concerns - all of which was discussed during MARID and the reasons why SPF did not have a PAYLOAD requirement. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From tim@eudaemon.net Tue Dec 20 10:01:15 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE5D11E80A2; Tue, 20 Dec 2011 10:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PITV40naAQPe; Tue, 20 Dec 2011 10:01:15 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 02B0811E807F; Tue, 20 Dec 2011 10:01:14 -0800 (PST) Received: from [192.168.82.190] (unknown [64.147.222.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 02F5DCB46; Tue, 20 Dec 2011 13:01:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Draegen In-Reply-To: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> Date: Tue, 20 Dec 2011 13:01:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9D9A1973-5714-41F1-8B40-96445E8DB127@eudaemon.net> References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> To: iesg@ietf.org X-Mailer: Apple Mail (2.1251.1) Cc: spfbis@ietf.org Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:01:15 -0000 On Dec 20, 2011, at 12:18 PM, IESG Secretary wrote: > Please send your comments to the IESG mailing list (iesg@ietf.org) by=20= > Tuesday, December 27, 2011 =20 >=20 > SPF Update (spfbis) I'm an advocate for this technology, and believe the IETF where this = work needs to happen. SPF is already widely-deployed. For context, SPF is cited in a 2007 document that prescribes how = financial institutions can bring security to email: http://www.bits.org/ http://www.bits.org/publications/security/BITSSecureEmailApr2007.pdf Although it has taken a number of years to become widely deployed, *at a = minimum* major financial services organizations are looking to build = upon SPF. Significant up-tick in adoption shows that the time is right = to progress SPF: https://otalliance.org/news/releases/EmailAuthTPoint.html Several reasons why this works needs to happen: - Hesitation to deploy remains in some areas due to the Experimental = state of the current SPF document. - A whole lot of operational experience and deployment data has been = gathered since the SPF and Sender-ID documents were released as = Experimental. - Bringing closure to existing Experimental documentation will produce = documents that will inform future developments. - Without such closure, the task of focusing development efforts to = produce systems that take advantage of SPF's capabilities will remain = unnecessarily hindered. =3D- Tim Draegen Director of Technical Strategy, Agari Chair of the Online Trust Alliance's Email Authentication Committee From dhc2@dcrocker.net Tue Dec 20 10:06:26 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BB721F877F; Tue, 20 Dec 2011 10:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyVWBGrbY-ko; Tue, 20 Dec 2011 10:06:26 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2C221F8ABB; Tue, 20 Dec 2011 10:06:26 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBKI6ILd012915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 10:06:25 -0800 Message-ID: <4EF0CE8D.4000100@dcrocker.net> Date: Tue, 20 Dec 2011 10:06:05 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: iesg@ietf.org References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> In-Reply-To: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 20 Dec 2011 10:06:26 -0800 (PST) Cc: spfbis@ietf.org, IESG Secretary , IETF Announcement list Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:06:26 -0000 small nit: > The initial draft set: > draft-kitterman-4408bis > draft-mehnle-spfbis-scope The second document currently is: draft-mehnle-spf-scope-00 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Tue Dec 20 10:14:53 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76FE21F85EF; Tue, 20 Dec 2011 10:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.079 X-Spam-Level: X-Spam-Status: No, score=-102.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErVdcVrAmE1R; Tue, 20 Dec 2011 10:14:52 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D29A121F85A7; Tue, 20 Dec 2011 10:14:52 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Dec 2011 10:14:50 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 20 Dec 2011 10:14:52 -0800 From: "Murray S. Kucherawy" To: "iesg@ietf.org" Date: Tue, 20 Dec 2011 10:14:50 -0800 Thread-Topic: [spfbis] WG Review: SPF Update (spfbis) Thread-Index: Acy/O1fV+Z7+tRKoSLipo0/nfEjM2QAB2/jw Message-ID: References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> In-Reply-To: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:14:53 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of IESG Secretary > Sent: Tuesday, December 20, 2011 9:18 AM > To: IETF Announcement list > Cc: spfbis@ietf.org > Subject: [spfbis] WG Review: SPF Update (spfbis) >=20 > A new IETF working group has been proposed in the Applications Area. > The IESG has not made any determination as yet. The following draft > charter was submitted, and is provided for informational purposes only. > Please send your comments to the IESG mailing list (iesg@ietf.org) by > Tuesday, December 27, 2011 > [...] I support the current charter, enough that I was the primary author of it. = I'm also willing to co-chair, edit documents, review documents, or be a ge= neral participant. I also echo Dave Crocker's comments that for me this is= more about doing The Right Thing with respect to the status of SPF, and no= t that I'm a particular proponent of it technically. I also find there is no basis for the concerns about fundamental changes to= the SPF protocol. The charter specifically proscribes these, though it pe= rmits the eventual creation of extensions, which are, by the very nature of= anything called an "extension", optional. -MSK From msk@cloudmark.com Tue Dec 20 10:17:05 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D9A21F845E for ; Tue, 20 Dec 2011 10:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9IUSikUzDiK for ; Tue, 20 Dec 2011 10:17:04 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9D87421F844F for ; Tue, 20 Dec 2011 10:17:04 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Dec 2011 10:17:02 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 20 Dec 2011 10:17:04 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 20 Dec 2011 10:17:03 -0800 Thread-Topic: [spfbis] SPFbis WG scope Thread-Index: Acy/Fe8jBghkzxUOSkS/u/ll9Bsy0gALYwWQ Message-ID: References: <4EEC1204.2000707@mail-abuse.org> <4EEF10A9.2030808@tana.it> <201112191051.42604.julian@mehnle.net> <4EEF2D69.9030700@tana.it> <4EEF98AE.1030102@tana.it> <4EF08478.9090704@tana.it> In-Reply-To: <4EF08478.9090704@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:17:05 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Tuesday, December 20, 2011 4:50 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] SPFbis WG scope >=20 > On 19/Dec/11 21:12, Murray S. Kucherawy wrote: > > Section 6 of RFC4408 creates the extension mechanism by allowing for > > extension modifiers (which "scope" is), though it doesn't create an > > IANA registry for them. I believe SPFbis intends to fix that. >=20 > I welcome the IANA registry. >=20 > For the charter, I just noted that the term "extension", consistently > with the wording of RFC 4408, does not appear in Julian's draft > (although the short title mentions "extended scopes"). OTOH, I see no > occurrence of the term "modifier" in the charter's text --the version > posted on 30 Nov. I assume that's something that we can live with... A modifier in SPF terms is an extension in general terms. So yes, I think = that mushy language is tolerable at this point. We can just be careful how= they're spelled out in the drafts. From msk@cloudmark.com Tue Dec 20 10:21:41 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABC021F85B8 for ; Tue, 20 Dec 2011 10:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5t0kmj0MtZq for ; Tue, 20 Dec 2011 10:21:40 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A115021F85AE for ; Tue, 20 Dec 2011 10:21:40 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Dec 2011 10:21:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 20 Dec 2011 10:21:40 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 20 Dec 2011 10:21:38 -0800 Thread-Topic: [spfbis] SPFbis WG scope Thread-Index: Acy/O1YvrVBBYMuSQKOvDmT1z3vP9AACG4AQ Message-ID: References: <4EEC1204.2000707@mail-abuse.org> <4EEFC795.4030800@dcrocker.net> <2068531.1KQ3N04jjg@scott-latitude-e6320> <4EF0C330.1000102@dcrocker.net> In-Reply-To: <4EF0C330.1000102@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:21:41 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dave CROCKER > Sent: Tuesday, December 20, 2011 9:18 AM > To: Scott Kitterman > Cc: spfbis@ietf.org > Subject: Re: [spfbis] SPFbis WG scope >=20 > Scott, the above is helpful. It suggests criteria and that's what I > think we should discuss and agree on. >=20 > Determining factual points, such as what is or is not used, can be a > challenge, but at least the question is about objective points rather > than opinions about wonderfulness. >=20 > My own view of criteria: >=20 > 1. Unused >=20 > A feature that has not yet received a significant degree of use > should be dropped. >=20 > For a feature that creates significant complexity, it is actually > important to drop it, since complexity invites programming and > operations errors. Examples of complexity are recursion, indirection > or complicated decision-trees. For a real world example, between RFC4871 and RFC6376, DKIM dropped "g=3D" = from key records. Observation of signatures received over a long period sh= owed near-zero use of that feature. Are there any installations that are collecting the properties of observed = SPF records that might be able to tally up which modifiers/extensions/whate= ver are actually in use out there? If not, could such be constructed easil= y? > 3. Specification Clarity >=20 > This is /not/ a basis for removing something, unless we find that w= e > cannot figure out how to write a clear specification. Improving specific= ation > clarity is, in fact, the primary constructive work of this phase in a > specification's life. One thing that might be worth clarifying, which has already come up, is the= "modifier" vs. "extension" point. I think it's fine the way it is, but Al= essandro's pointed out the potential for a mis-read. We might want to take= a run at fixing that, and be careful about naming the proposed IANA Regist= ry, etc. -MSK From hsantos@isdg.net Tue Dec 20 10:34:03 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040D911E8083 for ; Tue, 20 Dec 2011 10:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhHOQSLOHOEO for ; Tue, 20 Dec 2011 10:34:02 -0800 (PST) Received: from ftp.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 182C111E8073 for ; Tue, 20 Dec 2011 10:34:01 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2781; t=1324406039; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KSwwn8aGDQSExx5yHdHYbQhLIn0=; b=Png6P/0jFfgsUp+yk3eO 2cM+ryZxVX1cYyRNRVJhMy4N0Yaql520b8NVLjDbB1oTryR7IlL+wQxzYPMsyBdB oSjUp9tbETtLFXhlPCJhshEKDU5bRc7Dk8kalxKA8kfcm/uhTP0kSQ6pzdtBm3PE SLYQoqY5M2YpSOaFFzBkWHc= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 20 Dec 2011 13:33:59 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1902913613.15653.3548; Tue, 20 Dec 2011 13:33:58 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2781; t=1324405902; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=w0tDvkK JIg9t3oBnbO6RrBXeGWcAZQtaSVSojQl7jIU=; b=Wcjvwj6RWeJDWYNk3wGGHAz A/hwi+lgnm7YczGU4jgr1UP1iBdoWt5aSTroLDE50MIFwGz5x95KCOsGOMOrs8Rl MOOvZ6UuVV8n29PPyVwxz1RqDnwBVDbmZauy10JCCQa2HGzt8sAMJt7bbIufjOcP NTyBQr+J6W1rk6KfPANs= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.3) for spfbis@ietf.org; Tue, 20 Dec 2011 13:31:42 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.3) with ESMTP id 2501891641.9.6292; Tue, 20 Dec 2011 13:31:40 -0500 Message-ID: <4EF0D516.4000504@isdg.net> Date: Tue, 20 Dec 2011 13:33:58 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "iesg@ietf.org" , "spfbis@ietf.org" References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:34:03 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of IESG Secretary >> Sent: Tuesday, December 20, 2011 9:18 AM >> To: IETF Announcement list >> Cc: spfbis@ietf.org >> Subject: [spfbis] WG Review: SPF Update (spfbis) >> >> A new IETF working group has been proposed in the Applications Area. >> The IESG has not made any determination as yet. The following draft >> charter was submitted, and is provided for informational purposes only. >> Please send your comments to the IESG mailing list (iesg@ietf.org) by >> Tuesday, December 27, 2011 >> [...] > > I support the current charter, enough that I was the primary author of it. I'm also willing to co-chair, edit documents, review documents, or be a general participant. I also echo Dave Crocker's comments that for me this is more about doing The Right Thing with respect to the status of SPF, and not that I'm a particular proponent of it technically. This is a fundamentally a problem. One must not have any BIAS and must believe in the technology in order to be the WG project leader. Case in point.... > I also find there is no basis for the concerns about fundamental changes to > the SPF protocol. Thats exactly the problem. You wrote the charter, you have a documented history on being a vocal SPF opponent. You will have a major problem in this WG with people who are long time early adopters and implementators of SPF who does not agree which items in the proposed charter. You also have a history of filtering, ignoring, water down opposing viewpoints and thus I do not agree you qualify to be the chair for this proposed SPF BIG Working Group. > The charter specifically proscribes these, though it permits the eventual > creation of extensions, which are, by the very nature of anything called an > "extension", optional. But that is not an excuse to fundamentally change the protocol, violating the protocol SMTP level only framework to one that requires RFC5322 payload downloads - something that was 100% debates and restricted during 2003/2004 MARID working group producing the SPF RFC 4408 document and reason the RFC4405 SUBMITTER SMTP extension to specifically address the AUTHOR-DOMAIN needs this new SPF extension is duplicating but without exposing the author-domain, thus requiring a payload download requirement. You MUST have a understanding of MARID discussions and debates, the SPF history, the reasons it is a SMTP level only technology and why it is not a RFC5322 technology, and also be a believer of the protocol in order to be trusted as a chair and leader of this project. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dhc2@dcrocker.net Tue Dec 20 10:37:58 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9561611E8083 for ; Tue, 20 Dec 2011 10:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzOo2eOoIj2O for ; Tue, 20 Dec 2011 10:37:58 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 015E411E8073 for ; Tue, 20 Dec 2011 10:37:57 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBKIbpTY013721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 10:37:57 -0800 Message-ID: <4EF0D5F1.1080101@dcrocker.net> Date: Tue, 20 Dec 2011 10:37:37 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4EEC1204.2000707@mail-abuse.org> <4EEFC795.4030800@dcrocker.net> <2068531.1KQ3N04jjg@scott-latitude-e6320> <4EF0C330.1000102@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 20 Dec 2011 10:37:57 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:37:58 -0000 On 12/20/2011 10:21 AM, Murray S. Kucherawy wrote: >> 3. Specification Clarity >> > >> > This is/not/ a basis for removing something, unless we find that we >> > cannot figure out how to write a clear specification. Improving specification >> > clarity is, in fact, the primary constructive work of this phase in a >> > specification's life. > One thing that might be worth clarifying, which has already come up, is the "modifier" vs. "extension" point. I think it's fine the way it is, but Alessandro's pointed out the potential for a mis-read. We might want to take a run at fixing that, and be careful about naming the proposed IANA Registry, etc. In an earlier note, you used the word 'mushy'. It turns out that it is apt vocabulary with respect to my brain, today, for this issue. I'm not understanding the issue or the choices. Pedagogy about this, using simple words and sentences, would be appreciated. Thanks and sorry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Tue Dec 20 10:47:06 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19A21F8558 for ; Tue, 20 Dec 2011 10:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+bqHh7eG2UG for ; Tue, 20 Dec 2011 10:47:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id AFAFC21F850E for ; Tue, 20 Dec 2011 10:47:05 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Dec 2011 10:47:03 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 20 Dec 2011 10:47:05 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 20 Dec 2011 10:47:04 -0800 Thread-Topic: [spfbis] SPFbis WG scope Thread-Index: Acy/RoInpo/51XIoRkSED7xQu9akTQAAEgHw Message-ID: References: <4EEC1204.2000707@mail-abuse.org> <4EEFC795.4030800@dcrocker.net> <2068531.1KQ3N04jjg@scott-latitude-e6320> <4EF0C330.1000102@dcrocker.net> <4EF0D5F1.1080101@dcrocker.net> In-Reply-To: <4EF0D5F1.1080101@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:47:06 -0000 > -----Original Message----- > From: Dave CROCKER [mailto:dhc2@dcrocker.net] > Sent: Tuesday, December 20, 2011 10:38 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] SPFbis WG scope >=20 > In an earlier note, you used the word 'mushy'. It turns out that it is > apt vocabulary with respect to my brain, today, for this issue. I'm > not understanding the issue or the choices. >=20 > Pedagogy about this, using simple words and sentences, would be > appreciated. >=20 > Thanks and sorry. An SPF record can contain several different kinds of "clauses", such as: v=3Dspf1 +mx a:colo.example.com/28 -all The first ("v=3Dspf1") is a version clause. The remaining set in this exam= ple are all called "directives". In this one: v=3Dspf1 redirect=3D_spf.example.com The latter is called a "modifier". A directive is composed of a qualifier (+/-/?/~) followed by a "mechanism".= The set of mechanisms is fixed in RFC4408, which means adding one require= s a redefinition of the protocol. However, the set of modifiers is fluid i= nsofar as unrecognized ones are to be ignored, but RFC4408 didn't create an= IANA registry of these, which is something this group will have to fix. Thus, the available extension mechanism is the declaration of new modifiers= . The "scope" extension document refers to itself as an extension, not a n= ew modifier. That's the mushy language that probably could use some tidyin= g in one of the documents or both. -MSK From dotzero@gmail.com Tue Dec 20 10:47:54 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9605311E8073; Tue, 20 Dec 2011 10:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+T1hSOIUczT; Tue, 20 Dec 2011 10:47:54 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2ABC11E807F; Tue, 20 Dec 2011 10:47:53 -0800 (PST) Received: by dajz8 with SMTP id z8so6352215daj.31 for ; Tue, 20 Dec 2011 10:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kYqjELAsVVfNNuyT1S7rgj8lvWx0LxYM+Qd1K1Jwza8=; b=gvg6+ZgbTalaVts2FFvuj9JyjLFFMvBhw66kkYcmpx7GdyB6Qz0FEuBExRRr5iCAMJ Y4bqh6Vf50EB28xoNou4a7iVsoiCi7/ga8b6g+1/4fgn5/33SfPTGszQXljsiXFsQ+ZI j/4fHxPpjsMiimHe9CKxWl2lSNnwAw7umqsL0= MIME-Version: 1.0 Received: by 10.68.196.193 with SMTP id io1mr5035112pbc.19.1324406873406; Tue, 20 Dec 2011 10:47:53 -0800 (PST) Received: by 10.142.74.3 with HTTP; Tue, 20 Dec 2011 10:47:53 -0800 (PST) In-Reply-To: <4EF0D516.4000504@isdg.net> References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <4EF0D516.4000504@isdg.net> Date: Tue, 20 Dec 2011 13:47:53 -0500 Message-ID: From: Dotzero To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" , "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:47:54 -0000 On Tue, Dec 20, 2011 at 1:33 PM, Hector Santos wrote: > Murray S. Kucherawy wrote: >>> >>> -----Original Message----- >>> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behal= f >>> Of IESG Secretary >>> Sent: Tuesday, December 20, 2011 9:18 AM >>> To: IETF Announcement list >>> Cc: spfbis@ietf.org >>> Subject: [spfbis] WG Review: SPF Update (spfbis) >>> >>> A new IETF working group has been proposed in the Applications Area. >>> The IESG has not made any determination as yet. The following draft >>> charter was submitted, and is provided for informational purposes only. >>> Please send your comments to the IESG mailing list (iesg@ietf.org) by >>> Tuesday, December 27, 2011 >>> [...] >> >> >> I support the current charter, enough that I was the primary author of i= t. >> =A0I'm also willing to co-chair, edit documents, review documents, or be= a >> general participant. =A0I also echo Dave Crocker's comments that for me = this >> is more about doing The Right Thing with respect to the status of SPF, a= nd >> not that I'm a particular proponent of it technically. > > > This is a fundamentally a problem. One must not have any BIAS and must > believe in the technology in order to be the WG project leader. =A0Case i= n > point.... > > >> I also find there is no basis for the concerns about fundamental changes >> to the SPF protocol. > > > Thats exactly the problem. =A0You wrote the charter, you have a documente= d > history on being a vocal SPF opponent. You will have a major problem in t= his > WG with people who are long time early adopters and implementators of SPF > who does not agree which items in the proposed charter. =A0You also have = a > history of filtering, ignoring, water down opposing viewpoints and thus I= do > not agree you qualify to be the chair for this proposed SPF BIG Working > Group. > Hector, I think your comments are fundamentally unfair. I have worked with Murray in various working groups as well as in various forums. While I haven't always agreed with him I have always found him to be fair and straight forward. He is able to distinguish his positions as a participant from his activity as a chair and I have absolutely no problems with him being a co-chair for the working group. He is knowledgable in the space, has significant experience in working on drafts/RFCs. There have been instances over the years where I have fundamentally disagreed with him on a point and he has been nothing but straight forward and fair in his dealings with me. > >> The charter specifically proscribes these, though it permits the eventua= l >> creation of extensions, which are, by the very nature of anything called= an >> "extension", optional. > > > But that is not an excuse to fundamentally change the protocol, violating > the protocol SMTP level only framework to one that requires RFC5322 paylo= ad > downloads - something that was 100% debates and restricted during 2003/20= 04 > MARID working group producing the SPF RFC 4408 document and reason the > RFC4405 SUBMITTER SMTP extension to specifically address the AUTHOR-DOMAI= N > needs this new SPF extension is duplicating but without exposing the > author-domain, thus requiring a payload download requirement. > As far as I can tell there is nothing proposed for the working group (spfbis) which proposes to "fundamentally change the protocol". > You MUST have a understanding of MARID discussions and debates, the SPF > history, the reasons it is a SMTP level only technology and why it is not= a > RFC5322 technology, and also be a believer of the protocol in order to be > trusted as a chair and leader of this project. > I'm confident that Murray has an understanding of the MARID "discussions". > > -- > Hector Santos, CTO > http://www.santronics.com > http://santronics.blogspot.com > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From tim@eudaemon.net Tue Dec 20 10:48:08 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE2A11E807F for ; Tue, 20 Dec 2011 10:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLx3BlqvcJio for ; Tue, 20 Dec 2011 10:48:08 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7A72E11E8073 for ; Tue, 20 Dec 2011 10:48:08 -0800 (PST) Received: from [192.168.82.190] (unknown [64.147.222.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id D30CCCB4A for ; Tue, 20 Dec 2011 13:48:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Tim Draegen In-Reply-To: Date: Tue, 20 Dec 2011 13:48:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8D714B60-F806-4186-8DC1-1F1B58769572@eudaemon.net> References: <4EEC1204.2000707@mail-abuse.org> <4EEFC795.4030800@dcrocker.net> <2068531.1KQ3N04jjg@scott-latitude-e6320> <4EF0C330.1000102@dcrocker.net> To: spfbis@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:48:09 -0000 On Dec 20, 2011, at 1:21 PM, Murray S. Kucherawy wrote: > Are there any installations that are collecting the properties of = observed SPF records that might be able to tally up which = modifiers/extensions/whatever are actually in use out there? If not, = could such be constructed easily? Aye. We have the technology. Glad to dig in and share once the WG gets = its legs. -=3D Tim From msk@cloudmark.com Tue Dec 20 10:59:09 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACCD21F86A5; Tue, 20 Dec 2011 10:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa0IMdLb6Oqk; Tue, 20 Dec 2011 10:59:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A46D321F86A0; Tue, 20 Dec 2011 10:59:08 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Dec 2011 10:59:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 20 Dec 2011 10:59:08 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 20 Dec 2011 10:59:07 -0800 Thread-Topic: [spfbis] WG Review: SPF Update (spfbis) Thread-Index: Acy/R+N2jfhjH96IRRSipo0jRmMWSwAAFouA Message-ID: References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <4EF0D516.4000504@isdg.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:59:09 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dotzero > Sent: Tuesday, December 20, 2011 10:48 AM > To: Hector Santos > Cc: spfbis@ietf.org; iesg@ietf.org > Subject: Re: [spfbis] WG Review: SPF Update (spfbis) >=20 > > This is a fundamentally a problem. One must not have any BIAS and must > > believe in the technology in order to be the WG project leader. =A0Case > > in point.... > >[...] > > Thats exactly the problem. =A0You wrote the charter, you have a > > documented history on being a vocal SPF opponent. You will have a > > major problem in this WG with people who are long time early adopters > > and implementators of SPF who does not agree which items in the > > proposed charter. =A0You also have a history of filtering, ignoring, > > water down opposing viewpoints and thus I do not agree you qualify to > > be the chair for this proposed SPF BIG Working Group. >=20 > Hector, I think your comments are fundamentally unfair. I have worked > with Murray in various working groups as well as in various forums. > While I haven't always agreed with him I have always found him to be > fair and straight forward. He is able to distinguish his positions as a > participant from his activity as a chair and I have absolutely no > problems with him being a co-chair for the working group. He is > knowledgable in the space, has significant experience in working on > drafts/RFCs. There have been instances over the years where I have > fundamentally disagreed with him on a point and he has been nothing but > straight forward and fair in his dealings with me. > [...] Thanks, I appreciate the support. I am actually not an opponent of SPF; that's not what I said. I simply don= 't do any work to support or advance it as an implementer, and have chosen = instead to invest my time into developing DKIM and its friends. One might also characterize me as being against HTTP and TLS by the same lo= gic. -MSK From hsantos@isdg.net Tue Dec 20 11:11:26 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E47421F8A70 for ; Tue, 20 Dec 2011 11:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctEp9Jz8QYcI for ; Tue, 20 Dec 2011 11:11:26 -0800 (PST) Received: from ftp.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B139D21F86FF for ; Tue, 20 Dec 2011 11:11:25 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1978; t=1324408279; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1T43CGJYYSX9KR4uAnN6dIXwH4o=; b=whDGVFdBI2EQjJfG75l7 cXw4JjqJqA7dNgap/yJrF+Ek1xwBPYrJ2GLvT7rtjoScU4xy0m26aCjLdkOWW3od pXaVevAAcFzFCoSt1cDHvOtqlWzUoVorrG3HiT018GUtuiiVB+gxv3aEXeYs3Tkg YB5dyMhfZXXospbatXUc270= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 20 Dec 2011 14:11:19 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1905154692.15653.2788; Tue, 20 Dec 2011 14:11:19 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1978; t=1324408140; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=IACesMk OL3Ii77qWV9RmVetn9zK0K49iGvza/ieRXWA=; b=KHhJmTDJ0Ar78LdwMnw8sL6 45tlSv9r3L9E3EXzT1YLMjsbyAr4xKDVsIJ7Z+Z4Cozmg7k6N3wKoUovDb1O8Syn tsGPWEijs3J4DEAa71NUjJ8295I6qw3roxhCP3C9oG3DXlmN6krdnKkw6eMI/vZO r5EKvCZi6bMKFh1fKDzA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.3) for spfbis@ietf.org; Tue, 20 Dec 2011 14:09:00 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.3) with ESMTP id 2504130360.9.6740; Tue, 20 Dec 2011 14:08:59 -0500 Message-ID: <4EF0DDD4.6090105@isdg.net> Date: Tue, 20 Dec 2011 14:11:16 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <4EF0D516.4000504@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:11:26 -0000 Dotzero wrote: > On Tue, Dec 20, 2011 at 1:33 PM, Hector Santos wrote: > As far as I can tell there is nothing proposed for the working group > (spfbis) which proposes to "fundamentally change the protocol". The mere introduction of a new attribute that fundamentally works only by downloading the payload is a fundamental change to the SPF protocol, regardless if its injected into the revised protocol under the guise of an "optional" logic. Current implementations will apply SPF at the MAIL FROM or in smarter SPF implementations after the RCPT TO has been determining. If this scope= is part of the DNS query for the return path domain, then its intent has one purpose - to direct the SMTP logic to move its logic to another layer where is most likely does not currently exist. That is a fundamental change not only in SOFTWARE but in the framework of SPF. >> You MUST have a understanding of MARID discussions and debates, the SPF >> history, the reasons it is a SMTP level only technology and why it is not a >> RFC5322 technology, and also be a believer of the protocol in order to be >> trusted as a chair and leader of this project. > > I'm confident that Murray has an understanding of the MARID "discussions". If he did then he would sympathetic to the reasons SPF was designed as SMTP protocol and specifically design not to depend on any RFC5322 information. That what was RFC 4405, SUBMITTER, was for. Anyway, A bias has already established towards people who are involved deeply with SPF, has a bias towards SPF itself and has already shown how he will disagree with participants where a chair MUST be open minded. He does not qualify to be a fair chair for this WG and it it will be very unfair to people that do not want RFC5322 methods injected into SPF or if reconsidered by them, to be very carefully done. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From presnick@qualcomm.com Tue Dec 20 11:13:11 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B2B21F8A7A; Tue, 20 Dec 2011 11:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Otgk9DsiNYS; Tue, 20 Dec 2011 11:13:11 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFC321F85EF; Tue, 20 Dec 2011 11:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1324408390; x=1355944390; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4EF0DE03.4090300@qualcomm.com>|Date:=20Tu e,=2020=20Dec=202011=2013:12:03=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Hector=20Santos=20|CC:=20"iesg@ietf.org"=20,=20"spfbis @ietf.org"=20|Subject:=20Re:=20[spfbis] =20WG=20Review:=20SPF=20Update=20(spfbis)|References:=20< 20111220171805.D69BA21F8ABD@ietfa.amsl.com>=09=20<4EF0D516.4000504@isdg.net>|In-Reply-To:=20<4EF0D51 6.4000504@isdg.net>|Content-Type:=20text/plain=3B=20chars et=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=DCPS3ICV18HGLwrQK8ipuWqACgsJqsfF6eTTYMH5KKo=; b=scH1UV32sv0ICbFb9Iuxm7jLcjJBj8MyqNjtJ35u02P9F2JFyVkuXipn yb3ZgFQDYkyQDo6m/yY+QaAt90HVWkwPGpjUKWQyFppakm4fz432TiRj0 YdXlv7wwTn6Or2stmujLZyhApCriC0L3fQcKVLrgbly0JvvP2Tf++/Uyj I=; X-IronPort-AV: E=McAfee;i="5400,1158,6566"; a="146207567" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 20 Dec 2011 11:13:09 -0800 X-IronPort-AV: E=Sophos;i="4.71,382,1320652800"; d="scan'208";a="171410298" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Dec 2011 11:13:09 -0800 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 20 Dec 2011 11:12:06 -0800 Message-ID: <4EF0DE03.4090300@qualcomm.com> Date: Tue, 20 Dec 2011 13:12:03 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Hector Santos References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <4EF0D516.4000504@isdg.net> In-Reply-To: <4EF0D516.4000504@isdg.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "spfbis@ietf.org" , "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:13:11 -0000 Folks, let's bring this down a notch, shall we? First, the IESG is looking for comments on the charter. The charter includes no assigned chairs yet, so there is no need to comment on the qualifications of any particular person for that position. Second, Murray simply volunteered to be chair; no AD has actually appointed him. If you have suggestions, for or against, regarding potential chairs, feel free to send them to me. On two specific items below: On 12/20/11 12:33 PM, Hector Santos wrote: > This is a fundamentally a problem. One must not have any BIAS and must > believe in the technology in order to be the WG project leader. Two things here: 1. Everyone has their biases, for and against all sorts of things. What I care about choosing a chair is whether the person can reasonably set them aside and guide the WG fairly. 2. "Belief in the technology" is most certainly *not* a requirement for chair, and in fact I often find it is a *detriment* to being a good chair. Long stories aside, my experience has been that the best chairs have absolutely no "chips in the game" with regard to a particular technology, and experts in the field with strong beliefs in favor of the technology make lousy chairs. So I simply think the above analysis is incorrect. > Thats exactly the problem. You [...] You will have a major problem in > this WG with [...] You also have a history of [...] The above is *completely* inappropriate. Again, if anyone has opinions on particular candidates for chair, they can communicate them *privately* to me. But public personal criticism like the above has no place on this list, is disruptive to productive work, and will not be tolerated. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From sm@resistor.net Tue Dec 20 11:16:45 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F25021F8A7D; Tue, 20 Dec 2011 11:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiL-nnhhwHLv; Tue, 20 Dec 2011 11:16:40 -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 AA58C21F85EF; Tue, 20 Dec 2011 11:16:40 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id pBKJGZZ3016206; Tue, 20 Dec 2011 11:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1324408599; bh=EQtwrbORMjRwKbEob2vfW9rSIPNixpZ/ghCH0GIpOsQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Ui0FBU9gewYjsUe0FJLz5t4rtzoUbQl1IccJYCpp54ad+LABXY/rPK5wsjflMfag9 c+zlet18M6V8OGAH5ZvuUOOjjqCE97aJwIOwl6vgfbl8qpSQfa5fGeJD3rnHbnqtRt dbQMdGlBvHRnZA2WTUUHETpwj7hUrH6wp0Sd3iFM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1324408599; bh=EQtwrbORMjRwKbEob2vfW9rSIPNixpZ/ghCH0GIpOsQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=bqzSlCwZCAjr0aTNbw88Tlu2+rCmZ6HoKuOnCoGJThRa1qpMBNA8If1EW97KdlqME Ej3VQeMHHwoStHyh9X7J1wUhUGcI2lDuigpQnG4RFq+qgFnUkmtgoizayJySPoIaz0 ogzOuLaKdh6A6PxNh9vkcWiGcR2Kv/ir4Ky7tQ0g= Message-Id: <6.2.5.6.2.20111220104026.0add67f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Dec 2011 11:15:24 -0800 To: iesg@ietf.org From: SM In-Reply-To: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:16:45 -0000 At 09:18 20-12-2011, IESG Secretary wrote: >Changes to the SPF specification will be limited to the correction >of errors, removal of unused features, addition of any enhancements >that have already gained widespread support, and addition of >clarifying language. > >The working group will also produce a document describing the >course of the SPF/Sender-ID experiment (defined in the IESG note >on the RFCs in question), bringing that experiment to a formal >conclusion. No other work on Sender-ID will be done. > >Finally, the working group will develop the proposed "scope" >extension found in draft-mehnle-spfbis-scope. The first two work items will generate their share of controversies. I suggest removing the "scope" document from the list of work items to restrict the scope of the controversies at the initial stage. Once the proposed working group has produced the deliverables that can bring closure to the SPF/Sender-ID debates, it can determine whether there are still any surviving WG participants to pursue work on extensions to 4408bis. >The initial draft set: > draft-kitterman-4408bis > draft-mehnle-spfbis-scope That should be: draft-kitterman-4408bis-00 draft-mehnle-spfbis-scope-00 Regards, -sm From msk@cloudmark.com Tue Dec 20 11:19:56 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256EE21F86A0; Tue, 20 Dec 2011 11:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2k2ML+9Ap85; Tue, 20 Dec 2011 11:19:55 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B81FA21F867F; Tue, 20 Dec 2011 11:19:55 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Dec 2011 11:19:53 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 20 Dec 2011 11:19:55 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 20 Dec 2011 11:19:53 -0800 Thread-Topic: [spfbis] WG Review: SPF Update (spfbis) Thread-Index: Acy/S+61bgdD8qMFQzm+MoEk4ravlAAAAx4w Message-ID: References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <6.2.5.6.2.20111220104026.0add67f0@resistor.net> In-Reply-To: <6.2.5.6.2.20111220104026.0add67f0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:19:56 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of SM > Sent: Tuesday, December 20, 2011 11:15 AM > To: iesg@ietf.org > Cc: spfbis@ietf.org > Subject: Re: [spfbis] WG Review: SPF Update (spfbis) >=20 > The first two work items will generate their share of controversies. I > suggest removing the "scope" document from the list of work items to > restrict the scope of the controversies at the initial stage. Once the > proposed working group has produced the deliverables that can bring > closure to the SPF/Sender-ID debates, it can determine whether there > are still any surviving WG participants to pursue work on extensions to > 4408bis. My own opinion on this topic is that the chairs could serialize the work ju= st fine so that SPFbis itself is done first before any work on extensions t= ake place, without having to go through the process of re-chartering. We l= ike to block on AD procedure as little as possible. :-) That said, I'm told the re-chartering process is relatively cheap, so I wou= ldn't object to this if people push the point and convince the ADs that it'= s necessary. -MSK From stpeter@stpeter.im Tue Dec 20 11:22:28 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8310321F850E; Tue, 20 Dec 2011 11:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-4niiL8Jzpo; Tue, 20 Dec 2011 11:22:28 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF6C21F84DF; Tue, 20 Dec 2011 11:22:26 -0800 (PST) Received: from dhcp-64-101-72-192.cisco.com (unknown [64.101.72.192]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 54C894234D; Tue, 20 Dec 2011 12:30:21 -0700 (MST) Message-ID: <4EF0E071.4030504@stpeter.im> Date: Tue, 20 Dec 2011 12:22:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <6.2.5.6.2.20111220104026.0add67f0@resistor.net> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:22:28 -0000 On 12/20/11 12:19 PM, Murray S. Kucherawy wrote: >> -----Original Message----- From: spfbis-bounces@ietf.org >> [mailto:spfbis-bounces@ietf.org] On Behalf Of SM Sent: Tuesday, >> December 20, 2011 11:15 AM To: iesg@ietf.org Cc: spfbis@ietf.org >> Subject: Re: [spfbis] WG Review: SPF Update (spfbis) >> >> The first two work items will generate their share of >> controversies. I suggest removing the "scope" document from the >> list of work items to restrict the scope of the controversies at >> the initial stage. Once the proposed working group has produced >> the deliverables that can bring closure to the SPF/Sender-ID >> debates, it can determine whether there are still any surviving WG >> participants to pursue work on extensions to 4408bis. > > My own opinion on this topic is that the chairs could serialize the > work just fine so that SPFbis itself is done first before any work on > extensions take place, without having to go through the process of > re-chartering. We like to block on AD procedure as little as > possible. :-) > > That said, I'm told the re-chartering process is relatively cheap, so > I wouldn't object to this if people push the point and convince the > ADs that it's necessary. A least one of the current ADs (moi) is a fan of the phased approach. Peter -- Peter Saint-Andre https://stpeter.im/ From presnick@qualcomm.com Tue Dec 20 11:23:48 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768C821F8560; Tue, 20 Dec 2011 11:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lIv322RCRmJ; Tue, 20 Dec 2011 11:23:47 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id BB59A21F84DA; Tue, 20 Dec 2011 11:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1324409027; x=1355945027; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4EF0E0BE.6090404@qualcomm.com>|Date:=20Tu e,=2020=20Dec=202011=2013:23:42=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Hector=20Santos=20|CC:=20"spfbis@ietf.org"=20,=20"ie sg@ietf.org"=20|Subject:=20Re:=20[spfbis] =20WG=20Review:=20SPF=20Update=20(spfbis)|References:=20< 20111220171805.D69BA21F8ABD@ietfa.amsl.com>=09=09<4EF0D516.4000504@isdg.net>=09=20<4EF0 DDD4.6090105@isdg.net>|In-Reply-To:=20<4EF0DDD4.6090105@i sdg.net>|Content-Type:=20text/plain=3B=20charset=3D"ISO-8 859-1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=20 7bit|X-Originating-IP:=20[172.30.48.1]; bh=6PLwDhG5axcK2VQEdBDp70LgGtEJNpzZkMr+TOgpuo4=; b=GgtGrpK5nEQR++DuaZ9OIk0Eipir+bcv9n9z0M4oiost2XsEjYd+krLl CvAAfPDfePxibdY+XMHI8wrYF2j8LtPF/eL+1qIURxSUe3qUZUKDTVPXn wTDs1eBZuEW2J9ojMJ6mzFtrel/DzHdShgNdprIcfv1CgcjxF6eez7G5O c=; X-IronPort-AV: E=McAfee;i="5400,1158,6566"; a="148532496" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 20 Dec 2011 11:23:45 -0800 X-IronPort-AV: E=Sophos;i="4.71,382,1320652800"; d="scan'208";a="118903619" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Dec 2011 11:23:45 -0800 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 20 Dec 2011 11:23:44 -0800 Message-ID: <4EF0E0BE.6090404@qualcomm.com> Date: Tue, 20 Dec 2011 13:23:42 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Hector Santos References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <4EF0D516.4000504@isdg.net> <4EF0DDD4.6090105@isdg.net> In-Reply-To: <4EF0DDD4.6090105@isdg.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "spfbis@ietf.org" , "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:23:48 -0000 On 12/20/11 1:11 PM, Hector Santos wrote: > The mere introduction of a new attribute that fundamentally works only > by downloading the payload is a fundamental change to the SPF > protocol, regardless if its injected into the revised protocol under > the guise of an "optional" logic. > > Current implementations will apply SPF at the MAIL FROM or in smarter > SPF implementations after the RCPT TO has been determining. If this > scope= is part of the DNS query for the return path domain, then its > intent has one purpose - to direct the SMTP logic to move its logic to > another layer where is most likely does not currently exist. > > That is a fundamental change not only in SOFTWARE but in the framework > of SPF. I believe this is a repetition of the content of your earlier message, correct? If so, may I ask you to clarify for the IESG: Are you suggesting to the IESG that the "scope" extension be removed from the proposed charter? (The rest of your message was more of the inappropriate personal criticism that I mentioned earlier and shall be ignored, given that you sent your message before I sent my admonition.) pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From tim@eudaemon.net Tue Dec 20 11:24:26 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705C221F8560; Tue, 20 Dec 2011 11:24: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHmd8T6BSACs; Tue, 20 Dec 2011 11:24:26 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id EA12721F84DA; Tue, 20 Dec 2011 11:24:25 -0800 (PST) Received: from [192.168.82.190] (unknown [64.147.222.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 3CD7CCB46; Tue, 20 Dec 2011 14:24:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Draegen In-Reply-To: <4EF0E071.4030504@stpeter.im> Date: Tue, 20 Dec 2011 14:24:24 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1A416C02-830A-4140-9D95-0EE1367E917F@eudaemon.net> References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <6.2.5.6.2.20111220104026.0add67f0@resistor.net> <4EF0E071.4030504@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1251.1) Cc: spfbis@ietf.org, iesg@ietf.org Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:24:26 -0000 On Dec 20, 2011, at 2:22 PM, Peter Saint-Andre wrote: >> My own opinion on this topic is that the chairs could serialize the >> work just fine so that SPFbis itself is done first before any work on >> extensions take place, without having to go through the process of >> re-chartering. We like to block on AD procedure as little as >> possible. :-) >> >> That said, I'm told the re-chartering process is relatively cheap, so >> I wouldn't object to this if people push the point and convince the >> ADs that it's necessary. > > A least one of the current ADs (moi) is a fan of the phased approach. Peter, I'm a bit thick. Which of the two is the phased approach? =- Tim From stpeter@stpeter.im Tue Dec 20 11:28:55 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C64621F8511; Tue, 20 Dec 2011 11:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1Fl9xXrUutQ; Tue, 20 Dec 2011 11:28:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 11A9921F8508; Tue, 20 Dec 2011 11:28:55 -0800 (PST) Received: from dhcp-64-101-72-192.cisco.com (unknown [64.101.72.192]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F39974234D; Tue, 20 Dec 2011 12:36:49 -0700 (MST) Message-ID: <4EF0E1F5.8000406@stpeter.im> Date: Tue, 20 Dec 2011 12:28:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tim Draegen References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <6.2.5.6.2.20111220104026.0add67f0@resistor.net> <4EF0E071.4030504@stpeter.im> <1A416C02-830A-4140-9D95-0EE1367E917F@eudaemon.net> In-Reply-To: <1A416C02-830A-4140-9D95-0EE1367E917F@eudaemon.net> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, iesg@ietf.org Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:28:55 -0000 On 12/20/11 12:24 PM, Tim Draegen wrote: > On Dec 20, 2011, at 2:22 PM, Peter Saint-Andre wrote: >>> My own opinion on this topic is that the chairs could serialize the >>> work just fine so that SPFbis itself is done first before any work on >>> extensions take place, without having to go through the process of >>> re-chartering. We like to block on AD procedure as little as >>> possible. :-) >>> >>> That said, I'm told the re-chartering process is relatively cheap, so >>> I wouldn't object to this if people push the point and convince the >>> ADs that it's necessary. >> >> A least one of the current ADs (moi) is a fan of the phased approach. > > Peter, I'm a bit thick. Which of the two is the phased approach? Phase 1: finish revisions to the core spec. Phase 2: recharter, then work on extensions. Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Tue Dec 20 11:35:08 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A0221F8A69; Tue, 20 Dec 2011 11:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aANDKul0OfGL; Tue, 20 Dec 2011 11:35:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 750A521F8A66; Tue, 20 Dec 2011 11:35:08 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Dec 2011 11:35:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 20 Dec 2011 11:35:08 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 20 Dec 2011 11:35:07 -0800 Thread-Topic: [spfbis] WG Review: SPF Update (spfbis) Thread-Index: Acy/TZ44PDyhbhd2TPyq7Zs18C00QwAAFEwg Message-ID: References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <6.2.5.6.2.20111220104026.0add67f0@resistor.net> <4EF0E071.4030504@stpeter.im> <1A416C02-830A-4140-9D95-0EE1367E917F@eudaemon.net> <4EF0E1F5.8000406@stpeter.im> In-Reply-To: <4EF0E1F5.8000406@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:35:09 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Peter Saint-Andre > Sent: Tuesday, December 20, 2011 11:29 AM > To: Tim Draegen > Cc: spfbis@ietf.org; iesg@ietf.org > Subject: Re: [spfbis] WG Review: SPF Update (spfbis) >=20 > > Peter, I'm a bit thick. Which of the two is the phased approach? >=20 > Phase 1: finish revisions to the core spec. >=20 > Phase 2: recharter, then work on extensions. To complete the picture, rechartering involves circulating an updated chart= er that lists completed work and then describes proposed new work for that = WG, which goes through a two-week request for feedback before it gets appro= ved or modified based on that feedback. So we'd have to go through that to= add the "scope" extension back in later. -MSK From stpeter@stpeter.im Tue Dec 20 11:39:29 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9014B21F84D5; Tue, 20 Dec 2011 11:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYX8QpIrScwo; Tue, 20 Dec 2011 11:39:29 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EF50021F84B0; Tue, 20 Dec 2011 11:39:28 -0800 (PST) Received: from dhcp-64-101-72-192.cisco.com (unknown [64.101.72.192]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E4C034234D; Tue, 20 Dec 2011 12:47:23 -0700 (MST) Message-ID: <4EF0E46F.9050109@stpeter.im> Date: Tue, 20 Dec 2011 12:39:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <6.2.5.6.2.20111220104026.0add67f0@resistor.net> <4EF0E071.4030504@stpeter.im> <1A416C02-830A-4140-9D95-0EE1367E917F@eudaemon.net> <4EF0E1F5.8000406@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:39:29 -0000 On 12/20/11 12:35 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Peter Saint-Andre >> Sent: Tuesday, December 20, 2011 11:29 AM >> To: Tim Draegen >> Cc: spfbis@ietf.org; iesg@ietf.org >> Subject: Re: [spfbis] WG Review: SPF Update (spfbis) >> >>> Peter, I'm a bit thick. Which of the two is the phased approach? >> >> Phase 1: finish revisions to the core spec. >> >> Phase 2: recharter, then work on extensions. > > To complete the picture, rechartering involves circulating an updated charter that lists completed work and then describes proposed new work for that WG, which goes through a two-week request for feedback before it gets approved or modified based on that feedback. So we'd have to go through that to add the "scope" extension back in later. To be clear, I'm not yet saying that I think a phased approach is needed here, only that in general such an approach can motivate a group to complete its core work first. Peter -- Peter Saint-Andre https://stpeter.im/ From hsantos@isdg.net Tue Dec 20 11:40:49 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE2B21F8A57 for ; Tue, 20 Dec 2011 11:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT14HrV348-s for ; Tue, 20 Dec 2011 11:40:48 -0800 (PST) Received: from mail.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 85D1921F84D5 for ; Tue, 20 Dec 2011 11:40:48 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2762; t=1324410041; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=ftDKOanueRG3uR0GbeCZh25Rj04=; b=t3W045MZWgHe1l8gC4pV lJM4cGrbBsBsHBkWa4pzzH6POlviVU+SAiJQmPW8FbGW9BO2hO25sPBuPG5qt23K IKcRj1HMXbY8/wmTyo251/V4KcNy5rL7/bap+NwxEaz05+J0yNEi/5ZaqXP2oGtL Kv8H7/gjJKsiZHqeXr+aErY= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 20 Dec 2011 14:40:41 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1906915662.15653.520; Tue, 20 Dec 2011 14:40:40 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2762; t=1324409901; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=Qx6Hzbz DgAc30MgyDYXiBYz05nVNR7KoPwfYaIZ83lc=; b=tOxmEs+cSelazUeVEYPpMMK 8N+P4pZbJ+XjjEHHFgM9SnxM2nh5ALBPXYjsYK7ctAzzNvFnyNnxwMBYd1THYauL oJywFNKHwHUDHSXaf9ftvMpJR0kl++S2QSxcSYsTlnIyL1W1ZpiPIS/IhcvP1uSt eEu9/8GTFQ0TMaMqPMOg= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.3) for spfbis@ietf.org; Tue, 20 Dec 2011 14:38:21 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.3) with ESMTP id 2505891969.9.4744; Tue, 20 Dec 2011 14:38:21 -0500 Message-ID: <4EF0E4B5.1080800@isdg.net> Date: Tue, 20 Dec 2011 14:40:37 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <6.2.5.6.2.20111220104026.0add67f0@resistor.net> In-Reply-To: <6.2.5.6.2.20111220104026.0add67f0@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Cc: spfbis@ietf.org, iesg@ietf.org Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:40:49 -0000 +1, work out the current SPF spec issues, codify the spec, based on the 9 IETF-MAN/VENDOR-YEARS history. We need to keep in mind that back during MARID it was clearly envisioned that new PAYLOAD technologies will come and we always knew there would be a need to couple or augment the technologies. That is why a few of use considered a SMTP extension called HEAD to allow a sender to send the RFC5322 header first. But the principle reason why MARID started was because of the 2003 SORBIG world wide eVirus attacks which exploited 100% the SMTP relaxed nature of MAIL FROM checking and used the ACCEPT/BOUNCE requirement at a two prone attempt to deliver the payload: 1st the RCPT TO, 2nd the MAIL FROM during the bounce. So a key goal was to avoid any payload download which the original SPF clone CEP by Microsoft was promoting (changed to SENDER-ID). The compromise was the SUBMITTER protocol which was a SMTP extension to pass the PRA as a MAIL FROM keyword. MAIL FROM: SUBMITTER=user@AUTHOR-DOMAIN.COM If the goal of this SCOPE= idea is to serve the same purpose, then we already have the SUBMITTER protocol and its definitely in use. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com SM wrote: > At 09:18 20-12-2011, IESG Secretary wrote: >> Changes to the SPF specification will be limited to the correction >> of errors, removal of unused features, addition of any enhancements >> that have already gained widespread support, and addition of >> clarifying language. >> >> The working group will also produce a document describing the >> course of the SPF/Sender-ID experiment (defined in the IESG note >> on the RFCs in question), bringing that experiment to a formal >> conclusion. No other work on Sender-ID will be done. >> >> Finally, the working group will develop the proposed "scope" >> extension found in draft-mehnle-spfbis-scope. > > The first two work items will generate their share of controversies. I > suggest removing the "scope" document from the list of work items to > restrict the scope of the controversies at the initial stage. Once the > proposed working group has produced the deliverables that can bring > closure to the SPF/Sender-ID debates, it can determine whether there are > still any surviving WG participants to pursue work on extensions to > 4408bis. > >> The initial draft set: >> draft-kitterman-4408bis >> draft-mehnle-spfbis-scope > > That should be: > > draft-kitterman-4408bis-00 > draft-mehnle-spfbis-scope-00 > > Regards, > -sm > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From derek.diget+spfbis@wmich.edu Tue Dec 20 11:45:27 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE13C21F8AA8; Tue, 20 Dec 2011 11:45: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkPO1QlVJpnJ; Tue, 20 Dec 2011 11:45:27 -0800 (PST) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAC421F8A6F; Tue, 20 Dec 2011 11:45:27 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0LWI00DXXPJMO770@mta01.service.private>; Tue, 20 Dec 2011 14:45:24 -0500 (EST) X-WMU-Spam: Gauge=IIIIIIII, Probability=8% on Tue Dec 20 14:45:24 2011, Report=' WMU_MSA_SMTP+ 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_700_799 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.20.193315 - Tue Dec 20 14:45:23 2011 Date: Tue, 20 Dec 2011 14:45:22 -0500 (EST) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: iesg@ietf.org In-reply-to: <4EF0E1F5.8000406@stpeter.im> Message-id: References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <6.2.5.6.2.20111220104026.0add67f0@resistor.net> <4EF0E071.4030504@stpeter.im> <1A416C02-830A-4140-9D95-0EE1367E917F@eudaemon.net> <4EF0E1F5.8000406@stpeter.im> Cc: spfbis@ietf.org Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:45:28 -0000 On Dec 20, 2011 at 12:28 -0700, Peter Saint-Andre wrote: =>On 12/20/11 12:24 PM, Tim Draegen wrote: =>> Peter, I'm a bit thick. Which of the two is the phased approach? => =>Phase 1: finish revisions to the core spec. => =>Phase 2: recharter, then work on extensions. My vote for the group formation would have the initial charter just do phase 1. (That is to have the proposed charter remove the three references to the "scope" draft.) -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From hsantos@isdg.net Tue Dec 20 11:59:34 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F6F21F891D for ; Tue, 20 Dec 2011 11:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVmXK3zivnjF for ; Tue, 20 Dec 2011 11:59:34 -0800 (PST) Received: from mail.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 477CD21F8906 for ; Tue, 20 Dec 2011 11:59:34 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2261; t=1324411168; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=kbbJZgoOjQmvzOF+mIIQbxPFb7E=; b=AyZhCxM2WoYdR2cH0jfR 8wGRv320LxfUfNHJ3v4C1mgzNF+Ld9UKjrz25yuOMgI9kPxQ3iLG5YgAYqdbS3DS NU/U+IWndbdUsW4vSx+5zkEPgI/0/RodMDzTMeYQA+K+5yGxSI4MPYI9Ry+gzbzT KRhmzzIRkEpVSpT7r8dWrTk= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 20 Dec 2011 14:59:28 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1908043753.15653.3976; Tue, 20 Dec 2011 14:59:28 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2261; t=1324411029; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=Wr+XMEd /3m1+EY1g1BqvU+NoSGZo/CqQgQYbwlqF9k8=; b=OWmGMs9WJgoStnnQ8tlybt0 wv2DWZWzY92Ct5Aj+PkqmHaVfUIg2fjkKe9zNmX4HebgyrbO+7CSNcP5FAyTFhx3 7LeJI/8SywbTdVeDS2V9GEs0M5Z/9vobxA2bn4EzDJvhetHHpXPFBm0luflhbcSx trlANsnJ02z7DIkS1wLQ= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.3) for spfbis@ietf.org; Tue, 20 Dec 2011 14:57:09 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.3) with ESMTP id 2507019422.9.5720; Tue, 20 Dec 2011 14:57:08 -0500 Message-ID: <4EF0E91D.4060102@isdg.net> Date: Tue, 20 Dec 2011 14:59:25 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <4EF0D516.4000504@isdg.net> <4EF0DDD4.6090105@isdg.net> <4EF0E0BE.6090404@qualcomm.com> In-Reply-To: <4EF0E0BE.6090404@qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Cc: "spfbis@ietf.org" , "iesg@ietf.org" Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:59:34 -0000 Pete Resnick wrote: > On 12/20/11 1:11 PM, Hector Santos wrote: >> The mere introduction of a new attribute that fundamentally works only >> by downloading the payload is a fundamental change to the SPF >> protocol, regardless if its injected into the revised protocol under >> the guise of an "optional" logic. >> >> Current implementations will apply SPF at the MAIL FROM or in smarter >> SPF implementations after the RCPT TO has been determining. If this >> scope= is part of the DNS query for the return path domain, then its >> intent has one purpose - to direct the SMTP logic to move its logic to >> another layer where is most likely does not currently exist. >> >> That is a fundamental change not only in SOFTWARE but in the framework >> of SPF. > > I believe this is a repetition of the content of your earlier message, > correct? If so, may I ask you to clarify for the IESG: > > Are you suggesting to the IESG that the "scope" extension be removed > from the proposed charter? Yes. I believe the SUBMITTER protocol suffices the intent of the scope without download the payload. This scope= extension is too limiting and only does what we intentionally and specifically did not want during the original design of SPF. The reasons have not changed and the principle concern was encouraging the payload to be downloaded like SENDER-ID did. However I do support that SPF needs "Helper Technology" and this was also discussed over at MARID and over the years with the development of DKIM. For example, POLICIES that couple SPF plus DKIM with perhaps an advertisement of a DKIM scope in the SPF record. These ideas were all discuss in MARID, including suggestions with CSV/DNA that may expose the properties of the domain. In order words, give receivers a better reason to alter their SMTP logic to download the payload to do RFC5322 processing. So yes, I agree with a phase approach to first codify on the pure SPF protocol, clean it up, without the scope= idea and discussed what we learned to see how to augment technologies developed since then for a 2nd phase. Its not only SENDER-ID at RFC5322 but also DKIM now. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Tue Dec 20 12:01:51 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1482A21F8A35; Tue, 20 Dec 2011 12:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IT1KDzWDtJ0; Tue, 20 Dec 2011 12:01:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8A09921F89B8; Tue, 20 Dec 2011 12:01:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D4BEE20E40A4; Tue, 20 Dec 2011 15:01:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324411308; bh=cIN118jmbyoaWDdVYFwe5v07OOapN9H60EjbcI3DTo4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Of7nd4R0X9Adji0g6q62oihJY6YMUF9aLv9TRl7YhkoU9TCvfBgeo0JCV1T/KYks2 8fzxTF2qjABuqTaHylaH98yVDTpKR9TIndj2RR199IqgV+ML4JYD77La7aFPFMB+ah ZyW9uJfpPdsr9UA2CgbHJdunTKXCZFUaTlQc6uO8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BB17320E409F; Tue, 20 Dec 2011 15:01:48 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org, "iesg@ietf.org" Date: Tue, 20 Dec 2011 15:01:48 -0500 Message-ID: <2792477.VzkOiiEzQJ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4EF0E46F.9050109@stpeter.im> References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <4EF0E46F.9050109@stpeter.im> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 20:01:51 -0000 On Tuesday, December 20, 2011 12:39:27 PM Peter Saint-Andre wrote: > On 12/20/11 12:35 PM, Murray S. Kucherawy wrote: > >> -----Original Message----- > >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > >> Behalf Of Peter Saint-Andre Sent: Tuesday, December 20, 2011 11:29 AM > >> To: Tim Draegen > >> Cc: spfbis@ietf.org; iesg@ietf.org > >> Subject: Re: [spfbis] WG Review: SPF Update (spfbis) > >> > >>> Peter, I'm a bit thick. Which of the two is the phased approach? > >> > >> Phase 1: finish revisions to the core spec. > >> > >> Phase 2: recharter, then work on extensions. > > > > To complete the picture, rechartering involves circulating an updated > > charter that lists completed work and then describes proposed new work > > for that WG, which goes through a two-week request for feedback before > > it gets approved or modified based on that feedback. So we'd have to > > go through that to add the "scope" extension back in later. > To be clear, I'm not yet saying that I think a phased approach is needed > here, only that in general such an approach can motivate a group to > complete its core work first. I don't think that needs to be a concern in this case. There is a long standing group of core contributors to the SPF protocol that are strongly motivated to work on the core work, so I think some degree of parallelism is quite safe. The extension piece needs to lag the core protocol update regardless, but I don't think the need for a lag is so great that it shouldn't start before the core work is concluded. Scott K From dotis@mail-abuse.org Tue Dec 20 12:14:56 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A4621F8A66 for ; Tue, 20 Dec 2011 12:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2U0Pwmp5oJK for ; Tue, 20 Dec 2011 12:14:55 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id A009221F8A64 for ; Tue, 20 Dec 2011 12:14:55 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 1E93217400E4 for ; Tue, 20 Dec 2011 20:14:55 +0000 (UTC) Message-ID: <4EF0ECBE.3000204@mail-abuse.org> Date: Tue, 20 Dec 2011 12:14:54 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <201112170456.36790.julian@mehnle.net> <74F86505-A2EF-45C0-B7FA-177F7470F07F@eudaemon.net> In-Reply-To: <74F86505-A2EF-45C0-B7FA-177F7470F07F@eudaemon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 20:14:56 -0000 On 12/19/11 8:30 PM, Tim Draegen wrote: > On Dec 18, 2011, at 12:07 AM, Murray S. Kucherawy wrote: >>> Douglas Otis wrote: >>> >>>> Efforts to extend SPF to include PRA suffers from similar problems >>>> since malefactors can use unseen PRA header fields as well. >>> There are no such efforts. >> +1. >> >> I would also add that all of the other points raised are explicitly out of scope per the proposed charter. The discussion then needs to be about whether the scope should change to include them, or whether there's objection to creation of the working group altogether. > As of now I'm current on this thread, and I'd like to reiterate support for the proposed charter (I've previously published my support and reasoning for it). > > I see no reason for the scope of the charter to expand to include any of the bits in this thread. The only charter-changing proposal I could find is: > > On Dec 19, 2011, at 4:52 PM, Douglas Otis wrote: >> The scope of the charter should have recommended changes to better mitigate SPF related threats, especially when mechanisms posing greater concerns are seldom used. > I'm of the mind to relegate an effort to "better mitigate SPF related threats" to a proper research project - outside of the IETF - where "SPF related threats" can be defined, measured, and demonstrated. To use risk-management language -- such an effort will likely yield scenarios that are both extremely low in probability of occurring and extremely low cost in terms of damage. > > Sans real data showing otherwise, it doesn't make sense to me to change the charter to introduce work that may or may not fix a problem that hasn't been shown to exist yet. I'd like to reiterate my support for the existing scope of the WG as presented in the proposed charter. Here is draft demonstrating reflected network gain resolving authorization for a single return path using existing SPF libraries based upon essentially the existing draft. The system sending the message may be unaware of the results caused by the resolution of the return path requested by the submitter. http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01 The demonstration spf record using 10 mechanisms was as follows: cert-test.mail-abuse.org. IN TXT "v=spf1 mx:0.%{l}.%{d} mx:1.%{l}.%{d} mx:2.%{l}.%{d} mx:3.%{l}.%{d} mx:4.%{l}.%{d} mx:5.%{l}.%{d} mx:6.%{l}.%{d} mx:7.%{l}.%{d} mx:8.%{l}.%{d} mx:9.%{l}.%{d} ?all" Assuming PRA is never resolved, this illustrates how a small email From WebMaster@Commerco.Net Tue Dec 20 12:36:12 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAF221F8906 for ; Tue, 20 Dec 2011 12:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6Uqh0Ubq2Pw for ; Tue, 20 Dec 2011 12:36:12 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 23DC121F88A0 for ; Tue, 20 Dec 2011 12:36:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=WCT2t0hjl3pr9ZorMPoIDa0d8wBYscgHdqEFWSQDaHsn3o3h6ka9npUdXrPtYi34gNRv0PEuEX4QxolN0hwmPT4nUu33pBSdYQmxuMkxm/R6m7uzXCowgrGwy6bMJivTbT8ZekAvCxIVICl3vDxwf9otKvZbX+EewHPhBLikM6M= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Tue, 20 Dec 2011 20:36:07 +0000 Message-ID: <4EF0F1B1.8020907@Commerco.Net> Date: Tue, 20 Dec 2011 13:36:01 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> In-Reply-To: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 20:36:12 -0000 As an early adopter of and participant in SPF, I too support the proposed charter to bring RFC4408 from Experimental to Standards Track and am willing to assist with inputs where possible and appropriate. Alan M. On 12/20/2011 10:18 AM, IESG Secretary wrote: > A new IETF working group has been proposed in the Applications Area. > The IESG has not made any determination as yet. The following draft > charter was submitted, and is provided for informational purposes only. > Please send your comments to the IESG mailing list (iesg@ietf.org) by > Tuesday, December 27, 2011 > > SPF Update (spfbis) > ----------------------------------------- > Status: Proposed Working Group > Last Updated: 2011-12-09 > > Chair(s): > TBD > > Applications Area Director(s): > Pete Resnick > Peter Saint-Andre > > Applications Area Advisor: > Pete Resnick > > Mailing Lists: > General Discussion:spfbis@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis > Archive: http://www.ietf.org/mail-archive/web/spfbis/ > > Description of Working Group: > > The Sender Policy Framework (SPF, RFC4408) specifies the publication > of a DNS record which states that a listed IP address is authorized > to send mail on behalf of the listing domain name's owner. SMTP > servers extract the domain name in the SMTP "MAIL FROM" or "HELO" > command for confirming this authorization. The protocol has had > Experimental status for some years and has become widely deployed. > This working group will revise the specification, based on deployment > experience and listed errata, and will seek Standards Track status for > the protocol. > > The MARID working group created two specifications for publication of > email-sending authorization: Sender-ID (RFFC4405, RFC4406 and RFC4407) > and SPF (RFC4408), with both having Experimental status. By using > IP addresses, both protocols specify authorization in terms of path, > though unlike SPF, Sender-ID uses domain names found in the header of > the message rather than the envelope. > > The two protocols rely on the same policy publication mechanism, > namely a specific TXT resource record in the DNS. This creates a basic > ambiguity about the interpretation of any specific instance of the TXT > record. Because of this, there were concerns about conflicts between > the two in concurrent operation. The IESG Note added to each invited > an expression of community consensus in the period following these > publications. > > Both enjoyed initially large deployments. Broad SPF use continues, > and its linkage to the envelope -- rather than Sender-ID's linkage > to identifiers in the message content -- has proven sufficient among > operators. This concludes the experiment. > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. > > The working group will also produce a document describing the > course of the SPF/Sender-ID experiment (defined in the IESG note > on the RFCs in question), bringing that experiment to a formal > conclusion. No other work on Sender-ID will be done. > > Finally, the working group will develop the proposed "scope" > extension found in draft-mehnle-spfbis-scope. > > Specifically out-of-scope for this working group: > > * Revisiting past technical arguments that were covered > in the MARID working group, except where review is reasonably > warranted based on operational experience. > > * Discussion of the merits of SPF. > > * Discussion of the merits of Sender-ID in preference to SPF. > > * Extensions to SPF other than the one specified above. The > working group will re-charter to process other specific proposed > extensions as they are identified. > > The initial draft set: > draft-kitterman-4408bis > draft-mehnle-spfbis-scope > > Goals and Milestones: > > MMM YYYY: A standards track document defining SPF, based on RFC4408 and > as amended above, to the IESG for publication. > > MMM YYYY: A document describing the SPF/Sender-ID experiment and its > conclusions to the IESG for publication. > > MMM YYYY: A standards track document creating the "scope" extension to > the IESG for publication. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From spf2@kitterman.com Tue Dec 20 12:42:22 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F398F21F88A0 for ; Tue, 20 Dec 2011 12:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+FJTZa9Fxmf for ; Tue, 20 Dec 2011 12:42:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 13C1B21F84BA for ; Tue, 20 Dec 2011 12:42:21 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 51E8120E40A4; Tue, 20 Dec 2011 15:42:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324413740; bh=GZMgLJV7OVzasSkc3auqfE7mvaMZ81BftLnYbqtoF8E=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=RzxT+/ni2cS2vi0DTcMNMaJjQLiIWeMNfLAMdB2x8gqL5PteTNIl/4lMvQ0CHQpn5 Dil5Piq+pu3QZHUSHR2uY+lXAwEiOsUNaWpGEJ7NAnWpJqxV+9FFgRp/DzrTrCV3PA 55zYiMzO+ff8FZ64EMPZ76KH/Cup8BYPvPoCpfYQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 342A320E409F; Tue, 20 Dec 2011 15:42:20 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 20 Dec 2011 15:42:19 -0500 Message-ID: <1479091.7B2jUutPdV@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4EF0ECBE.3000204@mail-abuse.org> References: <4EEC1204.2000707@mail-abuse.org> <74F86505-A2EF-45C0-B7FA-177F7470F07F@eudaemon.net> <4EF0ECBE.3000204@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 20:42:22 -0000 On Tuesday, December 20, 2011 12:14:54 PM Douglas Otis wrote: ... > http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01 ... This is a 2006 draft that has been given a thorough technical scrub: http://www.openspf.net/draft-otis-spf-dos-exploit_Analysis The conclusion at the time was that the alleged threats are not particularly SPF unique. I don't know of any reason to believe that's changed. Scott K From dotis@mail-abuse.org Tue Dec 20 14:24:33 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305C711E8089 for ; Tue, 20 Dec 2011 14:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGz-oERmx1UX for ; Tue, 20 Dec 2011 14:24:32 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 913F511E807F for ; Tue, 20 Dec 2011 14:24:32 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 9C3791740294 for ; Tue, 20 Dec 2011 22:24:31 +0000 (UTC) Message-ID: <4EF10B1F.5050406@mail-abuse.org> Date: Tue, 20 Dec 2011 14:24:31 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <74F86505-A2EF-45C0-B7FA-177F7470F07F@eudaemon.net> <4EF0ECBE.3000204@mail-abuse.org> <1479091.7B2jUutPdV@scott-latitude-e6320> In-Reply-To: <1479091.7B2jUutPdV@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 22:24:33 -0000 On 12/20/11 12:42 PM, Scott Kitterman wrote: > On Tuesday, December 20, 2011 12:14:54 PM Douglas Otis wrote: > ... >> http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01 > ... > > This is a 2006 draft that has been given a thorough technical scrub: > > http://www.openspf.net/draft-otis-spf-dos-exploit_Analysis > > The conclusion at the time was that the alleged threats are not particularly > SPF unique. I don't know of any reason to believe that's changed. > http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01#appendix-B Perhaps I am at fault for not making examples more explicit. Nevertheless, this draft clearly shows in exacting and non-theoretical terms that resolving a single SPF Return-Path authorization using a compliant SPF library can cause recipients to issue 40,436 bytes in DNS requests directed against victim domains not seen within messages. This amount can double when PRA is resolved as well. The requests are initially prompted by 29,650 bytes from an attacker's DNS. Because SPF includes "l" local-part macro constructs, answers for "jo@example.com" can not be assumed the same as that for "lu@example.com". In addition, the 100 NX domains issued by victim's name servers NEVER caused the SPF compliant library to quit. In fact, SPF could have ended with "+all" and obtain PASS in addition to the DDoS aimed at anyone's DNS. Spammers often cycle originating local-parts in campaign runs. Once a run extends beyond the negative caching interval employed by their recipients, repeating the sequence will satisfy subsequent queries for MX records from cache. Ignoring the relatively smaller bandwidth used in the related activity called spamming, the overall DNS DDoS gain becomes extremely large without even leveraging EDNS0 extensions. Any value from SPF records can not be obtained when local-part macros or "exists" mechanisms are used. Use of APL RRsets (RFC3123) provide safer, more extensive and extendable information. There is justification for overloading TXT RRsets. -Doug From tim@eudaemon.net Tue Dec 20 14:56:48 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E39011E80A3 for ; Tue, 20 Dec 2011 14:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip2bfnUcdSp3 for ; Tue, 20 Dec 2011 14:56:47 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1DF11E80A2 for ; Tue, 20 Dec 2011 14:56:47 -0800 (PST) Received: from [10.0.1.17] (adsl-98-94-238-88.ard.bellsouth.net [98.94.238.88]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id D1D7BCB46 for ; Tue, 20 Dec 2011 17:56:50 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Tim Draegen In-Reply-To: <4EF10B1F.5050406@mail-abuse.org> Date: Tue, 20 Dec 2011 17:56:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8748A49D-AB9D-45C2-BB70-47D3112E4A38@eudaemon.net> References: <4EEC1204.2000707@mail-abuse.org> <74F86505-A2EF-45C0-B7FA-177F7470F07F@eudaemon.net> <4EF0ECBE.3000204@mail-abuse.org> <1479091.7B2jUutPdV@scott-latitude-e6320> <4EF10B1F.5050406@mail-abuse.org> To: spfbis@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 22:56:48 -0000 On Dec 20, 2011, at 5:24 PM, Douglas Otis wrote: > Perhaps I am at fault for not making examples more explicit. = Nevertheless, this draft clearly shows in exacting and non-theoretical = terms that resolving a single SPF Return-Path authorization using a = compliant SPF library can cause recipients to issue 40,436 bytes in DNS = requests directed against victim domains not seen within messages. This = amount can double when PRA is resolved as well. The requests are = initially prompted by 29,650 bytes from an attacker's DNS. It was very difficult for me to understand this draft, but I believe I = now get it. Then Scott Kitterman pointed me to Julian Mehnle's write = up; I'm clear. I agree that this attack vector is not unique to SPF. As a one-time = implementor of high-volume DNS servers, I don't see this particular = attack as being viable. In a research environment, maybe. But the cost = of constructing this attack does not make the resulting DoS attack very = likely.. if the actual effect is considered to be anything more than a = nuisance. Toss in caching (there appears to be some confusion in the = draft on how modern DNS caches work in terms of ability to clear caches = by overflowing them when junk results -- its not that simple), and the = threat is reduced to "low in probability of occurring and extremely low = cost in terms of damage". Given the reality of today's internet and constant DoS attacks against = various services, there are easier and cheaper ways to get this job = done. I believe this write up (or maybe a far simpler one) would have = greater impact as guidance to SPF developers to make sure they write = better code. =3D- Tim From dotis@mail-abuse.org Tue Dec 20 15:53:11 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1517411E808A for ; Tue, 20 Dec 2011 15:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bhwpEk+9ETh for ; Tue, 20 Dec 2011 15:53:10 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8718B11E8089 for ; Tue, 20 Dec 2011 15:53:10 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 5D7B817400E9 for ; Tue, 20 Dec 2011 23:53:10 +0000 (UTC) Message-ID: <4EF11FE6.9010102@mail-abuse.org> Date: Tue, 20 Dec 2011 15:53:10 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <74F86505-A2EF-45C0-B7FA-177F7470F07F@eudaemon.net> <4EF0ECBE.3000204@mail-abuse.org> <1479091.7B2jUutPdV@scott-latitude-e6320> <4EF10B1F.5050406@mail-abuse.org> <8748A49D-AB9D-45C2-BB70-47D3112E4A38@eudaemon.net> In-Reply-To: <8748A49D-AB9D-45C2-BB70-47D3112E4A38@eudaemon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 23:53:11 -0000 On 12/20/11 2:56 PM, Tim Draegen wrote: > On Dec 20, 2011, at 5:24 PM, Douglas Otis wrote: >> Perhaps I am at fault for not making examples more explicit. Nevertheless, this draft clearly shows in exacting and non-theoretical terms that resolving a single SPF Return-Path authorization using a compliant SPF library can cause recipients to issue 40,436 bytes in DNS requests directed against victim domains not seen within messages. This amount can double when PRA is resolved as well. The requests are initially prompted by 29,650 bytes from an attacker's DNS. > It was very difficult for me to understand this draft, but I believe I now get it. Then Scott Kitterman pointed me to Julian Mehnle's write up; I'm clear. > > I agree that this attack vector is not unique to SPF. As a one-time implementor of high-volume DNS servers, I don't see this particular attack as being viable. In a research environment, maybe. Tim, The test demonstrated a _simple_ SPF record can attack _any_ DNS server not related to any domain supporting the email exchange. It does not take a research environment to construct the attack since it does not require _any_ knowledge of the victim's DNS. It simply takes advantage of poorly considered constraints placed upon SPF macros able to introduce any portion of an email-address local-part or domain into a request. This ability permits DNS prompting to originate from any unrelated domain and directed toward any other unrelated domain. This attack can be sustained from domains unrelated to those supplying the initial SPF record. Such an ability allows attacks to side-step reputation filters, for example. > But the cost of constructing this attack does not make the resulting DoS attack very likely.. if the actual effect is considered to be anything more than a nuisance. A 150x gain (based upon a single email message sent to a single recipient) is only a nuisance? Much of this traffic originates from compromised systems numbered in the millions that will be sending spam anyway. Why allow DoS of DNS to be virtually free as well? > Toss in caching (there appears to be some confusion in the draft on how modern DNS caches work in terms of ability to clear caches by overflowing them when junk results -- its not that simple), and the threat is reduced to "low in probability of occurring and extremely low cost in terms of damage". The clearing of caches is not in question! Better caching will increase the effectiveness of an SPF initiated DoS attack. The attack is not against the reflectors, it is against targeted victims. These reflectors likely represent legitimate resolvers which makes any remedy disruptive, if not impossible. > Given the reality of today's internet and constant DoS attacks against various services, there are easier and cheaper ways to get this job done. I believe this write up (or maybe a far simpler one) would have greater impact as guidance to SPF developers to make sure they write better code. The reason for the extensive sequence was to illustrate the potential level of activity from a single 1KB message using the SPF strategy purportedly aimed at mitigating abuse. The activity logged clearly illustrates the potential for reflected activity caused by use of this poorly considered macro language. The definition of this protocol should be modified into a much safer form. It is unwise to expect implementations will exceed the qualify of the protocol specifications. -Doug From dhc2@dcrocker.net Tue Dec 20 22:02:39 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0036121F84DB for ; Tue, 20 Dec 2011 22:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw9bqOZOC9A6 for ; Tue, 20 Dec 2011 22:02:38 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 649C621F84D5 for ; Tue, 20 Dec 2011 22:02:37 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBL62U0s026664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Dec 2011 22:02:37 -0800 Message-ID: <4EF17668.2060701@dcrocker.net> Date: Tue, 20 Dec 2011 22:02:16 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EEC1204.2000707@mail-abuse.org> <74F86505-A2EF-45C0-B7FA-177F7470F07F@eudaemon.net> <4EF0ECBE.3000204@mail-abuse.org> <1479091.7B2jUutPdV@scott-latitude-e6320> <4EF10B1F.5050406@mail-abuse.org> <8748A49D-AB9D-45C2-BB70-47D3112E4A38@eudaemon.net> In-Reply-To: <8748A49D-AB9D-45C2-BB70-47D3112E4A38@eudaemon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 20 Dec 2011 22:02:37 -0800 (PST) Subject: Re: [spfbis] SPFbis WG scope X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 06:02:39 -0000 On 12/20/2011 2:56 PM, Tim Draegen wrote: > I agree that this attack vector is not unique to SPF. This continues the consistent pattern of responses that assess the concern as being outside the scope of the current working group. I have seen no pattern of comments that support pursuing the concern in this working group. (Nevermind pattern, I haven't seen /any/ support.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From vesely@tana.it Thu Dec 22 12:05:45 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E941F0C36; Thu, 22 Dec 2011 12:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.533 X-Spam-Level: X-Spam-Status: No, score=-4.533 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xABKLn0nn68Y; Thu, 22 Dec 2011 12:05:44 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD5C1F0C35; Thu, 22 Dec 2011 12:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324584342; bh=1DyrY9dpfYjHju7DcPNpbw/2Aqv3xAVoq+X1Zi3AZls=; l=1307; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=TL2P6wVYyxIqgFx21qRNKB7u7zkChSSyEpanD6uPwVkpzeP/OIg824HOjJVkpX9uI L2x8m8hOUEnQeQbqUSQOEMBtEeaYeCER+CgDuAH1s+rstxVkqYBdGHprnJknVZ2doq JGPmAkbPVHxT8wWTU7ggWVw+f3oByImDaCAJ+Dcc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 22 Dec 2011 21:05:42 +0100 id 00000000005DC033.000000004EF38D96.000071C2 Message-ID: <4EF38D96.80203@tana.it> Date: Thu, 22 Dec 2011 21:05:42 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: iesg@ietf.org References: <20111220171805.D69BA21F8ABD@ietfa.amsl.com> <6.2.5.6.2.20111220104026.0add67f0@resistor.net> <4EF0E071.4030504@stpeter.im> <1A416C02-830A-4140-9D95-0EE1367E917F@eudaemon.net> <4EF0E1F5.8000406@stpeter.im> In-Reply-To: <4EF0E1F5.8000406@stpeter.im> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] WG Review: SPF Update (spfbis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 20:05:45 -0000 I support the creation of the new WG on the basis of the submitted draft charter. Updating SPF is a long overdue job and I believe that moving RFC 4408 to standard track will benefit the community. I'm willing to contribute by reviewing proposed drafts. With respect to whether to phase or not to phase On 20/Dec/11 20:28, Peter Saint-Andre wrote: > > Phase 1: finish revisions to the core spec. > > Phase 2: recharter, then work on extensions. I note that the draft does say *Finally*, which resembles phasing and, paired with an appropriate choice of the dates displayed as "MMM YYYY", can likewise motivate the group to complete its core work first. It is a question of convenience and I'm neutral on this point. On 20/Dec/11 18:18, IESG Secretary wrote: > Description of Working Group: > Finally, the working group will develop the proposed "scope" > extension found in draft-mehnle-spfbis-scope. > Goals and Milestones: > > MMM YYYY: A standards track document defining SPF, based on RFC4408 and > as amended above, to the IESG for publication. > > MMM YYYY: A document describing the SPF/Sender-ID experiment and its > conclusions to the IESG for publication. > > MMM YYYY: A standards track document creating the "scope" extension to > the IESG for publication. From msk@cloudmark.com Fri Dec 23 12:47:29 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B3021F853E for ; Fri, 23 Dec 2011 12:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXDvNdkaJKjK for ; Fri, 23 Dec 2011 12:47:28 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1DF21F8508 for ; Fri, 23 Dec 2011 12:47:28 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 23 Dec 2011 12:47:25 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 23 Dec 2011 12:47:27 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Fri, 23 Dec 2011 12:47:30 -0800 Thread-Topic: Suggestion for an additional deliverable Thread-Index: AczBtBahL7ceea0XSVGHOJftcZsJkA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15673EXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 20:47:29 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C15673EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe this falls within the current scope, but it would involve either = an additional draft deliverable or an additional section in the spfbis docu= ment. There are two errata against RFC5451: http://www.rfc-editor.org/errata_sear= ch.php?rfc=3D5451 The first of these is a change to what Authentication-Results uses to repor= t SPF failures. In particular, SPF itself uses "fail", but A-R uses "hardf= ail" to report that case. Since RFC5451 set up IANA registries for results= of authentication methods, fixing this amounts to just an IANA action and = maybe an "Updates" against RFC5451. I believe we could do this in spfbis easily as it amounts to nothing more t= han a correction, and those are in scope. Although this modifies a documen= t outside of our current plan, it is a germane modification to this work. If there's objection, I can seek to do it as an AD-sponsored individual sub= mission or maybe through APPSAWG. Comments? -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C15673EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe this f= alls within the current scope, but it would involve either an additional dr= aft deliverable or an additional section in the spfbis document.=

 

There ar= e two errata against RFC5451: http://www.rfc-editor.org/errata_search.php?rfc=3D545= 1

 

The first of these is a change to what Authentication-Results uses = to report SPF failures.  In particular, SPF itself uses “fail= 221;, but A-R uses “hardfail” to report that case.  Since = RFC5451 set up IANA registries for results of authentication methods, fixin= g this amounts to just an IANA action and maybe an “Updates” ag= ainst RFC5451.

 

I believe we could do this in spfbis easily as it amounts = to nothing more than a correction, and those are in scope.  Although t= his modifies a document outside of our current plan, it is a germane modifi= cation to this work.

 

If there’s objection, I can seek to do it as a= n AD-sponsored individual submission or maybe through APPSAWG.

 

Comments?<= o:p>

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C6C15673EXCHC2corpclo_-- From dhc2@dcrocker.net Fri Dec 23 13:50:09 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96721F8B17 for ; Fri, 23 Dec 2011 13:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOU1WacVA1MM for ; Fri, 23 Dec 2011 13:50:09 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1F82C21F8B09 for ; Fri, 23 Dec 2011 13:50:09 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBNLo1Q1002025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 13:50:07 -0800 Message-ID: <4EF4F787.9090408@dcrocker.net> Date: Fri, 23 Dec 2011 13:49:59 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 23 Dec 2011 13:50:08 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Suggestion for an additional deliverable 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, 23 Dec 2011 21:50:09 -0000 > If there’s objection, I can seek to do it as an AD-sponsored individual > submission or maybe through APPSAWG. I don't understand. Unless I missed it, the draft charter does not cite RFC 5451, reporting or header fields. How does modifying a reporting specification fall within the current draft charter? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Fri Dec 23 14:42:08 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9E421F84AE for ; Fri, 23 Dec 2011 14:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v9uBeEDeu7G for ; Fri, 23 Dec 2011 14:42:07 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F5721F84AD for ; Fri, 23 Dec 2011 14:42:07 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id pBNMg1Xg020069 for ; Fri, 23 Dec 2011 14:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1324680124; bh=Bu+ACduG6Dbox6qvrHBdMj3CTLT+rIWQovoPAcyNioI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=gZbghbchSoMqb1ol2N5WlMcpRn0ozQ4f01M/M7BqqUGIEoji0PPHo0SUsTfbw0rlC Pdg1+nDysZ+0CImTW/Z6eT8BgD+HZzSxYes9BPV2bvRpmoO3HgXaNVBA05RRhyOw1O mAhFSMBA6XbSyPlIDcdD9zmUcukvjoRSbCHHhNgc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1324680124; bh=Bu+ACduG6Dbox6qvrHBdMj3CTLT+rIWQovoPAcyNioI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=e4J4FyqZCG2zVpzRkYTLJy0uoGWS5DyuhCxTYjC4IVH5n3o3FyYUB3jThWLWYLpfB tskAv8+vpMM5BYMOZdk1FSSVZ3FW3A36c7Wbr2XVJAMXYW/942xnunZGZx0FMMEJYD puJldKCb+sCn48e4xpM37gPNQ8Os9MKIrkF3iGdU= Message-Id: <6.2.5.6.2.20111223125517.09160578@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 23 Dec 2011 13:41:31 -0800 To: spfbis@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 22:42:08 -0000 Hi Murray, At 12:47 23-12-2011, Murray S. Kucherawy wrote: >I believe we could do this in spfbis easily as it amounts to nothing >more than a correction, and those are in scope. Although this >modifies a document outside of our current plan, it is a germane >modification to this work. I agree that it would be easy work. >If there's objection, I can seek to do it as an AD-sponsored >individual submission or maybe through APPSAWG. I suggest that you defer this until after the core work is completed. There will always be a good reason for adding deliverables. It's better not to go down that path. Regards, -sm From spf2@kitterman.com Fri Dec 23 15:25:53 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2633321F8B42 for ; Fri, 23 Dec 2011 15:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoJ7JVNp0H+r for ; Fri, 23 Dec 2011 15:25:52 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7F33F21F8B35 for ; Fri, 23 Dec 2011 15:25:52 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 1EE96D04084; Fri, 23 Dec 2011 17:25:50 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324682750; bh=iGos/yF2evZh24rQHh7NsAYxjZlxMR2HS7FR4QKB7ic=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=FBd5KitDxnPKqlf5nLX3LK4VcWCPKwjM97rRD2FG//ZErkGAMFQtq71eLuVAOk0DO zQ0v05/U9ykZPjGXAbmBvbusq61D80H2CRB5ODqU0MYYqreB7OfKUvWEFt59q9jIqL C28ZDOqrGz1M3R1Gv6fplE7WCMGACZIelUFYjlnI= Received: from 141.sub-97-1-192.myvzw.com (141.sub-97-1-192.myvzw.com [97.1.192.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2100FD04025; Fri, 23 Dec 2011 17:25:48 -0600 (CST) References: <6.2.5.6.2.20111223125517.09160578@resistor.net> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20111223125517.09160578@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 23 Dec 2011 18:25:54 -0500 To: spfbis@ietf.org Message-ID: <08a8505d-3901-4ad4-b584-63c68086ecc0@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 23:25:53 -0000 SM wrote: >Hi Murray, >At 12:47 23-12-2011, Murray S. Kucherawy wrote: >>I believe we could do this in spfbis easily as it amounts to nothing >>more than a correction, and those are in scope. Although this >>modifies a document outside of our current plan, it is a germane >>modification to this work. > >I agree that it would be easy work. > >>If there's objection, I can seek to do it as an AD-sponsored >>individual submission or maybe through APPSAWG. > >I suggest that you defer this until after the core work is >completed. There will always be a good reason for adding >deliverables. It's better not to go down that path. One possible reason to deal with this as core work would be if we wanted to explore deprecating the Received SPF header field in favor of the Authentication Results header field. SPF Received is in wide use, so it's not a candidate for removal, but we might start in that direction if we could make a few adjustments to Authentication Results. It would be difficult to do this immediately after we finish 4408bis. Scott K From WebMaster@Commerco.Net Fri Dec 23 15:44:12 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408DC21F8B35 for ; Fri, 23 Dec 2011 15:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nIJA+wxkt0e for ; Fri, 23 Dec 2011 15:44:11 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 955A121F8B0D for ; Fri, 23 Dec 2011 15:44:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=VBwSh8bPdkG1fmQ+OR0SZeXjWoE+roPGvpsuI+Cw9xJwzc5fdoKdL5W7iRYcYcyZwFJjHoDllzELbCaHh6wZKv8qOwUf/3gDXAvvV7XsfkbkUgNLalcY/A/XIQ4v6eFsyat9PZSAUCumDASXyFTYKfsbmuAwBT03QjKVPEzXQlE= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 23 Dec 2011 23:44:08 +0000 Message-ID: <4EF51243.7010801@Commerco.Net> Date: Fri, 23 Dec 2011 16:44:03 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Dec 2011 23:44:12 -0000 The errata items for RFC 5451 look correct. The comment from D. Stussy expresses the correct current expected SPF response per RFC 4408. Murray, since RFC 5451 looks like it is authored by you, would you entertain adjusting 2.4.2 (the SPF and Sender-ID results) to reflect the SPF responses per RFC 4408? Hardfail is not mentioned in RFC 4408 (http://www.rfc-editor.org/rfc/rfc4408.txt), so I'm not sure how it got into RFC 5451 (unless it is part of the Sender-ID fork, which I think is outside the scope of the charter for SPFbis). Best, Alan M. On 12/23/2011 1:47 PM, Murray S. Kucherawy wrote: > I believe this falls within the current scope, but it would involve > either an additional draft deliverable or an additional section in the > spfbis document. > > There are two errata against RFC5451: > http://www.rfc-editor.org/errata_search.php?rfc=5451 > > The first of these is a change to what Authentication-Results uses to > report SPF failures. In particular, SPF itself uses “fail”, but A-R uses > “hardfail” to report that case. Since RFC5451 set up IANA registries for > results of authentication methods, fixing this amounts to just an IANA > action and maybe an “Updates” against RFC5451. > > I believe we could do this in spfbis easily as it amounts to nothing > more than a correction, and those are in scope. Although this modifies a > document outside of our current plan, it is a germane modification to > this work. > > If there’s objection, I can seek to do it as an AD-sponsored individual > submission or maybe through APPSAWG. > > Comments? > > -MSK > > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From hsantos@isdg.net Fri Dec 23 19:40:18 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6504521F85A4 for ; Fri, 23 Dec 2011 19:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 321Takma1+Na for ; Fri, 23 Dec 2011 19:40:17 -0800 (PST) Received: from mail.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 44E1F21F85A1 for ; Fri, 23 Dec 2011 19:40:16 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2733; t=1324698005; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Va8LRBs6toWsXec6RRVDolopMdg=; b=qLQ7Pfx6iBYYQcfZZJz0 NJr/4rwbdcuMaddHAm1BzL62asNc/2OC1P/AOt2x5HkQASxtDkKamOaKeNyIBgEQ /YJSGzhjhEaU1ppCiQMS83EfOm3UhfcgRZLXTVii7prD+Ni5+Y3PC0DTVDKKIBJi 1mwsEaMJV1a/TLgzidGDrwI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 23 Dec 2011 22:40: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 v6.4.454.1) with ESMTP id 2194876738.17651.2580; Fri, 23 Dec 2011 22:40:04 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2733; t=1324697863; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=cPML61v rDV+Bh5OMnYioUfR9cQQ22svENx8bD++D8ws=; b=FwKQySVUNSYOyr7nLfPE5nz EBXPYCwasERyZf2O4mUiCCvBmE9yZBrxt+FzrDMpOzdbGuQlP1RASCDL/4H8ICK0 QcPoW+UygkPFpKhIlv5VTYUPLqhlzEgIrH+rs2MwcxEo1zXv5bZXPX7G1RQh5YV5 OIFSbINyNChD/6ghjfXU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 23 Dec 2011 22:37:43 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2793852985.644.2056; Fri, 23 Dec 2011 22:37:42 -0500 Message-ID: <4EF54997.9090708@isdg.net> Date: Fri, 23 Dec 2011 22:40:07 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 03:40:18 -0000 I can support adding AUTH-RES support to SPF-BIS charter. This is more in line with SPF-BIS work. Received-SPF is a SHOULD, thus is already optional for SPF implementations and it would not be a protocol change to offer an alternative 5322 reporting option for AUTH-RES or both. Since these headers are generally are for internal mail bots, there is already the possibility that other headers are using to pass more useful information for the internal mail processors. However, for domain SPF policies using -ALL (hard fail), when the result is a FAIL, the PAYLOAD will not be downloaded and there is NO 5322 header added, no Received-SPF. So by the time mail is downloaded, there will only be for results: result = = "Pass" / SoftFail" / "Neutral" / "None" / "TempError" / "PermError" This is critical important and one of the concerns I have with the mindset change with SPF-BIS now focusing on RFC5322 when it was never a major part of SPF other than for adding a Receiver-SPF header. What that means is, while its possible for an local policy to not reject the SPF failures at SMTP, and include a ReceivedSPF: Fail header, this defeats the operational importance of SPF a hard fail policy offers to avoid Accept/Bounce attacks. So I can support the support of AUTH-RES, but not with a focus of reporting to force payload downloads for the purpose of reporting AUTH-RES fail reports. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: > I believe this falls within the current scope, but it would involve either an additional draft deliverable or an additional section in the spfbis document. > > There are two errata against RFC5451: http://www.rfc-editor.org/errata_search.php?rfc=5451 > > The first of these is a change to what Authentication-Results uses to report SPF failures. In particular, SPF itself uses "fail", but A-R uses "hardfail" to report that case. Since RFC5451 set up IANA registries for results of authentication methods, fixing this amounts to just an IANA action and maybe an "Updates" against RFC5451. > > I believe we could do this in spfbis easily as it amounts to nothing more than a correction, and those are in scope. Although this modifies a document outside of our current plan, it is a germane modification to this work. > > If there's objection, I can seek to do it as an AD-sponsored individual submission or maybe through APPSAWG. > > Comments? > > -MSK > > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From dotzero@gmail.com Fri Dec 23 20:24:42 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5445111E80AD for ; Fri, 23 Dec 2011 20:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUJC2KSbNr4h for ; Fri, 23 Dec 2011 20:24:41 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E49B11E807F for ; Fri, 23 Dec 2011 20:24:41 -0800 (PST) Received: by dajz8 with SMTP id z8so9154877daj.31 for ; Fri, 23 Dec 2011 20:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tgMkoGMAqIu5TloosujnDkWgUvGXjtBNDYTSJm8CUoM=; b=F9llZ5rfHnH+o5HF9Vuo/Xq7jgAvnp5EFFoUhjuFr3rXhmo3vaQhxVSZJkmS+xR73K 1sA6uaWbzoD9RWsImU+H4YW8eRMP0YLKq00mjHf3rg9n0EV7RXfzKSijpH3VLGMi4X5p 5xQYpMFzjvxG3OfvJ96K+4GxxAvylLOy0lLnI= MIME-Version: 1.0 Received: by 10.68.213.138 with SMTP id ns10mr37013133pbc.53.1324700680956; Fri, 23 Dec 2011 20:24:40 -0800 (PST) Received: by 10.142.74.3 with HTTP; Fri, 23 Dec 2011 20:24:40 -0800 (PST) In-Reply-To: <4EF54997.9090708@isdg.net> References: <4EF54997.9090708@isdg.net> Date: Fri, 23 Dec 2011 23:24:40 -0500 Message-ID: From: Dotzero To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 04:24:42 -0000 On Fri, Dec 23, 2011 at 10:40 PM, Hector Santos wrote: > I can support adding AUTH-RES support to SPF-BIS charter. This is more in > line with SPF-BIS work. Received-SPF is a SHOULD, thus is already optiona= l > for SPF implementations and it would not be a protocol change to offer an > alternative 5322 reporting option for AUTH-RES or both. Since these heade= rs > are generally are for internal mail bots, there is already the possibilit= y > that other headers are using to pass more useful information for the > internal mail processors. > > However, for domain SPF policies using -ALL (hard fail), when the result = is > a FAIL, the PAYLOAD will not be downloaded and there is NO 5322 header > added, no Received-SPF. =A0So by the time mail is downloaded, there will = only > be for results: > > =A0 =A0result =3D =3D "Pass" / SoftFail" / "Neutral" / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "None" / "TempError" / "PermError" > Is this true? RFC4408 states: 2.5.4. Fail A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright. So rejecting is one option but marking is an option as well. This would mean that "Fail" could conceivably be a reported option. > This is critical important and one of the concerns I have with the mindse= t > change with SPF-BIS now focusing on RFC5322 when it was never a major par= t > of SPF other than for adding a Receiver-SPF header. > This is not necessarily a function of RFC5322. > What that means is, while its possible for an local policy to not reject = the > SPF failures at SMTP, and include a ReceivedSPF: Fail header, this defeat= s > the operational importance of SPF a hard fail policy offers to avoid > =A0Accept/Bounce attacks. > I have to disagree with you on this Hector. My experience with private policy assertions based on SPF failures (as well as DKIM failures) coupled with auth failure FBLs has convinced me that there is quite a bit of utility in capturing the payload. I guess where you stand depends on where you sit. > So I can support the support of AUTH-RES, but not with a focus of reporti= ng > to force payload downloads for the purpose of reporting AUTH-RES fail > reports. > Downloading the payload has always been an option in RFC4408 as indicated in 2.5.4. > -- > Hector Santos, CTO > http://www.santronics.com > http://santronics.blogspot.com > > Murray S. Kucherawy wrote: >> >> I believe this falls within the current scope, but it would involve eith= er >> an additional draft deliverable or an additional section in the spfbis >> document. >> >> There are two errata against RFC5451: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5451 >> >> The first of these is a change to what Authentication-Results uses to >> report SPF failures. =A0In particular, SPF itself uses "fail", but A-R u= ses >> "hardfail" to report that case. =A0Since RFC5451 set up IANA registries = for >> results of authentication methods, fixing this amounts to just an IANA >> action and maybe an "Updates" against RFC5451. >> >> I believe we could do this in spfbis easily as it amounts to nothing mor= e >> than a correction, and those are in scope. =A0Although this modifies a >> document outside of our current plan, it is a germane modification to th= is >> work. >> >> If there's objection, I can seek to do it as an AD-sponsored individual >> submission or maybe through APPSAWG. >> >> Comments? >> >> -MSK >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> 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 hsantos@isdg.net Fri Dec 23 21:17:17 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5386721F84ED for ; Fri, 23 Dec 2011 21:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZqvuGnHYvgo for ; Fri, 23 Dec 2011 21:17:16 -0800 (PST) Received: from mail.santronics.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 19DAD21F84E5 for ; Fri, 23 Dec 2011 21:17:15 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7155; t=1324703825; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lMtJ8Y76BtjRRfHC9jNBXMtJD4A=; b=eafXK6680402ItUV8d6g UAtfuzIcURw/lVuZFd0B6Nq1nnfzfrZ5rPcA0k4DqhOYekPG6yF7Z7w6NTHy4Ipt ZTezEYiJKgGjRFXiSMFiHKyH3oB7Wt86yeoeSca0bz97UBY5oXUzhXhQpcSNgzla I6DwUfd+yaj3iJXYBo/d2dU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 24 Dec 2011 00:17: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 v6.4.454.1) with ESMTP id 2200696886.17651.2608; Sat, 24 Dec 2011 00:17:05 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7155; t=1324703680; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zcoPLEV c4kElTzWs+nLlByVN1CKvzxzSUeUC9CDzcgM=; b=sb0fU+bigWFD+98UFzT7/m0 gyTkdTsTck/oANbQMdU00U+nuiXOR6D+2eCtmpuE0bV2adnUsIWG3eo6DA5aKJzk Zz023uVkLm5879vZfZyd8lZYg2hhyeM5YMYW6sp+X87tRWHQBzD/yxwpOGKWU9Yz pRyG4FYlvK6vxRga/ORo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 24 Dec 2011 00:14:40 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2799670110.651.5936; Sat, 24 Dec 2011 00:14:39 -0500 Message-ID: <4EF56050.7090800@isdg.net> Date: Sat, 24 Dec 2011 00:17:04 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <4EF54997.9090708@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 05:17:17 -0000 Dotzero wrote: >> However, for domain SPF policies using -ALL (hard fail), when the result is >> a FAIL, the PAYLOAD will not be downloaded and there is NO 5322 header >> added, no Received-SPF. �So by the time mail is downloaded, there will only >> be for results: >> >> � �result = = "Pass" / SoftFail" / "Neutral" / >> � � � � � � � "None" / "TempError" / "PermError" >> > > Is this true? RFC4408 states: > > 2.5.4. Fail > > A "Fail" result is an explicit statement that the client is not > authorized to use the domain in the given identity. The checking > software can choose to mark the mail based on this or to reject the > mail outright. It is true if the mail is rejected which is often the cause with the deterministic SPF protocol. > So rejecting is one option but marking is an option as well. This > would mean that "Fail" could conceivably be a reported option. Yes, see below. >> What that means is, while its possible for an local policy to not reject the >> SPF failures at SMTP, and include a ReceivedSPF: Fail header, this defeats >> the operational importance of SPF a hard fail policy offers to avoid >> �Accept/Bounce attacks. >> > > I have to disagree with you on this Hector. My experience with private > policy assertions based on SPF failures (as well as DKIM failures) > coupled with auth failure FBLs has convinced me that there is quite a > bit of utility in capturing the payload. I guess where you stand > depends on where you sit. And the history and how one has integrated newer stuff. >> So I can support the support of AUTH-RES, but not with a focus of reporting >> to force payload downloads for the purpose of reporting AUTH-RES fail >> reports. >> > > Downloading the payload has always been an option in RFC4408 as > indicated in 2.5.4. It was left open ended because of the history. The language in the original specs leading up to RFC 4408 was first considered when implementations were only mostly possible with ACCEPTED mail system. But as more implementations came on board and offered or changed to do more dynamic SMTP level processing, this altered the mind set. Keep in mind SPF was based on two other LMAP protocols called DMP and RMX. Both used SMTP level parameters for the LMAP domain::ip association assertion. We supported and explored DMP since RMX was more complex. In fact, DMP was deprecated long ago, and finally removed in our WCSAP product early this year. See Example Below. This was specifically highlight during the SPF-DISCUSS and MARID because there were two (actually four now) kinds of operations: - Original, Always Accept, especially for high scale operation needs. - With better/faster hardware, multi-thread OSes, more modem SMTP software began to do hooks at the SMTP state machine level. This capability was limited to certain SMTP software, it was not universal. - Many of the original setups, that did have the capability but would not scale back then, with the better hardware, they could feasibility do more of smtp level work, and - finally, among all, even if the software had dynamic SMTP level shimming capabilities, it MAY NOT included the more complex shimming at the DATA state. This because more important as DKIM was coming along and newer software began to add the FILTERING scripts to the DATA level to offer a EOD response. In short, SPF is written to allow people to implement it for both types of operations - Dynamic SMTP vs POST SMTP mail processing because the industry was changing very rapidly with better and faster, multi-core hardware during the 2000 decade. What systems were not capable of doing before and had to scale out, were not able to SCALE UP and add more integration of backend hosting databases and do more dynamic processing of the mail. This is very important to combat the hugely problematic Accept/Bounce problem. There was no doubt the direction took on a SMTP level deterministic result for HARD FAILS. If this was never the case (SPF clearly required the payload in all cases, or you believed that is how most systems worked) then the SPF/SENDER-ID history would be very different. That was the whole battle with the issue with SENDER-ID - not requiring or be dependent on the payload. So yes, there are things to clean up in 4408 with semantics when a Received-SPF: FAIL is possible but most likely will never be used or seen. Most of the language in 4408 was based originally on POST SMTP processing because that is how people explored it. But it quickly changed to DYNAMIC SMTP and the language was altered, not not always consistent. I saw that back then, but didn't think it was worth the time to get that cleaned up. Just consider, then to support SPF at the POST SMTP level, you need three parameters passed to the RFC5322 payload as headers or as META data. CIP IP (Connecting IP) RPD Return Path Domain (5321.MAIL FROM) CDN Client Domain (5321.EHLO/HELO) The RPD was required with SMTP receivers with the Return-Path: So POST-SMTP SPF processor can get that piece of data. But keep in mind that this COULD BE removed before the mail is finally posted. This is UUCP/SLIP history here related to this, the SPF would have to be done before it was finally posted. But where would the POST-SMTP SPF processor get the CIP and CDN? The only possibility would be a SMTP required Received: hop line. But not critical because an implementation can use proprietary META header for the post processing before the final post is done, like: ENV-IP: 1.2.3.4 ENV-CDN: mail.foobar.com ENV-FROM: alan@gmai.com ENV-TO: hsantos@isdg.net ENV-DATA: {RFC5322-PAYLOAD} The point is this is also material to codify in SPF-BIS to finally get to do modes of operations consistent for all results regardless if payload is downloaded or not. But for reporting, it must be understood that fail at SMTP MAY NOT include any payload available to add any Received-SPF or AUTH-RES header to pass on to anyone. DMP EXAMPLE: Here is how DMP work which predated SPF using DMP records still existing: nslookup -query=txt 9.131.247.208.in-addr._smtp-client.santronics.com 9.131.247.208.in-addr._smtp-client.santronics.com text = "dmp=allow" Change the IP and repeat: nslookup -query=txt 8.131.247.208.in-addr._smtp-client.santronics.com 8.131.247.208.in-addr._smtp-client.santronics.com text = "dmp=deny" I really liked DMP because it was designed to work with wild cards, but it also required you to add lots of TXT records and that is SPF offered over DMP. Otherwise, the concepts are the same. OVERALL - Accepting the PAYLOAD with SPF fails, is the odd exception for pure and true SPF operations that 100% honor a domains SPF hard fail policy. If a SPF receiver disregards the DOMAIN policy, then the legal responsibility now passed on to the RECEIVER because it intentionally ignored a DETERMINISTIC hard failure. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Fri Dec 23 21:51:39 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C54F21F8479 for ; Fri, 23 Dec 2011 21:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxsGqMFJLx4X for ; Fri, 23 Dec 2011 21:51:38 -0800 (PST) Received: from mail.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 257E121F8476 for ; Fri, 23 Dec 2011 21:51:37 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2631; t=1324705896; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VF2nOqkH62w5e6xC9/lHVlXcpmg=; b=mQtIUDFA5G3Y3JEeCA7Z o7vCz4cWOqauvw+xdRRBmdCogaMLKtXwuYz1XP3Kc2m7St3do0N2mJd9/vpM/kCX q4J5FrePqaVyftrAQYvVMrjw0/FBD7074cX0rhS2tG66YNDLcgZtmFRPpka7G1zU uLi2Kfs5wLVjITeBxepdTFg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 24 Dec 2011 00:51:36 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2202766957.17651.1104; Sat, 24 Dec 2011 00:51:35 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2631; t=1324705753; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=dcxQDq2 TRKxOZLkIyG30SfPALcDFxC338FoX6OCLJwg=; b=qa7WzeQaYQf4wEwvo/5r9XT EhW8v9M8doaag64RJUZrP50uhOTJSbzzcQhq5cVKrszJQoYMT5Zy/8H5ykuyr9u1 ch1WlyqcFfvvAe+MEdlolOvVE5ILiHz5xwbgwhkjGj6/x0f9Ifj2C/xK4yGLHvSg UzsbNPKV2MxmbdGpDZ9w= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 24 Dec 2011 00:49:13 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2801742563.654.3744; Sat, 24 Dec 2011 00:49:11 -0500 Message-ID: <4EF56869.9040905@isdg.net> Date: Sat, 24 Dec 2011 00:51:37 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <4EF54997.9090708@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 05:51:39 -0000 As a follow up, Dotzero wrote: > Downloading the payload has always been an option in RFC4408 as > indicated in 2.5.4. But consider the text in 2.5: Although invalid, malformed, or non-existent domains cause SPF checks to return "None" because no SPF record can be found, it has long been the policy of many MTAs to reject E-Mail from such domains, especially in the case of invalid "MAIL FROM". In order to prevent the circumvention of SPF records, rejecting E-Mail from invalid domains should be considered. In 2.5.5. SoftFail A "SoftFail" result should be treated as somewhere between a "Fail" and a "Neutral". The domain believes the host is not authorized but is not willing to make that strong of a statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal. Ask Scott, this became an OPTION with implementations to force a rejection due to the wide abuse over the 2000 decade experience. We offer SPF options such as these: Accept-SPF-Pass True ; if false, continue testing Accept-SPF-SoftFail FALSE ; if false, continue testing Accept-SPF-Neutral FALSE ; if false, continue testing rescode_spf_fail 550 ; rejected by SPF Lookup rescode_spf_softfail 550 ; rejected by SPF Lookup and that last one was added because of operational experience. In 10.5. Untrusted Information Sources it says: SPF uses information supplied by third parties, such as the "HELO" domain name, the "MAIL FROM" address, and SPF records. This information is then passed to the receiver in the Received-SPF: mail headers and possibly returned to the client MTA in the form of an SMTP rejection message. This is only possible with a ACCEPT mail first operation in order to create a bounce. A SMTP Level reject will not have a DSN or BOUNCE so its impossible to have an Receiver-SPF at this point. The sender could add it when it does the bounce, but I doubt it will add a Receiver-SPF unless there was some SMTP negotiated information in the 55x response where the sender can determine it was a SPF rejection. Overall, while RFC4408 has history to allow for payload acceptance before SPF processing was done, it is not the dominant mode and main focus of implementing SPF today as a means to avoid the need to accept the payloads in the first place. This is the kind of stuff we need to clean up in the RFC 4408, because the semantics are mixed with chicken vs egg design issues. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From vesely@tana.it Sat Dec 24 05:39:05 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89AB21F8461 for ; Sat, 24 Dec 2011 05:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8digeGxON3Ds for ; Sat, 24 Dec 2011 05:39:04 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B3B5821F845D for ; Sat, 24 Dec 2011 05:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324733943; bh=51ke+C6T7yyF4q2vFN502pvDHIYZpHLf9j7P4tlLBWY=; l=1268; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=aFU5fzUKblCEjnL+EOjhzK5RoDn1YJOUPE7ELaXMclqafJtcH7DFQwSyil/+QNN8N rEx9Ot479MWmjaesgbaIOdSVqRMKDM6P4c4leHAakaGpDuOZCBLLLLL75Xxa0KabxU BEZKe9Io6ce624ZYwXZAnWqGQQInV+HzgssNJ+b0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 24 Dec 2011 14:39:03 +0100 id 00000000005DC039.000000004EF5D5F7.00005082 Message-ID: <4EF5D5F7.6050507@tana.it> Date: Sat, 24 Dec 2011 14:39:03 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20111223125517.09160578@resistor.net> <08a8505d-3901-4ad4-b584-63c68086ecc0@email.android.com> In-Reply-To: <08a8505d-3901-4ad4-b584-63c68086ecc0@email.android.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 13:39:05 -0000 On 24/Dec/11 00:25, Scott Kitterman wrote: > SM wrote: > >> I suggest that you defer this until after the core work is >> completed. There will always be a good reason for adding >> deliverables. It's better not to go down that path. > > One possible reason to deal with this as core work would be if we > wanted to explore deprecating the Received SPF header field in > favor of the Authentication Results header field. We don't need to deprecate the former in order to allow the latter. An implementation may be configured to add either header field, independently of each other. A-R needs some configuration anyway, e.g. for how to set the "authserv-id" token. > SPF Received is in wide use, so it's not a candidate for removal, +1 > but we might start in that direction if we could make a few > adjustments to Authentication Results. I don't think we need a separate document for establishing allowing A-R instead of or in addition to R-SPF. However, it would be impractical to have a large document such as 4408bis update RFC 5451, because readers will have a hard time spotting what does the update consist of. It would be much better to produce a 5451bis, and/or somehow bless the errata meanwhile. jm2c From spf2@kitterman.com Sat Dec 24 16:19:54 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA4A21F848E for ; Sat, 24 Dec 2011 16:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PACtXcO-Gr1A for ; Sat, 24 Dec 2011 16:19:53 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECC021F8488 for ; Sat, 24 Dec 2011 16:19:53 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9F0F220E40B1; Sat, 24 Dec 2011 19:19:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324772391; bh=dwAsFpuFlQPbWd803p2MVhCevmDNAi6eh8YzgHPkjQw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=qfU+okP4DULFoy16bpiHZOeNitMOb10QPSITBqRXFQq78ajOw4l3NhFxLy9kFHE4a cPYhOjpIobth6nDOeyHihi46aHKXuqTYDoTe7Hy7/GEl2u+D3OXdhng5vKvyiWtkX5 7frRV4tdj0aiIG8uiBGzzzOrYFhKlfbxJuvIY7Dc= Received: from scott-latitude-e6320.localnet (74-222-219-222.dyn.everestkc.net [74.222.219.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7286020E40B0; Sat, 24 Dec 2011 19:19:51 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 24 Dec 2011 19:19:50 -0500 Message-ID: <3090262.yHcJHXWpZV@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4EF54997.9090708@isdg.net> References: <4EF54997.9090708@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] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 00:19:54 -0000 On Friday, December 23, 2011 10:40:07 PM Hector Santos wrote: > I can support adding AUTH-RES support to SPF-BIS charter. This is more > in line with SPF-BIS work. Received-SPF is a SHOULD, thus is already > optional for SPF implementations and it would not be a protocol change > to offer an alternative 5322 reporting option for AUTH-RES or both. > Since these headers are generally are for internal mail bots, there is > already the possibility that other headers are using to pass more > useful information for the internal mail processors. > > However, for domain SPF policies using -ALL (hard fail), when the > result is a FAIL, the PAYLOAD will not be downloaded and there is NO > 5322 header added, no Received-SPF. So by the time mail is > downloaded, there will only be for results: > > result = = "Pass" / SoftFail" / "Neutral" / > "None" / "TempError" / "PermError" > > This is critical important and one of the concerns I have with the > mindset change with SPF-BIS now focusing on RFC5322 when it was never > a major part of SPF other than for adding a Receiver-SPF header. > > What that means is, while its possible for an local policy to not > reject the SPF failures at SMTP, and include a ReceivedSPF: Fail > header, this defeats the operational importance of SPF a hard fail > policy offers to avoid Accept/Bounce attacks. > > So I can support the support of AUTH-RES, but not with a focus of > reporting to force payload downloads for the purpose of reporting > AUTH-RES fail reports. One of the rules for new modifiers in SPF is that they cannot change the SPF result. Whatever this extension does, the output it produces is not an SPF result, it's some kind of other result and should be reported in a way that doesn't confuse it with an SPF result. The extension draft should probably cover how to report it's results since it needs a different authenticatoin type. Scott K From msk@cloudmark.com Sat Dec 24 21:07:29 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A5E21F843D for ; Sat, 24 Dec 2011 21:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m3fqBMOeCSg for ; Sat, 24 Dec 2011 21:07:28 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C47B321F842C for ; Sat, 24 Dec 2011 21:07:26 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 24 Dec 2011 21:07:22 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 24 Dec 2011 21:07:25 -0800 From: "Murray S. Kucherawy" To: "dcrocker@bbiw.net" Date: Sat, 24 Dec 2011 21:07:29 -0800 Thread-Topic: [spfbis] Suggestion for an additional deliverable Thread-Index: AczBvNc+aBvVWZxZT3GwYGtvrQO9TwBBdoAA Message-ID: References: <4EF4F787.9090408@dcrocker.net> In-Reply-To: <4EF4F787.9090408@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 05:07:29 -0000 > -----Original Message----- > From: Dave CROCKER [mailto:dhc2@dcrocker.net] > Sent: Friday, December 23, 2011 1:50 PM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Suggestion for an additional deliverable >=20 > I don't understand. Unless I missed it, the draft charter does not > cite RFC 5451, reporting or header fields. How does modifying a > reporting specification fall within the current draft charter? There's some movement toward replacing the Received-SPF header field with t= he one defined in RFC5451 as the standard way to relay the results of SPF e= valuation on a message. If that's the consensus desire, then it seems to = me that resolving this erratum is a reasonable thing to include in the over= all "clean up and publish" effort that the charter seeks to execute. We don't have to; I can always do it as an individual submission. It just = seems a good fit. Or maybe it's time to consider moving RFC5451 to Interne= t Standard since it's been more than six months and there are ample impleme= ntations of it now, which I would consider doing through APPSAWG or as an i= ndividual. -MSK From msk@cloudmark.com Sat Dec 24 21:08:18 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141D321F843D for ; Sat, 24 Dec 2011 21:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZMkluqD2ngZ for ; Sat, 24 Dec 2011 21:08:17 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BA1F721F8441 for ; Sat, 24 Dec 2011 21:08:17 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 24 Dec 2011 21:08:14 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 24 Dec 2011 21:08:17 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Sat, 24 Dec 2011 21:08:21 -0800 Thread-Topic: [spfbis] Suggestion for an additional deliverable Thread-Index: AczBxBwrq/Lh4Il2QE+pvA0E17/WlwA/wHxg Message-ID: References: <6.2.5.6.2.20111223125517.09160578@resistor.net> In-Reply-To: <6.2.5.6.2.20111223125517.09160578@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 05:08:18 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of SM > Sent: Friday, December 23, 2011 1:42 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Suggestion for an additional deliverable >=20 > >If there's objection, I can seek to do it as an AD-sponsored individual > >submission or maybe through APPSAWG. >=20 > I suggest that you defer this until after the core work is completed. > There will always be a good reason for adding deliverables. It's > better not to go down that path. I suggest that it is "core work" given that the goal here is to clean up an= d republish SPF, and there's some consideration for the idea of dropping Re= ceived-SPF and replacing it with Authentication-Results. -MSK From msk@cloudmark.com Sat Dec 24 21:10:27 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB5721F8441 for ; Sat, 24 Dec 2011 21:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0K1AT-Hye80 for ; Sat, 24 Dec 2011 21:10:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F388E21F843D for ; Sat, 24 Dec 2011 21:10:23 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 24 Dec 2011 21:09:54 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 24 Dec 2011 21:09:57 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Sat, 24 Dec 2011 21:10:01 -0800 Thread-Topic: [spfbis] Suggestion for an additional deliverable Thread-Index: AczBzMd7XO0XHXmvTmaYa4PyqOZVhgA9n/6g Message-ID: References: <4EF51243.7010801@Commerco.Net> In-Reply-To: <4EF51243.7010801@Commerco.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 05:10:27 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Commerco WebMaster > Sent: Friday, December 23, 2011 3:44 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Suggestion for an additional deliverable >=20 > Murray, since RFC 5451 looks like it is authored by you, would you > entertain adjusting 2.4.2 (the SPF and Sender-ID results) to reflect > the SPF responses per RFC 4408? Hardfail is not mentioned in RFC 4408 > (http://www.rfc-editor.org/rfc/rfc4408.txt), so I'm not sure how it got > into RFC 5451 (unless it is part of the Sender-ID fork, which I think > is outside the scope of the charter for SPFbis). I'd be happy to do that. Fortunately we can tackle it as a simple IANA cha= nge and not a full republication of RFC5451. Since the change is specific = to SPF, I thought this might be a reasonable thing to add in the initial ef= fort of spfbis. From msk@cloudmark.com Sat Dec 24 21:17:36 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6A721F8481 for ; Sat, 24 Dec 2011 21:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipoBU0u+juS5 for ; Sat, 24 Dec 2011 21:17:35 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A1C5C21F847F for ; Sat, 24 Dec 2011 21:17:35 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 24 Dec 2011 21:17:32 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 24 Dec 2011 21:17:35 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Sat, 24 Dec 2011 21:17:39 -0800 Thread-Topic: [spfbis] Suggestion for an additional deliverable Thread-Index: AczCQXQsGB0D8aNbSoOzdKkotXYAYAAgkOZg Message-ID: References: <6.2.5.6.2.20111223125517.09160578@resistor.net> <08a8505d-3901-4ad4-b584-63c68086ecc0@email.android.com> <4EF5D5F7.6050507@tana.it> In-Reply-To: <4EF5D5F7.6050507@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 05:17:36 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Saturday, December 24, 2011 5:39 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] Suggestion for an additional deliverable >=20 > > One possible reason to deal with this as core work would be if we > > wanted to explore deprecating the Received SPF header field in favor > > of the Authentication Results header field. >=20 > We don't need to deprecate the former in order to allow the latter. While true, it does also mean that an agent which adds one or the other nee= ds to pick the one that downstream agents (i.e., MUAs) are most likely to u= se. Having two standards to do the same thing doesn't help interoperabilit= y. > > SPF Received is in wide use, so it's not a candidate for removal, >=20 > +1 >=20 > > but we might start in that direction if we could make a few > > adjustments to Authentication Results. I suggest we work toward convergence and eventually deprecate Received-SPF.= If we can do that directly in RFC4408bis by fixing up this one errata ite= m, then we should do so. > I don't think we need a separate document for establishing allowing A-R > instead of or in addition to R-SPF. However, it would be impractical > to have a large document such as 4408bis update RFC 5451, because > readers will have a hard time spotting what does the update consist of. > It would be much better to produce a 5451bis, and/or somehow bless the > errata meanwhile. I disagree; RFC4408bis can update RFC5451 just to make this one correction,= which amounts to a simple IANA action. RFC5451 would thereafter show as "= Updated by RFC4408bis", which means "If you're implementing RFC5451, you re= ally should go read RFC4408bis as well". The corrected definition will the= n appear in two places: RFC4408bis, and the registry of A-R method results. RFC5451 has two errata against it, one of which is minor (a change to an ex= ample), and the other would be resolved by this action. No need to do an R= FC5451bis just for this. Nice and neat. -MSK From spf2@kitterman.com Sat Dec 24 23:03:25 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4E021F84A7 for ; Sat, 24 Dec 2011 23:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOkBMHRCVMIl for ; Sat, 24 Dec 2011 23:03:25 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4104921F844E for ; Sat, 24 Dec 2011 23:03:25 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 52E7E20E40B1; Sun, 25 Dec 2011 02:03:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1324796603; bh=4GvnM+wqqvCiCLwZIsu5q5rIHOE30VJ5OWAeR3I2MoY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=L0u6qfHi+CCGpamwOx/xhj0FSOOyKP2oqCPS/xKaoL2/cJw1y0BUwdEmOCaNOdeOa tJs8DuDPj7YBeoexIftnBUnuoRRHQwXeSxisFkOAbIO6gDE/YuEh97k25J613JMUbC qmyPXROExFbY8wy3KE0OXdltJBv2NhNk1edhlqmg= Received: from scott-latitude-e6320.localnet (74-222-219-222.dyn.everestkc.net [74.222.219.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 24A7620E40B0; Sun, 25 Dec 2011 02:03:22 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 25 Dec 2011 02:03:21 -0500 Message-ID: <4908869.UtSTCztZJe@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <4EF4F787.9090408@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] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 07:03:25 -0000 On Saturday, December 24, 2011 09:07:29 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: Dave CROCKER [mailto:dhc2@dcrocker.net] > > Sent: Friday, December 23, 2011 1:50 PM > > To: Murray S. Kucherawy > > Cc: spfbis@ietf.org > > Subject: Re: [spfbis] Suggestion for an additional deliverable > > > > I don't understand. Unless I missed it, the draft charter does not > > cite RFC 5451, reporting or header fields. How does modifying a > > reporting specification fall within the current draft charter? > > There's some movement toward replacing the Received-SPF header field with > the one defined in RFC5451 as the standard way to relay the results of SPF > evaluation on a message. If that's the consensus desire, then it seems to > me that resolving this erratum is a reasonable thing to include in the > overall "clean up and publish" effort that the charter seeks to execute. I don't think the RFC 5451 Authentication Results header field is currently a fully suitable replacement for Received-SPF. It is close, but I think there is work to be done beyond the eratta. Not a lot, but some. I think it's sensible to fold adding investigating this as a core task and then using 4408bis to update 5451 if there is consensus to go in this direction. Scott K From dhc2@dcrocker.net Sun Dec 25 13:14:19 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EE421F844A for ; Sun, 25 Dec 2011 13:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrnDeMeCQNlh for ; Sun, 25 Dec 2011 13:14:18 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7215421F8440 for ; Sun, 25 Dec 2011 13:14:18 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBPLEAIi025425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Dec 2011 13:14:16 -0800 Message-ID: <4EF79222.5050005@dcrocker.net> Date: Sun, 25 Dec 2011 13:14:10 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4EF4F787.9090408@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 25 Dec 2011 13:14:16 -0800 (PST) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 21:14:19 -0000 On 12/24/2011 9:07 PM, Murray S. Kucherawy wrote: > There's some movement toward replacing the Received-SPF header field Absent an emergency, I'd recommend deferring this until the core work is done. That's not a comment on the benefit of the added task, but of working group focus. There might be some debate about having that spec fit within this working group at all, given that it's scope is broader than SPF, but since the actual work is SPF-related, we can probably fold it in. But, really, I think we'll do best by maintaining focus on the core work of the charter, first. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Sun Dec 25 20:45:44 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA0F21F88A0 for ; Sun, 25 Dec 2011 20:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IA0iWJoLoX7 for ; Sun, 25 Dec 2011 20:45:43 -0800 (PST) Received: from winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 72CBE21F8888 for ; Sun, 25 Dec 2011 20:45:42 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1825; t=1324874740; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=b9C0vNXqh8vAb5KGeDeZXR1bLPI=; b=n/AL3UBSZBFVFSeMEVGu UP4QJOk+uvVUB1xa+vH9lAvS8ne+tUss5kkJcRqRRgs1AFNBRCjQ8cvEYnZxPN6D TmGy2O6dsbgGN/wfk8v8zhIAC9XOaHdt8hcDh44GxPAbn1lIjfj/gNizY+XIXMFR Jo2xzjO+/OWACMAnpcX0vlU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 25 Dec 2011 23:45: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 v6.4.454.1) with ESMTP id 2371609491.20344.3612; Sun, 25 Dec 2011 23:45:39 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1825; t=1324874594; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=1Bxle/b xFgROAoGXcvyNWJE2ijAjL/xG/k67KDd1YvI=; b=AtB36rwyd3lVTKE9h9Y2lh1 zXmcJJnPvBugfdkLlf+oALuiPFOAzmmqYTgOsm3JjABn+R5sDcUCTm0JBLqijqv/ 9C7/1zh+TUKBwoC4sT2jqMMTgSECgrhBe8564R14UnkaNNyqMQ5kI8rBnDj6p9Hd 6SH2gyg6evd8LsenV95c= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 25 Dec 2011 23:43:14 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2970584125.974.3556; Sun, 25 Dec 2011 23:43:13 -0500 Message-ID: <4EF7FBF2.7010402@isdg.net> Date: Sun, 25 Dec 2011 23:45:38 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF54997.9090708@isdg.net> <3090262.yHcJHXWpZV@scott-latitude-e6320> In-Reply-To: <3090262.yHcJHXWpZV@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Augmenting SPF with additional Email technology X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 04:45:44 -0000 Scott Kitterman wrote: > On Friday, December 23, 2011 10:40:07 PM Hector Santos wrote: >> So I can support the support of AUTH-RES, but not with a focus of >> reporting to force payload downloads for the purpose of reporting >> AUTH-RES fail reports. > > One of the rules for new modifiers in SPF is that they cannot change the SPF > result. Whatever this extension does, the output it produces is not an SPF > result, it's some kind of other result and should be reported in a way that > doesn't confuse it with an SPF result. The extension draft should probably > cover how to report it's results since it needs a different authentication > type. +1, I think you are touching base with what we all expected would inevitably need to do once these protocols since MARID got to a point were we could it all together and had the data to evaluate and optimize the process - Basically establishing what would be the new persistent assertions both deterministic and heuristics systems could yse to get a low/zero false positive high payoff by combining all the email technologies, in particular SPF, DKIM and DKIM POLICY. IMO, the deterministic policies were easy in concept to understand, but it was the indeterministic results that needed to be dealt with - items closely related to a common issue with both IMO - 3rd party or middle ware related issues. With SPF, authorizing the transition point (multi-hops) issue and with DKIM, the authorization of the 3rd party signature. I have some text I wanted to post regarding this but will wait until I get a chance to review your draft and perhaps (or not) introduce it in my comments - haven't had the time yet to read it but will sometime early this week. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Mon Dec 26 04:39:43 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D923921F8B8D for ; Mon, 26 Dec 2011 04:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKwCrMhj9H8H for ; Mon, 26 Dec 2011 04:39:43 -0800 (PST) Received: from listserv.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 11EF621F8B9C for ; Mon, 26 Dec 2011 04:39:42 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1446; t=1324903180; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=sOeZdXII/RnOQgpXlcqd/c4R9f8=; b=MMSWwPopIGOxt6qFq7to B8/Vw10R7MeDL5G7GjLVT4aAsLhpDEiLgvhWUCQoh5QSHLSr7jL/RdJvJJ/NEKv0 cM7Z3Apx+AG1tqjpsbRl/LgNZKOCVuygNIjqDiP/ZjA59SXg6afmBykn9awS6tgc c3AAbpQEIuwFWPfpj7QAEYY= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 26 Dec 2011 07:39:40 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2400049955.20344.1700; Mon, 26 Dec 2011 07:39:40 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1446; t=1324903032; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9/N74ZT 0tCpfQKCYvXOFkPPfYatI2f1uEtIGdmWfUY0=; b=pgF6y82sKWUn6I5raBQQIKa 785j8tXBRqeCa+yKVzPmFN/pD/nikIewtjnAC6ShAQjYCVCiRfEbdZVCXz3lx2LB xYF3SOMGIX2a+EybsytqNptNNwDG/AcNY6I5cYyDZYYEikERCIHF56Vldmcv1dMG nP1qUcqRBuMzM4c67H0M= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 26 Dec 2011 07:37:12 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2999022282.1063.7252; Mon, 26 Dec 2011 07:37:11 -0500 Message-ID: <4EF86B09.2090608@isdg.net> Date: Mon, 26 Dec 2011 07:39:37 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Comments on draft-kitterman-4408bis-00 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 12:39:44 -0000 [Resubmitted from the proper membership address] Other than the following extremely minor comment, I saw no substantial change to this SPF-BIS draft in regards to the SPF protocol. Maybe its just me, but I see too much usage of the term MEMO for what is otherwise a RFC update for a proposed technical specification. In 1.1, it says:: The protocol was originally documented in [RFC4408], which this memo replaces. As far as I am concern, SPF-BIS I-D is not a MEMO A.K.A. Memorandum. It is an technical and/or functional specification depending on your discipline. I suggest text change to strengthen what this document really is: The protocol was originally documented in [RFC4408], which this [new] specification (or document) updates and replaces. Perhaps a correction or errata to SPF-BIF might be described as a MEMO or perhaps an Informational RFC, but this is a complete draft standard update for a proposed protocol specification - not a piece of a MEMO per se. Other than this nit, I did a complete compare and saw nothing that is of substance to write about. However, IMO, there are plenty of practical SPF-BIS material that should be considered that was learned over the decade. As an early adopter,I would like the opportunity to describe and outline these SPF-BIS material suggestions if there is interest. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From vesely@tana.it Mon Dec 26 10:42:36 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CB421F8C33 for ; Mon, 26 Dec 2011 10:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.036 X-Spam-Level: X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWMOKLT-Um6H for ; Mon, 26 Dec 2011 10:42:35 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7521F8C28 for ; Mon, 26 Dec 2011 10:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324924951; bh=1Y6zmRHV7Q2AoM6LWt1oUWQEbntR5Pmtq6KRlRUJDS4=; l=1975; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Q6idC4NWxZy6x16Dhk1bC+Rpk/PoDqtCze5ix7A3g1D8mGcZRyM0hqO8bci7aQwsI y/VGY5971k35NegWIHQoxrqZqTcWbFU2W826bqZPlj+gnDCyVCRsGNPsvCb7v8l3D9 QROCVlOC2nAq1d3u8i021xsqaRJiFN763PBXvE2Q= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 26 Dec 2011 19:42:31 +0100 id 00000000005DC039.000000004EF8C017.00007C4E Message-ID: <4EF8C017.8070809@tana.it> Date: Mon, 26 Dec 2011 19:42:31 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20111223125517.09160578@resistor.net> <08a8505d-3901-4ad4-b584-63c68086ecc0@email.android.com> <4EF5D5F7.6050507@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 18:42:36 -0000 On 25/Dec/11 06:17, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >> We don't need to deprecate the former in order to allow the latter. > > While true, it does also mean that an agent which adds one or the > other needs to pick the one that downstream agents (i.e., MUAs) are > most likely to use. Having two standards to do the same thing > doesn't help interoperability. It is also a question of modularity. The mail filter that sets Authentication Results needs to access the whole body of a message, and that might be the first time it gets called. In such cases, Received-SPF can be considered a convenient standard place to store the result of an SPF evaluation, temporarily if the filter will later translate it into an A-R field --on a shared-object architecture like Sendmail one could use core memory, but that's not always the case. For example, I get these: Return-Path: Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=ietf.org; dkim=pass header.i=@ietf.org Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by wmail.tana.it with ESMTP; Sun, 25 Dec 2011 06:17:37 +0100 id 00000000005DC03F.000000004EF6B1F2.00001C23 Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=HELO; sender=mail.ietf.org; remoteip=12.22.58.30; remotehost=mail.ietf.org; helo=mail.ietf.org; receiver=wmail.tana.it; Received-SPF: pass (Address passes the Sender Policy Framework) SPF=MAILFROM; sender=spfbis-bounces@ietf.org; remoteip=12.22.58.30; remotehost=mail.ietf.org; helo=mail.ietf.org; receiver=wmail.tana.it; >> readers will have a hard time spotting what does the update consist of. > > "If you're implementing RFC5451, you really should go read RFC4408bis as well". Isn't it a pain in the neck to have to learn the whole SPF spec for someone who just wishes to implement, say, the auth method for his MSA? From hsantos@isdg.net Tue Dec 27 09:29:50 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC6321F856F for ; Tue, 27 Dec 2011 09:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYiWVpX3hGkG for ; Tue, 27 Dec 2011 09:29:49 -0800 (PST) Received: from ntbbs.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 01DF621F8569 for ; Tue, 27 Dec 2011 09:29:44 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3367; t=1325006974; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=+6O1XIVpMw/vJO7sndmsvFzb4DA=; b=jYqcnAakzO0ksh9gB7ya gbm7vV3OWEDhXYhSbJEKZAxqdQnAW43UnKsfO4BoBzfpOWIiB1sb8oA1eqZIO1yk dDOqgDqnAc6MGAEXqo3SmIpFTrYoM0RdI9+/tp03+4m4ooWnpsZX8rSrJmtlYq8X ENUEaAgNmKgNhABMqsffteU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 27 Dec 2011 12:29:34 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2503841648.20344.3168; Tue, 27 Dec 2011 12:29:33 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3367; t=1325006823; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hvEOhi5 OzdYJDH52h1nARsxQ2ycDGBQdE5W10Hjk2+E=; b=mjk+pDItqTaNJylRhD+ApjH AEjhkcXp+xOwwHF4ORBm1rWmkz+Z3RnHydVlZJt29YHszJeX/eug0HbCQkTjj0p9 aeTMUr8PYmIdHuEEmcl82feowwWq8TJYoSd/2p4m9DKc08oUyIYy2LjPX0HLk9ie e20V4qLRoiDr4tJITtME= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 27 Dec 2011 12:27:03 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3102813547.2224.7152; Tue, 27 Dec 2011 12:27:02 -0500 Message-ID: <4EFA006D.6070703@isdg.net> Date: Tue, 27 Dec 2011 12:29:17 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Suggestions for SPF-BIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 17:29:50 -0000 The following suggestions I believe are reasonable for SPF-BIS, overall four items: 1) Dynamic vs Post SMTP SPF processing 2) Support for SMTP SUBMITTER Extension (RFC 4405) 3) Support for AUTH-RES (RFC 5965) 4) Dealing with Transition Points 1) Dynamic vs Post SMTP SPF processing SPF-BIS should make it very clear the two basic methods that it can be implemented: - Dynamic or Online SMTP processing, - Post Mail Acceptance, session ended mail processing. The first one is a SMTP level rejection and this is long followed the US EPCA requirement for satisfying User Expectation with an immediate notification. The 2nd one provides an 250 acceptance and User Expectation for delivery. Per US EPCA, a delay notification is required if delivery can not be met. To get around this, SPF-BIS, like ADSP, needs clear protocol standard semantics that a POST mail acceptance DISCARD is acceptable. SPF-BIF should have two sections that basically talks about: 1.1) The need to pass the SPF inputs to the PAYLOAD meta information so that a post smtp SPF process can take place. This not a standard format nor do I think it should be, but it needs to be pointed out to implementators what they need to pass. 1.2) Clear Technical Allowance for DISCARDING of mail for SPF HARD FAIL results, no bounce required. This is not related to a report channel if that is desired. 2) Support for SMTP SUBMITTER Extension (RFC 4405) SPF-BIS should include a section on the optional SUBMITTER support and describe how it is used by receivers and also what is required of them to make any forwarding of MAIL FROM persistent with any SUBMITTER keyword. For POST SMTP SPF processing, the question I have is how is SUBMITTER passed to the payload or if its necessary since the POST SMTP SPF processor would be able to do SENDER-ID logic with the available payload. This is probably a generic question regarding adding the Return-Path per SMTP receiver requirement. Does that include any keywords passed in in MAIL FROM? 3) Support for AUTH-RES (RFC 5965) I think it is reasonable from an engineering standpoint to offer support for AUTH-RES that SPF implementators can use either in place of Received-SPF or both. The main reason is that today, SPF is not the only game in town. DKIM is also part of the SMTP receiver mail processing. I don't think we have reached a point where we are beginning to couple multiple results for a final results, but when we do get to that point, it will be an easier design for algorithms based on looking at all the result entries in AUTH-RES. 4) Dealing with Transition Points It has been long understood since day one that the basic problem with SPF was how the LMAP domain::ip association is no longer valid after the first hop (transition points) or relays. Its the reason why SENDER-ID existed, the reason also DKIM first existed and was considered as a SPF replacement as a possible IP path independent solution. I think SPF-BIS should have a clear section that talks about this and want are current possible solutions to the problem. The section should also focus on what policies are used and how a particular policy can have an affect on transition points. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From SRS0=ZyGiz=7I==stuart@gathman.org Tue Dec 27 17:46:21 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA0721F8B0D for ; Tue, 27 Dec 2011 17:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noN2CRu1DBsl for ; Tue, 27 Dec 2011 17:46:20 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB4121F8B0C for ; Tue, 27 Dec 2011 17:46:20 -0800 (PST) Received: from fairfax.gathman.org (gathman [192.168.10.1]) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id pBS1jeXa028711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Dec 2011 20:45:42 -0500 Message-ID: <4EF8F336.8080508@gathman.org> Date: Mon, 26 Dec 2011 17:20:38 -0500 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF54997.9090708@isdg.net> <4EF56050.7090800@isdg.net> In-Reply-To: <4EF56050.7090800@isdg.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ReSent-Date: Tue, 27 Dec 2011 20:46:11 -0500 (EST) ReSent-From: "Stuart D. Gathman" ReSent-To: spfbis@ietf.org ReSent-Subject: Re: [spfbis] Suggestion for an additional deliverable ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 01:48:19 -0000 Long ago, Nostradamus foresaw that on 12/24/2011 12:17 AM, Hector Santos would write: > > In short, SPF is written to allow people to implement it for both > types of operations - Dynamic SMTP vs POST SMTP mail processing > because the industry was changing very rapidly with better and faster, > multi-core hardware during the 2000 decade. What systems were not > capable of doing before and had to scale out, were not able to SCALE > UP and add more integration of backend hosting databases and do more > dynamic processing of the mail. This is very important to combat the > hugely problematic Accept/Bounce problem. > > There was no doubt the direction took on a SMTP level deterministic > result for HARD FAILS. If this was never the case (SPF clearly > required the payload in all cases, or you believed that is how most > systems worked) then the SPF/SENDER-ID history would be very > different. That was the whole battle with the issue with SENDER-ID - > not requiring or be dependent on the payload. Checking SPF dynamically is technically not a problem. The problem for a small business is that a sender will publish a policy which gives a FAIL result, but still expect the email to be delivered. If we were gmail or aol, they would fix their problem and move on, but they will not do so for a small business. Hence, a small business must maintain a database of overrides to sender policy. Often, this database will include "substitute" SPF record reverse engineered from the sending patterns of the broken email domain. When reporting SPF results for such domains, an implementation MUST report the ACTUAL SPF result, and not the "customer is never wrong" policy driven result. Hence, any Received-SPF or Authentication-Results header must be able to report a FAIL result. P.S. Should 4408bis address when/if to send DSNs based on SPF results? From vesely@tana.it Wed Dec 28 02:50:34 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD5E21F8876 for ; Wed, 28 Dec 2011 02:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.597 X-Spam-Level: X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CPLc6CV-6Tw for ; Wed, 28 Dec 2011 02:50:33 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5066B21F87FC for ; Wed, 28 Dec 2011 02:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325069429; bh=pj4Pg0W/2OEUiYBOM/LViXd4HPhBK7F43+vnqMB48Ho=; l=1173; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ezzK+yCwrgmT9uNewJuCBz/9jlxHcawrDYY4AzImOthNnXajayMN62v5piETEf1c8 AuYg7VEAwBzy3/AvDjQYicgrxgFnrmanJufF8l/ThkYhDkIgMhPwbadcQJTRvBXp44 +Pprp7OxOgreEgIHmBeEmYzcdIqr/y+GUsP41YI8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 28 Dec 2011 11:50:29 +0100 id 00000000005DC033.000000004EFAF475.00002826 Message-ID: <4EFAF475.3090404@tana.it> Date: Wed, 28 Dec 2011 11:50:29 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF54997.9090708@isdg.net> <4EF56050.7090800@isdg.net> <4EF8F336.8080508@gathman.org> In-Reply-To: <4EF8F336.8080508@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 10:50:34 -0000 On 26/Dec/11 23:20, Stuart Gathman wrote: > > Hence, a small business must maintain a database of overrides to > sender policy. Often, this database will include "substitute" SPF > record reverse engineered from the sending patterns of the broken > email domain. When reporting SPF results for such domains, an > implementation MUST report the ACTUAL SPF result, and not the > "customer is never wrong" policy driven result. Agreed. However, well established policies (e.g. best-guess) deserve to be reported adequately too --especially for empty MAIL FROMs. > Hence, any Received-SPF or Authentication-Results header must be > able to report a FAIL result. Yes. But for result-based processing, that Hector calls post-SMTP, authentication is successful on "pass". Neutral, fail, or whatever else are just not authenticated. IOW, the important point is to bring out /positive/ results. Is that correct? > P.S. Should 4408bis address when/if to send DSNs based on SPF results? Given the similarity between DSN and SPF-reporting, that discussion may open up the possibility of a nice summing-up if it will be addressed in the other deliverable. From hsantos@isdg.net Wed Dec 28 05:57:40 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27EB21F85B9 for ; Wed, 28 Dec 2011 05:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xVkDrSmjp0Z for ; Wed, 28 Dec 2011 05:57:39 -0800 (PST) Received: from ftp.catinthebox.net (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 72D4D21F8551 for ; Wed, 28 Dec 2011 05:57:39 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3365; t=1325080650; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KDl38pUYU/2PafWCwTo69H+wnKo=; b=mPS3kYBGiwIS3KNbWKWw qvkm01Dc4PwerSAeTXXoEgU9u2U0aacFtuRvwRRtj3XtlzBRGFqgJCAct5OipGuo GWpOSO9PHtbhMHDfnOTeh1afvcGIOgMGLodlE2/5JOkcZLT8rBpEkJ4rxSnX4iUT 8cIXey1c6qhwNaRrAu56SEw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 28 Dec 2011 08:57:30 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2577517472.24321.2560; Wed, 28 Dec 2011 08:57:29 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3365; t=1325080497; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jHQsN5n LCfV6lX1MNh29el/uPE/Ww/2BrdTAUnjN2bo=; b=GyM/u0oTMHqcUMDTscPIF46 y8EPWOAUPd2DKz5BXjJr4TSiEEYhWJ1r2hxt5sz1F+z4S0Uq9rBxNmXLQYISZF+q Psvtbua2IK4rUl/b7yGGvhG+xVn1xYaeqNHlaiAtxOIi4kpOHsLYbxHzMpl5eVF3 deD+JfCiENISzs3qROQo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 28 Dec 2011 08:54:57 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3176487719.2391.1764; Wed, 28 Dec 2011 08:54:57 -0500 Message-ID: <4EFB2041.5040101@isdg.net> Date: Wed, 28 Dec 2011 08:57:21 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF54997.9090708@isdg.net> <4EF56050.7090800@isdg.net> <4EF8F336.8080508@gathman.org> In-Reply-To: <4EF8F336.8080508@gathman.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 13:57:40 -0000 Stuart Gathman wrote: > > P.S. Should 4408bis address when/if to send DSNs based on SPF results? > I like to view this as what is required in the first place. If an Online SMTP rejection is performed (for any reason), there is no DNS or bounce possibility at this node. The sender, or rather the hop (receiver) that did the initial 250 acceptance is required per SMTP to do a DNS/BOUNCE. That has nothing to do with SPF or any other email technology, and to keep with persistent engineering, SPF should not change it and if so, only by a standard POLICY concept that we have endorsed. That is where SPF policies come in to play: FAIL - A Domain Policy to REJECT, don't question it. SOFT - It looks wrong, but may be rejected is not automatic NEUTRAL - "I have no clue what I am doing." FAIL is a 100% deterministic and the DOMAIN is telling you, the sender information its wrong, don't accept it. The other two are indeterminate conditions. Any debates regarding this strong hard FAIL SPF policy is not related to the technical merits but one that begins to question the DOMAIN decision to use it. Thats is an entirely different concept. We often hear people say the domain doesn't know what its doing. That is was a poor or a mistake that a domain has a -ALL SPF policy. Well, I take the position giving domains the benefit of the doubt, one that included an explicit series of steps to add a -ALL to the SPF record. I agree there are times where you may need to whitelist a hard SPF policy because it took a path where the domain::ip assertion fails. But these are known transactions, they are not anonymous. This is the part of the protocol awareness of knowing the difference. Its not an reason to ignore the hard policy and accept all mail anyway. So I view this white listing is part the SPF protocol local policy option to TEST for SPF result, record and accept the mail only, but it is an EXCEPTION, not the NORM to do this. Look at this way, if SPF had this framework where you are just TEST/RECORD/ACCEPT the payload anyway, I sincerely doubt it would have been successful or even get the huge and super fast industry wide endorsement it did. I know I and many others would not had wasted our time when at the time the #1 problem was the huge ACCEPT/BOUNCE dilemma that the 2003 SORBIG eVirus highlighted to the world. That is what give a SPF a spark and got MARID started. There was no dominant position that was saying "Oh, lets test, record and accept the mail anyway." No. We were looking at many LMAP ideas and SPF was one of them for a new standard transport level based technology for immediate online SMTP level rejection. All the other payload stuff were interesting but it was very different and we need to remember that with SPF. The opponents of SPF has longed question the idea of an hard deterministic rejection protocol and also Receivers that were 100% ok with the idea of honoring them. I prefer not to get into this debate of questioning DOMAIN decision to use hard deterministic policies or receivers that choose to honor it by simply following the SPF protocol immediate reject semantics. Yet, there is no hard rule that says a local policy can do a Test/Record/Accept setup. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From msk@cloudmark.com Wed Dec 28 20:19:00 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38BF21F8514 for ; Wed, 28 Dec 2011 20:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.847 X-Spam-Level: X-Spam-Status: No, score=-101.847 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNkZ4OudDEla for ; Wed, 28 Dec 2011 20:19:00 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2113F21F8513 for ; Wed, 28 Dec 2011 20:19:00 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 28 Dec 2011 20:18:51 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 28 Dec 2011 20:18:55 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Wed, 28 Dec 2011 20:19:02 -0800 Thread-Topic: [spfbis] Suggestion for an additional deliverable Thread-Index: AczD/icoV2uyiTtNRqyq1aQ3cD8U2gB4pVhg Message-ID: References: <6.2.5.6.2.20111223125517.09160578@resistor.net> <08a8505d-3901-4ad4-b584-63c68086ecc0@email.android.com> <4EF5D5F7.6050507@tana.it> <4EF8C017.8070809@tana.it> In-Reply-To: <4EF8C017.8070809@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 04:19:00 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Alessandro Vesely > Sent: Monday, December 26, 2011 10:43 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] Suggestion for an additional deliverable >=20 > It is also a question of modularity. The mail filter that sets > Authentication Results needs to access the whole body of a message, and > that might be the first time it gets called. Why's that? An Authentication-Results field could be added to a message as= soon as SPF completes evaluation, and it doesn't require a full body downl= oad. > For example, I get these: >=20 > Return-Path: > Authentication-Results: wmail.tana.it; > spf=3Dpass smtp.mailfrom=3Dietf.org; > dkim=3Dpass header.i=3D@ietf.org There's no requirement that they be combined. At my site I run sid-milter = and opendkim, and they attach those independently. > > "If you're implementing RFC5451, you really should go read RFC4408bis > as well". >=20 > Isn't it a pain in the neck to have to learn the whole SPF spec for > someone who just wishes to implement, say, the auth method for his MSA? I was just explaining what the "Updates" would mean. We could leave it off= if that's how it might be interpreted. From msk@cloudmark.com Wed Dec 28 20:20:05 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC52921F851F for ; Wed, 28 Dec 2011 20:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD4sWk82oYXq for ; Wed, 28 Dec 2011 20:20:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5AD21F8514 for ; Wed, 28 Dec 2011 20:20:05 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 28 Dec 2011 20:20:01 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 28 Dec 2011 20:20:05 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Wed, 28 Dec 2011 20:20:11 -0800 Thread-Topic: [spfbis] Suggestion for an additional deliverable Thread-Index: AczFAst/2tiJyRWXRg+rfbC2DOccjwA3kUwA Message-ID: References: <4EF54997.9090708@isdg.net> <4EF56050.7090800@isdg.net> <4EF8F336.8080508@gathman.org> In-Reply-To: <4EF8F336.8080508@gathman.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 04:20:05 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Stuart Gathman > Sent: Monday, December 26, 2011 2:21 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Suggestion for an additional deliverable >=20 > P.S. Should 4408bis address when/if to send DSNs based on SPF results? Sure, if the community has operational experience in that area that warrant= s making some statements about it. From spf2@kitterman.com Wed Dec 28 20:51:08 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1881F21F84F8 for ; Wed, 28 Dec 2011 20:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9xdsxB1aQJc for ; Wed, 28 Dec 2011 20:51:07 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 71CFE21F84CC for ; Wed, 28 Dec 2011 20:51:07 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 694E520E4128; Wed, 28 Dec 2011 23:51:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325134265; bh=7K0ZXpWNVE5Iz+sjKUkCPWdgKCL04t5YEw3tjhzk22s=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=TPDlP7VA1hkwM7hAze1d+umDc5CNYt/H2CkdUOjEpP4Fr/m6Dk/DTwfLYPJlH2RwR nBFrHaMhcMER2Wh9Wxz6ADmLDsSuOmd6Pb3hBQCEFE7NTE1n0NbdTc3IGh/ja2w1tj XypkdeN6FOFvvX2olxEHausI3FQrd8ZS0Qax/CBA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4FBC420E4081; Wed, 28 Dec 2011 23:51:05 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 28 Dec 2011 23:51:04 -0500 Message-ID: <1590867.1quv5UxKKV@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <4EF8F336.8080508@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 04:51:08 -0000 On Wednesday, December 28, 2011 08:20:11 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Stuart Gathman Sent: Monday, December 26, 2011 2:21 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Suggestion for an additional deliverable > > > > P.S. Should 4408bis address when/if to send DSNs based on SPF results? > > Sure, if the community has operational experience in that area that warrants > making some statements about it. I think it's something for a BCP that might be part of follow on work after 4408bis. Scott K From vesely@tana.it Thu Dec 29 05:03:34 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7821F8591 for ; Thu, 29 Dec 2011 05:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.016 X-Spam-Level: X-Spam-Status: No, score=-4.016 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mr3GctCVw4Ci for ; Thu, 29 Dec 2011 05:03:33 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A6B5121F8573 for ; Thu, 29 Dec 2011 05:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325163808; bh=/t0xKdurwUmjqlY4Q5tLQMDkvbZKTqyiFIUBuoirHlk=; l=1049; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=P+mQR/LaUPU/xz3kacdOrsXkxWDXnXeIwDVOBM+IF9bUznjI5Zl9T7ACn/y9GxLsu 6LbdQSOnNLdVP/cHU9EaoUe6cpppUiljaKJCWpgM9d2AXGmUDejHvMQf8IcVL8/+3G IsJrEqyU9rwu1zkY57dWDzRJaHUuIE+LBGMcxYZ0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 29 Dec 2011 14:03:28 +0100 id 00000000005DC03F.000000004EFC6520.00000202 Message-ID: <4EFC6520.1000409@tana.it> Date: Thu, 29 Dec 2011 14:03:28 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20111223125517.09160578@resistor.net> <08a8505d-3901-4ad4-b584-63c68086ecc0@email.android.com> <4EF5D5F7.6050507@tana.it> <4EF8C017.8070809@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] A-R vs SPF-R, was Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 13:03:34 -0000 On 29/Dec/11 05:19, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> It is also a question of modularity. The mail filter that sets >> Authentication Results needs to access the whole body of a message, and >> that might be the first time it gets called. > > Why's that? An Authentication-Results field could be added to a > message as soon as SPF completes evaluation, and it doesn't require > a full body download. Courier-MTA checks SPF natively /and/ calls filters after full body download. So its users cannot have reject-on-fail /and/ filter-handled SPF at the same time. >> For example, I get these: >> >> Return-Path: >> Authentication-Results: wmail.tana.it; >> spf=pass smtp.mailfrom=ietf.org; >> dkim=pass header.i=@ietf.org > > There's no requirement that they be combined. Correct. Assuming that next release of Courier-MTA offers a choice, the only advantage of combining them will consist in specifying the "authserv-id" in just one config file. From dotis@mail-abuse.org Thu Dec 29 10:59:23 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB5921F8B62 for ; Thu, 29 Dec 2011 10:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVfy7UQPkTUn for ; Thu, 29 Dec 2011 10:59:23 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8553421F8B61 for ; Thu, 29 Dec 2011 10:59:23 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 37DE71740354 for ; Thu, 29 Dec 2011 18:59:23 +0000 (UTC) Message-ID: <4EFCB88A.1080104@mail-abuse.org> Date: Thu, 29 Dec 2011 10:59:22 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <1590867.1quv5UxKKV@scott-latitude-e6320> In-Reply-To: <1590867.1quv5UxKKV@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:59:24 -0000 On 12/28/11 8:51 PM, Scott Kitterman wrote: > On Wednesday, December 28, 2011 08:20:11 PM Murray S. Kucherawy wrote: >>> -----Original Message----- >>> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf >>> Of Stuart Gathman Sent: Monday, December 26, 2011 2:21 PM >>> To: spfbis@ietf.org >>> Subject: Re: [spfbis] Suggestion for an additional deliverable >>> >>> P.S. Should 4408bis address when/if to send DSNs based on SPF results? >> Sure, if the community has operational experience in that area that warrants >> making some statements about it. > I think it's something for a BCP that might be part of follow on work after > 4408bis. Is there any interest in assuring use of mx mechanism will work properly with domains publishing more than 5 MX records? Many current SPF libraries process a maximum of 5 rather than the specified 10 to circumvent a possible 100 DNS transactional sequence. The impact is this may cause intermittent failures difficult to troubleshoot. What makes this contentious is possible macro expansion of local-parts against cached SPF records. -Doug From hsantos@isdg.net Fri Dec 30 18:11:31 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4AB21F8505 for ; Fri, 30 Dec 2011 18:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw38RBaAQ79V for ; Fri, 30 Dec 2011 18:11:26 -0800 (PST) Received: from mail.catinthebox.net (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A0C6321F8507 for ; Fri, 30 Dec 2011 18:11:26 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1011; t=1325297475; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=CA86goXr4/9Mv0ztdN2MTkBbgE8=; b=VdCKp9hMz78lHXOJL4m6 3hLKXjw66rB0O8KzkaJpP+N5ZHiHMOoeBcDi9NeUjBUTHZMolgTNck5fcqA/TfNl tYmu8PxFHbiM9JXq01FNMDkd/QsHC/+Q7+cq2J0PSn9FdRiB995budWFkjYthVPz VYLJSYgBtQE9grj1I1Jc78Q= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 30 Dec 2011 21:11:15 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2794339456.25885.2908; Fri, 30 Dec 2011 21:11:14 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1011; t=1325297318; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=HjujABt GPFv928t2NOGh6k9RF6MkAbuiG5vzY1m+sJI=; b=s76cg3vV6QE4ahFULtjtNBE S9yNQjH6mqYDxm+nkRYO++10lmkdbuV+KOw5axiWP2uZilu/tdi3rb0pAYJ7GHG1 wdyQnVipnJ5oxRU3SIa5bcD+/rEs4v5eXtPVTBEA2sh0I5rzZS3bKGVZfhE9KONh vzC+2LFQJUR/Xzdjd5C8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 30 Dec 2011 21:08:38 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3393308297.2944.6308; Fri, 30 Dec 2011 21:08:37 -0500 Message-ID: <4EFE6F39.90000@isdg.net> Date: Fri, 30 Dec 2011 21:11:05 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <1590867.1quv5UxKKV@scott-latitude-e6320> <4EFCB88A.1080104@mail-abuse.org> In-Reply-To: <4EFCB88A.1080104@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Dec 2011 02:11:31 -0000 Douglas Otis wrote: > Is there any interest in assuring use of mx mechanism will work properly > with domains publishing more than 5 MX records? Can you illustrate the MX concern and whether there is an SPF problem here? > Many current SPF > libraries process a maximum of 5 rather than the specified 10 to > circumvent a possible 100 DNS transactional sequence. The impact is > this may cause intermittent failures difficult to troubleshoot. What > makes this contentious is possible macro expansion of local-parts > against cached SPF records. Doug, its been what? nearly 9, 10 years? I have yet to see a situation that was not managed with the SPF implementation, especially with recursive parts where limits are placed. I have yet to see or hear of any exploit that circumvents SPF implementations. Its all theoretical with the presumption the implementation is not aware of aggressive abuse. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Fri Dec 30 18:21:18 2011 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C5F21F8513 for ; Fri, 30 Dec 2011 18:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBVo2HwvJs-e for ; Fri, 30 Dec 2011 18:21:17 -0800 (PST) Received: from mail.catinthebox.net (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AF85C21F8507 for ; Fri, 30 Dec 2011 18:21:17 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1269; t=1325298074; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=AQ5oVNJuCyLTIWVw7UNhLprehWM=; b=jxcjd86tqcLwQ/2dHcfS GmDYtKR0rKtxxJ/nlWlQHSW1n8bXKy+LZc3mnmMZke4KbJ+WyFRnA+qREkrq6r8J eHfsfvLrQWefWomvO6CvqHT8VaX3HFvTkPDDoP3cgYYELZPqv6dK3uNeVrp1BtER 679XFyi6qyov5Muog28ij5k= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 30 Dec 2011 21:21:14 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2794939451.25885.3164; Fri, 30 Dec 2011 21:21:14 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1269; t=1325297918; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2skhPB4 CkvyJA0yiR4tm6GTrghBvH3dMRvFt7OJj3QQ=; b=f/8a7xa9LHOJp46IbfcEepL Glth85T8XQlMymNex2pvkfgl3eLj23ORmdBMu0HFD7kJO1flX2qjXpO3in5zgrQR ggPiHx15RzerE5ztYmnjTW49cvwGZIwjlN2iDodMzrOQmDKMouwscV8SaJVONTqT UbJmQ9lnl4Wjr1ztMmBM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 30 Dec 2011 21:18:38 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3393907782.2946.1980; Fri, 30 Dec 2011 21:18:37 -0500 Message-ID: <4EFE7191.6070404@isdg.net> Date: Fri, 30 Dec 2011 21:21:05 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <1590867.1quv5UxKKV@scott-latitude-e6320> In-Reply-To: <1590867.1quv5UxKKV@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Dec 2011 02:21:18 -0000 Scott Kitterman wrote: > On Wednesday, December 28, 2011 08:20:11 PM Murray S. Kucherawy wrote: >>> -----Original Message----- >>> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf >>> Of Stuart Gathman Sent: Monday, December 26, 2011 2:21 PM >>> To: spfbis@ietf.org >>> Subject: Re: [spfbis] Suggestion for an additional deliverable >>> >>> P.S. Should 4408bis address when/if to send DSNs based on SPF results? >> Sure, if the community has operational experience in that area that warrants >> making some statements about it. > > I think it's something for a BCP that might be part of follow on work after > 4408bis. In terms of SPF, a "BCP" is to reject HARD failures and/or mark them, record and save if you wish, but overall it is hurting users if a HARD failure was passed to them or begin to think about sending SPF determined rejection as BOUNCES - thats goes against its whole purpose in email life. If we begin to argue that fundamental point, then SPF is under attack for a framework and mindset change in this small and isolated group with leaders that are 100% against SPF and that concerns me. PS: Happy New Years :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com