From owner-ietf-mxcomp@mail.imc.org Sat Aug 13 00:57:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3o5b-0004UY-W4 for marid-archive@megatron.ietf.org; Sat, 13 Aug 2005 00:57:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20346 for ; Sat, 13 Aug 2005 00:57:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7D49CY8074301; Fri, 12 Aug 2005 21:09:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7D49CVA074300; Fri, 12 Aug 2005 21:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7D499Z6074286 for ; Fri, 12 Aug 2005 21:09:11 -0700 (PDT) (envelope-from matthew@elvey.com) Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 85E91CC98AB for ; Sat, 13 Aug 2005 00:09:08 -0400 (EDT) X-Sasl-enc: C+mkT62DGtBzaJpVhONzmcaeUsH0rIqIXxX6p6ckt/FJ 1123906148 Received: from [192.168.1.213] (banana.groupd.com [64.139.6.95]) by frontend3.messagingengine.com (Postfix) with ESMTP id 2C5361E1; Sat, 13 Aug 2005 00:09:07 -0400 (EDT) Message-ID: <42FD725E.1050802@elvey.com> Date: Fri, 12 Aug 2005 21:09:02 -0700 From: Matthew Elvey User-Agent: Thunderbird 1.0+ (Macintosh/20050811) MIME-Version: 1.0 To: MXCOMP Subject: Research question: How many legitimate mail sources are out there? X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Would someone out there please take a stab at answering this question? Or has it been answered already? What to I mean by a 'mail source'? Well, in technical terms I'm thinking someone could say something like: "Here's info from a large ISP (handling mail for x million customers). Over a period of ____ it accepted mail from x IP addresses that it thinks were sending it mostly ham" I'd be even happier with something like this: it accepted mail from x TLD Names in the HELO. I could live with something like: my greylisting server whitelisted x IP addresses (I'm figure John Levine could give us this number quite quickly for his a "several hundred individual mailboxes, a few dozen mailing lists, and the abuse.net message forwarding system.") Of course, sometimes several servers send through one IP, or one server sends through several IPs... I'm guessing that there are under a million such mail sources. There are around .1 billion TLD Names*. This is apropos this thread: SPF Loses Mindshare at http://www.circleid.com/article.php?id=1157_0_1_0_C/ *http://www.registrarstats.com/zonefile_enlarged.asp (Could be a few times more more, as this doesn't list ccTLDs...) From owner-ietf-mxcomp@mail.imc.org Sat Aug 13 11:05:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3xZe-0007So-9o for marid-archive@megatron.ietf.org; Sat, 13 Aug 2005 11:05:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25801 for ; Sat, 13 Aug 2005 11:05:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7DEdC6O082343; Sat, 13 Aug 2005 07:39:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7DEdCkQ082342; Sat, 13 Aug 2005 07:39:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7DEdAo7082334 for ; Sat, 13 Aug 2005 07:39:11 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 8149B16FAB for ; Sat, 13 Aug 2005 10:40:01 -0400 (EDT) From: "Alan DeKok" To: MXCOMP Subject: Re: Research question: How many legitimate mail sources are out there? In-Reply-To: Your message of "Fri, 12 Aug 2005 21:09:02 PDT." <42FD725E.1050802@elvey.com> Date: Sat, 13 Aug 2005 10:40:01 -0400 Message-Id: <20050813144001.8149B16FAB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Matthew Elvey wrote: > Would someone out there please take a stab at answering this question? > Or has it been answered already? Yes. http://www.striker.ottawa.on.ca/~aland/spam/ The data covers a significant portion of the Internet. > I'm guessing that there are under a million such mail sources. There > are around .1 billion TLD Names*. Close. As of a year ago, about 300k IP's. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Aug 13 20:41:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E46Ys-0007PN-2y for marid-archive@megatron.ietf.org; Sat, 13 Aug 2005 20:41:14 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19878 for ; Sat, 13 Aug 2005 20:41:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E0I35X066722; Sat, 13 Aug 2005 17:18:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7E0I3IM066721; Sat, 13 Aug 2005 17:18:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E0Hxrc066704 for ; Sat, 13 Aug 2005 17:18:00 -0700 (PDT) (envelope-from dean@av8.com) Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j7E0Hwon028179 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 13 Aug 2005 20:17:59 -0400 Date: Sat, 13 Aug 2005 20:17:56 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Alan DeKok cc: MXCOMP Subject: Re: Research question: How many legitimate mail sources are out there? In-Reply-To: <20050813144001.8149B16FAB@mail.nitros9.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 13 Aug 2005, Alan DeKok wrote: > > Matthew Elvey wrote: > > Would someone out there please take a stab at answering this question? > > Or has it been answered already? > > Yes. http://www.striker.ottawa.on.ca/~aland/spam/ > > The data covers a significant portion of the Internet. > > > I'm guessing that there are under a million such mail sources. There > > are around .1 billion TLD Names*. > > Close. As of a year ago, about 300k IP's. Really? 300K "legitimate mail sources"? Worldwide? "legitimate mail sources": That would include corporate mail servers, right? Gee, I think there are more than that in the United States. Probably more than that in Canada, too. Maybe you want to rethink that a bit. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Sat Aug 13 21:12:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E472n-0003Jr-8a for marid-archive@megatron.ietf.org; Sat, 13 Aug 2005 21:12:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20571 for ; Sat, 13 Aug 2005 21:12:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E0f65w068505; Sat, 13 Aug 2005 17:41:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7E0f5ZE068504; Sat, 13 Aug 2005 17:41:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7E0f3SR068493 for ; Sat, 13 Aug 2005 17:41:04 -0700 (PDT) (envelope-from prvs=johnl/0009fd36e7@iecc.com) Received: (qmail 18806 invoked by uid 100); 14 Aug 2005 00:41:02 -0000 Date: 14 Aug 2005 00:41:02 -0000 Message-ID: <20050814004102.18805.qmail@xuxa.iecc.com> From: John Levine Subject: Re: Research question: How many legitimate mail sources are out there? In-Reply-To: <42FD725E.1050802@elvey.com> Organization: I.E.C.C., Trumansburg NY USA To: matthew@elvey.com cc: ietf-mxcomp@imc.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >I could live with something like: my greylisting server whitelisted x >IP addresses (I'm figure John Levine could give us this number quite >quickly for his a "several hundred individual mailboxes, a few dozen >mailing lists, and the abuse.net message forwarding system.") It's about 22,000 addresses. My fixed greylist covers about 3000 more addresses in CIDR blocks, of which probably no more than a few hundred send mail. I have no idea how this relates to the pattern a larger ISP would see. R's, John From owner-ietf-mxcomp@mail.imc.org Sat Aug 13 21:23:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E47E9-0004cI-Gz for marid-archive@megatron.ietf.org; Sat, 13 Aug 2005 21:23:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20805 for ; Sat, 13 Aug 2005 21:23:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E127Tt070034; Sat, 13 Aug 2005 18:02:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7E127IS070033; Sat, 13 Aug 2005 18:02:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E125Mx070025 for ; Sat, 13 Aug 2005 18:02:06 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B8CA916FAB for ; Sat, 13 Aug 2005 21:02:57 -0400 (EDT) From: "Alan DeKok" To: MXCOMP Subject: Re: Research question: How many legitimate mail sources are out there? In-Reply-To: Your message of "Sat, 13 Aug 2005 20:17:56 EDT." Date: Sat, 13 Aug 2005 21:02:57 -0400 Message-Id: <20050814010257.B8CA916FAB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > Really? Yes. Sincerely, Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Aug 23 15:24:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7eNo-0006TA-Pg for marid-archive@megatron.ietf.org; Tue, 23 Aug 2005 15:24:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25654 for ; Tue, 23 Aug 2005 15:24:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NIpB1v057601; Tue, 23 Aug 2005 11:51:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NIpBV4057600; Tue, 23 Aug 2005 11:51:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NIp9UY057575 for ; Tue, 23 Aug 2005 11:51:10 -0700 (PDT) (envelope-from matthew@elvey.com) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0A7A9CCA308; Tue, 23 Aug 2005 14:51:08 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Tue, 23 Aug 2005 14:51:08 -0400 X-Sasl-enc: VirqdfNhj8+FmsE0OLvwcUK2EfChcvIFwgtonT6xOSIc 1124823067 Received: from [192.168.2.98] (adsl-67-112-27-89.dsl.snfc21.pacbell.net [67.112.27.89]) by frontend3.messagingengine.com (Postfix) with ESMTP id C6D5F1E1; Tue, 23 Aug 2005 14:51:06 -0400 (EDT) Message-ID: <430B7020.2090003@elvey.com> Date: Tue, 23 Aug 2005 11:51:12 -0700 From: Matthew Elvey Reply-To: MXCOMP User-Agent: Thunderbird 1.0+ (Macintosh/20050811) MIME-Version: 1.0 To: MXCOMP , moz-sent@elvey.sent.com, spf-discuss@v2.listbox.com Subject: FUD in Meng's "What To Do" X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 12345678901234567890123456789012345678901234567890123456789012345678901234567890 While DKIM is clearly gaining momentum, a lightweight (LMAP) solution (lightweight in terms of bandwidth, DNS, CPU, user and administrator load) is needed as well, such as CSV or SPF3. DKIM is not lightweight in terms of bandwidth, DNS, CPU or administrator load. SPF is not lightweight in terms of DNS, user or administrator load. Meng writes in whitepaper.pdf: > Spread FUD about the edge cases. > None of the approaches are perfect. A message could be for- > warded through a site that does not perform srs and does > not prepend Resent headers; that message could then pass > through an mta that munges the content for perfectly good > reasons. This corner case is a favourite of technical perfec- > tionists who use it to argue that one can never reliably reject > a message based on sender authentication. I've never seen anyone make this case. It appears that this is spreading misinformation. The case I've seen made is that while this flaw (and others) exist in SPF's flavor of sender authentication, it does not apply to some other authentication systems that fit in an Aspen framework. I also felt misled after seeing 'CSV' in big letters on the cover, but found no mention of it in the body of the paper. I've set reply-to to MXCOMP to try and direct discussion there. From owner-ietf-mxcomp@mail.imc.org Thu Aug 25 13:59:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8M12-0004nk-Up for marid-archive@megatron.ietf.org; Thu, 25 Aug 2005 13:59:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04267 for ; Thu, 25 Aug 2005 13:59:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PHR2Mi034855; Thu, 25 Aug 2005 10:27:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PHR2Vg034854; Thu, 25 Aug 2005 10:27:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PHR0tq034845 for ; Thu, 25 Aug 2005 10:27:01 -0700 (PDT) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A3A9232008F; Thu, 25 Aug 2005 19:26:45 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15941-03; Thu, 25 Aug 2005 19:26:41 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69A8632008A; Thu, 25 Aug 2005 19:26:38 +0200 (CEST) Date: Thu, 25 Aug 2005 10:14:39 -0700 From: Harald Tveit Alvestrand To: Julian Mehnle , Brian Carpenter Cc: Ted Hardie , ietf@ietf.org, SPF Council , MARID , SPF Discussion , iesg@ietf.org Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Message-ID: X-Mailer: Mulberry/4.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian, not speaking for anyone but myself..... one matter of principle: are you of the opinion that the IESG should try to police which experiments get run on the Internet by refusing to publish RFCs documenting possibly-conflicting experments? Both of these documents were published at the request of their authors. I know that ways in which they could cause conflict were pointed out to the authors, and that both authors upheld their requests to publish. If you ask the IESG to assert the power to police this kind of experiment, please make sure you will be happy with the result if they agree with you..... Harald --On 25. august 2005 00:45 +0200 Julian Mehnle wrote: > I believe that draft-lyon-senderid-core-01 conflicts in a significant > aspect with draft-schlitt-spf-classic-02, on which the former depends, and > which has also been approved by the IESG to be published as an > Experimental RFC.[2] The conflicting part of the Sender-ID specification > disrespects the substantial history the SPF specification has outside the > IETF. Through its decision, the IESG also ignores SPF's deployed base.[3] > And even if the IESG intends to run both of the specifications as an > experiment before deciding any further on how to proceed with them, the > publication of conflicting specifications is bound to disrupt these > experiments. From owner-ietf-mxcomp@mail.imc.org Thu Aug 25 14:32:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8MWm-0007sV-9f for marid-archive@megatron.ietf.org; Thu, 25 Aug 2005 14:32:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06153 for ; Thu, 25 Aug 2005 14:32:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PI8t8I038508; Thu, 25 Aug 2005 11:08:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PI8tS8038507; Thu, 25 Aug 2005 11:08:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PI8slF038500 for ; Thu, 25 Aug 2005 11:08:54 -0700 (PDT) (envelope-from sommerfeld@sun.com) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7PI8fHT008255; Thu, 25 Aug 2005 11:08:41 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7PI8fWB028508; Thu, 25 Aug 2005 14:08:41 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7PI8eBL014646; Thu, 25 Aug 2005 14:08:40 -0400 (EDT) Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 From: Bill Sommerfeld To: Harald Tveit Alvestrand Cc: Julian Mehnle , Brian Carpenter , Ted Hardie , iesg@ietf.org, SPF Council , MARID , SPF Discussion , ietf@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1124993318.13993.123.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Thu, 25 Aug 2005 14:08:39 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2005-08-25 at 13:14, Harald Tveit Alvestrand wrote: > are you of the opinion that the IESG should try to police which experiments > get run on the Internet by refusing to publish RFCs documenting > possibly-conflicting experments? It depends on the form of the conflict. I believe that the IESG has the duty to ensure that concurrent experiments either use experimental codepoints in non-conflicting ways, or else require them to use distinct codepoints; to fail to do this creates the risk that any experimental results will be muddled/contaminated. In this case, the two experiments interpret the same codepoints in the DNS in subtly different ways. A mail-sending domain indicates that it is participating by publishing certain DNS RR's. Crucially, a mail-sending domain cannot opt in to the SPF experiment without also opting in to the senderid experiment. This renders any claimed results of either experiment suspect. - Bill From owner-ietf-mxcomp@mail.imc.org Thu Aug 25 15:03:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8N0Z-0000py-2p for marid-archive@megatron.ietf.org; Thu, 25 Aug 2005 15:03:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07952 for ; Thu, 25 Aug 2005 15:03:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PIZuRk040775; Thu, 25 Aug 2005 11:35:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PIZudL040774; Thu, 25 Aug 2005 11:35:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PIZtFK040766 for ; Thu, 25 Aug 2005 11:35:55 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LS8SE0RVVK005NVF@mauve.mrochek.com> (original mail from ned.freed@mrochek.com) for ietf-mxcomp@imc.org; Thu, 25 Aug 2005 11:35:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1124994950; h=Received: Cc:To:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References; b=bFwQP5PyXUxu8qi4TA/fuitrIBliTpHX/5UfJtVM g5A776bnF8HCH5NMRzlhFw0+COJW6C5trZvbNBQOPZCCDQ== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LS8RO9TFXC000092@mauve.mrochek.com>; Thu, 25 Aug 2005 11:35:13 -0700 (PDT) Cc: Harald Tveit Alvestrand , Ted Hardie , SPF Council , iesg@ietf.org, MARID , SPF Discussion , ietf@ietf.org To: Bill Sommerfeld Message-id: <01LS8SDHSDVC000092@mauve.mrochek.com> Date: Thu, 25 Aug 2005 11:26:07 -0700 (PDT) From: Ned Freed Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 In-reply-to: "Your message dated Thu, 25 Aug 2005 14:08:39 -0400" <1124993318.13993.123.camel@thunk> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <1124993318.13993.123.camel@thunk> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Thu, 2005-08-25 at 13:14, Harald Tveit Alvestrand wrote: > > are you of the opinion that the IESG should try to police which experiments > > get run on the Internet by refusing to publish RFCs documenting > > possibly-conflicting experments? > It depends on the form of the conflict. > I believe that the IESG has the duty to ensure that concurrent > experiments either use experimental codepoints in non-conflicting ways, > or else require them to use distinct codepoints; to fail to do this > creates the risk that any experimental results will be > muddled/contaminated. Bingo. There is, after all, an "experiment" in "experimental". A conflict that stands a good chance of making it imposisble to get useful results from the experiment is something that clearly needs to be resolved prior to publication. There's even some support for this in RFC 2026. Section 4.2.1 talks about experimental publication being subject to "verification that there has been adequate coordination with the standards process". Now, this is phrased in terms of conflicts with standards, not conflicts between experiments, likely because the case of conflicting experiments was never envisioned. > In this case, the two experiments interpret the same codepoints in the > DNS in subtly different ways. > A mail-sending domain indicates that it is participating by publishing > certain DNS RR's. > Crucially, a mail-sending domain cannot opt in to the SPF experiment > without also opting in to the senderid experiment. This renders any > claimed results of either experiment suspect. RIght again. In any case, I support this appeal to the extent that I believe the conflicts need to be resolved prior to publication. I take no position on the means by which the conflict is resolved as long as a resolution is reached. Ned From owner-ietf-mxcomp@mail.imc.org Thu Aug 25 15:31:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8NRI-000181-R0 for marid-archive@megatron.ietf.org; Thu, 25 Aug 2005 15:31:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10457 for ; Thu, 25 Aug 2005 15:31:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJ9DqN044406; Thu, 25 Aug 2005 12:09:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJ9Dek044405; Thu, 25 Aug 2005 12:09:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJ9DQP044399 for ; Thu, 25 Aug 2005 12:09:13 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from [192.168.0.2] (adsl-64-175-240-92.dsl.sntc01.pacbell.net [64.175.240.92]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7PJ9XLJ020255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2005 12:09:33 -0700 Message-ID: <430E173E.1010000@dcrocker.net> Date: Thu, 25 Aug 2005 12:08:46 -0700 From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf@ietf.org CC: Ted Hardie , SPF Council , iesg@ietf.org, MARID , SPF Discussion Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 References: <1124993318.13993.123.camel@thunk> <01LS8SDHSDVC000092@mauve.mrochek.com> In-Reply-To: <01LS8SDHSDVC000092@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > In any case, I support this appeal to the extent that I believe the conflicts > need to be resolved prior to publication. I take no position on the means > by which the conflict is resolved as long as a resolution is reached. All of this raises the obvious question of the purpose in having the IESG "approve" Experimental status. If the approval does not pertain to basic technical issues, such as known conflicts with other specifications, it is difficult to imagine any benefit in the approval process. On the other hand, the fact of IESG "approval" for these two specifications has been richly touted as progress on the standards track. Given how sensitive the IETF community is about misrepresentation of its actions and labels, we should make sure that the value-add of those actions is clear and real. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net From owner-ietf-mxcomp@mail.imc.org Thu Aug 25 15:31:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8NRO-0001AE-Sd for marid-archive@megatron.ietf.org; Thu, 25 Aug 2005 15:31:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10465 for ; Thu, 25 Aug 2005 15:31:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJ6YNF044195; Thu, 25 Aug 2005 12:06:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJ6YdZ044191; Thu, 25 Aug 2005 12:06:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJ6WFl044176 for ; Thu, 25 Aug 2005 12:06:32 -0700 (PDT) (envelope-from sommerfeld@sun.com) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7PJ6MTW001015; Thu, 25 Aug 2005 13:06:23 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7PJ6LUj024693; Thu, 25 Aug 2005 15:06:21 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7PJ6Lqj014982; Thu, 25 Aug 2005 15:06:21 -0400 (EDT) Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 From: Bill Sommerfeld To: ned.freed@sun.com Cc: Harald Tveit Alvestrand , Ted Hardie , SPF Council , iesg@ietf.org, MARID , SPF Discussion , ietf@ietf.org In-Reply-To: <01LS8SDHSDVC000092@mauve.mrochek.com> References: <1124993318.13993.123.camel@thunk> <01LS8SDHSDVC000092@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1124996780.13993.179.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Thu, 25 Aug 2005 15:06:21 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2005-08-25 at 14:26, ned.freed@sun.com wrote: > In any case, I support this appeal to the extent that I believe the conflicts > need to be resolved prior to publication. I take no position on the means > by which the conflict is resolved as long as a resolution is reached. And I wholeheartedly agree with this. From owner-ietf-mxcomp@mail.imc.org Thu Aug 25 15:50:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Nju-0007TU-7R for marid-archive@megatron.ietf.org; Thu, 25 Aug 2005 15:50:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11368 for ; Thu, 25 Aug 2005 15:50:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJPXbU045732; Thu, 25 Aug 2005 12:25:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJPWf6045731; Thu, 25 Aug 2005 12:25:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJPV8l045725 for ; Thu, 25 Aug 2005 12:25:32 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 0DADC26C074; Thu, 25 Aug 2005 21:25:31 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id ACC6B26C06D; Thu, 25 Aug 2005 21:25:29 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j7PJPTYa801691; Thu, 25 Aug 2005 21:25:29 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 1ECF416AA81; Thu, 25 Aug 2005 21:25:29 +0200 (CEST) Date: Thu, 25 Aug 2005 21:25:29 +0200 From: Stephane Bortzmeyer To: Harald Tveit Alvestrand Cc: Julian Mehnle , Brian Carpenter , Ted Hardie , iesg@ietf.org, SPF Council , MARID , SPF Discussion , ietf@ietf.org Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Message-ID: <20050825192529.GA29872@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 25, 2005 at 10:14:39AM -0700, Harald Tveit Alvestrand wrote a message of 41 lines which said: > are you of the opinion that the IESG should try to police which > experiments get run on the Internet by refusing to publish RFCs > documenting possibly-conflicting experments? If the IESG were to refuse to publish the Sender-ID document as it is, it would not "police" everything: anyone can still do what he wants on the Internet. The only thing than the IETF can do is to "bless" or not the document, saying in essence "it is interesting and worth more experimentation". Not blessing it does not mean actively using lethal force against those who still want to try it. So, cool down, nobody asked the IESG to police or to censor or to forbid, just to NOT bless a bad idea (reusing SPF records in an unattended way). From owner-ietf-mxcomp@mail.imc.org Thu Aug 25 16:21:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OES-00050m-Fi for marid-archive@megatron.ietf.org; Thu, 25 Aug 2005 16:21:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16586 for ; Thu, 25 Aug 2005 16:21:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJx6QH049603; Thu, 25 Aug 2005 12:59:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJx69X049602; Thu, 25 Aug 2005 12:59:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from thunker.thunk.org (thunk.org [69.25.196.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJx4AY049595 for ; Thu, 25 Aug 2005 12:59:05 -0700 (PDT) (envelope-from tytso@thunk.org) Received: from root (helo=think.thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1E8NsA-0005rP-00; Thu, 25 Aug 2005 15:58:50 -0400 Received: from tytso by think.thunk.org with local (Exim 4.52) id 1E8Ns8-0003dT-6t; Thu, 25 Aug 2005 15:58:48 -0400 Date: Thu, 25 Aug 2005 15:58:48 -0400 From: "Theodore Ts'o" To: Stephane Bortzmeyer Cc: Harald Tveit Alvestrand , Ted Hardie , SPF Council , iesg@ietf.org, MARID , SPF Discussion , ietf@ietf.org Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Message-ID: <20050825195848.GD13537@thunk.org> References: <20050825192529.GA29872@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050825192529.GA29872@nic.fr> User-Agent: Mutt/1.5.9i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 25, 2005 at 09:25:29PM +0200, Stephane Bortzmeyer wrote: > If the IESG were to refuse to publish the Sender-ID document as it is, > it would not "police" everything: anyone can still do what he wants on > the Internet. > > The only thing than the IETF can do is to "bless" or not the document, > saying in essence "it is interesting and worth more > experimentation". Not blessing it does not mean actively using lethal > force against those who still want to try it. > > So, cool down, nobody asked the IESG to police or to censor or to > forbid, just to NOT bless a bad idea (reusing SPF records in an > unattended way). I agree with this sentiment. It's not like the RFC series is the only place that protocol specifications for such experiments can be published, and with Google and the Wayback Archive, the search and persistence problems are solved as well. So we should only publish if we think we can add some kind of value beyond that which any yahoo who owns a web server can do with publishing some random specification on the web. Making sure that experiments don't collide with one another seems like a very basic starting point. This is especially important in this particular case given how contentious the debate over proposals in this problem space have been in the past. - Ted From owner-ietf-mxcomp@mail.imc.org Thu Aug 25 16:42:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OYN-0006BZ-I9 for marid-archive@megatron.ietf.org; Thu, 25 Aug 2005 16:42:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17792 for ; Thu, 25 Aug 2005 16:42:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKLMc7051397; Thu, 25 Aug 2005 13:21:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PKLMX5051396; Thu, 25 Aug 2005 13:21:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKLMpF051390 for ; Thu, 25 Aug 2005 13:21:22 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j7PKLAPs025397 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 25 Aug 2005 13:21:10 -0700 In-Reply-To: <01LS8SDHSDVC000092@mauve.mrochek.com> References: <1124993318.13993.123.camel@thunk> <01LS8SDHSDVC000092@mauve.mrochek.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4ADD46C3-4C14-47CD-91AA-D9C2E3BADC83@mail-abuse.org> Cc: iesg@ietf.org, MARID , ietf@ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Thu, 25 Aug 2005 13:21:09 -0700 To: Ned Freed X-Mailer: Apple Mail (2.734) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 25, 2005, at 11:26 AM, Ned Freed wrote: > > >> A mail-sending domain indicates that it is participating by >> publishing >> certain DNS RR's. >> Crucially, a mail-sending domain cannot opt in to the SPF experiment >> without also opting in to the senderid experiment. This renders any >> claimed results of either experiment suspect. >> > > RIght again. > > In any case, I support this appeal to the extent that I believe the > conflicts > need to be resolved prior to publication. I take no position on the > means > by which the conflict is resolved as long as a resolution is reached. As with any conflict, there are two parties involved. In this case, the SPF group has essentially ignored potential conflicts by neglecting to include support for a subsequent version of the DNS record. This newer record explicitly expresses the intended scope. At the MAAWG meeting in Dusseldorf, Julian suggested SPF developers would only consider use of the newer DNS record version provided Sender-ID abdicated use of the initial version of the record. Sender- ID supports both versions. An appeal was made for the SPF group to consider supporting the newer version of the record as a solution for avoiding this conflict. This suggested use of the record is part of interim advice on the MAAWG website. It would appear this appeal reflects a decisions to remain intransigent. http://www.maawg.org/about/whitepapers/spf_sendID/ A condition that Sender-ID abdicate the use of the scope-less version of the record is puzzling, as once the newer record is also adopted by SPF, the claimed conflict is resolved. Meng Wong, an author of both drafts, explained the conflict in his white paper by indicating the SPF draft was for historical purposes and suggested Sender-ID embraced both semantics. Sender-ID's use of the initial version of the DNS record will create problems should the publisher of the record intend the semantics to exclude Sender-ID. The methods suggested by the Sender-ID draft to circumvent their semantics could negatively impact the publisher. This conflict is not accidental or without a simple solution, but rather based upon a desire to withdraw Sender-ID semantics in a manor that negatively impacts the Sender-ID effort. I am _not_ a proponent of Sender-ID. While the merging of semantics was initially considered acceptable by the MARID WG, the desire to now exclude the Sender-ID semantics is primarily due to subsequent licensing notifications. At that time so long ago, the technical solution to allow the record publisher to formally indicate their desired semantics was to change the version of the record that provided the requisite scoping parameters. Rather than adopting this solution, the SPF group insists anyone that published the initial version of this record only intended to support SPF and not Sender-ID. This would be a difficult conclusion following any number of gatherings where email administrators have subsequently and repeatedly been provided information that indicated this initial record version supports both, and that the subsequent record versions can be used to isolate the scope of the record. While this conflict should be resolved, without evidence that Sender- ID has fallen out of favor, which the stance by the SPF group prohibits, the obvious solution would likely be for the SPF group to finally adopt the newer record version. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 09:17:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8e4x-00046E-KO for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 09:17:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18552 for ; Fri, 26 Aug 2005 09:17:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QClRfp075410; Fri, 26 Aug 2005 05:47:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QClRMa075409; Fri, 26 Aug 2005 05:47:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.hxr.us [216.93.167.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QClQ44075398 for ; Fri, 26 Aug 2005 05:47:26 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.4] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 26 Aug 2005 08:47:23 -0400 id 000B3ACD.430F0F5C.0000619D In-Reply-To: <1124993318.13993.123.camel@thunk> References: <1124993318.13993.123.camel@thunk> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> Cc: Brian Carpenter , Ted Hardie , iesg@ietf.org, MARID , ietf@ietf.org Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 08:47:17 -0400 To: Bill Sommerfeld X-Mailer: Apple Mail (2.733) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 25, 2005, at 2:08 PM, Bill Sommerfeld wrote: > In this case, the two experiments interpret the same codepoints in the > DNS in subtly different ways. > > A mail-sending domain indicates that it is participating by publishing > certain DNS RR's. > Crucially, a mail-sending domain cannot opt in to the SPF experiment > without also opting in to the senderid experiment. This renders any > claimed results of either experiment suspect. If this is the source of the conflict, then BOTH experiments should not use the v=spf1 records. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 09:43:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8eUA-00037s-NS for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 09:43:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19998 for ; Fri, 26 Aug 2005 09:43:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QDFGEV086088; Fri, 26 Aug 2005 06:15:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QDFGTV086087; Fri, 26 Aug 2005 06:15:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QDFFsK086077 for ; Fri, 26 Aug 2005 06:15:15 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 93CD626C08D; Fri, 26 Aug 2005 15:15:14 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 65D0926C076; Fri, 26 Aug 2005 15:15:13 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j7QDFDYa976626; Fri, 26 Aug 2005 15:15:13 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 42BB816A9C9; Fri, 26 Aug 2005 15:15:13 +0200 (CEST) Date: Fri, 26 Aug 2005 15:15:13 +0200 From: Stephane Bortzmeyer To: ietf@ietf.org, iesg@ietf.org, MARID Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 MARID Message-ID: <20050826131513.GA29797@nic.fr> References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 26, 2005 at 08:47:17AM -0400, Andrew Newton wrote a message of 21 lines which said: > If this is the source of the conflict, then BOTH experiments should > not use the v=spf1 records. It is an absolutely incredible request since SPF uses these records since its beginning (a long time before Sender-ID existed) and since there is (unlike SenderID) actual deployment, which can not be called back. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 10:18:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8f2E-0004eC-Pt for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 10:18:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22768 for ; Fri, 26 Aug 2005 10:18:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QDre1I001555; Fri, 26 Aug 2005 06:53:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QDrevb001554; Fri, 26 Aug 2005 06:53:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.hxr.us [216.93.167.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QDrekL001546 for ; Fri, 26 Aug 2005 06:53:40 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.4] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 26 Aug 2005 09:53:39 -0400 id 000B3AD8.430F1EE3.00006E03 In-Reply-To: <20050826131513.GA29797@nic.fr> References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <20050826131513.GA29797@nic.fr> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf@ietf.org, iesg@ietf.org, MARID Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 MARID Date: Fri, 26 Aug 2005 09:53:38 -0400 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.733) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2005, at 9:15 AM, Stephane Bortzmeyer wrote: > > On Fri, Aug 26, 2005 at 08:47:17AM -0400, > Andrew Newton wrote > a message of 21 lines which said: > > >> If this is the source of the conflict, then BOTH experiments should >> not use the v=spf1 records. >> > > It is an absolutely incredible request since SPF uses these records > since its beginning (a long time before Sender-ID existed) and since > there is (unlike SenderID) actual deployment, which can not be called > back. Is this appeal about avoiding further conflict or is it about challenging past differences? -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 10:25:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8f9E-0006oY-GU for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 10:25:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23475 for ; Fri, 26 Aug 2005 10:25:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QDxwEq004109; Fri, 26 Aug 2005 06:59:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QDxwUx004108; Fri, 26 Aug 2005 06:59:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QDxvb2004095 for ; Fri, 26 Aug 2005 06:59:57 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1E8ejy-0004PM-Lb; Fri, 26 Aug 2005 08:59:36 -0500 From: wayne To: "IETF MARID WG" Cc: Brian Carpenter , Ted Hardie , iesg@ietf.org, MARID , SPF Discussion , ietf@ietf.org References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> Mail-Copies-To: nobody Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Aug 2005 08:59:29 -0500 In-Reply-To: <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> (Andrew Newton's message of "Fri, 26 Aug 2005 08:47:17 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org, brc@zurich.ibm.com, hardie@qualcomm.com, iesg@ietf.org, ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com, ietf@ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net X-Spam-Status: No, score=-7.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> Andrew Newton writes: > On Aug 25, 2005, at 2:08 PM, Bill Sommerfeld wrote: > >> In this case, the two experiments interpret the same codepoints in the >> DNS in subtly different ways. >> >> A mail-sending domain indicates that it is participating by publishing >> certain DNS RR's. >> Crucially, a mail-sending domain cannot opt in to the SPF experiment >> without also opting in to the senderid experiment. This renders any >> claimed results of either experiment suspect. > > If this is the source of the conflict, then BOTH experiments should > not use the v=spf1 records. > > -andy The stated goal of draft-schlitt-spf-classic is to document SPF, basically as it was before the IETF got involved. Yes, the IETF is calling it an experiment, which I don't agree with. It is documenting an existing, well established, protocol. Are you saying that the IETF shouldn't publish an RFC that documents SPF? Yes, the IETF, via that MARID WG, tried to create a new protocol called SenderID that was based on both SPF and CallerID. I can see that newly created protocol being called an experiement, but I don't see why the IETF should go out of its way to bless a new protocol that is incompatible with an existing one. Is this the normal process of the IETF to create conflicting standards, just because one standard was developed outside the IETF? -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 11:11:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8frd-0001oa-Q1 for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 11:11:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25700 for ; Fri, 26 Aug 2005 11:11:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QEjKL0012345; Fri, 26 Aug 2005 07:45:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QEjKe5012344; Fri, 26 Aug 2005 07:45:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.167.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QEjKbW012338 for ; Fri, 26 Aug 2005 07:45:20 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.4] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 26 Aug 2005 10:45:19 -0400 id 000B3A78.430F2AFF.00007847 In-Reply-To: References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Cc: "IETF MARID WG" , Brian Carpenter , Ted Hardie , iesg@ietf.org, SPF Discussion , ietf@ietf.org Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 10:45:17 -0400 To: wayne X-Mailer: Apple Mail (2.733) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2005, at 9:59 AM, wayne wrote: >>> In this case, the two experiments interpret the same codepoints >>> in the >>> DNS in subtly different ways. >>> >>> A mail-sending domain indicates that it is participating by >>> publishing >>> certain DNS RR's. >>> Crucially, a mail-sending domain cannot opt in to the SPF experiment >>> without also opting in to the senderid experiment. This renders any >>> claimed results of either experiment suspect. >>> >> >> If this is the source of the conflict, then BOTH experiments should >> not use the v=spf1 records. >> >> -andy >> > > The stated goal of draft-schlitt-spf-classic is to document SPF, > basically as it was before the IETF got involved. Yes, the IETF is > calling it an experiment, which I don't agree with. It is documenting > an existing, well established, protocol. > > > Are you saying that the IETF shouldn't publish an RFC that documents > SPF? I stated that the SPF and Sender ID experiments should not use the v=spf1 records to avoid conflict. I did not state that the IETF should not publish an Experimental RFC about SPF. But since you brought this up: if you (the author of the document) do not consider this to be an experiment, then perhaps the IETF should not publish SPF as an Experimental RFC. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 11:24:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8g4P-0005my-PH for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 11:24:42 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26609 for ; Fri, 26 Aug 2005 11:24:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QErNDJ013074; Fri, 26 Aug 2005 07:53:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QErN7F013073; Fri, 26 Aug 2005 07:53:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QErNAY013067 for ; Fri, 26 Aug 2005 07:53:23 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1E8fZy-0005Wd-GO; Fri, 26 Aug 2005 09:53:19 -0500 From: wayne To: spf-discuss@v2.listbox.com (SPF discussions) Cc: "IETF MARID WG" , Brian Carpenter , Ted Hardie , iesg@ietf.org, MARID , SPF Discussion , ietf@ietf.org References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Mail-Copies-To: nobody Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Aug 2005 09:53:13 -0500 In-Reply-To: <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> (Andrew Newton's message of "Fri, 26 Aug 2005 10:45:17 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: spf-discuss@v2.listbox.com, ietf-mxcomp@imc.org, brc@zurich.ibm.com, hardie@qualcomm.com, iesg@ietf.org, ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com, ietf@ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net X-Spam-Status: No, score=-7.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Andrew Newton writes: > But since you brought this up: if you (the author of the document) do > not consider this to be an experiment, then perhaps the IETF should > not publish SPF as an Experimental RFC. I asked for the IESG to not consider the SPF I-D to be experiemental. It was turned down. According to Ted, *none* of the IESG members expressed interest in changing the status from Experiemental. So far, no one has appealed that decision, and there are only a few days left to do so. Like the appeal on the re-use of SPFv1 records, I don't think it would be a productive use of my time to write an appeal on the experimental status, and thus I won't do it. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 11:25:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8g5F-0005u4-6g for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 11:25:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26685 for ; Fri, 26 Aug 2005 11:25:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QEuTgo013294; Fri, 26 Aug 2005 07:56:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QEuTYe013293; Fri, 26 Aug 2005 07:56:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from procserver.webwayone.co.uk (webway-one-02.hiway.co.uk [62.8.115.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QEuRJi013284 for ; Fri, 26 Aug 2005 07:56:28 -0700 (PDT) (envelope-from SRS0=MGA9ayDB=W5=webwayone.co.uk=graham@webwayone.co.uk) DKIM-Signature: a=rsa-sha1; c=nowsp; d=webwayone.co.uk; s=ww1p; t=1125068358; h=From:To:Subject:References:Date:In-Reply-To: Message-ID:User-Agent:MIME-Version:Content-Type; b=FRNtHovi9dkn7S5v lmrfUF1I86Fk06xELFJmcelYlDp11Jfmgf6vZqQd+VqzkK0EullGcx94PTaL3n54m0f gbQ== Received-SPF: none (procserver.webwayone.co.uk: domain of graham@webwayone.co.uk does not designate permitted sender hosts) receiver=procserver.webwayone.co.uk; client-ip=192.168.50.45; envelope-from=; helo=gmdev.webwayone.co.uk; Received: from gmdev.webwayone.co.uk (graham@gmdev.webwayone.co.uk [192.168.50.45]) by procserver.webwayone.co.uk (8.13.4/8.13.4) with ESMTP id j7QExCFd014812 for ; Fri, 26 Aug 2005 15:59:18 +0100 From: Graham Murray To: ietf-mxcomp@imc.org Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Date: Fri, 26 Aug 2005 15:56:21 +0100 In-Reply-To: <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> (Andrew Newton's message of "Fri, 26 Aug 2005 10:45:17 -0400") Message-ID: <87slwwlpbe.fsf@gmdev.webwayone.co.uk> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (i586-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > But since you brought this up: if you (the author of the document) do > not consider this to be an experiment, then perhaps the IETF should > not publish SPF as an Experimental RFC. That would be a good idea. As there is already more than one implementation of the SPF protocol, should it not be possible to 'skip' the experimental phase and go straight to the start of the standards track? From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 13:26:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hyf-00006s-Eq for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 13:26:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02764 for ; Fri, 26 Aug 2005 13:26:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QH17OY026841; Fri, 26 Aug 2005 10:01:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QH179B026840; Fri, 26 Aug 2005 10:01:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QH1735026834 for ; Fri, 26 Aug 2005 10:01:07 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j7QH0rwg032417 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 26 Aug 2005 10:00:53 -0700 In-Reply-To: References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6503D26C-DB8E-404D-8D8F-5087F64A9119@mail-abuse.org> Cc: IETF MARID WG , iesg@ietf.org, ietf@ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 10:00:52 -0700 To: wayne X-Mailer: Apple Mail (2.734) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2005, at 7:53 AM, wayne wrote: > > In <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Andrew Newton > writes: > > >> But since you brought this up: if you (the author of the document) do >> not consider this to be an experiment, then perhaps the IETF should >> not publish SPF as an Experimental RFC. >> > > I asked for the IESG to not consider the SPF I-D to be experiemental. > It was turned down. According to Ted, *none* of the IESG members > expressed interest in changing the status from Experiemental. > > So far, no one has appealed that decision, and there are only a few > days left to do so. Like the appeal on the re-use of SPFv1 records, I > don't think it would be a productive use of my time to write an appeal > on the experimental status, and thus I won't do it. If the goal of the SPF Classic draft was intended to capture a point in time pre-dating semantic extensions related to RFC-2822 defined content, then perhaps the draft should be on an historic track. ; ) SPF Classic has not achieved the goal of capturing a pristine version of pre-MARID semantics. With some semantic changes introduced by the SPF Classic draft itself, these potential semantic conflicts, as well as those introduced by Sender-ID, have not been addressed. Prudent accommodations were made within the Sender-ID draft however. The SPF Classic draft has not found higher ground in this regard. Expecting any standards group to retroactively arbitrate semantics restrictions for a previously enigmatic DNS record would be disruptive. An unfrozen SPF Classic draft adding provisions for a scoped version of the DNS record would allow some percentage of publishers the means to indicate their intended semantics when so needed. The conflict issue being described seems specifically based upon a design flaw within SPF Classic. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 13:52:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8iND-0008LO-34 for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 13:52:15 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03966 for ; Fri, 26 Aug 2005 13:52:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QHO0js029859; Fri, 26 Aug 2005 10:24:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QHO05q029858; Fri, 26 Aug 2005 10:24:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QHNxQX029851 for ; Fri, 26 Aug 2005 10:23:59 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.1) with ESMTP id j7QHNf7e007970; Fri, 26 Aug 2005 10:23:41 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Aug 2005 10:23:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 10:23:41 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Thread-Index: AcWp0GIePBh4wrX2Tha4VIx0nhK7iAAkA87Q From: "Hallam-Baker, Phillip" To: , , "MARID" X-OriginalArrivalTime: 26 Aug 2005 17:23:41.0907 (UTC) FILETIME=[E799F230:01C5AA62] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QHNxQX029852 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Let me phrase it this way: the IESG should not sanction conflicting > experiments by publishing conflicting specifications, I agree. But I do not believe that SPF and Sender-ID conflict in any way whatsoever and this was accepted by the WG right up to the point where people started to complain about IPR licenses. I do not think that the IESG should block a proposal citing a conflict when the real animus here is entirely due to the IPR issue. All SPF does is provide a mechanism whereby sending parties can describe their outgoing edge mail servers. The recipient has the absolute right to interpret that data in any way they see fit. That is the entire point of a spam filtering scheme. Nobody has ever demonstrated a conflict as far as I am concerned, all attempts to allege a conflict begin, "the sender intends" which is utterly irrelevant. The sender does not have the right to decide what email client I use, they do not have the right to determine what spam filter I use either. Sender-ID simply describes one means of interpreting an SPF record. It may or may not work, it may or may not be optimal, that is why it is an experiment. An SPF record may be constructed in such a fashion that Sender-ID verification is not possible. That is not a conflict, it is simply an artifact that results from the baroque nature of the SPF spec. I do not believe that one group should be able to block a proposal they do not like by alleging a non-existent conflict. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 14:12:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8igX-0005kB-ED for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 14:12:13 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04858 for ; Fri, 26 Aug 2005 14:12:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QHnjDH031915; Fri, 26 Aug 2005 10:49:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QHnjP8031914; Fri, 26 Aug 2005 10:49:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QHnij1031908 for ; Fri, 26 Aug 2005 10:49:44 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.1) with ESMTP id j7QHncgr016135; Fri, 26 Aug 2005 10:49:38 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Aug 2005 10:49:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 10:49:37 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD375A2AB9@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Thread-Index: AcWqPM6jSr92SuJoQe28JLtgGHW4DAAJs76g From: "Hallam-Baker, Phillip" To: "Andrew Newton" , "Bill Sommerfeld" Cc: "Ted Hardie" , , , "MARID" X-OriginalArrivalTime: 26 Aug 2005 17:49:38.0174 (UTC) FILETIME=[873571E0:01C5AA66] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QHnij1031909 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Behalf Of Andrew Newton > If this is the source of the conflict, then BOTH experiments should > not use the v=spf1 records. Which would at the same time provide an opportunity to address the one part of SPF/Sender-ID that does give me significant concern, the exclusive appropriation of the TXT record. A prefixed record would be much less likely to collide with other records. A proposal has been made to cut an new RR but as the group discovered 50% of the legacy infrastructure does not support new RRs despite claims to the contrary. Support in this case has to be production quality, not the ability to coax particular bits out of a server in certain limited circumstances that no network admi is ever going to accept on a production server. The main objection to prefixed records is that they do not work with wildcards. This is actually a failure of imagination rather than fact. It is quite possible to develop a resolution procedure for prefix records that works acceptably with legacy DNS resolvers and meets the needs of network admins. The first step is to address the problem that wildcards do not match an existing node. As was demonstrated on the list this is easily solved using a macro processor. The second step is how to create a wildcard for _prefix.*.example.com without changing legacy DNS servers. The way to do this is to introduce a pointer record using CNAME as follows: _prefix.exists.example.com TXT "Policy1" *.example.com CNAME _wildcard.example.com _prefix._wildcard.example.com TXT "Policy2" The resolution algorithm for domain X is: 1) Check for a TXT record for _prefix.X if it exists, return the TXT string and stop 2) Check for a CNAME at X, if it does not exist return 'NIL' and stop 3) Check for a TXT record for _prefix.Y where Y is the CNAME mapping. If it exists return the TXT string, otherwise stop. Applying these rules to the scheme above we get: Lookup ("exists.example.com", "prefix") = "Policy1" [cost 1 lookup] Lookup ("empty.example.com", "prefix") = "Policy2" [cost 3 lookups] Lookup ("empty.example.com", "noprefix") = NIL [cost 3 lookups] This algorithm is 100% compatible with the deployed, legacy DNS and meets all use cases that were proposed for wildcarding. It never takes more than three DNS lookups. The first two can be requested in parallel, an intelligent DNS server could return the CNAME as an additional record for optimization purposes. If this mechanism was adopted as policy for ALL prefixed records there would no longer be any need to define new RRs unless there was a need to define a new record syntax. It would also allow admins to manage their policy records much more effectively, the default node is treated as if it was just another node. If folk really want to argue over the SPF=1 issue I think that they are saying that the protocol is not really embedded enough to be beyond change. If that is the case I think that we should fix the problem caused by the exclusive appropriation of TXT. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 14:33:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8j0g-0002aG-Mv for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 14:33:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05615 for ; Fri, 26 Aug 2005 14:33:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIDMFI034861; Fri, 26 Aug 2005 11:13:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QIDMWC034860; Fri, 26 Aug 2005 11:13:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.hxr.us [216.93.167.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIDMjw034854 for ; Fri, 26 Aug 2005 11:13:22 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.4] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 26 Aug 2005 14:13:19 -0400 id 000C7B77.430F5BC0.000045E6 In-Reply-To: <87slwwlpbe.fsf@gmdev.webwayone.co.uk> References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> <87slwwlpbe.fsf@gmdev.webwayone.co.uk> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57A12D32-481E-4FE2-B0D1-25768D33952E@hxr.us> Cc: ietf-mxcomp@imc.org Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 14:13:15 -0400 To: Graham Murray X-Mailer: Apple Mail (2.733) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2005, at 10:56 AM, Graham Murray wrote: > > Andrew Newton writes: > > >> But since you brought this up: if you (the author of the document) do >> not consider this to be an experiment, then perhaps the IETF should >> not publish SPF as an Experimental RFC. >> > > That would be a good idea. As there is already more than one > implementation of > the SPF protocol, should it not be possible to 'skip' the > experimental phase > and go straight to the start of the standards track? It should not be possible. Please consult RFC 2026 and RFC 2418. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 14:33:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8j0h-0002dR-IV for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 14:33:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05618 for ; Fri, 26 Aug 2005 14:33:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIB6U6034307; Fri, 26 Aug 2005 11:11:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QIB6K4034306; Fri, 26 Aug 2005 11:11:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIB5lM034298 for ; Fri, 26 Aug 2005 11:11:05 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1BCBBE0049; Fri, 26 Aug 2005 14:10:55 -0400 (EDT) To: spf-discuss@v2.listbox.com (SPF discussions) Cc: Ted Hardie , ietf@ietf.org, Brian Carpenter , MARID , iesg@ietf.org Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> From: Sam Hartman Date: Fri, 26 Aug 2005 14:10:55 -0400 In-Reply-To: (wayne@schlitt.net's message of "Fri, 26 Aug 2005 09:53:13 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "wayne" == wayne writes: wayne> In <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Andrew wayne> Newton writes: >> But since you brought this up: if you (the author of the >> document) do not consider this to be an experiment, then >> perhaps the IETF should not publish SPF as an Experimental RFC. wayne> I asked for the IESG to not consider the SPF I-D to be wayne> experiemental. It was turned down. According to Ted, wayne> *none* of the IESG members expressed interest in changing wayne> the status from Experiemental. As a point of fact, I only saw requests from you to publish as a proposed standard or some other standards track document rather than experimental. Of course I would not have seen private communication between you and Ted. however if you do not consider SPF an experiment, standards track is not the only status to consider. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 14:42:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8j9q-0005iy-QI for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 14:42:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06131 for ; Fri, 26 Aug 2005 14:42:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIKktC035664; Fri, 26 Aug 2005 11:20:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QIKk7w035663; Fri, 26 Aug 2005 11:20:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIKjwB035651 for ; Fri, 26 Aug 2005 11:20:45 -0700 (PDT) (envelope-from dotzero@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so5910wri for ; Fri, 26 Aug 2005 11:20:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jk76+gV3HGgu7TFDQBvfOPYSnIAGb4hT+4BDq1Lj+Z33u3C9h2ZlMX0r0iNcpZURMPsKP71Xe2o/VHHiaeiDSIM68d12HWGfXCgxuD6hT6ab7tI2F4W+GZ6q5bBCuI5KJKFhZFYOAi1sdsn5xMYIphsu2VyNQpT3pxk1ryUafQQ= Received: by 10.54.30.27 with SMTP id d27mr3540757wrd; Fri, 26 Aug 2005 11:20:38 -0700 (PDT) Received: by 10.54.122.7 with HTTP; Fri, 26 Aug 2005 11:20:38 -0700 (PDT) Message-ID: <7ae58c22050826112058b14708@mail.gmail.com> Date: Fri, 26 Aug 2005 14:20:38 -0400 From: Dotzero To: spf-discuss@v2.listbox.com Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Cc: ietf@ietf.org, MARID In-Reply-To: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QIKkwB035658 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/26/05, Hallam-Baker, Phillip wrote: > > Let me phrase it this way: the IESG should not sanction conflicting > > experiments by publishing conflicting specifications, > > I agree. > > But I do not believe that SPF and Sender-ID conflict in any way > whatsoever and this was accepted by the WG right up to the point where > people started to complain about IPR licenses. > Not quite correct. The reason that people did not complain was that supporters of SID were pushing for use of SPF2 records at the time. It was only after the announcement that SID would use (abuse) SPF1 records that it became an issue. > I do not think that the IESG should block a proposal citing a conflict > when the real animus here is entirely due to the IPR issue. > So all of the discussion on the spf-discuss list has nothing to do with technical issues and has only been a cover for unhappiness with IPR issues? I find that a stretch. > All SPF does is provide a mechanism whereby sending parties can describe > their outgoing edge mail servers. The recipient has the absolute right > to interpret that data in any way they see fit. That is the entire point > of a spam filtering scheme. > Let us remind ourselves what SPF stands for SENDER Policy Framework. If the publisher of a record has no reasonable expectation of how that record will be used and every expectation that it may be abused then what incentive do they have to publish the record? SPF does not describe outgoing edge mail servers.... it describes the policies associated with the domain. The issue at hand is not whether an individual recipient chooses to interpret the data a particular way. Interpretation by the recipient is should I reject on softfail or not or should I assign a point value in conjunction with other things. Writing a standard which subverts the intent of individuals publishing to a different and existing standard is simply unethical and wrong. What happened was essentially a political move because people chose not to publish SPF2 records for PRA. So, the response was to force people to opt-out (publish an essentially meaningless SPF2 record) because the SID camp was losing in the real world marketplace. > Nobody has ever demonstrated a conflict as far as I am concerned, all > attempts to allege a conflict begin, "the sender intends" which is > utterly irrelevant. The sender does not have the right to decide what > email client I use, they do not have the right to determine what spam > filter I use either. > An interesting argument. Of what value is publishing a record (of any sort) if the publisher of said record has a reasonable expectation that it will be used in arbitrary ways to the publishers detriment? One argument that was put forth after the announcement that SID would apply PRA to SPF1 records was that it was a conspiracy to get publishers to yank their SPF1 records. People and organizations chose to publish a record according to a standard because they have a reasonable expectation on how that record will be used. While there may be edge cases of abuse, the expectation is that most people will respect the standard. That's why it's called a standard. > Sender-ID simply describes one means of interpreting an SPF record. It > may or may not work, it may or may not be optimal, that is why it is an > experiment. > I can see someone using this "logic" in any number of circumstances.... "Your honor, I have this alternative means of interpreting what a red stoplight indicates.....go go go as fast as you can". > An SPF record may be constructed in such a fashion that Sender-ID > verification is not possible. That is not a conflict, it is simply an > artifact that results from the baroque nature of the SPF spec. > You are implying that individuals published SPF1 records with the intent of subverting SID verification. This is akin to blaming the victim for the actions of the mugger. I would argue that most of those who published SPF1 records did so with no knowledge or anticipation that PRA would be applied to those records. > I do not believe that one group should be able to block a proposal they > do not like by alleging a non-existent conflict. > I don't hear anyone trying to block the SID proposal in its entirety. I only see the blocking of an abusive portion of the proposal. Why weren't the supporters of the SID proposal willing to go out and promote use of SPF2/PRA format/records? I haven't seen any of the core SPF activists oppose the use of SPF2 records by SID for PRA. We again come back to the politics of the issue. SID was losing in the marketplace (numbers of published records). A significant aspect of these types of experiments is whether people buy in to the approach. Applying PRA to SPF1 records was a way of sidestepping this issue regardless of whether the (publisher)marketplace bought into SID. Mike From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 14:48:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jFf-0007B2-QL for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 14:48:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06311 for ; Fri, 26 Aug 2005 14:48:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIMjXg035866; Fri, 26 Aug 2005 11:22:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QIMilh035865; Fri, 26 Aug 2005 11:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pix525.e-dialog.com (pix525.e-dialog.com [64.28.75.220]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIMiNm035848 for ; Fri, 26 Aug 2005 11:22:44 -0700 (PDT) (envelope-from JMacDonald@e-dialog.com) Received: from corp-exc2.e-dialog.com (corp-exc2.ad.e-dialog.com [10.0.30.26]) by pix525.e-dialog.com (8.12.11/8.12.11) with ESMTP id j7QIMCHb013943; Fri, 26 Aug 2005 14:22:22 -0400 Received: from jm-node4.e-dialog.com ([10.0.40.189]) by corp-exc2.e-dialog.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Aug 2005 14:22:17 -0400 Subject: RE: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 From: Jeff Macdonald To: spf-discuss@v2.listbox.com Cc: ietf@ietf.org, MARID In-Reply-To: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain Organization: E-Dialog Date: Fri, 26 Aug 2005 14:22:17 -0400 Message-Id: <1125080537.2967.57.camel@jmacdonald-work.e-dialog.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-16) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Aug 2005 18:22:17.0786 (UTC) FILETIME=[173A81A0:01C5AA6B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-08-26 at 10:23 -0700, Hallam-Baker, Phillip wrote: > I do not believe that one group should be able to block a proposal they > do not like by alleging a non-existent conflict. A conflict does exist interpreting v=spf1 records in a PRA scope. I had a customer who was a victim of joe-jobbing. We use separate domains for RFC821 and RFC822 identities. The RFC821 identity (MAIL FROM) would never be used as a RFC822 identity (FROM). RFC821 FROM: foo@customer.bounce.esp.com RFC822 From: branding@brand.esp.com Before Sender-ID came I had this: brand.esp.com IN TXT "v=spf1 -all" This means if brand.esp.com was ever seen as a RFC821 MAIL FROM domain, it could be considered a forgery. Along comes Sender-ID, reusing v=spf1 records for PRA tests. Microsoft then decides to put a warning for those records that fail Sender-ID tests for its Hotmail/MSN users. Since Sender-ID checks RFC822 identities against a record meant for RFC821 identities, it gets an erroneous FAIL. This is what I believe is the conflict. It is real. It exists. In order to get correct results I have to publish 2 records in DNS: brand.esp.com IN TXT "spfv2.0/pra a:outbound.brand.esp.com -all" brand.esp.com IN TXT "v=spf1 -all" OR (this one opts out of Sender-ID): brand.esp.com IN TXT "spfv2.0/pra" brand.esp.com IN TXT "v=spf1 -all" This also means that to participate in one experiment I have to participate in another. That seems wrong to me. -- :: Jeff Macdonald | Principal Engineer, Messaging Technologies :: e-Dialog | jmacdonald@e-dialog.com :: 131 Hartwell Ave. | Lexington, MA 02421 :: v: 781-372-1922 | f: 781-863-8118 :: www.e-dialog.com From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 15:01:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jSR-00026N-GG for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 15:01:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06786 for ; Fri, 26 Aug 2005 15:01:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIcQT9037497; Fri, 26 Aug 2005 11:38:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QIcQu4037496; Fri, 26 Aug 2005 11:38:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIcP1l037485 for ; Fri, 26 Aug 2005 11:38:25 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1E8j5f-0001Ng-LC; Fri, 26 Aug 2005 13:38:20 -0500 From: wayne To: spf-discuss@v2.listbox.com (SPF discussions) Cc: Ted Hardie , ietf@ietf.org, Brian Carpenter , MARID , iesg@ietf.org References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Mail-Copies-To: nobody Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Aug 2005 13:38:10 -0500 In-Reply-To: (Sam Hartman's message of "Fri, 26 Aug 2005 14:10:55 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: spf-discuss@v2.listbox.com, hardie@qualcomm.com, ietf@ietf.org, brc@zurich.ibm.com, ietf-mxcomp@imc.org, iesg@ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net X-Spam-Status: No, score=-7.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Sam Hartman writes: >>>>>> "wayne" == wayne writes: > > wayne> I asked for the IESG to not consider the SPF I-D to be > wayne> experiemental. It was turned down. According to Ted, > wayne> *none* of the IESG members expressed interest in changing > wayne> the status from Experiemental. > > > As a point of fact, I only saw requests from you to publish as a > proposed standard or some other standards track document rather than > experimental. > > Of course I would not have seen private communication between you and > Ted. > > however if you do not consider SPF an experiment, standards track is > not the only status to consider. Yes, good point. I really hadn't considered other status. I guess Informational might also be appropriate. I still think Standard Track is most appropriate, but again, I don't think it would be a productive use of time to try and change the current Experimental designation. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 15:35:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jzK-00032K-7U for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 15:35:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10234 for ; Fri, 26 Aug 2005 15:35:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJF2dQ042266; Fri, 26 Aug 2005 12:15:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJF2JR042264; Fri, 26 Aug 2005 12:15:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJF2fh042258 for ; Fri, 26 Aug 2005 12:15:02 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.1/8.13.1) with ESMTP id j7QJExbB020676; Fri, 26 Aug 2005 12:14:59 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 12:14:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 12:14:58 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD375A2ABD@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Thread-Index: AcWqbIdPT9J8u3anT2u9v/ucD40YkgABIQWQ From: "Hallam-Baker, Phillip" To: "wayne" , Cc: , X-OriginalArrivalTime: 26 Aug 2005 19:14:59.0193 (UTC) FILETIME=[7392EE90:01C5AA72] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QJF2fh042259 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > All SPF does is provide a mechanism whereby sending parties can > > describe their outgoing edge mail servers. The recipient has the > > absolute right to interpret that data in any way they see > fit. That is > > the entire point of a spam filtering scheme. > > You have long advocated this position, but unfortunately the > definition of "outgoing edge mail servers" is not a nice, > clean, crisp concept. It sounds good, but unfortunately, it > doesn't work. OK, "All SPF does is ATTEMPT TO provide a mechanism whereby " Happy now? It does not matter which way you try to slice it, the sender of the message has no connection to any of the forwarder mechanisms or any other part of the email infrastructure. At some point there is a boundary between infrastructure the sender has control of and where he does not. That boundary is very clearly defined in my universe but even if it was ambiguous it would still exist. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 15:37:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k1P-0004M8-Hj for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 15:37:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10547 for ; Fri, 26 Aug 2005 15:37:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJCdO3041920; Fri, 26 Aug 2005 12:12:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJCdmg041919; Fri, 26 Aug 2005 12:12:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJCc8F041912 for ; Fri, 26 Aug 2005 12:12:38 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.1) with ESMTP id j7QJCOJn013429; Fri, 26 Aug 2005 12:12:24 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Aug 2005 12:12:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 12:12:24 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD375A2ABC@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 Thread-Index: AcWqbWOOKRzovJpQRX6qO9vj+OU44gABFTsQ From: "Hallam-Baker, Phillip" To: "wayne" , Cc: X-OriginalArrivalTime: 26 Aug 2005 19:12:24.0772 (UTC) FILETIME=[17882840:01C5AA72] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QJCc8F041914 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Behalf Of wayne > > The way to do this is to introduce a pointer record using CNAME as > > follows: > > > > _prefix.exists.example.com TXT "Policy1" > > *.example.com CNAME _wildcard.example.com > > _prefix._wildcard.example.com TXT "Policy2" > > I don't believe this will work since CNAMEs have to be the > only thing in a given node, and so a wildcard CNAME would > conflict with all other wildcard usage, such as wildcard MX records. OK, lets try PTR, or one of the previously defined by largely unused records. How about MR? This can be made to work if people want it to. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 15:54:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8kHi-0000vb-Rr for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 15:54:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11621 for ; Fri, 26 Aug 2005 15:54:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJTwpw043940; Fri, 26 Aug 2005 12:29:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJTwwL043939; Fri, 26 Aug 2005 12:29:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJTwsY043932 for ; Fri, 26 Aug 2005 12:29:58 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.1) with ESMTP id j7QJTqCM021315; Fri, 26 Aug 2005 12:29:52 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 12:29:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 12:29:52 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD375A2ABE@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Thread-Index: AcWqbIdPT9J8u3anT2u9v/ucD40YkgABmH1w From: "Hallam-Baker, Phillip" To: "wayne" , Cc: , X-OriginalArrivalTime: 26 Aug 2005 19:29:52.0738 (UTC) FILETIME=[882B1420:01C5AA74] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QJTwsY043933 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > There are several known conflicts, as outlined in the appeal, > and they don't begin with "the sender intends". You appear to refer to: http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf&i=200508250045.27 704.julian%40mehnle.net * Many mailing lists rewrite the MAIL FROM identity when distributing messages, but do not change the header (PRA) identities. And they are not required to do so by RFCs 2821 or 1123 or any other current IETF standards. * Many organizations with their own domains outsource their bulk message sending (newsletters, etc.) to ESPs, who use their own domain in the MAIL FROM identity and the organization's domain in the From: header, but do not add a Sender: header.[12] * If the MAIL FROM is empty ("MAIL FROM:<>"), the MAIL FROM identity, as defined by the SPF specification, falls back to HELO identity[5, section 2.2], while the PRA identity is usually unpredictable. The first is simply a KNOWN FAILURE MODE of Sender-ID. The PRA check is known to fail in certain circumstances, just as the SPF check is known to give false positives. In both cases the overwhelming number of false positives come from poorly maintained records, not the internals of the protocol. The second is also a known failure mode of the PRA check. That is why the bulk mail senders have been adding Sender-ID records and adding From: headers. Paid bulk senders that have not fixed this already went out of business. PRA comaptibility is a checklist compliance item in all RFPs for that type of business. If you want to send bulk email you already have to meet this criteria, PRA checking is already live at several anti-spam vendors and it is not going to be turned off. The final case is one that Lyon and others strongly assert should be handled by a BATV type mechanism. Treatment of bounce mail is outside the scope of PRA because it can be handled much more effectively by other means. Since all these 'failures' are simply known properties of the PRA check there is absolutely no value in changing the version string. The PRA implementations are certainly not going to follow this advice if it is made. All that the IESG would achieve is to further confuse and complicate deployment of SPF/Sender-ID by giving advice that is ill-founded. Only the receiver of an email has any right to decide how their spam filter is going to work. The purpose of SPF is to provide the sender a mechanism that helps them to pursuade the recipient to receive the email message. The way that all email authentication checks work in practice is to look for any form of evidence that would allow the mail to be whitelisted. The fact that an email message might fail a particular test is irrelevant, the receiver is trying to help the sender to pass. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 16:05:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8kSL-0006ao-JD for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 16:05:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14882 for ; Fri, 26 Aug 2005 16:05:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJi6XU045821; Fri, 26 Aug 2005 12:44:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJi6Dg045820; Fri, 26 Aug 2005 12:44:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJi6nu045807 for ; Fri, 26 Aug 2005 12:44:06 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.1/8.13.1) with ESMTP id j7QJi3hS021894; Fri, 26 Aug 2005 12:44:03 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 12:44:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 12:44:03 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD375A2ABF@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 Thread-Index: AcWqdRRb+Z980O10TFub/u3hnMtvawAASEaA From: "Hallam-Baker, Phillip" To: "wayne" , Cc: , X-OriginalArrivalTime: 26 Aug 2005 19:44:03.0625 (UTC) FILETIME=[83562190:01C5AA76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QJi6nu045808 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Behalf Of wayne > > At some point there is a boundary between infrastructure the sender > > has control of and where he does not. That boundary is very clearly > > defined in my universe but even if it was ambiguous it would still > > exist. > > The problem is that for different identities, this "boundary" > is different. In particular, the boundaries between the SPF > identities (2821.MAILFROM and 2821.HELO) are different than > SenderID (PRA). The identities are completely irrelevant. The only relevant boundary is between what the sender controls and what they do not. All that any sender, forwarder or any other mail injector can ever be expected to do is to define the boundaries of the systems they control. Once that boundary is defined the definition is fair game for any party to use to interpret it to meet their operational needs. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 16:11:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8kYI-0002H0-BD for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 16:11:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17678 for ; Fri, 26 Aug 2005 16:11:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJfJaF045536; Fri, 26 Aug 2005 12:41:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJfJgk045535; Fri, 26 Aug 2005 12:41:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJfHl6045529 for ; Fri, 26 Aug 2005 12:41:18 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8k4Z-0004TN-Kf for ietf-mxcomp@imc.org; Fri, 26 Aug 2005 21:41:07 +0200 Received: from footbone.schlitt.net ([67.52.51.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 21:41:07 +0200 Received: from wayne by footbone.schlitt.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 21:41:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: wayne Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 14:24:46 -0500 Lines: 29 Message-ID: References: <198A730C2044DE4A96749D13E167AD375A2ABD@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: footbone.schlitt.net User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux) Cancel-Lock: sha1:HFwoWhXG75MgMg3n5rDDxM/OAUA= Cc: spf-discuss@v2.listbox.com, ietf@ietf.org Cc: spf-discuss@v2.listbox.com, ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <198A730C2044DE4A96749D13E167AD375A2ABD@MOU1WNEXMB04.vcorp.ad.vrsn.com> "Hallam-Baker, Phillip" writes: >> > All SPF does is provide a mechanism whereby sending parties can >> > describe their outgoing edge mail servers. The recipient has the >> > absolute right to interpret that data in any way they see >> fit. That is >> > the entire point of a spam filtering scheme. >> >> You have long advocated this position, but unfortunately the >> definition of "outgoing edge mail servers" is not a nice, >> clean, crisp concept. It sounds good, but unfortunately, it >> doesn't work. > > OK, "All SPF does is ATTEMPT TO provide a mechanism whereby " > > Happy now? Sorry, but no.. > At some point there is a boundary between infrastructure the sender has > control of and where he does not. That boundary is very clearly defined > in my universe but even if it was ambiguous it would still exist. The problem is that for different identities, this "boundary" is different. In particular, the boundaries between the SPF identities (2821.MAILFROM and 2821.HELO) are different than SenderID (PRA). -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 16:12:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8kZB-0002oC-KB for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 16:12:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17932 for ; Fri, 26 Aug 2005 16:12:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJqXFk046758; Fri, 26 Aug 2005 12:52:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJqXFw046757; Fri, 26 Aug 2005 12:52:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJqWPq046748 for ; Fri, 26 Aug 2005 12:52:33 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8kEL-0006qv-0G for ietf-mxcomp@imc.org; Fri, 26 Aug 2005 21:51:13 +0200 Received: from footbone.schlitt.net ([67.52.51.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 21:51:12 +0200 Received: from wayne by footbone.schlitt.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 21:51:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: wayne Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 13:34:01 -0500 Lines: 25 Message-ID: References: <198A730C2044DE4A96749D13E167AD375A2AB9@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: footbone.schlitt.net User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux) Cancel-Lock: sha1:dOU21uLnYBYtS48wk2zONLP36fk= Cc: ietf@ietf.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <198A730C2044DE4A96749D13E167AD375A2AB9@MOU1WNEXMB04.vcorp.ad.vrsn.com> "Hallam-Baker, Phillip" writes: > [PHB brainstorms about a new protocol...] > > The main objection to prefixed records is that they do not work with > wildcards. This is actually a failure of imagination rather than fact. > It is quite possible to develop a resolution procedure for prefix > records that works acceptably with legacy DNS resolvers and meets the > needs of network admins. > > [...] > > The way to do this is to introduce a pointer record using CNAME as > follows: > > _prefix.exists.example.com TXT "Policy1" > *.example.com CNAME _wildcard.example.com > _prefix._wildcard.example.com TXT "Policy2" I don't believe this will work since CNAMEs have to be the only thing in a given node, and so a wildcard CNAME would conflict with all other wildcard usage, such as wildcard MX records. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 16:21:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8kh9-0004PC-UC for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 16:21:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20454 for ; Fri, 26 Aug 2005 16:20:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJxRZr047406; Fri, 26 Aug 2005 12:59:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJxRL7047405; Fri, 26 Aug 2005 12:59:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJxPFr047399 for ; Fri, 26 Aug 2005 12:59:26 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E8kKl-0000S1-Vq for ietf-mxcomp@imc.org; Fri, 26 Aug 2005 21:57:52 +0200 Received: from footbone.schlitt.net ([67.52.51.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 21:57:51 +0200 Received: from wayne by footbone.schlitt.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 21:57:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: wayne Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 14:56:05 -0500 Lines: 87 Message-ID: References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> <6503D26C-DB8E-404D-8D8F-5087F64A9119@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: footbone.schlitt.net User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux) Cancel-Lock: sha1:cQu4zyT2yuDmU0EBtzvn6Q0xlA0= Cc: ietf@ietf.org, spf-discuss@v2.listbox.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <6503D26C-DB8E-404D-8D8F-5087F64A9119@mail-abuse.org> Douglas Otis writes: > If the goal of the SPF Classic draft was intended to capture a point > in time pre-dating semantic extensions related to RFC-2822 defined > content, then perhaps the draft should be on an historic track. ; ) RFC2026 says: 4.2.4 Historic A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. [...] This wouldn't apply because there are no newer specifications for SPF, nor is it obsolete. > SPF Classic has not achieved the goal of capturing a pristine version > of pre-MARID semantics. With some semantic changes introduced by the > SPF Classic draft itself, [...] There isn't a "pristine" version of SPF, there are several different draft specifications and a whole bunch of implementation. There are, unfortunately, conflicts between these. The SPF-classic I-D attempts to document the most coherent intersection of these. There have been *very* few semantic changes that were introduced in the current spf-classic I-D. Almost everything was either part of one of the earlier, pre-MARID specs, or part of one of the earlier, pre-MARID implementations. Of hand, I can think of only the following three "new" items in the spf-classic I-D: 1) The introduction of a new DNS RR type. Personally, I would be happy to get rid of this, but there are a lot of folks, especially in the IETF who think this is very important. 2) The SPF result code "unknown" was renamed "PermError" and the result code "Error" was renamed "TempError". This is truely a holdover from MARID. I think the names are much better, but yeah, it is a change. 3) The result of a redirect modifier that has, as its target, a domain name that has no SPF records has been changed from returning a result code of "None" to "PermError". Actually, I'm not certain what the result code in the earlier draft should be because it was a corner case that was not addressed. There were quite a few places where we either removed things like Receiver Policy, or changed things from "MUST" to either "SHOULD" or "MAY". We did this when we found that existing implemenations did not obey the "MUST" and in practice, a "SHOULD" or "MAY" would be more productive as the standard. In some cases we also had to tighten the requirements in order to make things more portable. For example, there were a couple of SPF implementations (pre-MARID) that enforced processing limits needed to prevent SPF from being used as an (effective) DoS vector. Since these implementations were deployed, domain owners need to make sure their records conform to these limits in order to make sure their records would be processed correctly everywhere. Finally, we found some cases where features were simply not used in practice. For example, the ABNF for the Received-SPF: header in the older specs could allow for the creation of headers that did not conform to what RFC2822 wants. In practice, the Received-SPF: headers generated by actual implementations conformed to RFC2822, and so the ABNF could be tightened up. It took a great deal of work to find as many SPF implementations as we could, figure out how the actually worked, find as many SPF records as we could, figure out which features are used, and to resolve as many conflicts as we could in the best, most coherent, way we could. While I'm sure that the SPF-classic I-D can be improved, I think it has done a good job of meeting the goal of documenting SPF, as it existed pre-MARID. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 17:03:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8lMb-0003CQ-SO for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 17:03:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22553 for ; Fri, 26 Aug 2005 17:03:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKWTDL051020; Fri, 26 Aug 2005 13:32:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QKWTSr051019; Fri, 26 Aug 2005 13:32:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKWSit051013 for ; Fri, 26 Aug 2005 13:32:28 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8kqe-0001wo-4b for ietf-mxcomp@imc.org; Fri, 26 Aug 2005 22:30:48 +0200 Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 22:30:48 +0200 Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 22:30:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 21:51:00 +0200 Organization: Lines: 16 Message-ID: <430F72A4.6FA2@xyzzy.claranet.de> References: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.221 X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com, ietf@ietf.org Cc: spf-discuss@v2.listbox.com, ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > But I do not believe that SPF and Sender-ID conflict in any > way whatsoever and this was accepted by the WG What you believe is your business, but this was never accepted by the WG, because it's plain wrong, see also reference [12] in the appeal: http://purl.net/xyzzy/home/test/senderid-appeal.htm#r12 The complete thread (starting in mxcomp) is very interesting: http://news.gmane.org/group/gmane.mail.spam.spf.discuss/thread=8111 Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 17:03:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8lMd-0003Co-48 for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 17:03:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22556 for ; Fri, 26 Aug 2005 17:03:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKa7Cm051517; Fri, 26 Aug 2005 13:36:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QKa7PC051516; Fri, 26 Aug 2005 13:36:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKa6iR051509 for ; Fri, 26 Aug 2005 13:36:06 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id D2FE216CCA; Fri, 26 Aug 2005 16:37:22 -0400 (EDT) From: "Alan DeKok" To: "Hallam-Baker, Phillip" Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 In-Reply-To: Your message of "Fri, 26 Aug 2005 12:29:52 PDT." <198A730C2044DE4A96749D13E167AD375A2ABE@MOU1WNEXMB04.vcorp.ad.vrsn.com> Cc: "wayne" , ietf@ietf.org, ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com Date: Fri, 26 Aug 2005 16:37:22 -0400 Message-Id: <20050826203722.D2FE216CCA@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hallam-Baker, Phillip" wrote: > Only the receiver of an email has any right to decide how their spam > filter is going to work. Sure, but the intent of the sender, and/or owner of the SPF record matters, too. Common consent makes the net work. Otherwise, people could send HTTP GET requests to an MX, and claim it's their "valid" interpretation of MX records. If a recipient doesn't want to use SPF records in the way the publishers intended, that's their right. But they shouldn't claim that their interpretation is compliant. If the SPF authors believe that another proposal has an incompatible interpretation of SPF records, then that belief should be relevant to the discussion. Otherwise, any large company can DoS the IETF by publishing incompatible interpretations and/or implementations of proposals they don't like. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 17:13:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8lVv-0005Sv-Ob for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 17:13:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22974 for ; Fri, 26 Aug 2005 17:13:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKpDkD052677; Fri, 26 Aug 2005 13:51:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QKpD7n052676; Fri, 26 Aug 2005 13:51:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKpB7k052669 for ; Fri, 26 Aug 2005 13:51:12 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8l9w-00071r-Ca for ietf-mxcomp@imc.org; Fri, 26 Aug 2005 22:50:44 +0200 Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 22:50:44 +0200 Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Aug 2005 22:50:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 22:31:54 +0200 Organization: Lines: 16 Message-ID: <430F7C3A.2156@xyzzy.claranet.de> References: <198A730C2044DE4A96749D13E167AD375A2ABF@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.221 X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com, ietf@ietf.org Cc: spf-discuss@v2.listbox.com, ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > Once that boundary is defined the definition is fair game for > any party to use to interpret it to meet their operational > needs. The boundaries are different and incompatible for spf2.0/mfrom (roughly te same as v=spf1) and spf2.0/pra. That's the point of the appeal, replace one occurence of "pra,mfrom" by "mfrom" in chapter 3.4 "backwards compatibility". Have you ever seen an RfC claiming that you can interpret MD5 as truncated SHA because after all they are both only hashes ? Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 19:06:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nHb-0004HF-92 for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 19:06:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00217 for ; Fri, 26 Aug 2005 19:06:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QMeVhP064953; Fri, 26 Aug 2005 15:40:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QMeVtg064952; Fri, 26 Aug 2005 15:40:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QMeUYY064946 for ; Fri, 26 Aug 2005 15:40:30 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.1/8.13.1) with ESMTP id j7QMeRIo021871; Fri, 26 Aug 2005 15:40:27 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 15:40:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 15:40:27 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD375A2AC2@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 Thread-Index: AcWqhF3Qg6W7dAGjRqWFKrMBNkt2zAACqZcQ From: "Hallam-Baker, Phillip" To: "Julian Mehnle" , , "MARID" X-OriginalArrivalTime: 26 Aug 2005 22:40:27.0651 (UTC) FILETIME=[27E85530:01C5AA8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QMeUYY064947 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit As has recently been pointed out on the namedroppers list, the dual track RR and TXT approach does not work. It leads to ambiguities when the records do not match - which they will inevitably dur to the DNS protocol. > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > Behalf Of Julian Mehnle > Sent: Friday, August 26, 2005 5:21 PM > To: ietf@ietf.org; MARID > Subject: Re: Appeal: Publication of > draft-lyon-senderid-core-01 in conflictwith referenced > draft-schlitt-spf-classic-02 > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hallam-Baker, Phillip wrote: > > Which would at the same time provide an opportunity to > address the one > > part of SPF/Sender-ID that does give me significant concern, the > > exclusive appropriation of the TXT record. > > > > A prefixed record would be much less likely to collide with other > > records. > > > > A proposal has been made to cut an new RR but as the group > discovered > > 50% of the legacy infrastructure does not support new RRs despite > > claims to the contrary. Support in this case has to be production > > quality, not the ability to coax particular bits out of a server in > > certain limited circumstances that no network admi is ever going to > > accept on a production server. > > What about the new SPF RR type (99) recently assigned by IANA? > > $ named -v > BIND 9.3.1 > $ grep TYPE99 /etc/bind/zones/net.mehnle > @ IN TYPE99 \# 15 0e763d73706631206d78202d616c6c > > $ dig -v > DiG 9.3.1 > $ dig mehnle.net TYPE99 +sho > \# 15 0E763D73706631206D78202D616C6C > > $ host -V > host version 991529 > $ host -t 99 mehnle.net > mehnle.net 99 # ( ; unknown type > 0E 76 3D 73 70 66 31 20 6D 78 20 2D 61 6C 6C ; > .v=spf1 mx -all > ) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDD4ewwL7PKlBZWjsRAsJ1AJ9mS+vB3+zp5MVWTB5x5Q6N4oZK1gCgvn+e > hOvx+pNMHSIPVU1Q9HnvzOg= > =+/dM > -----END PGP SIGNATURE----- > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 19:26:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nah-0001nc-HP for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 19:26:31 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00868 for ; Fri, 26 Aug 2005 19:26:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QN17LD067092; Fri, 26 Aug 2005 16:01:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QN17Y8067091; Fri, 26 Aug 2005 16:01:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QN153B067082 for ; Fri, 26 Aug 2005 16:01:05 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8nBn-00077k-It for ietf-mxcomp@imc.org; Sat, 27 Aug 2005 01:00:47 +0200 Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 01:00:47 +0200 Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 01:00:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Sat, 27 Aug 2005 00:40:39 +0200 Organization: Lines: 127 Message-ID: <430F9A67.5A7C@xyzzy.claranet.de> References: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.221 X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com, ietf@ietf.org Cc: spf-discuss@v2.listbox.com, ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > I do not think that the IESG should block a proposal citing a > conflict when the real animus here is entirely due to the IPR > issue. Hogwash, I've proposed a way to "fix" PRA to avoid at least the worst incompatibility (a "default Sender" derived from the Return-Path in the spirit of RfC 3834). After that was ignored (maybe it was a bad idea) I proposed a clean "opt-in" modifier for those, where both "boundaries" for PRA and MAiL FROM are in fact identical. After all that is possible, even likely (somebody says 80%). But it is not guaranteed (80% is not good enough, BLs operate near 99.5%). The WG settled on "spf2.0/pra,mfrom" in the last week of its existence, I supported this. Certainly not my fault that the WG was closed exactly at the time when a clean solution was in sight, http://purl.net/xyzzy/home/test/MARID.appeal.txt JFTR. the last quote in this mail was an article from you. MARID was closed as soon as it was clear that abusing v=spf1 for PRA without explicit consent of the sender policy publisher is a non-starter, because it would be _tschnical_ FUBAR. > All SPF does is provide a mechanism whereby sending parties > can describe their outgoing edge mail servers. The recipient > has the absolute right to interpret that data in any way they > see fit. Sure, you do what you like, use PRA, or how about Message-IDs ? Or better try a random generator., no DNS headaches if all you want are random rejections. Most mails are spam, so rejecting mails always hits more spam than legit mail, no matter how you decide this. But v=spf1 FAIL is no 80% or 99.5% idea, it is 100% if you do it right accepting all consequences. "Interpret v=spf1 with PRA" is not implicitly the intent of most publishers. If they explicitly want this they are free to publish spf2.0/pra. We're talking about RfCs defining _sender policies_ - what you as receiver do with it is beside the point, as long as domain owners can express their intention. Several hundred thousand domain owners did this, they know or should know that it means what the relevant v=spf1 drafts said. And the SPF RfC reflects this as good as possible (calling that an "experiment" is a part of the many MARID legends all featuring the "let's steal v=spf1 for PRA" theme). PRA doesn't necessarily reflect what these publishers intended. > That is the entire point of a spam filtering scheme. Neither v=spf1 (spf2.0/mfrom) nor PRA (spf2.0/pra) are a good "spam filtering scheme". PRA is a (dubious) anti-phishing idea, and the MAIL FROM part of v=spf1 fights bogus bounces to innocent (spoofed) bystanders. You can use both as input for "spam filtering", e.g. use PASS as "asssume innocent until proven guilty" like AOL, or use a FAIL as "once a liar, always a liar" indicator for the sending IP or HELO identity. But the primary purpose of v=spf1 is MOT "yet-another-FUSSP". It's about avoiding bounces to spoofed Return-Paths, and maybe offer a base for FQDN-reputation systems with HELO-PASS (same idea as CSV-CSA). So the design goals of v=spf1 and PRA are already different, no surprise that many resulting policies are also different. > Nobody has ever demonstrated a conflict as far as I am > concerned, all attempts to allege a conflict begin, "the > sender intends" which is utterly irrelevant. That's not true, this has been proven numerous times. PRA and MAIL FROM identity can be different for various valid reasons. 2476bis 6.1 and 2476bis 8.1 are different chapters. v=spf1 is in the spirit of 2476 6.1, RfC 3834, STD 10, and draft-hutzler. It has nothing to do with 2822-identities, 2476bis 8.1, or PRA. Essentially PRA wants "SHOULD add Sender" where 2476 only says "MAY add Sender" in 8.1. We could discuss this, and in fact "we" (TINW) did, see also: That's in the same thread mentioned before (started in mxcomp): http://news.gmane.org/group/gmane.mail.spam.spf.discuss/thread=8111 > Sender-ID simply describes one means of interpreting an SPF > record. It may or may not work, it may or may not be optimal If you want "sub-optimal" bogus interpretations then that's your personal right as receiver, but the IETF (mis)represented by the IESG should not sanction this abuse as RfC. You can't publish an RfC where you say "if no MX works just try A", because that would be broken and cause harm. RfCs are not supposed to cause foreseeable harm intentionally - as the very minimum they'd need corresponding security considerations. > that is why it is an experiment. The experimental status of v=spf1 is fictitious and beside the point. The author proposed "PS" with a proper IETF last call. > I do not believe that one group should be able to block a > proposal they do not like by alleging a non-existent conflict Nobody proposed to "block" PRA. It should only stay away from sender policies designed for the incompatible v=spf1. There's nothing wrong with PRA-experiments using spf2-0/pra policies. While I guess that PRA will fail miserably I've no problem if others wish to paricipante in this PRA-experiment. But (not only) I don't want this. No experiments with non-voluntary participants. We're talking about legit mails lost in limbo, and spectacular pseudo-PRA-PASS phishing opportunities. Bye From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 19:44:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nsW-00007n-8N for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 19:44:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01617 for ; Fri, 26 Aug 2005 19:44:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QNKVJQ069760; Fri, 26 Aug 2005 16:20:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QNKVMI069759; Fri, 26 Aug 2005 16:20:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QNKU1B069751 for ; Fri, 26 Aug 2005 16:20:30 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j7QNKJZb017752; Fri, 26 Aug 2005 16:20:19 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j7QNKEh5017749; Fri, 26 Aug 2005 16:20:18 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 26 Aug 2005 16:20:14 -0700 (PDT) From: "william(at)elan.net" To: "Hallam-Baker, Phillip" cc: ietf@ietf.org, MARID , spf-discuss@v2.listbox.com Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 In-Reply-To: <198A730C2044DE4A96749D13E167AD375A2AC2@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: References: <198A730C2044DE4A96749D13E167AD375A2AC2@MOU1WNEXMB04.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 26 Aug 2005, Hallam-Baker, Phillip wrote: > As has recently been pointed out on the namedroppers list, the dual > track RR and TXT approach does not work. It leads to ambiguities when > the records do not match - which they will inevitably dur to the DNS > protocol. Actually what has been pointed out is that it is incorrect to make it a permanent error if the client when retrieving both RRs checks if they are the same and finds they are not because in some cases due to DNS caching the results would not be consistent even if on the server side it is (only a problem when record was recently updated). That does not mean you can't make it part of the spec that if both RRs are published they MUST be the same and that client should check SPF (type99) RR and if its not present then look for TXT RR. For those clients where algorithm like that is considered too slow (i.e. spamassasin which does all dns queries in parallel), then it will have to be that if SPF RR is received, its data is to be used (no matter if TXT RR as present or not). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 19:53:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8o0k-0001nd-GB for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 19:53:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01826 for ; Fri, 26 Aug 2005 19:53:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QNUwMq070506; Fri, 26 Aug 2005 16:30:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QNUwKR070505; Fri, 26 Aug 2005 16:30:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QNUvZV070498 for ; Fri, 26 Aug 2005 16:30:57 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8nel-0004AV-PZ for ietf-mxcomp@imc.org; Sat, 27 Aug 2005 01:30:43 +0200 Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 01:30:43 +0200 Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 01:30:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Sat, 27 Aug 2005 01:26:24 +0200 Organization: Lines: 38 Message-ID: <430FA520.2EAB@xyzzy.claranet.de> References: <198A730C2044DE4A96749D13E167AD375A2AB8@MOU1WNEXMB04.vcorp.ad.vrsn.com> <7ae58c22050826112058b14708@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.221 X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com, ietf@ietf.org Cc: spf-discuss@v2.listbox.com, ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dotzero wrote: > Writing a standard which subverts the intent of individuals > publishing to a different and existing standard is simply > unethical and wrong. +1 > What happened was essentially a political move because people > chose not to publish SPF2 records for PRA. So, the response > was to force people to opt-out (publish an essentially > meaningless SPF2 record) because the SID camp was losing in > the real world marketplace. +1 > One argument that was put forth after the announcement that > SID would apply PRA to SPF1 records was that it was a > conspiracy to get publishers to yank their SPF1 records. Yes, when I said "excessive technical incompotence or outright corruption" it wasn't the polite way to put it, but it was and still is how I feel about it. > People and organizations chose to publish a record according > to a standard because they have a reasonable expectation on > how that record will be used. While there may be edge cases > of abuse, the expectation is that most people will respect > the standard. That's why it's called a standard. +1 > "Your honor, I have this alternative means of interpreting > what a red stoplight indicates.....go go go as fast as you > can". LOL, precisely. Full ACK on all your points, bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 21:02:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8p5u-0008Qt-9z for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 21:02:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04261 for ; Fri, 26 Aug 2005 21:02:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R0dELQ076732; Fri, 26 Aug 2005 17:39:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R0dEri076731; Fri, 26 Aug 2005 17:39:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R0dEeL076725 for ; Fri, 26 Aug 2005 17:39:14 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [10.2.164.130] (SJC-Office-NAT-244.Mail-Abuse.ORG [168.61.10.244]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j7R0ctHt030459 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 26 Aug 2005 17:38:59 -0700 In-Reply-To: References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> <6503D26C-DB8E-404D-8D8F-5087F64A9119@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: IETF MARID WG , ietf@ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 17:38:52 -0700 To: wayne X-Mailer: Apple Mail (2.734) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2005, at 12:56 PM, wayne wrote: > > In <6503D26C-DB8E-404D-8D8F-5087F64A9119@mail-abuse.org> Douglas > Otis writes: > > >> If the goal of the SPF Classic draft was intended to capture a point >> in time pre-dating semantic extensions related to RFC-2822 defined >> content, then perhaps the draft should be on an historic track. ; ) >> > > RFC2026 says: > > 4.2.4 Historic > > A specification that has been superseded by a more recent > specification or is for any other reason considered to be > obsolete is > assigned to the "Historic" level. [...] > > This wouldn't apply because there are no newer specifications for SPF, > nor is it obsolete. My apologies for this poor attempt at humor. With the authors insisting the draft only documents prior art that is now in conflict, it becomes difficult to consider this draft as experimental. With an experimental draft, one would expect modifications addressing issues as they arise. This record conflict has been a problem for a long time. If this draft is really only for historical purposes, perhaps SPF Classic should dropped. Sender-ID would then need to introduce a different draft defining the syntax related to the DNS records. > >> SPF Classic has not achieved the goal of capturing a pristine version >> of pre-MARID semantics. With some semantic changes introduced by the >> SPF Classic draft itself, [...] >> > > There isn't a "pristine" version of SPF, there are several different > draft specifications and a whole bunch of implementation. There are, > unfortunately, conflicts between these. The SPF-classic I-D attempts > to document the most coherent intersection of these. The reduction in processing limitations seemed substantial with understandable reasons. There was a change that including HELO in parallel with the MAIL FROM rather than when the MAIL FROM was NULL. A number of other changes have since been struck. Problems created when modifying record processing or what identifies are applied could be ameliorated through use of record versioning. This would ensure the server understood how to utilize the record being offered. While I agree with the view that PRA semantics may create problems when applied against the initial record version, the Sender-ID draft permits the use of a scoped version of the record which makes it clear what semantics are expected. Accommodating this identical provision within SPF would have resolved the potential Sender-ID conflict and also would have been a means to acknowledge adherence to newer processing limits and HELO checking, for example. Sender-ID does not define the syntax of the record, but instead depends upon the SPF draft for these definitions. It would appear the Sender-ID draft is willing to follow the syntax defined by the SPF draft. The major difference is that Sender-ID accommodates both versions of the record, whereas, despite the reasons, SPF has deliberately elected not to support the scoped version. This difference relates to a prefix of "v=spf1 ..." versus "spf2.0/ , ..." > While I'm sure that the SPF-classic I-D can be improved, I think it > has done a good job of meeting the goal of documenting SPF, as it > existed pre-MARID. I understand this is the justification used for the draft then ignoring the scoping problem. : ( Solutions: a) Sender-ID avoids applying any RFC-2822 content semantics to the initial DNS record version. b) SPF incorporates support for a scoped version of the DNS record. c) a & b d) Drop SPF Classic and create a separate syntax document. The number of domains publishing the initial version of the DNS records negatively affected is likely less than those that benefit. By itself, SPF is not without its own significant issues. Even Hotmail publishes just the initial record version, but depends upon the PRA. It would seem that while the SPF effort claims guardianship, they have been guilty of versioning abuses as well. Although option b is not perfect, it is good enough. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 23:07:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8r2o-0002RF-7c for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 23:07:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07962 for ; Fri, 26 Aug 2005 23:07:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R2fm7W086073; Fri, 26 Aug 2005 19:41:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R2fm8O086071; Fri, 26 Aug 2005 19:41:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R2flOO086063 for ; Fri, 26 Aug 2005 19:41:47 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8qcc-0003mi-Cu for ietf-mxcomp@imc.org; Sat, 27 Aug 2005 04:40:42 +0200 Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 04:40:42 +0200 Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 04:40:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Sat, 27 Aug 2005 03:53:43 +0200 Organization: Lines: 34 Message-ID: <430FC7A7.6311@xyzzy.claranet.de> References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.221 X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com, ietf@ietf.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > I stated that the SPF and Sender ID experiments should not > use the v=spf1 records to avoid conflict. Yes, you are a prominent part of this "embrace and extend" strategy also known as "steal or destroy". > if you (the author of the document) do not consider this to > be an experiment, then perhaps the IETF should not publish > SPF as an Experimental RFC. Perhaps the IETF should choose its leadership more carefully. It didn't work, this trick to get rid of the critical "NOT RECOMMENDED" in draft-schlitt by a note to the RfC editor. It didn't work, this trick to close MARID when it was clear that abusing v=spf1 for PRA is a non-starter. Hopefully it also won't work by the infamous "SHOULD abuse v=spf1" in senderid-core-01. The persons listed on... http://www.ietf.org/u/ietfchair/dea-directorate.html as well as all "no objections" on http://tinyurl.com/ayaun will have a hard time to redeem themselves in my eyes, and so far only one managed this. When Keith said here that all this was only an error, not intentional, I fear that isn't the case for some of these persons. No paseran From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 23:40:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8rYW-0003vd-PI for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 23:40:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09062 for ; Fri, 26 Aug 2005 23:40:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R3Da4p091217; Fri, 26 Aug 2005 20:13:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R3Dakk091216; Fri, 26 Aug 2005 20:13:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts20-srv.bellnexxia.net (tomts20.bellnexxia.net [209.226.175.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R3DZHs091205 for ; Fri, 26 Aug 2005 20:13:35 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.94.158.46]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050827031334.KMZE26550.tomts20-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 26 Aug 2005 23:13:34 -0400 X-IMBH: Yes From: "John Glube" To: Cc: Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 23:15:32 -0400 Message-ID: <000901c5aab5$962903c0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <198A730C2044DE4A96749D13E167AD375A2ABF@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit |-----Original Message----- |From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-|mxcomp@mail.imc.org] On Behalf Of Hallam-Baker, Phillip |Sent: August 26, 2005 3:44 PM |To: wayne; ietf@ietf.org |Cc: ietf-mxcomp@imc.org; spf-discuss@v2.listbox.com |Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 |inconflictwith referenced draft-schlitt-spf-classic-02 | |The only relevant boundary is between what the sender |controls and what they do not. All that any sender, |forwarder or any other mail injector can ever be expected |to do is to define the boundaries of the systems they |control. | |Once that boundary is defined the definition is fair game |for any party to use to interpret it to meet their |operational needs. I have a real problem with this last position. The underlying thrust behind sender authentication is to establish a framework for use by certification and reputation services, both external and internal to facilitate the delivery of ham, while rejecting spam. [1] A sender publishes a policy record based on a protocol in anticipation that recipient networks will use that record in accordance with that protocol. If recipient networks are going to use the sender's policy record for any purpose, whether in accord with the stated protocol or otherwise, then senders are better of not publishing a policy record. Otherwise, senders run the risk that the record will be misused and result in legitimate, requested and in some cases necessary mail not being delivered. As to the appeal, in my mind having reviewed both protocols with great care, we need to ask, what is "the conflict?" * Draft-schlitt-spf-classic-02 says in essence that we do not recommend receivers use spfv1 records for any use other than that set out in this protocol. * Draft-lyon-senderid-core-01 says in essence that receivers can use v=spf1 records for PRA authentication. It further advises senders to check whether their v=spf1 records can be used for this purpose and if not to publish the appropriate spf2.0 record. "The conflict" apparently is that the Schlitt draft recommends against use of spfv1 records for use with PRA authentication, while the Lyon draft says that receivers can use the spfv1 records for use with PRA authentication and therefore senders need to ensure their spfv1 records are suitable for this purpose. How did this conflict arise? It arose after the closure of MARID and prior to the filing of senderid-core-00. Let's remember the scene. The open source community was up in arms over the IPR disclosure by Microsoft. At the same time America Online had publicly withdrawn its support for Sender-ID due to the lack of backward compatibility between spf2.0 and spf1. Mr. Wong, over the strong objections of many within the SPF community, went ahead and negotiated an arrangement that allowed for the backward compatibility of PRA authentication with spfv1 records. [2] Further to this arrangement: * The Lentczner draft for spfv1, which only supported mail from authentication and the Lyon draft for spf2, which supported both mail from and PRA authentication were filed with the IESG. * Both drafts flowed from MARID. * The Lyon draft supported backward compatibility and in response America Online announced its continued support for Sender ID. * Microsoft published an SPF wizard which supported the publication of spfv1 records, subject to the need of publishers to be satisfied their spfv1 records could be used for both mail from and PRA authentication. Shortly afterwards, due in large measure to the anger and upset over Mr. Wong's management of the relationship with Microsoft and the resulting failure to fully separate the Sender Policy Framework from Sender ID after the collapse of MARID, the SPF Community elected a Council to run the affairs of the SPF Community. In accord with its mandate, the Council proceeded to withdraw the Lentczner draft from the IESG and substitute in its place the Schlitt draft. The IESG was now faced with a situation where the Lyon draft, which had relied upon the Lentczner draft, both of which flowed out of MARD, was now relying on the Schlitt draft for its underpinning. In turn the Schlitt draft re-introduced helo authentication based on historical usage and contains the recommendation which conflicts with the backward compatibility arrangement in the Lyon draft. [3] Since neither side was prepared to budge, the IESG ultimately allowed both drafts to proceed forward as experiments, with very strong disclaimers. Now the IESG is faced with an appeal from its decision to allow publication of the Lyon draft based on the conflict with the Schlitt draft. What to do? The appellant could withdraw his appeal and allow "sleeping dogs to lie where they are." However, if the appellant persists, which seems likely, then given the historical background, the IESG should: * Withdraw approval for both the Lyon and Schlitt drafts; and * Call upon the authors of the respective drafts to reconcile their differences at which time both drafts can proceed to be published as experimental drafts. In turn, if a negotiated settlement can't be reached within a suitable time frame, the IESG could decide to call upon the authors of the Schlitt and Lyon drafts to re-file their documents as informational RFCs only, merely documenting matters for historical purposes, which the IESG could then approve for publication. This stance places a hammer over the heads of both sides to settle matters and if not, to bring the experiments to an end as being "ill starred" at least in the IESG's eyes. John Glube Toronto, Canada [1] The Federal Trade Commission supports "e-mail authentication" in the belief that this will make it easier to track down the bad guys. This position is based on the view that the technical community can develop a protocol which will receive wide spread acceptance and so necessitate its use if senders wish to have their mail delivered. In my view, the reality is that network security is the key technical umbrella. This umbrella can provide cover for the appropriate cultural framework, especially within the marketing and user community. In turn, this cultural backdrop can then support the appropriate legislative framework, which in turn supports the necessary technical, legal and cultural drive to bring "the various problems" under control. The problem? The necessary cultural and legislative framework is absent from the mix, so leaving gaping holes in the technical umbrella. In saying this I acknowledge a strong bias against the existing legislative framework, which I believe makes any real solution unlikely. But that is a different debate. As to e-mail authentication, this only supports one part of a potential technical solution of how to deal with e-mail after it is sent. What role can SPF and Sender ID realistically play in this process? I simply reference the MAAWG white paper released on July 8, 2005: [2] At the time that Mr. Wong was negotiating the arrangements with America Online and Microsoft, I was in strong opposition. In my view, if pressed, Microsoft would have been prepared to amend its IPR and re-write its license to meet the concerns raised during MARID, in exchange for access to the existing base of spfv1 records through the concept of backward compatibility, rather than allow Sender ID to die. The present situation, given the appeal to the IESG, potentially creates the same opportunity, if one believes there is merit in saving this particular experiment. [3] In my view, the IESG should have rejected both the Schlitt and Lyons drafts as experimental RFCs, because they did not flow from MARID. The Schlitt draft documents an historical reality as opposed to supporting an e-mail authentication experiment, claiming that all the work which needs to be done has been done. The Lyons draft puts forward the concept of backward compatibility, while the work done during MARID indicated that this was the wrong approach. As a result both drafts were arguably outside of the stipulated process for filing experimental protocols as called for when MARID closed. Having said this, I understand the political desire to utilize the existing record base of spfv1 records to support the experiment. However once the "arrangement" was rejected by the SPF Community by withdrawing the Lentczner draft and filing the Schlitt draft, the IESG response should have been to reject both the Schlitt and Lyon drafts and require the parties to work in accord with the stipulated process based on the work done during MARID. From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 23:44:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8rcW-0005Im-1i for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 23:44:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09373 for ; Fri, 26 Aug 2005 23:44:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R3LQkr092043; Fri, 26 Aug 2005 20:21:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R3LQ8s092042; Fri, 26 Aug 2005 20:21:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R3LOVY092036 for ; Fri, 26 Aug 2005 20:21:25 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8rFK-0001Eo-S4 for ietf-mxcomp@imc.org; Sat, 27 Aug 2005 05:20:42 +0200 Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 05:20:42 +0200 Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 05:20:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Sat, 27 Aug 2005 05:02:57 +0200 Organization: Lines: 36 Message-ID: <430FD7E1.738@xyzzy.claranet.de> References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.221 X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com, ietf@ietf.org Cc: spf-discuss@v2.listbox.com, ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > Informational might also be appropriate. Not from my POV, I wanted this beast under IETF control. That's why I pushed for an RfC, and later after reading the "fine print" 2026 for standards track. "Informational" is something the authors could update whenever it pleases them. There was no SPF Council last year, "we" (TINW) trusted that the IETF and MARID would get it right. Okay, that failed spectacularly forcing "us" to create the SPF Council. I still prefer standards track, not some obscure one and a half standards SDO "SPF". The role model for "us" might be XMPP (not Phil's idea W3C, that's megalomaniac). > I still think Standard Track is most appropriate ACK. Now if the IESG thinks that something with less than one million participants covering roughly about 80% of AOL's inbound mails is an "experiment", then that's their choice, and we'll remind them of their own choice for each and every wannabe-PS with a smaller deployment. > I don't think it would be a productive use of time to > try and change the current Experimental designation. ACK. Better get a proper PS later, with interoperability reports, relevant "lessons learned", etc. - too late for DKIM, but still useful for other / later efforts trying to do wild and wonderful things with DNS. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Aug 26 23:47:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8rfb-00060h-A3 for marid-archive@megatron.ietf.org; Fri, 26 Aug 2005 23:47:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10206 for ; Fri, 26 Aug 2005 23:47:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R3PG1H092285; Fri, 26 Aug 2005 20:25:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R3PGLc092284; Fri, 26 Aug 2005 20:25:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R3PFZm092277 for ; Fri, 26 Aug 2005 20:25:15 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E8rIW-0001sY-Cv for ietf-mxcomp@imc.org; Sat, 27 Aug 2005 05:24:00 +0200 Received: from footbone.schlitt.net ([67.52.51.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 05:24:00 +0200 Received: from wayne by footbone.schlitt.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 05:24:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: wayne Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Fri, 26 Aug 2005 22:23:27 -0500 Lines: 79 Message-ID: References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> <6503D26C-DB8E-404D-8D8F-5087F64A9119@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: footbone.schlitt.net User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux) Cancel-Lock: sha1:L+zZBFFAYuRsXglvclQaF9j3fCg= Cc: ietf@ietf.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Douglas Otis writes: > On Aug 26, 2005, at 12:56 PM, wayne wrote: > >>> SPF Classic has not achieved the goal of capturing a pristine version >>> of pre-MARID semantics. With some semantic changes introduced by the >>> SPF Classic draft itself, [...] >>> >> >> There isn't a "pristine" version of SPF, there are several different >> draft specifications and a whole bunch of implementation. There are, >> unfortunately, conflicts between these. The SPF-classic I-D attempts >> to document the most coherent intersection of these. > > > The reduction in processing limitations seemed substantial with > understandable reasons. The reduced process limits has existed dating back to Feb 23, 2004 in the libspf-alt implementation. It was picked up later (still pre-MARID) by at least one other SPF implementation. > There was a change that including HELO in > parallel with the MAIL FROM rather than when the MAIL FROM was NULL. Independent HELO checking was argued for since the summer of 2003. The Spamassassin development version was doing HELO checking in the Dec 2003 or Jan 2004, I'm not sure which. The change in the spec dates back to May 16 2004. While MARID was going on at that point, it was still before the MARID WG had adopted any drafts. In reality, this is an incredibly minor change because almost all MTAs send email with a null MAIL FROM every once and a while, so the HELO domain would be checked at least some of the time. Having it be checked all the time makes very little practical difference. > A number of other changes have since been struck. Yes, there were a HUGE number of incompatible changes made during the MARID process and, in hind sight, starting with the MARID drafts and trying to make it compatible was probably a mistake. However, we did try to eliminate as many changes as we could find. > Problems created > when modifying record processing or what identifies are applied could > be ameliorated through use of record versioning. Maybe, but the implementations that did the processing limits were deployed in early 2004, so unless you have a time machine, we are pretty much stuck with them now. > While I agree with the view that PRA semantics may create problems s/may/will/ > when applied against the initial record version, the Sender-ID draft > permits the use of a scoped version of the record which makes it > clear what semantics are expected. Our goal in writing the spf-classic draft was to document what is and was, not to create something new. The job of creating something new was given by Ted Hardie to the MARID authors. > Accommodating this identical > provision within SPF would have resolved the potential Sender-ID > conflict and also would have been a means to acknowledge adherence to > newer processing limits and HELO checking, for example. The SenderID drafts have never contained the HELO identity. This makes it not fully backwards compatible with SPF-classic. The SenderID drafts are not under our control, so we can't fix it. -wayne From owner-ietf-mxcomp@mail.imc.org Sat Aug 27 00:44:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8sY2-0005En-5Z for marid-archive@megatron.ietf.org; Sat, 27 Aug 2005 00:44:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11885 for ; Sat, 27 Aug 2005 00:44:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R4LAPH097635; Fri, 26 Aug 2005 21:21:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R4LAnj097634; Fri, 26 Aug 2005 21:21:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R4L9XU097626 for ; Fri, 26 Aug 2005 21:21:09 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E8sBP-0003Z9-IS for ietf-mxcomp@imc.org; Sat, 27 Aug 2005 06:20:43 +0200 Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 06:20:43 +0200 Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 06:20:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 MARID Date: Sat, 27 Aug 2005 06:10:16 +0200 Organization: Lines: 11 Message-ID: <430FE7A8.644@xyzzy.claranet.de> References: <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <20050826131513.GA29797@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.221 X-Mailer: Mozilla 3.0 (OS/2; U) Cc: ietf@ietf.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > It is an absolutely incredible request since SPF uses these > records since its beginning (a long time before Sender-ID > existed) and since there is (unlike SenderID) actual > deployment, which can not be called back. SPF is also older than Caller-ID, a patented XML-over-DNS idea. JFTR, Frank From owner-ietf-mxcomp@mail.imc.org Sat Aug 27 01:31:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8tHR-0000n3-AV for marid-archive@megatron.ietf.org; Sat, 27 Aug 2005 01:31:01 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13333 for ; Sat, 27 Aug 2005 01:30:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R57SZT002719; Fri, 26 Aug 2005 22:07:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R57SP9002718; Fri, 26 Aug 2005 22:07:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R57R2Z002697 for ; Fri, 26 Aug 2005 22:07:28 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 920C916CCA for ; Sat, 27 Aug 2005 01:08:44 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 In-Reply-To: Your message of "Sat, 27 Aug 2005 05:02:57 +0200." <430FD7E1.738@xyzzy.claranet.de> Date: Sat, 27 Aug 2005 01:08:44 -0400 Message-Id: <20050827050844.920C916CCA@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann wrote: > Not from my POV, I wanted this beast under IETF control. Why? The concerns you expressed in your previous message about the IETF leadership and methods were serious. How do you believe you can move forward, given your concerns? Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Aug 27 02:12:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8tve-0004KB-8t for marid-archive@megatron.ietf.org; Sat, 27 Aug 2005 02:12:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26407 for ; Sat, 27 Aug 2005 02:12:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R5kTES019849; Fri, 26 Aug 2005 22:46:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R5kTXj019848; Fri, 26 Aug 2005 22:46:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7R5kSdk019833 for ; Fri, 26 Aug 2005 22:46:28 -0700 (PDT) (envelope-from scott@kitterman.com) Message-Id: <200508270546.j7R5kSdk019833@above.proper.com> Received: (qmail 51647 invoked from network); 27 Aug 2005 05:46:20 -0000 Received: from unknown (HELO ?70.201.193.250?) (unknown) by unknown with SMTP; 27 Aug 2005 05:46:20 -0000 X-pair-Authenticated: 70.201.193.250 Mime-Version: 1.0 X-Mailer: SnapperMail 1.9.5.01 by Snapperfish, www.snappermail.com To: Cc: Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflict with referenced draft-schlitt-spf-classic-02 From: Scott Kitterman Date: Sat, 27 Aug 2005 1:45 -0400 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ...... Original Message ....... On Fri, 26 Aug 2005 23:15:32 -0400 "John Glube" wrote: >"The conflict" apparently is that the Schlitt draft >recommends against use of spfv1 records for use with PRA >authentication, while the Lyon draft says that receivers >can use the spfv1 records for use with PRA authentication >and therefore senders need to ensure their spfv1 records >are suitable for this purpose. I think this misses the essentiatpoint. There is an installed base of v=spf1 records published in some significant part before MARID. Those records were published with Mail From and HELO and only with Mail From and HELO in mind. The appeal is not just about what the Schlitt Draft (rightly) says. >How did this conflict arise? It arose after the closure of >MARID and prior to the filing of senderid-core-00. > >Let's remember the scene. The open source community was up >in arms over the IPR disclosure by Microsoft. At the same >time America Online had publicly withdrawn its support for >Sender-ID due to the lack of backward compatibility between >spf2.0 and spf1. > >Mr. Wong, over the strong objections of many within the SPF >community, went ahead and negotiated an arrangement that >allowed for the backward compatibility of PRA >authentication with spfv1 records. [2] > >Further to this arrangement: > >* The Lentczner draft for spfv1, which only supported mail >from authentication and the Lyon draft for spf2, which >supported both mail from and PRA authentication were filed >with the IESG. > >* Both drafts flowed from MARID. > >* The Lyon draft supported backward compatibility and in >response America Online announced its continued support for >Sender ID. > Thus conflicting with one of the few areas of MARID for which their was a rough consensus. This back room deal should not be allowed to overturn working group rough consensus. >* Microsoft published an SPF wizard which supported the >publication of spfv1 records, subject to the need of >publishers to be satisfied their spfv1 records could be >used for both mail from and PRA authentication. > >Shortly afterwards, due in large measure to the anger and >upset over Mr. Wong's management of the relationship with >Microsoft and the resulting failure to fully separate the >Sender Policy Framework from Sender ID after the collapse >of MARID, the SPF Community elected a Council to run the >affairs of the SPF Community. > >In accord with its mandate, the Council proceeded to >withdraw the Lentczner draft from the IESG and substitute in >its place the Schlitt draft. I agree it was regarded as a substitute. I don't think that was the intent. The intent was to document existing (pre-MARID) practice and give up on MARID as a good try gone bad. >The IESG was now faced with a situation where the Lyon >draft, which had relied upon the Lentczner draft, both of >which flowed out of MARD, was now relying on the Schlitt >draft for its underpinning. > Although it takes advantage of some lessons learned from MARID, the Schlitt draft is not a MARID product. It documents the results of roughly two years of independent protocol development, experimentation, and deployment. There are at least a dozen independent interoperable implementations in use today that result from these efforts. >In turn the Schlitt draft re-introduced helo authentication >based on historical usage and contains the recommendation >which conflicts with the backward compatibility arrangement >in the Lyon draft. [3] HELO checking has long been a part of SPF. The HELO identity was never addressed by MARID and so it's not surprising it wouldn't be in MARID drafts. >Since neither side was prepared to budge, the IESG >ultimately allowed both drafts to proceed forward as >experiments, with very strong disclaimers. > >Now the IESG is faced with an appeal from its decision to >allow publication of the Lyon draft based on the conflict >with the Schlitt draft. Based on the conflict with the intended usage of record publishers. There are reasons the Schlitt draft says what it does. I published v=spf1 records before the attempted merger of SPF and MS Caller-ID for E-Mail. I'm in a bit of a bind due to this decision. My DNS provider only supports one TXT record per domain name, so the proposed PRA opt-out is not an option for me. I participate in a number of mail lists. Some add a 2822-Sender. Some don't. Subscribers to mail lists that don't add the 2822-Sender whose providers check PRA will get a Fail for my e-mails. As it stands, I've got no way to stop this other than abandon SPF too. That doesn't seem right. >What to do? The appellant could withdraw his appeal and >allow "sleeping dogs to lie where they are." > >However, if the appellant persists, which seems likely, >then given the historical background, the IESG should: > >* Withdraw approval for both the Lyon and Schlitt drafts; >and > >* Call upon the authors of the respective drafts to >reconcile their differences at which time both drafts can >proceed to be published as experimental drafts. Please suggest a way this is possible that doesn't leave me forced to either suck up bogus PRA failures on mailing lists or abandon SPF. Despite suggestions by some, this is a technical issue, not a social issue. If my e-mail getting delivered weren't at risk, I wouldn't be staying up late writing this. Early in MARID I argued for record re-use, but during the discussions of the working group I became convinced it was a bad idea. >In turn, if a negotiated settlement can't be reached within >a suitable time frame, the IESG could decide to call upon >the authors of the Schlitt and Lyon drafts to re-file their >documents as informational RFCs only, merely documenting >matters for historical purposes, which the IESG could then >approve for publication. Given the extensive experimentation already concluded with SPF and the broad review given the Schlitt draft prior to submission, I think if both drafts are to be reconsidered, it would make more sense to publish the Schlitt draft as a standards track RFC and publish the Lyons draft (less the re-use of v=spf1 records) as an experiment built on top of it. >This stance places a hammer over the heads of both sides to >settle matters and if not, to bring the experiments to an >end as being "ill starred" at least in the IESG's eyes. > Without practical time travel, I'm not sure what there is to settle. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Sat Aug 27 07:44:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8z6x-0008Pq-DM for marid-archive@megatron.ietf.org; Sat, 27 Aug 2005 07:44:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09327 for ; Sat, 27 Aug 2005 07:44:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7RBKLde046554; Sat, 27 Aug 2005 04:20:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7RBKL33046553; Sat, 27 Aug 2005 04:20:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7RBKJX5046535 for ; Sat, 27 Aug 2005 04:20:19 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E8yiG-0007S5-Qt for ietf-mxcomp@imc.org; Sat, 27 Aug 2005 13:19:04 +0200 Received: from 62.80.58.221 ([62.80.58.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 13:19:04 +0200 Received: from nobody by 62.80.58.221 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Aug 2005 13:19:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Sat, 27 Aug 2005 13:17:45 +0200 Organization: Lines: 29 Message-ID: <43104BD9.49E1@xyzzy.claranet.de> References: <430FD7E1.738@xyzzy.claranet.de> <20050827050844.920C916CCA@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.221 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan DeKok wrote: >> Not from my POV, I wanted this beast under IETF control. > Why? Because Meng and the SPF community as it was before MARID produced at least three ideas how to change the spec. per hour, and that made me very nervous. With a reason, Meng manouvered himself in a very awkward position, after all he's the co-author of both drafts in the subject. He claims that it's sitting on a fence, but actually it's barbed wire. > The concerns you expressed in your previous message about > the IETF leadership and methods were serious. Some of them, not all of them. It's a test, interesting for anybody volunteering time for the IETF if it turns out to be "directorated" by the commercial interests of some big players. > How do you believe you can move forward, given your > concerns? Julian proposed a simple remedy, it could be even shorter, delete four letters in chapter 3.4 of senderid-core. Bye. From owner-ietf-mxcomp@mail.imc.org Sat Aug 27 14:50:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E95lX-0000p3-Uk for marid-archive@megatron.ietf.org; Sat, 27 Aug 2005 14:50:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24167 for ; Sat, 27 Aug 2005 14:50:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7RIM6vD024787; Sat, 27 Aug 2005 11:22:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7RIM6dw024786; Sat, 27 Aug 2005 11:22:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from triagewireless.com (c-064-186-224-138.sd2.redwire.net [64.186.224.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7RIM4DL024773 for ; Sat, 27 Aug 2005 11:22:04 -0700 (PDT) (envelope-from tom@triagewireless.com) Received: from [66.27.68.108] (helo=horatio) by triagewireless.com with esmtp (Exim 3.35 #1 (Debian)) id 1E94Ez-0000WB-00; Sat, 27 Aug 2005 10:13:13 -0700 From: "Thomas Gal" To: "'Frank Ellermann'" , Cc: Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 MARID Date: Sat, 27 Aug 2005 11:21:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <430FE7A8.644@xyzzy.claranet.de> Thread-Index: AcWqtD6KfenfJGHKTSqMKDNV95SKzgAeUcsA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Message-Id: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Well clearly IANA won't accept 2 differing registrations that overlap on this matter. Certainly it is the IETF/IESG/IAB's job to rectify that incongruity? If the two proposals cannot come to a resolution regarding the differing interpretations of the DNS records then clearly they must be required to use different/non-overlapping syntax. For the IESG to say "Change your records to v=senderid or something that doesn't conflict with this other previously printed document and large number of installations or we can't really distribute this document" makes perfect sense. Certainly, though everyone may not agree on the solution, we agrees that publishing both unchanged seems silly(using common sense not procedure for a moment)? Certainly not publishing either seems to make more sense than publishing both. If these documents are distributed elsewhere and conflicting that's one thing (beccause they'll be read no matter which forum they are distributed through), but if we distribute them without anything close to rough consensus on the acceptability of this conflict between documents (which I don't think we have) then what has anyone accomplished? Have we followed the spirit of our rules (rough consensus and working code) if it's clear that it's NOT POSSIBLE to have working code because the proposals are mutually exclusive? I'm not going to try to harp on IPR, or the end of the IETF, or industry blah blah regarding this decision, but this decision seems important, so iresspective of all the other things involved, I think it's important that a good decision is made on this matter. No consensus and non possiblity for working code. I would be interested in polling to know how people feel on these 2 matters: (1) This draft should not be published by the IETF due, at LEAST due to the fundamental conflict with SPF, which makes running code impossible. Even a split on this issue will indicate lack of consensus for publishing this document. (2) The document should either: a. be published elsewhere if consistency (i.e. no changes) is paramount b. the conflict should be resolved (most useful, least likely based on history) c. the syntax should be changed by the RFC editor (or author) which will essentially also resolve the conflict, make the documents consistent, and not sacrafice IETF principles. -Tom -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Frank Ellermann Sent: Friday, August 26, 2005 9:10 PM To: ietf@ietf.org Cc: ietf-mxcomp@imc.org Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 MARID Stephane Bortzmeyer wrote: > It is an absolutely incredible request since SPF uses these records > since its beginning (a long time before Sender-ID > existed) and since there is (unlike SenderID) actual deployment, which > can not be called back. SPF is also older than Caller-ID, a patented XML-over-DNS idea. JFTR, Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From owner-ietf-mxcomp@mail.imc.org Sat Aug 27 15:28:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E96M1-0000Zk-JA for marid-archive@megatron.ietf.org; Sat, 27 Aug 2005 15:28:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26769 for ; Sat, 27 Aug 2005 15:28:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7RJ0fKk026915; Sat, 27 Aug 2005 12:00:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7RJ0fNU026914; Sat, 27 Aug 2005 12:00:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7RJ0b6R026905 for ; Sat, 27 Aug 2005 12:00:37 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j7RJ0XAJ001761; Sat, 27 Aug 2005 12:00:34 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j7RJ0UwC001757; Sat, 27 Aug 2005 12:00:33 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 27 Aug 2005 12:00:30 -0700 (PDT) From: "william(at)elan.net" To: John Glube cc: ietf@ietf.org, ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 In-Reply-To: <000901c5aab5$962903c0$6c62fea9@ibmrkydk2ufvdd> Message-ID: References: <000901c5aab5$962903c0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 26 Aug 2005, John Glube wrote: > |The only relevant boundary is between what the sender > |controls and what they do not. All that any sender, > |forwarder or any other mail injector can ever be expected > |to do is to define the boundaries of the systems they > |control. > | > |Once that boundary is defined the definition is fair game > |for any party to use to interpret it to meet their > |operational needs. > > I have a real problem with this last position. > > The underlying thrust behind sender authentication is to > establish a framework for use by certification and > reputation services, both external and internal to > facilitate the delivery of ham, while rejecting spam. [1] With such a statement you're making an assumption that the technology (i.e. SPF and SID) is only good for sender authentication and anti-spam. This is a common mistake, especially in regards to SPF, and is largely due to how the technology has been marketed by many. But it is all not technically correct as SPF aims at stopping spoofing of RFC2821 MAILFROM address and to prevent backcuster of delivery failure messages when address is misused. Also what is true about SPF may not be true about SID and as they operate on different identities you're bound to see problems if incorrect record is used. > A sender publishes a policy record based on a protocol in > anticipation that recipient networks will use that record > in accordance with that protocol. Correct. And with two conflicting specifications it is difficult to understand what the intent of the sender is. This is a problem for both SID and SPF protocols and unless resolved it discourages participation of users in these experiments and thus IETF would be enable to get true results about usability of the technology. [skip] > "The conflict" apparently is that the Schlitt draft > recommends against use of spfv1 records for use with PRA > authentication, while the Lyon draft says that receivers > can use the spfv1 records for use with PRA authentication > and therefore senders need to ensure their spfv1 records > are suitable for this purpose. > > How did this conflict arise? It arose after the closure of > MARID and prior to the filing of senderid-core-00. > > Let's remember the scene. The open source community was up > in arms over the IPR disclosure by Microsoft. The IPR disclosure's problem was not actually IPR limited text itself, the main problem was how it happened and that many (I'll go as far as to say majority of individual participants at MARID) lost trust in Microsoft especially after the disclosure of their overreaching patent applications. It is really failure of Microsoft to be able to play fair and work together with open-source and similar communities even when both sides were willing to try for common good (and the technical people from Microsoft participating at MARID were not at all responsible for it, they were victims of the decisions made quite deep at their company). Further work of the WG would have been very difficult with two sides not being able to easily talk to each other (which would make it difficult to come to consensus, although if given time to cool down it could have been possible, but you can see this difficulty even now with SPF and SID drafts). > At the same time America Online had publicly withdrawn its support > for Sender-ID due to the lack of backward compatibility between > spf2.0 and spf1. I don't think it was the reason. They knew about luck of backwards compatibility even before and did not say anything. I'll go as far as to say that somebody asked AOL to temporary withdraw support and they were willing to play along. > Mr. Wong, over the strong objections of many within the SPF > community, went ahead and negotiated an arrangement that > allowed for the backward compatibility of PRA > authentication with spfv1 records. [2] The problem is that Meng never understood about real causes for failure of MARID as I tried to describe above and did not understand concerns of those who actually created SPF (he was editor of the original draft and "managed" the group but not really author of the technology which came together based on work of individual participants at spf-discuss), he assumed himself to be appropriate representative of open-source-like group that created SPF and that he could on their behalf continue to talk and work further with MS to create common standard as MS wanted from MARID, but in the way he did it, he just showed further where MARID was failing and why it was appropriate for work to now be done on two *separate* "experiments" as IETF asked. The result is that there was a lot of outrage at the spf-discuss in October/November 2004 when new individual submission SID draft came out with reuse of v=spf1 records and consequently Meng was removed from being person responsible for representing views of SPF and replaced with group of people (SPF Council), plus primary editor of the SPF documents was also replaced. This was not unexpected if one could understand what happened at MARID. > Further to this arrangement: > > * The Lentczner draft for spfv1, which only supported mail > from authentication and the Lyon draft for spf2, which > supported both mail from and PRA authentication were filed > with the IESG. > > * Both drafts flowed from MARID. Partially true (drafts did "flow" from MARID, but there were already significant differences then the actual MARID drafts). And as far as Mark Lentczner's spf draft it was already partly in the way SPF community wanted as far as documenting real v=spf1, but he was just not willing to take it further (probably also did not understand what happened at MARID and wanted to continue that work largely as is, plus he probably knew about agreements Meng was at the same time making behind the scenes with MS and AOL). > * The Lyon draft supported backward compatibility and in > response America Online announced its continued support for > Sender ID. It would be nice to know what happened behind the scenes. In fact it what you see here is an example of why IETF standardization work should be done in public instead of private. > * Microsoft published an SPF wizard which supported the > publication of spfv1 records, subject to the need of > publishers to be satisfied their spfv1 records could be > used for both mail from and PRA authentication. > > Shortly afterwards, due in large measure to the anger and > upset over Mr. Wong's management of the relationship with > Microsoft and the resulting failure to fully separate the > Sender Policy Framework from Sender ID after the collapse > of MARID, the SPF Community elected a Council to run the > affairs of the SPF Community. > > In accord with its mandate, the Council proceeded to > withdraw the Lentczner draft from the IESG and substitute in > its place the Schlitt draft. See above, I think I explained more how this all really came about. > The IESG was now faced with a situation where the Lyon > draft, which had relied upon the Lentczner draft, both of > which flowed out of MARID, was now relying on the Schlitt > draft for its underpinning. Yes. And it is all result of that unfortunate attempt to "continue MARID" with spf1 taken by Meng instead of proceeding as me and several others originally expected as far as having v=spf1 documented first and then quickly move to SPF2 as separate document series based on MARID and proceeding further to UnifiedSPF (i.e. one common format for policy records with separate identities/scopes and how to interpret those identity records). That second document series would have been real successor to MARID but it did not happen. What you have now is that neither of the documents approved by IESG is really MARID documents and they really do need to be viewed as separate individual submissions and should be judged on their own merits. SPF draft is best attempt so far to document SPF protocol as it was developed prior to MARID (with only few things borrowed from MARID) draft-lyon-senderid and other SID documents should be viewed as separate private submission of proprietary Microsoft CID implementation which instead of original CID XML DNS record has now adapted SPF record syntax. And as separate submission made to IETF, it should also be responsibility of IESG that their proposal does not come into conflict with other LMAP proposed experiments and does not break any other IETF standards. > In turn the Schlitt draft re-introduced helo authentication > based on historical usage and contains the recommendation > which conflicts with the backward compatibility arrangement > in the Lyon draft. [3] Again, please understand that v=spf1 document does not represent MARID work perse - its separate submission documenting pre-MARID protocol slightly further developed and better documented (with that documenting being in part result of working at MARID). > Since neither side was prepared to budge, the IESG > ultimately allowed both drafts to proceed forward as > experiments, with very strong disclaimers. Yes, mistake on their part. > Now the IESG is faced with an appeal from its decision to > allow publication of the Lyon draft based on the conflict > with the Schlitt draft. I believe at this point the appeal is only to IETF chair and not to IESG. [An interesting situation BTW - because IESG as a whole made decision to proceed with drafts publication where as now only one person from IESG has opportunity to overrule them. For government-like structure this appears to show where IETF Chair has power of veto like President has over decisions of Congress, but President represents separate branch of government, where as in countries with parliamentary democracies the prime-minister typically can not overrule the parliament] > What to do? The appellant could withdraw his appeal and > allow "sleeping dogs to lie where they are." > > However, if the appellant persists, which seems likely, > then given the historical background, the IESG should: > > * Withdraw approval for both the Lyon and Schlitt drafts; > and That would not be appropriate. The appeal is only against SID draft (should have been against all 3 SID drafts actually - they can't be published separately). SPF draft should continue to be viewed as separate submission and decided on its own merit. So should (as individual submission on its own merit) be viewed whatever MS comes up with and certainly there should be no conflicts that arise from its when they want to reuse somebody else's record or fields - it should be done only in a way that effects are limited to those who agree to participate in their experiment. > * Call upon the authors of the respective drafts to > reconcile their differences at which time both drafts can > proceed to be published as experimental drafts. You can "call upon the authors" once again but it has been done before and it has not resulted in reconciliation so far. The conflict that became clear at the end of MARID is still there and so is inappropriate use of somebody else's work that MS is so famous for. > In turn, if a negotiated settlement can't be reached within > a suitable time frame, the IESG could decide to call upon > the authors of the Schlitt and Lyon drafts to re-file their > documents as informational RFCs only, merely documenting > matters for historical purposes, which the IESG could then > approve for publication. Even for informational purposes publishing conflicting specifications is not appropriate. There really is not much of a choice here - if IETF/IESG agrees there is a conflict, it must request one of the drafts to be withdrawn and fixed (and if author does not do it, IESG would have no choice but to block it from going further). Since its the SID draft that depends on SPF draft, the SID would have to be the one to be withdrawn (i.e. SID can't be published without SPF draft where as SPF draft can be published without SID). In separate post I'll show why its correct to withdraw SID draft for other reasons too. As far as MARID work IESG wanted, the correct thing is start working on SPF2/3 where we left off at MARID and create it as new series where all scopes are clearly separated. But what IESG really wanted was to experiment with these technologies (I doubt they cared as to particulars of the record syntax) and in fact SPF1 does in as far as providing way to see how RFC2821 MAIL FROM verification can be achieved. For MS the same could be achieved if they instead worked on further on original Caller-ID (or it could be achieved if they published real MARID in the way documents went to MARID at last-call in August with only spf2.0 used). [skip] > [2] At the time that Mr. Wong was negotiating the > arrangements with America Online and Microsoft, I was in > strong opposition. Most others as well and he did not understand that it was just make situation that brought end of MARID a lot worse which is exactly what happened. > In my view, if pressed, Microsoft would have been prepared > to amend its IPR and re-write its license to meet the > concerns raised during MARID, in exchange for access to the > existing base of spfv1 records through the concept of > backward compatibility, rather than allow Sender ID to die. I suspect we both know some of the things that were not made public and so I'll just note that happen to disagree. I do not believe Microsoft would have been able to do anything more - it really was not something that was up to the people who we were working with, they've done all they could on this matter and in fact said as much. > The present situation, given the appeal to the IESG, > potentially creates the same opportunity, if one believes > there is merit in saving this particular experiment. I do not believe it can happen now either and I think trying to negotiate would hit the same road-block as before and it would not be anything people seen as standing behind SID at MS (and thus involved in such negotiations) could do anything about. But if reuse of spf1 records is really realy the only way for MS and it wants to continue, then the only possibility for negotiation I see is to get it part the way for both sides. This would involve: 1. MS agrees to change its draft and only use positive results of SID verification on v=spf1 records (but not fail, softfail or results if record is absent) and that for negative results real SPF2.0 record would be needed. 2. SPF community agrees to soften v=spf1 draft and allow for use of positive results with other identities (I brought this up before and while some thought it was ok, others thought there are is too much potential for confusion and incorrect results even then - no way can we come to consensus unless its really part of negotiation and MS gives something else to make it worth it). 3. Both sides agree to work further on the next version of protocol that would have clear separation of scopes and core protocol document that both sides could then reuse [this would be real successor to MARID]. Both sides agree that once such new documents are ready, they will begin to promote this new version. --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sat Aug 27 21:02:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9BZR-0008Pq-Oa for marid-archive@megatron.ietf.org; Sat, 27 Aug 2005 21:02:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08891 for ; Sat, 27 Aug 2005 21:02:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S0ZbbB046021; Sat, 27 Aug 2005 17:35:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7S0ZbHT046020; Sat, 27 Aug 2005 17:35:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S0ZadB046014 for ; Sat, 27 Aug 2005 17:35:36 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j7S0ZIsJ006090 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 27 Aug 2005 17:35:19 -0700 Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 From: Douglas Otis To: "william(at)elan.net" Cc: ietf@ietf.org, ietf-mxcomp@imc.org In-Reply-To: References: <000901c5aab5$962903c0$6c62fea9@ibmrkydk2ufvdd> Content-Type: text/plain Date: Sat, 27 Aug 2005 17:35:18 -0700 Message-Id: <1125189318.25606.333.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2005-08-27 at 12:00 -0700, william(at)elan.net wrote: > But if reuse of spf1 records is really realy the only way for MS > and it wants to continue, then the only possibility for negotiation > I see is to get it part the way for both sides. This would involve: > 1. MS agrees to change its draft and only use positive results of > SID verification on v=spf1 records (but not fail, softfail or > results if record is absent) and that for negative results real > SPF2.0 record would be needed. This overlooks a problem related to abuse-feedback techniques accruing to "Sender-ID verified" identities. An erroneous positive verification based upon a PRA, unchecked by the sender perhaps due to licensing issues, could be a serious concern. These SPF records are public and outbound servers are often shared. Neither of the path registration schemes provide domain protection at shared servers. Even with MTA checks to mitigate domain spoofing at shared servers, these checks may also be limited by the same licensing issues. This retains a need to understand the assurances made by the sender with respect to the scope of the record, and is unrelated to how a failure is handled. Assume the miscreants will know what passes. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Aug 27 23:09:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9DXg-00085E-SG for marid-archive@megatron.ietf.org; Sat, 27 Aug 2005 23:09:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12368 for ; Sat, 27 Aug 2005 23:09:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S2fxC1052679; Sat, 27 Aug 2005 19:41:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7S2fx56052678; Sat, 27 Aug 2005 19:41:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S2fxPw052672 for ; Sat, 27 Aug 2005 19:41:59 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.94.158.46]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050828024158.BIGH21470.tomts22-srv.bellnexxia.net@ibmrkydk2ufvdd> for ; Sat, 27 Aug 2005 22:41:58 -0400 X-IMBH: Yes From: "John Glube" To: Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflict with referenced draft-schlitt-spf-classic-02 Date: Sat, 27 Aug 2005 22:43:52 -0400 Message-ID: <000001c5ab7a$53e87430$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <200508270546.j7R5kSdk019833@above.proper.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit |I think this misses the essentiatpoint. There is an |installed base of v=spf1 records published in some |significant part before MARID. Those records were |published with Mail From and HELO and only with Mail From |and HELO in mind. The appeal is not just about what the |Schlitt Draft (rightly) says. One of my fundamental difficulties with the whole discussion surrounding SPF/Sender ID is that proponents continually rely on an "installed base" as justification for refusing to change. What happened prior to MARID was pre-IETF. The exercise was an experiment. I can't speak for others, but when I published my record in June 2004, at the time I understood the discussion to be about mail from authentication and domain owners protecting their domains against spoof attacks. I also understood that SPF was an experiment and ultimately, I may have to change my record. Today, given what I know about the plusses and minuses of SPF as a result of significant and ongoing testing, I would have to say the reasons being put forward to encourage people to publish SPF records were at best wishful thinking. So, from my perspective, although I appreciate and respect the desire to support early adopters, when the whole issue of spfv1 and spf2.0 was reviewed during MARID, my understanding was that: * The included scopes within the SIDF were going to be MFROM and PRA; * It was decided to include both scopes in the SIDF protocol; and, * People would have to upgrade their existing records. Was I happy with this last decision? Not particularly and at the time, I quite frankly did not understand the need to proceed in that fashion. But, given the ongoing "troubles" as the Irish would say, I now believe those who advocated the need to move entirely to spf2.0 were correct. It certainly seems logical from an engineering perspective. Of course, spfv1 advocates would suggest that those who even dare suggest such an approach as a solution are ... well the idea is simply unspeakable and by even putting it forward, I have joined forces with the devil, or something worse. Since it seems evident from comments made to this list and elsewhere, that representatives of the SPF community wish to pursue the appeal and are not interested in negotiation, then speaking for myself, I ask that: * The IESG chair accept the appeal and based on the concerns raised request the IESG to review the decision to grant experimental status to what is commonly called SPF-Classic and Sender ID group of documents. * The IESG rescind the grant of experimental status to the SPF-Classic and Sender ID group of documents. * The IESG request the original authors for SPF being Messrs Wong, Lentczner, Katz and Lyon to re-submit drafts in accord with and subject to the conditions laid out in the request for individual submissions made after the MARID closure for experimental status. * As to the SPF-Classic draft, although this falls outside the scope of the conditions laid out in the request for individual submissions made after the MARID closure, since the IESG previously considered the document, the IESG invite the authors, Messrs Schlitt and Wong to resubmit this draft as an individual submission for experimental RFC status. * The IESG then based on the concerns raised in the appeal and such other concerns and circumstances as appropriate, treat the various submissions and make those decisions which it deems appropriate in the circumstances as to which if any drafts should be approved for publication as experimental or informational RFC status as appropriate. All that being said, I wish the parties and particularly the IESG chair all the best, as he endeavors to sort through this thorny mess. John Glube From owner-ietf-mxcomp@mail.imc.org Sat Aug 27 23:27:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Dox-0002zK-Ny for marid-archive@megatron.ietf.org; Sat, 27 Aug 2005 23:27:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12736 for ; Sat, 27 Aug 2005 23:26:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S31k8I055114; Sat, 27 Aug 2005 20:01:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7S31k2B055112; Sat, 27 Aug 2005 20:01:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S31i2u055093 for ; Sat, 27 Aug 2005 20:01:44 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E9DPN-0001GP-4n for ietf-mxcomp@imc.org; Sun, 28 Aug 2005 05:00:33 +0200 Received: from c-180-160-106.hh.dial.de.ignite.net ([62.180.160.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 05:00:33 +0200 Received: from nobody by c-180-160-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 05:00:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 Date: Sun, 28 Aug 2005 04:58:43 +0200 Organization: Lines: 161 Message-ID: <43112863.5226@xyzzy.claranet.de> References: <000901c5aab5$962903c0$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-106.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit william(at)elan.net wrote: > SPF aims at stopping spoofing of RFC2821 MAILFROM address > and to prevent backcuster of delivery failure messages when > address is misused. Yes. (I've reduced the X-posts to mxcomp - maybe a bad idea) > with two conflicting specifications it is difficult to > understand what the intent of the sender is. This is a > problem for both SID and SPF protocols and unless resolved > it discourages participation of users in these experiments Good point, unreliable results are also bad for PRA checks. > the technical people from Microsoft participating at MARID > were not at all responsible for it, they were victims of the > decisions made quite deep at their company IBTD, they are listed as "inventors" in the patent application . I doubt that this happened against their will - okay, with all this "opt-out" madness everything is possible, but for a patent the lawyers would try to avoid all formal problems. > difficult to come to consensus, although if given time to > cool down it could have been possible, but you can see this > difficulty even now with SPF and SID drafts The consensus to separate SPF from PRA, or rather MAIL FROM from PRA putting aside HELO for later, was IMHO very clear. When Mark was asked to create marid-mfrom-00 (and did within less than a week) I really thought that the WG would finally start to do something productive instead of XML-over-DNS, dubious 2822-PRA constructs, and IPR issues. But three days later it was closed. The first process failure in this saga, or rather the second, discussing CID / SID at all instead of the clean LMAP proposals was already desastrous: The ASRG is essentially dead since Yakov resigned, one day after CID was pushed on the LMAP stack as surprise-MARID-input. > he assumed himself to be appropriate representative of > open-source-like group that created SPF and that he could on > their behalf continue to talk and work further with MS Meng published "an apology for Sender-ID" as I-D, at this time he knew well that "unified SPF" did not represent the wishes of the community, He proposed v=marid as clean way to solve the "Olson objection". Not sure about others, but I accepted the latter. I never had a problem with the idea that those who _explicitly_ want it should get PRA, it's their mail. > It would be nice to know what happened behind the scenes. At least the MARID Jabber logs are public, the last two are: > what you see here is an example of why IETF standardization > work should be done in public instead of private. Tricky to get the WG Charter right. I'm still surprised that LTRU actually produced something, in that case it worked well. For DKIM I'm less confident. Maybe if Dave adopts some ideas from among others Doug and Earl - that false promises and hype are a trap should be clear after SPF, "we" cleaned the field by testing most errors. ;-) > they really do need to be viewed as separate individual > submissions and should be judged on their own merits. True. But there's nothing wrong with spf2.0 reusing the ABNF, protocol, error handling, processing limits, SPF RR, etc. of v=spf1. If they're lazy enough they can even reuse the rather obscure Received-SPF, unlike Authentication-Results that's at least in a shape which _might_ survive Bruce's^Wan IETF review. > SPF draft is best attempt so far to document SPF protocol as > it was developed prior to MARID (with only few things > borrowed from MARID) ACK, mainly it adopted revolutionary ideas like "ABNF must pass Bill's parser" and all the other formal nits... Okay, it also reduced Doug's imaginary "thousands of DNS queries" to now only "hundreds". Or in other words roughly ten for the worst non-attack case. [senderid] > as separate submission made to IETF, it should also be > responsibility of IESG that their proposal does not come > into conflict with other LMAP proposed experiments and does > not break any other IETF standards. Indeed. > please understand that v=spf1 document does not represent > MARID work perse Of course not. After MARID was closed Mark proposed to resume the work on v=spf1, the community decided to follow this plan. > slightly further developed and better documented (with that > documenting being in part result of working at MARID). The RfC is _much_ better than the last pre-MARID draft. > I believe at this point the appeal is only to IETF chair and > not to IESG. Pardon ? AFAIK there are only four appeal levels, to the AD in the case of a WG, to IETF Chair in the case of the IESG, to the IAB in the case of a process failure, and finally ISOC. > now only one person from IESG has opportunity to overrule > them. Are you sure ? Where can Brian overrule the IESG ? He's only the primus inter pares, the AD of the general area. Like our SPF Council Chair. > The appeal is only against SID draft It's only against four letters in this draft from my POV. > SPF draft should continue to be viewed as separate submission > and decided on its own merit. Of course, as you see in the tracker that's precisely how it was handled. > As far as MARID work IESG wanted, the correct thing is start > working on SPF2/3 where we left off at MARID If the IESG would have "wanted" any further MARID work they'd not have closed this WG, don't you think ? IMHO they want as less as possible to do with MARID. Even in the course of my aborted MARID appeal it was clear (from my POV) that reviving MARID after its sudden death was and is no option. SPF is a free and open project, we now have our own elected Council. I'm not interested to exchange it against the IESG. We tested this approach here in MARID, it failed, forget it. If XMPP can do it, SPF can also do it, and if it doesn't work we're at least sure that it's our own fault, and not some big player pulling strings in backchambers. > SPF community agrees to soften v=spf1 draft and allow for > use of positive results with other identities Over my cold and dead body, pseudo-PRA-PASS phishing is ugly. We can offer op=pra opt-in, time to publish this as I-D when needed about 60 seconds. For "we" read SPF-TINW, not IETF-we. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sun Aug 28 00:55:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9FCS-0003L4-9f for marid-archive@megatron.ietf.org; Sun, 28 Aug 2005 00:55:20 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15285 for ; Sun, 28 Aug 2005 00:55:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S4WYVd060313; Sat, 27 Aug 2005 21:32:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7S4WYbf060312; Sat, 27 Aug 2005 21:32:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S4WWR2060306 for ; Sat, 27 Aug 2005 21:32:32 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E9Eob-000746-97 for ietf-mxcomp@imc.org; Sun, 28 Aug 2005 06:30:41 +0200 Received: from c-180-160-106.hh.dial.de.ignite.net ([62.180.160.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 06:30:41 +0200 Received: from nobody by c-180-160-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Aug 2005 06:30:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02 Date: Sun, 28 Aug 2005 06:13:41 +0200 Organization: Lines: 36 Message-ID: <431139F5.5A9F@xyzzy.claranet.de> References: <430FE7A8.644@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-160-106.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Cc: ietf@ietf.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thomas Gal wrote: > Well clearly IANA won't accept 2 differing registrations that > overlap on this matter. Certainly it is the IETF/IESG/IAB's > job to rectify that incongruity? There's IMHO no IANA problem, using the same DNS RR type 99 is possible / desirable. > For the IESG to say "Change your records to v=senderid or > something that doesn't conflict with this other previously > printed document and large number of installations or we > can't really distribute this document" makes perfect sense. Yes, that's in fact all that has to be done, and what the appeal proposes, spf2.0 may interpret v=spf1 as spf2.0/mfrom, but not as spf2.0/mfrom,pra The proposed remedy is "KISS". > I'm not going to try to harp on IPR, or the end of the IETF, IANAL and not very much interested in the former - excl. the day when I tried to read and understand the IPR boilerplate in the first CID draft, because it was obvious right from the day when CID was published that something very odd happens. IIRC the plan for MARID was to use several ASRG LMAP proposals as input (SPF, CSV, MTAMARK among others). After CID was added and the ASRG cochair resigned (ASRG almost dead since this day) the situation deteriorated. So back to your statement above: The senderid-appeal is the continuation of the "shuffle those deck chairs" thread here. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sun Aug 28 01:31:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9FlY-0002Gz-QF for marid-archive@megatron.ietf.org; Sun, 28 Aug 2005 01:31:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16428 for ; Sun, 28 Aug 2005 01:31:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S555MH063274; Sat, 27 Aug 2005 22:05:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7S555r6063273; Sat, 27 Aug 2005 22:05:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7S554Ku063267 for ; Sat, 27 Aug 2005 22:05:04 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j7S54qi0014524; Sat, 27 Aug 2005 22:04:52 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j7S54q7Q014521; Sat, 27 Aug 2005 22:04:52 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 27 Aug 2005 22:04:52 -0700 (PDT) From: "william(at)elan.net" To: Douglas Otis cc: ietf@ietf.org, ietf-mxcomp@imc.org Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 In-Reply-To: <1125189318.25606.333.camel@bash.adsl-64-142-13-68> Message-ID: References: <000901c5aab5$962903c0$6c62fea9@ibmrkydk2ufvdd> <1125189318.25606.333.camel@bash.adsl-64-142-13-68> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 27 Aug 2005, Douglas Otis wrote: > On Sat, 2005-08-27 at 12:00 -0700, william(at)elan.net wrote: > >> But if reuse of spf1 records is really realy the only way for MS >> and it wants to continue, then the only possibility for negotiation >> I see is to get it part the way for both sides. This would involve: >> 1. MS agrees to change its draft and only use positive results of >> SID verification on v=spf1 records (but not fail, softfail or >> results if record is absent) and that for negative results real >> SPF2.0 record would be needed. > > This overlooks a problem related to abuse-feedback techniques accruing > to "Sender-ID verified" identities. An erroneous positive verification > based upon a PRA, unchecked by the sender perhaps due to licensing > issues, could be a serious concern. These SPF records are public and > outbound servers are often shared. I did not say its good way for the future, but it does eliminate the cases of failures [i.e. email not delivered] due to record being used by incorrect protocol, which is a lot worse then what you describe. And what I said is that this maybe an acceptable [temporary] compromise (not something that either side is fully happy with) while waiting for permanent solution, which is #3 on on my list -.both sides agree to work on the next version of SPF that has clear scoping and when finished promote that instead of spf1. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sun Aug 28 11:45:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9PLZ-0003t6-DC for marid-archive@megatron.ietf.org; Sun, 28 Aug 2005 11:45:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26362 for ; Sun, 28 Aug 2005 11:45:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7SFAqD2010641; Sun, 28 Aug 2005 08:10:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7SFAqES010640; Sun, 28 Aug 2005 08:10:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts16-srv.bellnexxia.net (tomts16.bellnexxia.net [209.226.175.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7SFAp1X010634 for ; Sun, 28 Aug 2005 08:10:51 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.94.158.46]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050828151049.SAKC21026.tomts16-srv.bellnexxia.net@ibmrkydk2ufvdd> for ; Sun, 28 Aug 2005 11:10:49 -0400 X-IMBH: Yes From: "John Glube" To: Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 Date: Sun, 28 Aug 2005 11:12:39 -0400 Message-ID: <000701c5abe2$f00f72b0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 26 Aug 2005, John Glube wrote: > |The only relevant boundary is between what the sender > |controls and what they do not. All that any sender, > |forwarder or any other mail injector can ever be expected > |to do is to define the boundaries of the systems they > |control. > | > |Once that boundary is defined the definition is fair game > |for any party to use to interpret it to meet their > |operational needs. > > I have a real problem with this last position. > > The underlying thrust behind sender authentication is to > establish a framework for use by certification and > reputation services, both external and internal to > facilitate the delivery of ham, while rejecting spam. [1] |With such a statement you're making an assumption that the |technology (i.e. SPF and SID) is only good for sender |authentication and anti-spam. With respect, this does not correctly state what I mean, which is partially my fault as I should have written: |The underlying benefit of e-mail authentication for senders |interested in e-mail delivery is to establish a framework that |supports certification and reputation services, both external |and internal to facilitate the delivery of ham, while rejecting |spam [1] I fully understand that the design objective of SPF (Mail From authentication) is to help thwart domain spoofing and that of Sender ID (PRA authentication) is to help prevent domain phishing. My point is that saying to commercial entities involved in the sending of solicited bulk e-mail, transactional and relationship e-mail that receivers can use their sender policy records for what ever purpose they want, irrespective of the stipulated protocols is not acceptable. As to the rest of the discussion, it seems SPF folks supporting the appeal are not interested in pushing back on Microsoft as it relates to the IPR and License, but simply want to fully sever the relationship between spfv1 and spf2.0. In that case, I presume the SPF Community has no problem with these potential developments: * The IESG, based on the Chair's recommendation, deciding to revoke publication of the SPF Classic and Sender ID drafts as Experimental RFC's. * The IESG asking Messrs Lentczner, Wong, Katz and Lyon to produce a set of drafts for spf2.0 as experimental RFCs based on the work done during MARID, with Messrs Lentczner and Wong doing the work on spf2.0, mfrom and Katz and Lyon doing the work on spf2.0, pra. * The IESG asking Messrs Schlitt and Wong to resubmit the spf-classic draft as an individual submission outside of MARID for consideration as an informational RFC. * Hotmail/MSN and various vendors of filtering software that presently use spfv1 records telling senders they need to publish spf2.0 records. * Hotmail/MSN dropping all public support for spfv1, including amending its web sites and wizard accordingly. * SpamAssassin, to remain competitive, announcing its support for spf2.0, mfrom in the next version of its product. * AOL, having been spurned by the SPF Community, deciding to join Hotmail/MSN and support the full transition to spf2.0. Will these developments happen? I don't know. But, hopefully folks have gone into this with their eyes wide open. Given the reaction of some to the initial comments posted by members of the IESG, I fear this is not the case. As such, there is every possibility that those supporting "technical purity" within the SPF Community are in for a rude awakening, with the end result being further Internet balkanization. John Glube From owner-ietf-mxcomp@mail.imc.org Mon Aug 29 01:20:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9c3y-0006Lk-Ln for marid-archive@megatron.ietf.org; Mon, 29 Aug 2005 01:20:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02488 for ; Mon, 29 Aug 2005 01:20:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7T4oJqB063592; Sun, 28 Aug 2005 21:50:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7T4oJdj063591; Sun, 28 Aug 2005 21:50:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7T4oIDs063580 for ; Sun, 28 Aug 2005 21:50:18 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1E9baq-0008Ve-AB for ietf-mxcomp@imc.org; Sun, 28 Aug 2005 23:50:17 -0500 From: wayne To: "IETF MARID WG" References: <000901c5aab5$962903c0$6c62fea9@ibmrkydk2ufvdd> Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Sun, 28 Aug 2005 23:49:59 -0500 In-Reply-To: <000901c5aab5$962903c0$6c62fea9@ibmrkydk2ufvdd> (John Glube's message of "Fri, 26 Aug 2005 23:15:32 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net X-Spam-Status: No, score=-6.9 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE,WORK_AT_HOME autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <000901c5aab5$962903c0$6c62fea9@ibmrkydk2ufvdd> "John Glube" writes: > How did this conflict arise? It arose after the closure of > MARID and prior to the filing of senderid-core-00. > > Let's remember the scene. The open source community was up > in arms over the IPR disclosure by Microsoft. That was not the only objection to SenderID and the PRA. The objections to SenderID and the PRA include: * The re-purposing of the Resent-* headers. The SenderID drafts require forwarded email to add Resent-* headers, while RFC2822 explicitly says that forwarders are not supposed to add these headers. Since forwarders do not currently add Resent-* headers, it would have been just as easy to create a new header for this purpose. * The PRA can not distinguish between these two cases: 1) An email is sent to a mailing list, which adds a Sender: header, and then the mailing lists sends it on to an email forwarder. According to the SenderID documents, the forwarder needs to add the Resent-* headers. The resulting email will end up with both Sender: and Resent-* headers. 2) Someone "bounces" an email (in the pine/elm/gnus sense of re-sending the email) to a mailing list. As per RFC2822, these MUAs correctly add the Resent-* headers to the email. The mailing list then adds a Sender: header. The resulting email will end up with both Sender: and Resent-* headers. The PRA has to give incorrect results in at least one of these cases. * The re-purposing of the SPFv1 record, as outlined in this appeal. * The PRA has a higher error rate than SPF since it fails not only in cases where there is forwarding going on, but also on many mailing lists. * SenderID and the PRA is no more effective at stopping phishing than classic SPF. Simply displaying the "PRA PASS" result actually makes the phishing problem worse, unless you also display the domain name that caused the PASS result. Otherwise, phishers will put a service@paypal.com on the From: header, and add a "Resent-Sender: foo@phisher.com", and the result will be a PRA PASS which looks like it came from paypal. If you display the domain that caused the PRA PASS, you can just as easily display the domain from the Return-Path and use SPF instead. At this point, there are no advantages to using the PRA. Of course, there was also: * The PRA requires a patent license that is incompatible with several open source licenses, representing a significant number of MTA and spam-filter software currently deployed. It also requires commercial companies to inform Microsoft when they plan to create a product that uses the PRA. And finally, there are people who objected to both SPF and SenderID because: * Both SPF and SenderID break forwarding. * Both SPF and SenderID require everyone to either send email through designated MTAs, or to have special exceptions created often requiring specialized software. This is known as the "working from home user", "roaming user" or "traveling salesman" problem. * Both SPF and SenderID break greating-card sites and the "send a news article to a friend" sites. The licensing issue was most certainly *NOT* the only cause for the closing of the MARID WG. All in all, the PRA has lots of disadvantages compared with SPF and no advantages. (Other than support by MS, that is.) Except for the cases of the re-purposing of SPFv1 records and the re-purposing of the Resent-* headers, I think the market can deal with the problems with the PRA. > Mr. Wong, over the strong objections of many within the SPF > community, went ahead and negotiated an arrangement that > allowed for the backward compatibility of PRA > authentication with spfv1 records. [2] You can't "negotiate" over technical problems. No one can create "backward compatibility" by decree. > Further to this arrangement: > > * The Lentczner draft for spfv1, which only supported mail > from authentication and the Lyon draft for spf2, which > supported both mail from and PRA authentication were filed > with the IESG. > > * Both drafts flowed from MARID. You have the timeline slightly messed up here. The work Mark Lentczner did during MARID was not about SPFv1, it was about SenderID. Mark created an SPF-classic draft *after* MARID was shut down. There is some dispute about whether this was intended to be part of the call for individual submissions made when MARID ended, but it was never intended to be used as the basis for the SenderID drafts. The fact that the lentczner-spf-00 I-D did not include support for the HELO identity was one of many incompatibilities with earlier SPF specifications and deployed SPF implementations. It was due to the large number of incompatibilities that the lentczner-spf-00 draft never reached a rough consensus level of support within the SPF community. > * Microsoft published an SPF wizard which supported the > publication of spfv1 records, subject to the need of > publishers to be satisfied their spfv1 records could be > used for both mail from and PRA authentication. It should be noted that the SPF wizard that Microsoft created produced completely invalid SPF records until shortly before the FTC Email Auth Summit, which was long after MARID closed. The number of records with these tell-tail errors is actually fairly small, indicating just how little MS backing for publishing SPF records actually had. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Aug 29 11:56:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9lzM-0005sv-5q for marid-archive@megatron.ietf.org; Mon, 29 Aug 2005 11:56:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18015 for ; Mon, 29 Aug 2005 11:55:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TFTBpT014700; Mon, 29 Aug 2005 08:29:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TFTBXV014699; Mon, 29 Aug 2005 08:29:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TFTA1D014693 for ; Mon, 29 Aug 2005 08:29:10 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j7TFSwcj023229; Mon, 29 Aug 2005 08:28:58 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j7TFSrgp023226; Mon, 29 Aug 2005 08:28:53 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 29 Aug 2005 08:28:52 -0700 (PDT) From: "william(at)elan.net" To: Brian E Carpenter cc: ietf@ietf.org, MARID , spf-discuss@v2.listbox.com Subject: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Brian, With IESG already considering other issues with publication of draft-lyon-senderid-core as experimental RFC, I'd like to request it also formerly consider and make determination in regards to issues raised at the very end of MARID regarding use of Resent- header fields by draft-lyon-senderid-core and draft-lyon-senderid-pra which appears to be in violation of the RFC2822 intended use of those fields. The more fundamental problem in regards to this issue and the issue raised by Julian Mehnle is that it appears that so-called SenderID experiment is not limited to only those who wish to participate it, but has effects on other internet users, in particular those who want to use only SPF (Classic SPF) as well as those who interpret and use Resent- fields (they can not be certain when looking at received email if fields had been added by user action at MUA in according with RFC2822 or in automated manner by forwarding entity as required by senderid) and this problem must be addressed before such publication is approved by IESG as official IETF experiment. The details of the appeal listed below are largely copy of my previous message to IESG on this subject, those interested can also see: http://www.imc.org/ietf-mxcomp/mail-archive/msg04713.html http://www.imc.org/ietf-822/mail-archive/msg05670.html http://www.imc.org/ietf-mxcomp/mail-archive/msg05774.html Details of the objection in regards to RFC2822 specified Resent fields: 1. Recommendations for forwarders incompatible with RFC2822 Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt | 7.2 E-Mail Forwarders | | In order to pass the PRA variant of the test, a program that forwards | received mail to other addresses MUST add an appropriate header that | contains an e-mail address that it is authorized to use. Such | programs SHOULD use the Resent-From header for this purpose. The above is is incompatible with the section 3.6.6 of RFC2822: Ref: http://www.ietf.org/rfc/rfc2822.txt | Note: Reintroducing a message into the transport system and using | resent fields is a different operation from "forwarding". | "Forwarding" has two meanings: One sense of forwarding is that a mail | reading program can be told by a user to forward a copy of a message | to another person, making the forwarded message the body of the new | message. A forwarded message in this sense does not appear to have | come from the original sender, but is an entirely new message from | the forwarder of the message. On the other hand, forwarding is also | used to mean when a mail transport program gets a message and | forwards it on to a different destination for final delivery. Resent | header fields are not intended for use with either type of | forwarding. This objection was discussed at MARID [1] and was found to be valid based on the answer by Pete Resnick [2] and in subsequent discussion in jabber conference [3]. Note: Same objection applies to section 7.3 of senderid-core document which requires use of Resent- fields by mail lists References: [1] http://www.imc.org/ietf-mxcomp/mail-archive/msg04713.html [2] http://www.imc.org/ietf-mxcomp/mail-archive/msg04972.html [3] http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-09-20.html 2. Use Resent-* headers for automatic action, which is incompatible with RFC2822 Ref: http://www.ietf.org/rfc/rfc2822.txt (section 3.6.6): | Resent fields are | strictly informational. They MUST NOT be used in the normal | processing of replies or other such automatic actions on messages. I take "automatic action" to include rejection and bouncing of messages and draft-lyon-senderid-core-01 recommends when PRA address derived from Resent- header is not authorized based on corresponding SPF record check, then message is to be rejected by mail system in automated manner. 3. PRA algorithm fails when message is RFC822 compliant, but not RFC2822 compliant Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt | Where messages conform to RFC822 rather than RFC2822, it is possible | for the algorithm to give unexpected results. An RFC822 message | should not normally contain more than one set of resent headers; | however the placement of those headers is not specified, nor are they | required to be contiguous. It is hence possible that the Resent-From | header will be selected even though a Resent-Sender header is present. | Such cases are expected to be rare or non-existent in practice The problem is acknowledged in the draft, however I disagree that it should be ignored quite so easily because RFC822 is still listed as Internet Standard where as RFC2822 is just Proposed Standard. 4. Resent-From can not be used without Resent-Date Ref: http://www.ietf.org/rfc/rfc2822.txt (section 3.6.6): | When resent fields are used, the "Resent-From:" and "Resent-Date:" | fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent. | Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be | identical to "Resent-From:". While not specifically mentioned, I believe draft-lyon-senderid-core document implies that only Resent-From is to be added by those forwarding systems that participate in the experiment (this is difficult to confirm because so far I've not found ANY forwarding system that is actually adding Resent- as per senderid-core draft). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Aug 29 14:53:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9okl-0000wn-2T for marid-archive@megatron.ietf.org; Mon, 29 Aug 2005 14:53:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27838 for ; Mon, 29 Aug 2005 14:53:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TIMqnW029832; Mon, 29 Aug 2005 11:22:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TIMqTD029831; Mon, 29 Aug 2005 11:22:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TIMotj029821 for ; Mon, 29 Aug 2005 11:22:51 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E9oFR-0004CX-4Z for ietf-mxcomp@imc.org; Mon, 29 Aug 2005 20:20:45 +0200 Received: from c-180-161-85.hh.dial.de.ignite.net ([62.180.161.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 20:20:45 +0200 Received: from nobody by c-180-161-85.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2005 20:20:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822 Date: Mon, 29 Aug 2005 20:06:40 +0200 Organization: Lines: 25 Message-ID: <43134EB0.300@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-180-161-85.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Cc: ietf@ietf.org, spf-discuss@v2.listbox.com Cc: ietf@ietf.org, ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable william(at)elan.net wrote: [...] > http://www.imc.org/ietf-mxcomp/mail-archive/msg05774.html Yes, that was a very good article. > incompatible with RFC2822 I'm still a bit lost how this could actually _break_ something. For obvious reasons the author can't say "updates 2822", how should he fix it ? As you said the 822 issue is mentioned in the senderid-pra draft. Do you want more "security considerations", something along the line of "PRA-participants agree to break an explicit MUST in 2822" ? > I disagree that it should be ignored quite so easily because > RFC822 is still listed as Internet Standard where as RFC2822 > is just Proposed Standard. Touch=E9. OTOH the author isn't responsible for this "detail" - in the spirit of TINW (for an IETF-we) it's "our" fault. Bye. From owner-ietf-mxcomp@mail.imc.org Mon Aug 29 17:39:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9rLo-0003nN-Ny for marid-archive@megatron.ietf.org; Mon, 29 Aug 2005 17:39:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08208 for ; Mon, 29 Aug 2005 17:39:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TKu5YS045456; Mon, 29 Aug 2005 13:56:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TKu52H045455; Mon, 29 Aug 2005 13:56:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TKu4KH045448 for ; Mon, 29 Aug 2005 13:56:04 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j7TKtwvQ027890; Mon, 29 Aug 2005 13:55:58 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j7TKtqTg027887; Mon, 29 Aug 2005 13:55:56 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 29 Aug 2005 13:55:51 -0700 (PDT) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: ietf@ietf.org, ietf-mxcomp@imc.org Subject: Re: [spf-discuss] Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822 In-Reply-To: <43134EB0.300@xyzzy.claranet.de> Message-ID: References: <43134EB0.300@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 29 Aug 2005, Frank Ellermann wrote: >> incompatible with RFC2822 > > I'm still a bit lost how this could actually _break_ something. > For obvious reasons the author can't say "updates 2822", how > should he fix it ? As you said the 822 issue is mentioned in > the senderid-pra draft. > > Do you want more "security considerations", something along > the line of "PRA-participants agree to break an explicit MUST > in 2822" ? Its not that easy because participants are not the only ones who see messages from such forwarders (if they ever come into existence) and so as I mentioned the draft actions are not limited to those who agree to participate in the experiment (but at least and unlike re-purposing of v=spf1 records this action would not cause failures as you correctly note). And since this actually breaks standard, this would seem to require explicit action and consent from IESG with understanding about it and update to RFC2822 with consensus and last call if properly done (and there has not been even an attempt by draft authors to ask for review at ietf-smtp or ietf-822 and do last-call like SPF draft author has done voluntarily). I guess its also fundamental question on how seriously does IETF really protect its own standards and follows its own procedures on how they are to be changed. As far as fixing it there are two ways to go about it (and you're correct that I should have mentioned considering its an appeal and there I have to say, not only what I believe is wrong but how it can be fixed): 1. As I already mentioned, IETF can do separate draft that updates RFC2822 and illuminates ambiguities allowing for reuse of Resent- header fields by forwarders. This new draft (and only that draft) would have to go to standard track as proposed standard with appropriate review and last call same as RFC2822. 2. Without changing standard, SID for its experiment (and since none of the systems adding Resent are adding it the way they want right now anyway, so no changes to running systems) can just create new header field and use that - this possibility has been mentioned at MARID btw. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Aug 31 14:11:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAX3E-0003C5-UI for marid-archive@megatron.ietf.org; Wed, 31 Aug 2005 14:11:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03993 for ; Wed, 31 Aug 2005 14:11:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VHbTN0034464; Wed, 31 Aug 2005 10:37:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VHbTfD034463; Wed, 31 Aug 2005 10:37:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VHbSXs034454 for ; Wed, 31 Aug 2005 10:37:28 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39390) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1EAWWS-0003x7-PJ (Exim 4.51) (return-path ); Wed, 31 Aug 2005 18:37:16 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1EAWWS-0002Tf-QO (Exim 4.43) (return-path ); Wed, 31 Aug 2005 18:37:16 +0100 Date: Wed, 31 Aug 2005 18:37:16 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Frank Ellermann cc: ietf@ietf.org, ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com Subject: Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822 In-Reply-To: <43134EB0.300@xyzzy.claranet.de> Message-ID: References: <43134EB0.300@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 29 Aug 2005, Frank Ellermann wrote: > > > incompatible with RFC2822 > > I'm still a bit lost how this could actually _break_ something. > For obvious reasons the author can't say "updates 2822", how > should he fix it ? As you said the 822 issue is mentioned in > the senderid-pra draft. Regarding RFC 822, the S-ID draft doesn't mention the fact that a large proportion of software which does something useful with Resent- headers still implements the 822 syntax, not the 2822 syntax. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.