From owner-ietf-mxcomp@mail.imc.org Fri Oct 1 03:45:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02664 for ; Fri, 1 Oct 2004 03:45: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 i917EI3X036700; Fri, 1 Oct 2004 00:14:18 -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 i917EIse036699; Fri, 1 Oct 2004 00:14:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from soyouz2.netaktiv.com (ns2.netaktiv.com [80.67.170.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i917E4JN036561 for ; Fri, 1 Oct 2004 00:14:05 -0700 (PDT) (envelope-from stephane@laperouse.internatif.org) Received: by soyouz2.netaktiv.com (Postfix, from userid 10) id 9A98EA7B7D; Fri, 1 Oct 2004 09:13:57 +0200 (CEST) Received: by fetiche (Postfix, from userid 1000) id BD58C18B35; Thu, 30 Sep 2004 19:58:40 +0100 (CET) Date: Thu, 30 Sep 2004 19:58:40 +0100 From: Stephane Bortzmeyer To: Danny Angus Cc: MXCOMP Subject: Re: Processed-By (or Transmitted-By) header concept Message-ID: <20040930185840.GA1131@laperouse.internatif.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.6+20040722i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 30, 2004 at 09:20:18AM +0100, Danny Angus wrote a message of 110 lines which said: > far more valuable in this role would be the normalisation, through > clarification and mandating, of existing optional compliant > behaviour and non-standard best practice. ... > I can see why you think this, but I would contend that if Received > and Resent headers included the full range of fields available to > them and HELO/EHLO contents were standardised and mandated From a purely engineering point of view, it is nice and reasonable. But for producing actual outputs, I doubt you will be able to update RFC 2821 and 2822 on Received headers in the short term. Or to modify the code of several MTAs. It is typically easier, both in standard documents and in currently deployed code to add new stuff than to try to modify old stuff. From owner-ietf-mxcomp@mail.imc.org Fri Oct 1 04:49:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07251 for ; Fri, 1 Oct 2004 04:49:09 -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 i918Guv7059851; Fri, 1 Oct 2004 01:16: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 i918Gu73059850; Fri, 1 Oct 2004 01:16:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by above.proper.com (8.12.11/8.12.9) with SMTP id i918GsKb059836 for ; Fri, 1 Oct 2004 01:16:55 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-8.tower-78.messagelabs.com!1096618613!2228109 X-StarScan-Version: 5.2.10; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 17453 invoked from network); 1 Oct 2004 08:16:54 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-8.tower-78.messagelabs.com with SMTP; 1 Oct 2004 08:16:54 -0000 Received: from emerald.slc.co.uk (emerald.slc.co.uk) by drsneaky.slc.co.uk (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Fri, 1 Oct 2004 09:16:53 +0100 Subject: Re: Processed-By (or Transmitted-By) header concept To: Stephane Bortzmeyer Cc: MXCOMP X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Danny Angus Date: Fri, 1 Oct 2004 09:16:53 +0100 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 01/10/2004 09:16:53 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: > From a purely engineering point of view, it is nice and > reasonable. But for producing actual outputs, I doubt you will be able > to update RFC 2821 and 2822 on Received headers in the short term. Or > to modify the code of several MTAs. Fair point. What I'm actually proposing, though, is that a new, stricter, specification for Recieved(etc) be written as an interim measure which would not obsolete 2822 but compliment it. Eventually the next iteration of 822 et al could obsolete our rfc and adopt the chnage. So.. an MTA could continue to implement rfc2822, and optionally implement our new RFC by constructing the headers with as much optional information as is incuded in 2822 and required by us. I think that most MTA's already validate and publish some degree of optional information in received headers, and some of them can have this behaviour changed by config alone. d. *************************************************************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi! ted. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************** From owner-ietf-mxcomp@mail.imc.org Fri Oct 1 05:56:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12169 for ; Fri, 1 Oct 2004 05:56: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 i919PjxQ082196; Fri, 1 Oct 2004 02:25: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 i919PjEI082195; Fri, 1 Oct 2004 02:25:45 -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 i919PitM082184 for ; Fri, 1 Oct 2004 02:25:44 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i919eTaF007971; Fri, 1 Oct 2004 02:40:29 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i919eTm3007968; Fri, 1 Oct 2004 02:40:29 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 1 Oct 2004 02:40:29 -0700 (PDT) From: "william(at)elan.net" To: Danny Angus cc: Stephane Bortzmeyer , MXCOMP Subject: Re: Processed-By (or Transmitted-By) header concept In-Reply-To: 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 Fri, 1 Oct 2004, Danny Angus wrote: > > From a purely engineering point of view, it is nice and > > reasonable. But for producing actual outputs, I doubt you will be able > > to update RFC 2821 and 2822 on Received headers in the short term. Or > > to modify the code of several MTAs. > > Fair point. > What I'm actually proposing, though, is that a new, stricter, specification > for Recieved(etc) be written as an interim measure which would not obsolete > 2822 but compliment it. Eventually the next iteration of 822 et al could > obsolete our rfc and adopt the chnage. I really don't know if it helps but for some time I've been gathering data on errors in Received lines and which MTAs are compliant and not. The results I have so far is that virtually all MTAs under certain conditions (and some always) add Received lines that are directly syntatically incompatible with RFC2822. And in any case fixing Received is completely diffirent task that will probably take quite a bit more effort even if new draft is published. Plus as far as which of the data that goes into Processed-By is also in Received, there is only one value - envelope recepient (which is "for" clause on received line). The envelope from (returnpath) is added in this from by one mailer: Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by above.proper.com (8.12.11/8.12.9) with SMTP id i918GsKb059836 for ; Fri, 1 Oct 2004 01:16:55 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) But if you look at RFC2822 it says that syntax of Received is: received = "Received:" name-val-list ";" date-time CRLF date-time = [ day-of-week "," ] date FWS time [CFWS] time = time-of-day FWS zone zone = (( "+" / "-" ) 4DIGIT) Based on above addition of "(envelope-from ph10@cus.cam.ac.uk)" at the end of Received after time violates RFC2822, so we should not promote this behavior for the future. In addition I do not think it is appropriate behavior to mandate adding "envelope-from" to every received line, its of interest to know the value when it has changed, but repeating it every time is waste of header space (did you call that "header blotting"?). Additionally Processed-By provides for new "Original-*" headers for recording previous values of Sender, CC, Reply-To, List-ID, etc. There is no equivalent for this in current SMTP specs and if you send email to mail list, it'll rewrite original Sender and its value is lost to recepient. If you have message that went through more then one mail list, you'll only see info about last email list, as each would want to add the same list of headers overiding previous values (and sometimes mixing it up which is even worth). When you add forwarding to the mix the situation is even worth. So I'm sorry but I really don't see how Received line is going to help with all this, we do need new specification. And as far as Received line - its also a good idea idea to write something up to explain to MTA writers what they need to do with it, but this is separate task. > I think that most MTA's already validate and publish some degree of > optional information in received headers Hahaha (sorry it the "most" part and "validate" that got me...) As far as optional information - entire Received line is optional informatio and at best you can hope to find EHLO name and ip address of the SMTP Client and even that is not for certain. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam and Email Security Research Worksite: http://www.elan.net/~william/emailsecurity/ From owner-ietf-mxcomp@mail.imc.org Fri Oct 1 14:23:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04047 for ; Fri, 1 Oct 2004 14:23:14 -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 i91HkvGa045284; Fri, 1 Oct 2004 10:46:57 -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 i91HkvAG045283; Fri, 1 Oct 2004 10:46:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91HkiEr045271 for ; Fri, 1 Oct 2004 10:46:44 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 2CF6C414C5; Fri, 1 Oct 2004 10:46:46 -0700 (PDT) Subject: Re: Processed-By (or Transmitted-By) header concept From: Douglas Otis To: "william(at)elan.net" Cc: Danny Angus , Stephane Bortzmeyer , MXCOMP In-Reply-To: References: Content-Type: text/plain Message-Id: <1096652684.31564.22.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 01 Oct 2004 10:46:46 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-10-01 at 02:40, william(at)elan.net wrote: > On Fri, 1 Oct 2004, Danny Angus wrote: > > > > From a purely engineering point of view, it is nice and > > > reasonable. But for producing actual outputs, I doubt you will be able > > > to update RFC 2821 and 2822 on Received headers in the short term. Or > > > to modify the code of several MTAs. > > > > Fair point. > > What I'm actually proposing, though, is that a new, stricter, specification > > for Recieved(etc) be written as an interim measure which would not obsolete > > 2822 but compliment it. Eventually the next iteration of 822 et al could > > obsolete our rfc and adopt the chnage. > > I really don't know if it helps but for some time I've been gathering data > on errors in Received lines and which MTAs are compliant and not. The > results I have so far is that virtually all MTAs under certain conditions > (and some always) add Received lines that are directly syntatically > incompatible with RFC2822. And in any case fixing Received is completely > diffirent task that will probably take quite a bit more effort even if > new draft is published. > > Plus as far as which of the data that goes into Processed-By is also in > Received, there is only one value - envelope recepient (which is "for" > clause on received line). The envelope from (returnpath) is added in this > from by one mailer: > > Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) > by above.proper.com (8.12.11/8.12.9) with SMTP id i918GsKb059836 > for ; Fri, 1 Oct 2004 01:16:55 -0700 (PDT) > (envelope-from Danny_Angus@slc.co.uk) > > But if you look at RFC2822 it says that syntax of Received is: > received = "Received:" name-val-list ";" date-time CRLF > date-time = [ day-of-week "," ] date FWS time [CFWS] > time = time-of-day FWS zone > zone = (( "+" / "-" ) 4DIGIT) > > Based on above addition of "(envelope-from ph10@cus.cam.ac.uk)" at the end > of Received after time violates RFC2822, so we should not promote this > behavior for the future. In addition I do not think it is appropriate > behavior to mandate adding "envelope-from" to every received line, its > of interest to know the value when it has changed, but repeating it every > time is waste of header space (did you call that "header blotting"?). > > Additionally Processed-By provides for new "Original-*" headers for > recording previous values of Sender, CC, Reply-To, List-ID, etc. There > is no equivalent for this in current SMTP specs and if you send email > to mail list, it'll rewrite original Sender and its value is lost to > recipient. If you have message that went through more then one mail list, > you'll only see info about last email list, as each would want to add > the same list of headers overriding previous values (and sometimes > mixing it up which is even worth). When you add forwarding to the mix > the situation is even worth. > > So I'm sorry but I really don't see how Received line is going to help > with all this, we do need new specification. And as far as Received > line - its also a good idea idea to write something up to explain to MTA > writers what they need to do with it, but this is separate task. > > > I think that most MTA's already validate and publish some degree of > > optional information in received headers > Hahaha (sorry it the "most" part and "validate" that got me...) > > As far as optional information - entire Received line is optional > information and at best you can hope to find EHLO name and > ip address of the SMTP Client and even that is not for certain. There has been some consideration given this within CSV. It would be helpful to mark the Received header indicating a successful validation using the CSV record. This would assist in locating the weak-link and perhaps to deprecate message assertions as a result. Once the HELO domain has been validated, then the address list technique of SPF and Sender-ID can be abandoned and replaced by the use of a name list. This name list approach is much more expedient and safer. Any reputation assertions should be based upon the HELO information and not the mailbox domain. A name list referenced by the mailbox domain will allow rejection of obviously spoofed mail or alert the receiver of this potential. The mailbox domain identity carried through the mail channel is not strong enough to safely base negative assertions. If to stop the problem, stop it at the source. The source is the mail transfer agent, and any name involved with blocking must be constrained to exclusively identify the administration of the mail transfer agent. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Oct 1 22:40:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00964 for ; Fri, 1 Oct 2004 22:40: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 i922FcZK073696; Fri, 1 Oct 2004 19:15:38 -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 i922Fcsd073695; Fri, 1 Oct 2004 19:15:38 -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 i922Fb55073688 for ; Fri, 1 Oct 2004 19:15:37 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i922UXKr001085; Fri, 1 Oct 2004 19:30:33 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i922UXnt001082; Fri, 1 Oct 2004 19:30:33 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 1 Oct 2004 19:30:33 -0700 (PDT) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: MXCOMP Subject: Re: [spf-discuss] Trying to specify SPF Classic? In-Reply-To: <20041002010441.GP21013@dumbo.pobox.com> 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 Fri, 1 Oct 2004, Meng Weng Wong wrote: > I have proposed to the IETF AD and co-chairs that we publish > an Experimental RFC to document SPF Classic, and also > publish Experimental RFCs for Sender ID to make Microsoft > happy, and also publish Experiemental RFCs that head in the > direction of Unified SPF. SenderID (PRA) and UnifiedSPF based on SPF 2.0, we're not quite ready with that draft, I'd like more discussion on scoping and making it more compatible with SPF 1.0. So I would recommend publishing Classic SPF1.0 draft to RFC now and wait a little more with SPF2.0 and do more discussions both on protocol and on other aspects Unified SPF. When we're ready with all other Unified SPF drafts (that means we have published them and discussed and tried the concept and have implementations available) then we can ask for publiication of SPF2.0 protocol and all related unified SPF drafts to Experimental RFCs. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sat Oct 2 03:51:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02112 for ; Sat, 2 Oct 2004 03:51: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 i927Gq9C036669; Sat, 2 Oct 2004 00:16: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 i927Gqcp036668; Sat, 2 Oct 2004 00:16:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from soyouz2.netaktiv.com (ns2.netaktiv.com [80.67.170.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i927GdSl036548 for ; Sat, 2 Oct 2004 00:16:39 -0700 (PDT) (envelope-from stephane@laperouse.internatif.org) Received: by soyouz2.netaktiv.com (Postfix, from userid 10) id 7C015A7BD0; Sat, 2 Oct 2004 09:16:32 +0200 (CEST) Received: by fetiche (Postfix, from userid 1000) id 647A718B36; Fri, 1 Oct 2004 19:13:45 +0100 (CET) Date: Fri, 1 Oct 2004 19:13:45 +0100 From: Stephane Bortzmeyer To: "william(at)elan.net" Cc: ietf-mxcomp@imc.org Subject: Re: Alternatives drafts for SUBMITTER identity Message-ID: <20041001181345.GC1153@laperouse.internatif.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.6+20040722i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Sep 27, 2004 at 11:33:56AM -0700, william(at)elan.net wrote a message of 1020 lines which said: > 5.3 Interpreting the Results of SPF > Verification...............6 I do not se why we should introduce a given verification (SPF) in the draft. SUBMITTER stands by itself. Of course, it is developed mostly for SPF but it may be used by other protocols. My advice: drop everything related to SPF. From owner-ietf-mxcomp@mail.imc.org Sat Oct 2 13:48:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29158 for ; Sat, 2 Oct 2004 13:48:03 -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 i92HFpuQ043047; Sat, 2 Oct 2004 10:15:51 -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 i92HFpAY043046; Sat, 2 Oct 2004 10:15:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92HFp8S043029 for ; Sat, 2 Oct 2004 10:15:51 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.153] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 8CD0640E2; Sat, 2 Oct 2004 10:15:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: spf-discuss@v2.listbox.com, IETF MARID WG From: Mark Lentczner Subject: Hackers conference Date: Sat, 2 Oct 2004 10:15:59 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Friends - Is anyone attending the Hacker's conference? If so, please let me know ASAP by private e-mail. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Mon Oct 4 22:11:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20996 for ; Mon, 4 Oct 2004 22:11:46 -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 i951h9Is038614; Mon, 4 Oct 2004 18:43:09 -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 i951h9Au038613; Mon, 4 Oct 2004 18:43:09 -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 i951h9IV038607 for ; Mon, 4 Oct 2004 18:43:09 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i951wb8V001159 for ; Mon, 4 Oct 2004 18:58:37 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i951wais001156 for ; Mon, 4 Oct 2004 18:58:37 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 4 Oct 2004 18:58:36 -0700 (PDT) From: "william(at)elan.net" To: MXCOMP Subject: Regarding Microsoft comments to FTC regarding MARID and Sender ID 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 Mon, 4 Oct 2004, John Glube wrote [on spf-discuss mail list]: > Apropos Anne's comment, people may wish to read Microsoft's > submission in response to the Request for Comments issued > by the FTC and NIST concerning the Sender Authentication Summit: > > http://www.ftc.gov/os/comCents/emailauthentication/512447-0039.pdf > > The most interesting part? The submission was signed by Michael Hintze, > Senior Corporate Attorney, Microsoft Corporation. I want to share part of that comment that I found most interest in regards to closure of MARID WG (while I would have liked to shre more then just this text, I could not directly copy the text from that pdf and I don't have time to retype larger portions): "The IETF working group on Sender ID has not reached consensus on the proposal and has suspended its worK for now - decision which is being appealed - but the disclosure of intellcctual property rights to IETF and its publication of Sender ID Framework specifications endures and thereby satisfies the conditions for an open standard The test of whether Sender ID or any other proposed solution is an open standard is not Whether it has been ratified through an open consensus- based process, but rather whether the proposal can be widely adopted - indeed many successfull industry standards are not ratified by a standard-setting organization. ... Microsoft cannot, however, confirm whether it has patent rights in other [email authentication] technology nor, obviously, whether any other party has patent rights that might be needed to make use or sell implementations of other proposed authentication standards" > When you have finished reading that document, if folks don't understand > the need to get on with the show, both technically, commercially and > public relations wise, then The closure of MARID was not the end, the real show is just starting ... > To read all of the comments: > > http://www.ftc.gov/os/comments/emailauthentication > > For those who are interested in the patent issue, also read > the submission by Larry Rosen: > > http://www.ftc.gov/os/comments/emailauthentication/512447-0038.pdf > > John Glube > Toronto, Canada > > For The Record, Will Microsoft Own Email? > http://www.learnsteps4profit.com -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Oct 7 21:36:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24214 for ; Thu, 7 Oct 2004 21:36:14 -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 i980xrev043420; Thu, 7 Oct 2004 17:59:53 -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 i980xrs8043419; Thu, 7 Oct 2004 17:59:53 -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 i980xouw043408 for ; Thu, 7 Oct 2004 17:59:52 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i981Fp1N008301; Thu, 7 Oct 2004 18:15:51 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i981FpXc008298; Thu, 7 Oct 2004 18:15:51 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 7 Oct 2004 18:15:51 -0700 (PDT) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: MXCOMP Subject: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: FYI ---------- Forwarded message ---------- Date: Thu, 07 Oct 2004 15:34:38 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-leibzon-responsible-submitter-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Responsible Submitter of an E-mail Message Author(s) : W. Leibzon Filename : draft-leibzon-responsible-submitter-00.txt Pages : 18 Date : 2004-10-7 This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-leibzon-responsible-submitter-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-leibzon-responsible-submitter-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-leibzon-responsible-submitter-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-leibzon-responsible-submitter-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ietf-mxcomp@mail.imc.org Thu Oct 7 23:59:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03599 for ; Thu, 7 Oct 2004 23:59:19 -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 i983bhoY056300; Thu, 7 Oct 2004 20:37:43 -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 i983bhKS056299; Thu, 7 Oct 2004 20:37:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i983bhL7056277 for ; Thu, 7 Oct 2004 20:37:43 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id CF692414C4; Thu, 7 Oct 2004 20:37:47 -0700 (PDT) Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) From: Douglas Otis To: "william(at)elan.net" Cc: spf-discuss@v2.listbox.com, MXCOMP In-Reply-To: References: Content-Type: text/plain Message-Id: <1097206667.16694.445.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 07 Oct 2004 20:37:47 -0700 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, 2004-10-07 at 18:15, william(at)elan.net wrote: > Subject: I-D ACTION:draft-leibzon-responsible-submitter-00.txt > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-leibzon-responsible-submitter-00.txt Here are some excerpts from this recent Submitter proposal. | The purpose of the SUBMITTER parameter is to allow the SMTP client to | indicate to the server the address of the entity most recently | responsible for injecting a message into the e-mail transport stream. One possible view, assuming it is authenticated, would be the HELO domain is the entity most recently accountable for injecting the message. This provides a clear and strong definition. It also does not require a modification to SMTP for this information to be obtained early within the SMTP transaction and steers clear of many complexities. ... | This document provides means to authenticate the DOMAIN of the | appropriate email address; it is not directed at the local-part. That is good, as the HELO domain does not have a local part. | A domain owner gets to determine which SMTP clients speak on behalf | of addresses within the domain; a responsible domain owner should not | authorize SMTP clients that will lie about local parts. If this were done using a list of root HELO names, the mailbox domain owner could easily describe which SMTP clients speak on behalf of this mailbox domain, always within a single DNS lookup. I don't understand what is meant by lying about local parts. It would make more sense had this said to limit the authorization of SMTP clients to those shared by other responsible mailbox domains. But as these mailbox domains must not be held accountable for this sharing, it would make even more sense to say only the HELO domain is to be held accountable for any abuses. | In case of email submission by end-user this address can be found in | "Sender:" header since RFC2822 specifies that Sender header represents | "agent responsible for actual transmission of the message" and if | Sender is not present then responsible party is email author listed | in "From:" header. Would it not be equivalent to saying the authenticated HELO domain plays the role of sender? In which case, the HELO root name list referenced by the RFC2822 From mailbox domain can then indicate when the message is "outside" the nominal mail channel. Mail policy asserted by the mailbox domain owner could also indicate whether messages "outside" the nominal channel are to be rejected. This prevents the problem of invited exploits where SMTP client authentication is also attempted using this description of this nominal mail channel with a long list of addresses. This long address list provides many other serious risks as well. | In case of email list, the responsible party is mail list and the | address should be that of email list itself. Again, an authenticated HELO domain can play this role with much less chance of spoofing. In many cases, the HELO domain will be the same domain as the RFC2822 sending domain. | In case of forwarding service, the address should be that of the | forwarding agent or that of a user of that forwarding agent, whose | settings caused email retransmission. Here again, an authenticated HELO domain can play this role with much less chance of spoofing. The use of the HELO domain does not require a modification to SMTP and provides a stronger and more secure named identity. The mailbox domain can be protected by describing the nominal mail channel through the use of root name lists of these HELO domains. The admonishments regarding the mailbox domain authorization of SMTP clients is entirely misplaced, as the administrator of the SMTP client must be held accountable, and this administrator is positively identified by the HELO domain. Any other domain reference would be based upon an unverifiable assumption of the mail channel integrity. For more details see: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt -Doug From owner-ietf-mxcomp@mail.imc.org Sat Oct 9 02:21:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17939 for ; Sat, 9 Oct 2004 02:21: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 i995rnZJ037717; Fri, 8 Oct 2004 22:53:49 -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 i995rndP037716; Fri, 8 Oct 2004 22:53:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (adsl-69-225-172-218.dsl.pltn13.pacbell.net [69.225.172.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i995rm1n037677 for ; Fri, 8 Oct 2004 22:53:48 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 54F5E1D651; Fri, 8 Oct 2004 22:53:48 -0700 (PDT) Date: Fri, 08 Oct 2004 22:53:51 -0700 From: Greg Connor To: spf-discuss@v2.listbox.com Cc: MXCOMP Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) Message-ID: <7335297.1097276031@[192.168.0.2]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thank you William, for taking the time to write and submit this draft. I like the idea of having a SUBMITTER extension to ESMTP, mostly because it allows another alternative for forwarders who don't want to munge the return-path ala SRS. Some quick comments on the draft... --"william(at)elan.net" wrote: > 4.1 Setting the SUBMITTER Parameter Value > ... > > SMTP servers which are involved in retransmission of the message but > which do not cause change in the direction of SMTP transmission > SHOULD use SUBMITTER value they received during incoming SMTP > transmission as value for outgoing SMTP transmission. If there was > no SUBMITTER MAIL parameter during incoming transmission, then SMTP > server MUST NOT use SUBMITTER for outgoing transmission unless it > can find email address of the entity which last caused introduction > of a message into the email delivery system by other means. Keeping the same Submitter at an intermediate hop might result in a Fail. You might consider relaxing this language a bit to allow for cases where the message is being passed along at points other than its initial injection where Submitter is most likely to Pass. My suggestion would be to have a given mail server decide whether it is acting as an agent for the sender, or an agent for the receiver. If the mailserver doing the sending is authorized to accept any and all mail for the recipient (RCPT) regardless of the sender's identity (i.e. if the Recipient is considered local) then it is probably an agent for the receiver, and it should check the Submitter value, but should probably not pass it on. If the mail server doing the sending is acting as an agent for the Submitter, and a check that uses its own IP would result in a Pass, then it is OK to pass the Submitter value on. > An SMTP client that supports the Responsible Submitter extension and > that can set Responsible Submitter value MUST include the SUBMITTER > parameter on all messages. This includes messages containing a null > reverse-path in the MAIL command. A couple exceptions might be 1. if the Submitter is the same as the return path, maybe it is not needed, or 2. if the client is an agent for the receiver, not the sender, and it has already verified Submitter itself (because verifying Submitter again at the next hop might fail.) > 4.2 Processing the SUBMITTER Parameter > Might want to add something like, "It is important to note that the Submitter is not intended to bypass or replace other checks, such as return path or HELO, *unless* the receiver trusts the sender to substitute an alternate return path. The presence of Submitter alone should not be taken as a substitute for other checks. The receiver should exercise best judgement when setting the policy regarding when to bypass other checks." > 5.1 Publishing DNS Authorization Records > > Domains that are used as part of the Responsible Submitter address > SHOULD publish SPF DNS Authorization records that allow to verify > ip addresses of hosts that are authorized to use given domain when > setting SUBMITTER parameter. SPF records used for publishing this > information MUST use "submit" scope identifier. Do you want to say that a scope of /submit will be used for this check, and if not present, then a general-purpose SPF record may be used instead? That would allow sites to publish a single record for all scopes, if those scopes have the same access characteristics anyway. > 5.2 Checking DNS Authorization Records > > For an SMTP Server to test authorization of SMTP Client to use > certain domain as part of the SUBMITTER parameter, the SMTP Server > MUST evaluate the results of check_host() function as defined in > [SPF-PROTOCOL] with arguments as follows: > > - the "submit" scope identifier > - the ip address of the SMTP client host > - the domain portion of the SUBMITTER parameter > - the full email address in SUBMITTER parameter > > If SMTP Client provided SUBMITTER argument to MAIL command then SMTP > Client SHOULD perform authorization check during the time of SMTP > transaction. The check can be performed directly at the time of MAIL > command or it may be easier to delay the check to later stage of SMTP > transmission. I would include a note here to say that checking the validity of the Submitter parameter during the initial submission is a best practice, because it allows the receiver to stop the transaction with a 5xx error (or 4xx for temp fail) and won't result in a bounce message being send to a (supposed, unverified) sender. Checking after the fact can also be supported (perhaps as part of a scoring system) but receivers are recommended to check during initial receipt if possible. > 5.3 Interpreting the Results of SPF Verification > Regarding the interpretation section, I think we should probably push for SUBMITTER to get a Pass result, or else it should be pretty much ignored. It particular, if the Submitter check doesn't result in a Pass, then it should not be used as a basis for establishing trust (for example, in order to bypass return path checks that would otherwise fail). Might want to state up front that results other than Pass should not be used to extend trust. > 5.3.2 Pass > A Pass result alone should not be considered sufficient to bypass other checks. For example, a forwarder may use Submitter to signal that it is forwarding a message with a return path that it is not normally allowed to use, and that the receiver is requested to check Submitter and not check return path. The receiver in this case should only bypass the return path check if it trusts the forwarder to forward mail and assert an alternate return path. Or, a receiver may choose to note the submitter and return path and allow the MUA to decide which submitters are trusted. > 5.4.1 Displaying Verification Results in MUA > > When displaying a received message, an MUA SHOULD check message for > Authentication-Results headers and if last entered such header is > proceeded only by Received and Return-Path trace headers which appear > to have been added by MDA or by other MTAs which are known to be on > the same network as MUA, then MUA should display the value of > Responsible Submitter as found in "envelope-submitter" as well as > display to the user the results of SPF verification. > > If email address of Responsible Submitter is the same as address in > one of the "From:" headers, then MUA should show that email address > as email origin and indicate by some means that it has been SPF- > verified based on submitter identity. If header "From:" address is > not the same, then origin of the email should be indicated as being > that of Responsible Submitter with email listed as having been sent > on behalf of the party listed in "From:" header. It should be made > clear that only Responsible Submitter part of the email origin has > been SPF-verified and not the header "From:" address part. > > MUA may also want to find envelope-submitter values from all > "Authentication-Results:" headers as well as "Sender:" and all > "From:" headers and display them as addresses responsible for > transmission of the message. Optionally, a MUA may choose to keep a list of which submitter values are "trusted" (such as the users own forwarding address). If the submitter is trusted, *and* a previous/second Authentication Results header exists (in proper order to have been added by the trusted forwarder), the MUA may choose to display this authentication result instead. (In other words, if a mail is claimed to be forwarded, then the submitter should be displayed and attributed as the sender, unless the MUA knows that the submitter is really a forwarding account that I have assigned as trusted, in which case the message can be safely attributed to whatever submitter came right before. If the MUA doesn't allow users to set trust levels, then anyone who uses a forwarding address will see his own address as the Submitter for pretty much every message.) > 6.1 Mail Submission > > Under normal circumstances, Alice would configure her MUA to submit > her message to the mail system using the SUBMIT protocol [SUBMIT]. > The MUA would transmit the message without the SUBMITTER parameter. > The SUBMIT server would validate that the MUA is allowed to submit a > message through some external scheme, perhaps SMTP Authentication > [SMTPAUTH]. The SUBMIT server would then extract her address from the > RFC 2822 header "Sender" or if it missing then out of first "From:" > header and it would set SUBMITTER parameter to this address for > subsequent transmissions of the message. > > Note that setting SUBMITTER parameter based on values of "Sender" and > "From" header should be done ONLY if SMTP Server is certain that mail > submission is taking place, i.e. if either SUBMIT protocol is used or > if SMTP protocol with SMTP authentication [SMTPAUTH] is used. Might want to refer readers to RFC 2476 and remind them that it is the responsibility of the SUBMIT server to verify that the person submitting the message is really authorized to use the claimed return-path. It is legal to assert a different return path (for example if Alice would like to send from the current location but would like any bounces or delivery reports sent to her other address) BUT with two caveats. 1. The server accepting the initial submission SHOULD reject any message with a return path that cannot be verified as belonging to the submitting user (we are not making this part up, refer to RFC2476) and 2. the user submitting the message should make sure that the guest/mobile location is permitted as part of the return path domain's policy, because many sites will check return path anyway even if Submitter passes (because they don't trust Submitter as a forwarder of otherwise-unacceptable return paths.) One way to satisfy 1. (verification of return path) is to keep a list of "alternate addresses" the sender may use, and if the sender wants to add to the list, send him a test message at that address and ask the user to verify receipt by replying or clicking a link containing a secret cookie. (This would be similar to signing up for a mailing list.) Once the address is verified, the sending user may use it as one of his alternate return paths. (The page where you add more "alternate" addresses for your ISP to verify is also a good place to explain to the user that he or the owner of his other domain should add us as an authorized sender.) If the forwarder is not implicitly trusted by the receiver, or if the conditions 1-2 are not met, then the Submit servers should substitute a return path that it CAN verify (like the user's local address instead of the remote address). The user is free to set From: and Reply-To: but the Sender: and return path should be either local or verified-remote addresses and should be tied to the user by SMTP AUTH or some other method (static IP, pop-before-smtp, whatever) -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sat Oct 9 03:07:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20663 for ; Sat, 9 Oct 2004 03:07: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 i996YE60053110; Fri, 8 Oct 2004 23:34: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 i996YE8t053109; Fri, 8 Oct 2004 23:34:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (adsl-69-225-172-218.dsl.pltn13.pacbell.net [69.225.172.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i996YDZQ053099 for ; Fri, 8 Oct 2004 23:34:13 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 15EE31D651; Fri, 8 Oct 2004 23:34:21 -0700 (PDT) Date: Fri, 08 Oct 2004 23:34:24 -0700 From: Greg Connor To: Douglas Otis , "william(at)elan.net" Cc: MXCOMP Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) Message-ID: <9768175.1097278464@[192.168.0.2]> In-Reply-To: <1097206667.16694.445.camel@ddev.mail-abuse.org> References: <1097206667.16694.445.camel@ddev.mail-abuse.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [I removed spf-discuss from the cc: list, since Doug is not a member there and his message therefore didn't appear on that list.] --Douglas Otis wrote: >| The purpose of the SUBMITTER parameter is to allow the SMTP client to >| indicate to the server the address of the entity most recently >| responsible for injecting a message into the e-mail transport stream. > > One possible view, assuming it is authenticated, would be the HELO > domain is the entity most recently accountable for injecting the > message. This provides a clear and strong definition. It also does not > require a modification to SMTP for this information to be obtained early > within the SMTP transaction and steers clear of many complexities. Doug's reply seems to indicate either a misunderstanding of the main point behind SUBMITTER, or else he is trying to commandeer the discussion and steer it back to his favorite topic of HELO verification. I consider it rude to take someone else's hard work and criticize it because it doesn't match your own "pet" issue. But since I don't have direct knowledge of Doug's motives here, perhaps it's appropriate to be charitable here and assume a misunderstanding rather than intentional insult and provocation. [for now] >| This document provides means to authenticate the DOMAIN of the >| appropriate email address; it is not directed at the local-part. > > That is good, as the HELO domain does not have a local part. >| A domain owner gets to determine which SMTP clients speak on behalf >| of addresses within the domain; a responsible domain owner should not >| authorize SMTP clients that will lie about local parts. > > If this were done using a list of root HELO names, the mailbox domain > owner could easily describe which SMTP clients speak on behalf of this > mailbox domain, always within a single DNS lookup. I don't understand > what is meant by lying about local parts. It would make more sense had > this said to limit the authorization of SMTP clients to those shared by > other responsible mailbox domains. But as these mailbox domains must > not be held accountable for this sharing, it would make even more sense > to say only the HELO domain is to be held accountable for any abuses. Continued discussion of HELO in this context gets us further from the topic of the draft itself. HELO was not mentioned in the draft (other than the response to EHLO should contain SUBMITTER in the capability list.) So, I will try to respond to this without mentioning HELO. I have a pretty fair idea of what "clients that lie about local parts" really means. It means that the domain owner should make sure that any SMTP clients he chooses to authorize should check the local part against the known/verifiable information for the user (such as SMTP AUTH, static IP, pop-before-smtp, etc.) This prevents one customer of the service provider from impersonating other users at the same service provider. (My previous message describes methods that ISPs might use to verify that the localpart being claimed really is owned by the user being authenticated. This is not new -- RFC 2476 says that the submit server should verify if the user is really authorized to use that particular return path -- William's draft is just applying something similar to the submitter address.) >| In case of email submission by end-user this address can be found in >| "Sender:" header since RFC2822 specifies that Sender header represents >| "agent responsible for actual transmission of the message" and if >| Sender is not present then responsible party is email author listed >| in "From:" header. > > Would it not be equivalent to saying the authenticated HELO domain plays > the role of sender? No, it clearly would not. A message should only have one sender, but may have multiple submitters on its way to destination, just as it may have multiple hops for each submitter. >In which case, the HELO root name list referenced Remainder of this paragraph ignored. >| In case of email list, the responsible party is mail list and the >| address should be that of email list itself. > > Again, an authenticated HELO domain can play this role with much less > chance of spoofing. In many cases, the HELO domain will be the same > domain as the RFC2822 sending domain. I disagree with both statements. The HELO domain clearly cannot play the role of SUBMITTER, because SUBMITTER is a mailbox, not a domain name. Also, the same mail server may send messages on behalf of multiple SUBMITTERS, but would require a RSET to change its HELO name. Also it is pretty clearly not true that the HELO domain will be the same as the sending domain, unless we are considering changing the meaning of HELO. Furthermore, I would point out that Doug's tone has changed here from questioning (such as "One possible view" or "Would it not be equivalent") to lecturing William and the other listmembers as to why *his* way works better. This makes me believe that this is NOT all just a big misunderstanding, and that the behavior of taking someone else's message and commandeering it for his own purposes is indeed intentional. If it is in fact intentional, I would like to point out that it is quite rude, and I would go so far as to say that this sort of behavior was one of the main stumbling blocks that made MARID fail. Stubbornly insisting that one way is right, even if it doesn't have anything to do with the current thread, and even if the idea you are describing is specifically excluded from the current discussion, is not valid behavior for a collaborative working group. (I know the WG chairs had a lot on their minds, but perhaps they should have been more strict about not allowing such selfish behavior) >| In case of forwarding service, the address should be that of the >| forwarding agent or that of a user of that forwarding agent, whose >| settings caused email retransmission. > > Here again, an authenticated HELO domain can play this role with much > less chance of spoofing. The use of the HELO domain does not require a > modification to SMTP and provides a stronger and more secure named > identity. Further indication that we have moved from "not quite understanding" to "disagreeing and lecturing"... > The admonishments regarding the mailbox domain authorization of SMTP > clients is entirely misplaced, as the administrator of the SMTP client > must be held accountable, and this administrator is positively > identified by the HELO domain. Any other domain reference would be > based upon an unverifiable assumption of the mail channel integrity. > > For more details see: > http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt > > -Doug Looks like this is the essence of the sales pitch... Doug would prefer us not to read William's draft and instead to pay more attention to his own. No thanks. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sat Oct 9 09:28:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13332 for ; Sat, 9 Oct 2004 09:28:10 -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 i99D1max058797; Sat, 9 Oct 2004 06:01: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 i99D1mWe058796; Sat, 9 Oct 2004 06:01:48 -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 i99D1m7x058790 for ; Sat, 9 Oct 2004 06:01:48 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.47] (adsl-64-142-13-68.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i99D1uFQ027332 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 9 Oct 2004 06:01:56 -0700 Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) From: Douglas Otis To: Greg Connor Cc: "william(at)elan.net" , MXCOMP In-Reply-To: <9768175.1097278464@[192.168.0.2]> References: <1097206667.16694.445.camel@ddev.mail-abuse.org> <9768175.1097278464@[192.168.0.2]> Content-Type: text/plain Message-Id: <1097326726.12208.123.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 09 Oct 2004 05:58:47 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-10-08 at 23:34, Greg Connor wrote: > [I removed spf-discuss from the cc: list, since Doug is not a member there > and his message therefore didn't appear on that list.] > > --Douglas Otis wrote: > > >| The purpose of the SUBMITTER parameter is to allow the SMTP client to > >| indicate to the server the address of the entity most recently > >| responsible for injecting a message into the e-mail transport stream. > > > > One possible view, assuming it is authenticated, would be the HELO > > domain is the entity most recently accountable for injecting the > > message. This provides a clear and strong definition. It also does not > > require a modification to SMTP for this information to be obtained early > > within the SMTP transaction and steers clear of many complexities. > > Doug's reply seems to indicate either a misunderstanding of the main point > behind SUBMITTER, or else he is trying to commandeer the discussion and > steer it back to his favorite topic of HELO verification. > > I consider it rude to take someone else's hard work and criticize it > because it doesn't match your own "pet" issue. But since I don't have > direct knowledge of Doug's motives here, perhaps it's appropriate to be > charitable here and assume a misunderstanding rather than intentional > insult and provocation. [for now] These were earnest comments aimed at providing a fully comparable result with few risks and changes to SMTP and with stronger identifications. > >| This document provides means to authenticate the DOMAIN of the > >| appropriate email address; it is not directed at the local-part. > > > > That is good, as the HELO domain does not have a local part. > > > >| A domain owner gets to determine which SMTP clients speak on behalf > >| of addresses within the domain; a responsible domain owner should not > >| authorize SMTP clients that will lie about local parts. > > > > If this were done using a list of root HELO names, the mailbox domain > > owner could easily describe which SMTP clients speak on behalf of this > > mailbox domain, always within a single DNS lookup. I don't understand > > what is meant by lying about local parts. It would make more sense had > > this said to limit the authorization of SMTP clients to those shared by > > other responsible mailbox domains. But as these mailbox domains must > > not be held accountable for this sharing, it would make even more sense > > to say only the HELO domain is to be held accountable for any abuses. > > > Continued discussion of HELO in this context gets us further from the topic > of the draft itself. HELO was not mentioned in the draft (other than the > response to EHLO should contain SUBMITTER in the capability list.) So, I > will try to respond to this without mentioning HELO. > > I have a pretty fair idea of what "clients that lie about local parts" > really means. It means that the domain owner should make sure that any > SMTP clients he chooses to authorize should check the local part against > the known/verifiable information for the user (such as SMTP AUTH, static > IP, pop-before-smtp, etc.) This prevents one customer of the service > provider from impersonating other users at the same service provider. Such assurance should not be considered the responsibility of the mailbox domain owner when the mail channel description is open-ended. In this case, there is no means to make assurances with respect to these local parts. This should not be overlooked, as this open-ended approach is very much needed to ensure delivery of much of the mail. Where the mail channel description has been declared the exclusive source of a mailbox domain, still this would assume each SMTP client is making mail channel checks and that each is able to constrain the use of the local part on behalf the specific domain. This seems to forgo the nature of mail being relayed where the mailbox domain owner does not always control all of these agents. In the case where the mail channel has been declared the exclusive source for the mailbox domain and where all the agents are controlled by the mailbox domain owner, there may be an expectation of the local part of the RFC2821 MailFrom being protected. This would be a special case that should not be assumed by the recipient. Although the marid-mpr draft makes the state of mail channel explicit and can also include the RFC2822 From, SPF does not provide this information, such that no presumptive expectations of even the mailbox domain itself being protected is possible. > (My previous message describes methods that ISPs might use to verify that > the localpart being claimed really is owned by the user being > authenticated. This is not new -- RFC 2476 says that the submit server > should verify if the user is really authorized to use that particular > return path -- William's draft is just applying something similar to the > submitter address.) > > > >| In case of email submission by end-user this address can be found in > >| "Sender:" header since RFC2822 specifies that Sender header represents > >| "agent responsible for actual transmission of the message" and if > >| Sender is not present then responsible party is email author listed > >| in "From:" header. > > > > Would it not be equivalent to saying the authenticated HELO domain plays > > the role of sender? > > No, it clearly would not. A message should only have one sender, but may > have multiple submitters on its way to destination, just as it may have > multiple hops for each submitter. The goal of establishing the mail channel by way of submitters can be equally achieved using a list of authenticated HELO root names referenced by the RFC2822 From or even the RFC2821 MailFrom as the message source. I don't want to lecture why it is bad to use the mail channel description to serve the dual role of authenticating the SMTP client. : ) > >In which case, the HELO root name list referenced > > Remainder of this paragraph ignored. > > >| In case of email list, the responsible party is mail list and the > >| address should be that of email list itself. > > > > Again, an authenticated HELO domain can play this role with much less > > chance of spoofing. In many cases, the HELO domain will be the same > > domain as the RFC2822 sending domain. > > I disagree with both statements. The HELO domain clearly cannot play the > role of SUBMITTER, because SUBMITTER is a mailbox, not a domain name. > Also, the same mail server may send messages on behalf of multiple > SUBMITTERS, but would require a RSET to change its HELO name. Also it is > pretty clearly not true that the HELO domain will be the same as the > sending domain, unless we are considering changing the meaning of HELO. This statement was aimed at the ease of mapping the mail channel in many cases. Yes, the HELO domain could change dependent upon the mailbox domain being relayed, but the reason for doing so would be to properly establish accountability. I contend accountability can not be shifted to a mailbox domain in any other manner. This name can also be directly authenticated whereas this is not possible with any other domain within the mail channel without making assumptions of the mail channel integrity. > Furthermore, I would point out that Doug's tone has changed here from > questioning (such as "One possible view" or "Would it not be equivalent") > to lecturing William and the other listmembers as to why *his* way works > better. This makes me believe that this is NOT all just a big > misunderstanding, and that the behavior of taking someone else's message > and commandeering it for his own purposes is indeed intentional. I had requested previously that William state the broader goals of this proposal. This was not to elicit attacks on possible motives, but rather a discussion of possible alternatives. What problem does this suite of proposals solve? Finding a means to the same end without a significant impact upon SMTP does not seem like commandeering for questionable purposes. I could say the contrary may more aptly apply. > If it is in fact intentional, I would like to point out that it is quite > rude, and I would go so far as to say that this sort of behavior was one of > the main stumbling blocks that made MARID fail. Stubbornly insisting that > one way is right, even if it doesn't have anything to do with the current > thread, and even if the idea you are describing is specifically excluded > from the current discussion, is not valid behavior for a collaborative > working group. (I know the WG chairs had a lot on their minds, but perhaps > they should have been more strict about not allowing such selfish behavior) The means to the same end was what I considered important in that this is stating a means to the same goal and my comments are directed to what I see as serious defects that can be mended. You seem to have abstracted something sinister in these comments. I think being stubborn would be a way of describing both views it would seem. Ignoring the problems does not make them disappear however. > >| In case of forwarding service, the address should be that of the > >| forwarding agent or that of a user of that forwarding agent, whose > >| settings caused email retransmission. > > > > Here again, an authenticated HELO domain can play this role with much > > less chance of spoofing. The use of the HELO domain does not require a > > modification to SMTP and provides a stronger and more secure named > > identity. > > > Further indication that we have moved from "not quite understanding" to > "disagreeing and lecturing"... Care to comment as to why this role would not be stronger with HELO than other derived names? > > The admonishments regarding the mailbox domain authorization of SMTP > > clients is entirely misplaced, as the administrator of the SMTP client > > must be held accountable, and this administrator is positively > > identified by the HELO domain. Any other domain reference would be > > based upon an unverifiable assumption of the mail channel integrity. > > > > For more details see: > > http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt > > > > -Doug > > > Looks like this is the essence of the sales pitch... Doug would prefer us > not to read William's draft and instead to pay more attention to his own. > No thanks. I am not a salesman making a pitch that could compare to those I have already heard. I find it unfortunate this is the typical depth of consideration given to potential downsides or their possible solutions. This is of shared goals but perhaps more focused upon ensuring accountability is reasonably strong for there to be the possibility of safely making assessments. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Oct 10 09:46:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10898 for ; Sun, 10 Oct 2004 09:46: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 i9AD99ue064136; Sun, 10 Oct 2004 06:09:09 -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 i9AD99vY064135; Sun, 10 Oct 2004 06:09:09 -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 i9AD8wxI064118 for ; Sun, 10 Oct 2004 06:09:00 -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 B46BD16CC3 for ; Sun, 10 Oct 2004 09:18:54 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) In-Reply-To: Your message of "Sat, 09 Oct 2004 05:58:47 PDT." <1097326726.12208.123.camel@localhost.localdomain> Date: Sun, 10 Oct 2004 09:18:54 -0400 Message-Id: <20041010131854.B46BD16CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > The means to the same end was what I considered important in that this > is stating a means to the same goal and my comments are directed to what > I see as serious defects that can be mended. You seem to have > abstracted something sinister in these comments. Everyone knows you prefer EHLO checking, and why. If you see flaws in a proposal, then it would be preferred to discuss those flaws, and only those flaws, in any thread centered around that proposal. Any reference to another method would be best left to one sentence, and a reference URL to an I-D proposal. When a thread is about topic X, and you spend a significant part of a message talking about topic Y, others can view that as trying to change the topic of conversation. Changing topics in the middle of a thread usually warrants a change of subject line. > I think being stubborn would be a way of describing both views it > would seem. I have seen people on this list discuss EHLO checking in threads with you. Other threads you join (like this one), which are on other topics, often end in discussing EHLO checks, with the same subject line. This can be viewed as thread hijacking. > Ignoring the problems does not make them disappear however. Accusing others of ignoring a problem because they don't like thread hijacking is missing the point. If a proposal has flaws, then the proof of those flaws doesn't need to include discussions of EHLO checking. Leave it out of the discussion, spend time talking about the flaws, and you're less likely to get accused of having sinister intent. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sun Oct 10 13:19:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25297 for ; Sun, 10 Oct 2004 13:19: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 i9AGq4Ws078599; Sun, 10 Oct 2004 09:52:04 -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 i9AGq4xd078598; Sun, 10 Oct 2004 09:52:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9AGq2QA078585 for ; Sun, 10 Oct 2004 09:52:03 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Sun, 10 Oct 2004 12:57:30 -0400 Received: from ([65.10.102.29]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 3597848390; Sun, 10 Oct 2004 12:57:29 -0400 Message-ID: <001101c4aee8$e1ec1e10$6401a8c0@hdev1> From: "Hector Santos" To: References: <20041010131854.B46BD16CC3@mail.nitros9.org> Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) Date: Sun, 10 Oct 2004 12:47:49 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I don't have any conflict of interest issues, in fact, my involvement has been 100% strictly on the technical merits as well as possible legal and social implications of the proposals. So would it be safe for me to discuss client domain issues and how it relates to SUBMITTER without getting accused of being rude or emotional? The fact is I did have some comments, but when you have others scrutinizing people's input, publicly ostracizing them, why should one even bother? There are four key issues with SUBMITTER: 1) Potential legal user privacy issues with the exposure of user addresses. It would be a major mistake for SMTP developers to open this Pandora Box when there is no technical reason to do so. See #2 2) Since this is a domain-level authentication scheme, only the domain is required to be exposed. Not the full address. This will solved #1. Note: The other possible solution is to use a responsible "postmaster" address to avoid the exposure of user's account addresses that was not introduced by the legitimate user himself. 3) Responsible domains must change at transition points where the original domain is no longer responsible. This is a real possibility during deployment where there will be a high degree of heterogeneous systems. We have seen it in practice where companies "explore" new advanced SMTP systems with new AVS concepts within their existing set or mix of SMTP software. If it was not addressed it needs to be added to the specs. If it was implied in the spec, it needs clarification. 4) Finally, to support SUBMITTER, any client machine domain authentication can not be violated. This (#4) was pretty much what Doug is pointing out. The IP must be secured if SUBMITTER is used, hence the machine domain and IP must be secured as well. In fact, in my own AVS scheme, this sort of mix policy conflict is a trigger for rejection. Hope this helps -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Alan DeKok" To: Sent: Sunday, October 10, 2004 9:18 AM Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) > > Douglas Otis wrote: > > The means to the same end was what I considered important in that this > > is stating a means to the same goal and my comments are directed to what > > I see as serious defects that can be mended. You seem to have > > abstracted something sinister in these comments. > > Everyone knows you prefer EHLO checking, and why. If you see flaws > in a proposal, then it would be preferred to discuss those flaws, and > only those flaws, in any thread centered around that proposal. Any > reference to another method would be best left to one sentence, and a > reference URL to an I-D proposal. > > When a thread is about topic X, and you spend a significant part of > a message talking about topic Y, others can view that as trying to > change the topic of conversation. Changing topics in the middle of a > thread usually warrants a change of subject line. > > > I think being stubborn would be a way of describing both views it > > would seem. > > I have seen people on this list discuss EHLO checking in threads > with you. Other threads you join (like this one), which are on other > topics, often end in discussing EHLO checks, with the same subject > line. This can be viewed as thread hijacking. > > > Ignoring the problems does not make them disappear however. > > Accusing others of ignoring a problem because they don't like thread > hijacking is missing the point. > > If a proposal has flaws, then the proof of those flaws doesn't need > to include discussions of EHLO checking. Leave it out of the > discussion, spend time talking about the flaws, and you're less likely > to get accused of having sinister intent. > > Alan DeKok. > > From owner-ietf-mxcomp@mail.imc.org Sun Oct 10 17:43:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16448 for ; Sun, 10 Oct 2004 17:43: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 i9ALCkSL001526; Sun, 10 Oct 2004 14:12: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 i9ALCklD001525; Sun, 10 Oct 2004 14:12:46 -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 i9ALCfKO001514 for ; Sun, 10 Oct 2004 14:12:41 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.47] (adsl-64-142-13-68.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i9ALChBt010090 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 10 Oct 2004 14:12:44 -0700 Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) From: Douglas Otis To: Alan DeKok Cc: ietf-mxcomp@imc.org In-Reply-To: <20041010131854.B46BD16CC3@mail.nitros9.org> References: <20041010131854.B46BD16CC3@mail.nitros9.org> Content-Type: text/plain Message-Id: <1097442574.839.297.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 10 Oct 2004 14:09:34 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-10-10 at 06:18, Alan DeKok wrote: > Douglas Otis wrote: > > The means to the same end was what I considered important in that this > > is stating a means to the same goal and my comments are directed to what > > I see as serious defects that can be mended. You seem to have > > abstracted something sinister in these comments. > > Everyone knows you prefer EHLO checking, and why. If you see flaws > in a proposal, then it would be preferred to discuss those flaws, and > only those flaws, in any thread centered around that proposal. Any > reference to another method would be best left to one sentence, and a > reference URL to an I-D proposal. > > When a thread is about topic X, and you spend a significant part of > a message talking about topic Y, others can view that as trying to > change the topic of conversation. Changing topics in the middle of a > thread usually warrants a change of subject line. There was about a draft submitted as indicated by the subject line. I read this draft and made comments directed at problems seen with the reasoning proffered to support of these substantial changes. I described the problem and offered a context to describe solutions. This was reviewing 18 lines of draft text with 36 lines of comments largely constrained to offering alternatives for the names attempted to be passed by Submitter. To understand the basis for Submitter seems to require reviewing the elemental goals, and how they can be safely achieved. These statements were to elicit a discussion on these basics. > > I think being stubborn would be a way of describing both views it > > would seem. > > I have seen people on this list discuss EHLO checking in threads > with you. Other threads you join (like this one), which are on other > topics, often end in discussing EHLO checks, with the same subject > line. This can be viewed as thread hijacking. This misses the points being made by suggesting this was about HELO domain name checks. An allowance for an open comparison of related problems and solutions for these problems is appropriate. Comments regarding suspected motives is inappropriate and do not dismiss the substance of these concerns. I have no desire for forums that ignore grave problems. This forum, if earnest in endeavor, should address, support, defend, or explain the basis for critical decisions. > > Ignoring the problems does not make them disappear however. > > Accusing others of ignoring a problem because they don't like thread > hijacking is missing the point. The topic Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt seems to be the ideal thread for comments related to concerns regarding the text of this draft and the stated aims. > If a proposal has flaws, then the proof of those flaws doesn't need > to include discussions of EHLO checking. This was not about EHLO checking. In fact, it has little to do with EHLO checking. It was about using a name list rather than an address list to overcome problems related to knowing when the list is open, dealing with the problems of an open list, enabling stronger preventions of spoofing and phishing, and establishing fair accountability for discovered abuse. When done properly, this removes the need for the entire Submitter proposal! Going into lecture mode, a name list rather than an address list solves many problems that place mail and DNS at serious risk as with SPF or Sender-ID. When implemented with a name list, this still allows tracking the sender by either the the From, or the MailFrom and largely makes the PRA algorithm unneeded, but still possible. > Leave it out of the discussion, spend time talking about the flaws, > and you're less likely to get accused of having sinister intent. I will be happy to limit discussion to specific areas, provided this does not artificially exclude valid solutions. Offering a solution to a problem also dismisses a view this problem is just a burden that must be endured as a cost for change. The goals for MARID were reasonable and there are possible solutions. SPF or Sender-ID/Submitter, as currently structured, are not reasonable solutions. Thank you for your advise. I know I must remain guarded. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Oct 10 18:40:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20654 for ; Sun, 10 Oct 2004 18:40:44 -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 i9AMFxM1005071; Sun, 10 Oct 2004 15:15: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 i9AMFx3e005070; Sun, 10 Oct 2004 15:15:59 -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 i9AMFw9g005064 for ; Sun, 10 Oct 2004 15:15:58 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i9AMWVee030679; Sun, 10 Oct 2004 15:32:31 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i9AMWV3G030676; Sun, 10 Oct 2004 15:32:31 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 10 Oct 2004 15:32:31 -0700 (PDT) From: "william(at)elan.net" To: Hector Santos cc: ietf-mxcomp@imc.org Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) In-Reply-To: <001101c4aee8$e1ec1e10$6401a8c0@hdev1> 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 Sun, 10 Oct 2004, Hector Santos wrote: > I don't have any conflict of interest issues, in fact, my involvement > has been 100% strictly on the technical merits as well as possible > legal and social implications of the proposals. So would it be safe > for me to discuss client domain issues and how it relates to > SUBMITTER without getting accused of being rude or emotional? > The fact is I did have some comments, but when you have others > scrutinizing people's input, publicly ostracizing them, why should > one even bother? You can safely assume that I look at all the comments and appreciate all the input. If I see that somebody has other agenda and is trying to hijack the thread, I do not respond and would not take their comments seriously, but for all other cases I do and appreciate you taking your time to review the proposal and would usually respond to the list or to whoever made the comments directly (but it maybe be up to week before I respond depending on how much other work I have). > There are four key issues with SUBMITTER: > > 1) Potential legal user privacy issues with the exposure of user addresses. > > It would be a major mistake for SMTP developers to open this Pandora Box > when there is no technical reason to do so. See #2 Currently user emails are exposed in "From", "Sender", "To", "Cc" and most important in "RCPT TO" and "MAIL FROM", none of those have brought privacy issues that could not be overcome. Now the exposure during forwarding by submitter is almost certain to be that final recepient would see in submitter the email of original recepient of the message (before forwarding) I don't think this too much of the privacy issue. But for those users that do care, the MTA can insert neutral mailbox like "postmaster" instead. > 2) Since this is a domain-level authentication scheme, only the domain is > required to be exposed. Not the full address. This will solved #1. > > Note: The other possible solution is to use a responsible "postmaster" > address to avoid the exposure of user's account addresses that was > not introduced by the legitimate user himself. All right I agree that it would be usefull to specifically mention possibility of using "responsible postmaster" and how it may solve certain privacy concerns. In the next version of the draft I will add paragrapth regading these issues. > 3) Responsible domains must change at transition points where the > original domain is no longer responsible. Clearly this is so. > This is a real possibility during deployment where there will be a > high degree of heterogeneous systems. We have seen it in practice > where companies "explore" new advanced SMTP systems with new > AVS concepts within their existing set or mix of SMTP software. > > If it was not addressed it needs to be added to the specs. If it was > implied in the spec, it needs clarification. This will be addressed and clarifed. > 4) Finally, to support SUBMITTER, any client machine domain authentication > can not be violated. That I do not understand. This is not about client machine, this is about submitter address which in my view more of "network-wide" authentication, i.e. it represents address of the person or entity at particular email network which was responsible for making changes to direction of the message and thus is the entity that re-submitted the email message for delivery. The actual machine that added submitter maybe several hops away but that machine would use email address which corresponds to spf record that that lists all ip address of other local machines on same network that could potentially be the ones sending email out of the net and to another. > This (#4) was pretty much what Doug is pointing out. The IP must be secured > if SUBMITTER is used, hence the machine domain and IP must be secured as > well. In fact, in my own AVS scheme, this sort of mix policy conflict is a > trigger for rejection. I do not disagree with premises that EHLO name must also be protected and that its bettter to check it before SUBMITTER or MAIL-FROM. In fact if you did not read my comments on what needs to be checked and how see: http://archives.listbox.com/spf-discuss@v2.listbox.com/200409/0978.html But I do disagree that "IP must be secured if SUBMITTER is used", I don't see it as prerequisite. Either SMTP Client knows about the ip and considers it to be machine on local network (i.e. its agent of the SMTP Client) and then EHLO check does not matter (unless somebody hijacked the space...) or we have unknown ip of some server on another network and we can assume that server to be an agent of submitter and thus do spf check of submitter and expect that ip address to verify. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam and Email Security Research Worksite: http://www.elan.net/~william/emailsecurity/ From owner-ietf-mxcomp@mail.imc.org Mon Oct 11 10:50:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11713 for ; Mon, 11 Oct 2004 10:50: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 i9BE0G0f099743; Mon, 11 Oct 2004 07:00: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 i9BE0G7B099742; Mon, 11 Oct 2004 07:00:16 -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 i9BE0FIB099725 for ; Mon, 11 Oct 2004 07:00:15 -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 6C32216CC3 for ; Mon, 11 Oct 2004 10:10:17 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Communication styles (was Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) ) In-Reply-To: Your message of "Sun, 10 Oct 2004 14:09:34 PDT." <1097442574.839.297.camel@localhost.localdomain> Date: Mon, 11 Oct 2004 10:10:17 -0400 Message-Id: <20041011141017.6C32216CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > There was about a draft submitted as indicated by the subject line. I > read this draft and made comments ... My message was clear that everyone understood you did that. The problem was when you appeared to be doing more. >> [ EHLO && thread hijacking ] > > This misses the points being made by suggesting this was about HELO > domain name checks. An allowance for an open comparison of related > problems and solutions for these problems is appropriate. Then start a new thread which is intended to talk about open comparisons. > Comments regarding suspected motives is inappropriate and do not > dismiss the substance of these concerns. There was no attempt to dismiss the substance of your concerns. There were attempts to get you to realize that threads allegedly about a topic should remain on that topic, or should change the subject line. (As has been done here) > This forum, if earnest in endeavor, should address, support, > defend, or explain the basis for critical decisions. This can be done without turning any topic to EHLO checking. > Thank you for your advise. I know I must remain guarded. I do not ask you to remain guarded. I ask you to expose any and all flaws in proposals. This exposure does not require repeated statements as to the benefits of other proposals. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Oct 11 18:41:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06636 for ; Mon, 11 Oct 2004 18:41: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 i9BM9qXc044683; Mon, 11 Oct 2004 15:09: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 i9BM9qAD044682; Mon, 11 Oct 2004 15:09:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BM9psf044669 for ; Mon, 11 Oct 2004 15:09:51 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 89C4A414C6; Mon, 11 Oct 2004 15:09:50 -0700 (PDT) Subject: Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd) From: Douglas Otis To: "william(at)elan.net" Cc: Hector Santos , MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1097532590.7607.100.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 11 Oct 2004 15:09:50 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-10-10 at 15:32, william(at)elan.net wrote: > On Sun, 10 Oct 2004, Hector Santos wrote: > > > I don't have any conflict of interest issues, in fact, my involvement > > has been 100% strictly on the technical merits as well as possible > > legal and social implications of the proposals. So would it be safe > > for me to discuss client domain issues and how it relates to > > SUBMITTER without getting accused of being rude or emotional? > > The fact is I did have some comments, but when you have others > > scrutinizing people's input, publicly ostracizing them, why should > > one even bother? > > You can safely assume that I look at all the comments and appreciate all > the input. If I see that somebody has other agenda and is trying to > hijack the thread, I do not respond and would not take their comments > seriously, but for all other cases I do and appreciate you taking your > time to review the proposal and would usually respond to the list or > to whoever made the comments directly (but it maybe be up to week before > I respond depending on how much other work I have). > > > There are four key issues with SUBMITTER: > > > > 1) Potential legal user privacy issues with the exposure of user addresses. > > > > It would be a major mistake for SMTP developers to open this Pandora Box > > when there is no technical reason to do so. See #2 > > Currently user emails are exposed in "From", "Sender", "To", "Cc" and most > important in "RCPT TO" and "MAIL FROM", none of those have brought privacy > issues that could not be overcome. > > Now the exposure during forwarding by submitter is almost certain to be > that final recepient would see in submitter the email of original recepient > of the message (before forwarding) I don't think this too much of the > privacy issue. But for those users that do care, the MTA can insert > neutral mailbox like "postmaster" instead. > > > 2) Since this is a domain-level authentication scheme, only the domain is > > required to be exposed. Not the full address. This will solved #1. > > > > Note: The other possible solution is to use a responsible "postmaster" > > address to avoid the exposure of user's account addresses that was > > not introduced by the legitimate user himself. > > All right I agree that it would be usefull to specifically mention > possibility of using "responsible postmaster" and how it may solve > certain privacy concerns. In the next version of the draft I will add > paragrapth regading these issues. > > > 3) Responsible domains must change at transition points where the > > original domain is no longer responsible. > Clearly this is so. > > > This is a real possibility during deployment where there will be a > > high degree of heterogeneous systems. We have seen it in practice > > where companies "explore" new advanced SMTP systems with new > > AVS concepts within their existing set or mix of SMTP software. > > > > If it was not addressed it needs to be added to the specs. If it was > > implied in the spec, it needs clarification. > > This will be addressed and clarified. > > > 4) Finally, to support SUBMITTER, any client machine domain authentication > > can not be violated. > > That I do not understand. > > This is not about client machine, this is about submitter address which > in my view more of "network-wide" authentication, i.e. it represents > address of the person or entity at particular email network which > was responsible for making changes to direction of the message and thus > is the entity that re-submitted the email message for delivery. The > actual machine that added submitter maybe several hops away but that > machine would use email address which corresponds to spf record that > that lists all ip address of other local machines on same network that > could potentially be the ones sending email out of the net and to another. > > > This (#4) was pretty much what Doug is pointing out. The IP must be secured > > if SUBMITTER is used, hence the machine domain and IP must be secured as > > well. In fact, in my own AVS scheme, this sort of mix policy conflict is a > > trigger for rejection. > > I do not disagree with premises that EHLO name must also be protected and > that its bettter to check it before SUBMITTER or MAIL-FROM. In fact if > you did not read my comments on what needs to be checked and how see: > http://archives.listbox.com/spf-discuss@v2.listbox.com/200409/0978.html > > But I do disagree that "IP must be secured if SUBMITTER is used", I don't > see it as prerequisite. Either SMTP Client knows about the ip and considers > it to be machine on local network (i.e. its agent of the SMTP Client) > and then EHLO check does not matter (unless somebody hijacked the space...) > or we have unknown ip of some server on another network and we can assume > that server to be an agent of submitter and thus do spf check of submitter > and expect that ip address to verify. On point 1 that Hector made, this system must be able to run with an "open-ended" list without inviting exploits. This is needed to allow providers an ability to permit any mailbox address in the messages sent. The dual role of using the mail-channel address list as a means of both authorizing the message and the client unfortunately makes these open lists attractive for spammers due to unfair accountability. This freedom is lost once these open lists become so inundated as to be unusable. This also makes for a painful transition and an eventual loss of freedom. The use of an address list comes with a substantial risk which unfortunately is the premise that SPF and Sender-ID use. The dual use of this list invites exploits when described as "open-ended" but there is nothing within the SPF protocol to detect this "open-ended" state. Do you understand this problem and do you have a solution? As related to Submitter, to prevent spoofing and allow the use of "open-ended" lists, there must be a name that can not be spoofed in this environment. This mechanism will likely be needed for at least half a decade. There are no headers within the email message that can be directly authenticated. Even Submitter exposing these early in the transaction does not decease the ability to spoof these names in a partially open environment. There is nothing within the SPF protocol draft to ensure exclusion of repeated label lookups. A popular version of Bind also makes this oversight. The use of a script parser makes this problem worse. Do you understand this problem and can you explain how this is overcome? The grave problems created by the use of address lists with respect to DNS and network integrity is solved by adopting a name list to describe the mail-channel. Financial institutions that are heavily phished, are not using mailing lists, and have warned their customers about their messages not able to be forwarded, can close their lists. The solution, for "open-ended" list exploitation as well as the DNS and network related issues, is found by using a name list. Through the use of a name list for the mail channel, the lists can remain open for the majority of users for a smooth transition, and closed when needed. The dual use address list is extremely problematic in this area. Do you understand the problem and do you have a solution for this? The expectations of there being a flag day or some key point where all lists will suddenly become closed have not confronted issues in this transition to full compliance. This compliance is put into greater doubt should Microsoft spend a decade battling over these issues in court. Once these lists are seen as normally being "open-ended," then the selection of the "accountable name" used in Submitter should be reconsidered. A strong name is needed that can be directly authenticated in order to prove protection against spoofing and phishing. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Oct 22 20:07:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15508 for ; Fri, 22 Oct 2004 20:07: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 i9MNZfXm040034; Fri, 22 Oct 2004 16:35: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 i9MNZf04040033; Fri, 22 Oct 2004 16:35: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 i9MNZfIB040027 for ; Fri, 22 Oct 2004 16:35:41 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i9MNsPQY008679 for ; Fri, 22 Oct 2004 16:54:25 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i9MNsPmr008675 for ; Fri, 22 Oct 2004 16:54:25 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 22 Oct 2004 16:54:25 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Guess what faciliated this former WG's area director to write this up ... (and you can also wonder what would have happened if this was already an RFCat the time of WG closure) ---------- Forwarded message ---------- Date: Fri, 22 Oct 2004 14:41:33 -0700 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org Cc: rfc-editor@rfc-editor.org Subject: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF A new Request for Comments is now available in online RFC libraries. RFC 3929 Title: Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF Author(s): T. Hardie Status: Experimental Date: October 2004 Mailbox: hardie@qualcomm.com Pages: 11 Characters: 26493 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-hardie-alt-consensus-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3929.txt This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="RFC-INFO@RFC-EDITOR.ORG" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="rfc3929.txt"; SITE="ftp.isi.edu"; ACCESS-TYPE=anon-ftp; DIRECTORY=in-notes Content-ID: --OtherAccess-- --NextPart Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --NextPart-- From owner-ietf-mxcomp@mail.imc.org Fri Oct 22 21:32:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21116 for ; Fri, 22 Oct 2004 21:32:21 -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 i9N18Gqa056361; Fri, 22 Oct 2004 18:08: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 i9N18G6k056360; Fri, 22 Oct 2004 18:08:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from lakermmtao08.cox.net (lakermmtao08.cox.net [68.230.240.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9N18FxN056334 for ; Fri, 22 Oct 2004 18:08:16 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from A31P ([68.100.55.187]) by lakermmtao08.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041023010813.XQY28744.lakermmtao08.cox.net@A31P>; Fri, 22 Oct 2004 21:08:13 -0400 From: "Scott Hollenbeck" To: "'william\(at\)elan.net'" , Subject: RE: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) Date: Fri, 22 Oct 2004 21:08:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcS4kNC8/cJEIT1oQ6igpCR9PpdFKQACzGOA Message-Id: <20041023010813.XQY28744.lakermmtao08.cox.net@A31P> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: william(at)elan.net [mailto:william@elan.net] > Sent: Friday, October 22, 2004 7:54 PM > To: ietf-mxcomp@imc.org > Subject: RFC 3929 on Alternative Decision Making Processes > for Consensus-Blocked Decisions in the IETF (fwd) > > > Guess what faciliated this former WG's area director to write > this up ... > (and you can also wonder what would have happened if this was > already an RFCat the time of WG closure) This document was first published in May 2003, long before MARID existed. IETF last call started in June 2004. It was approved by the IESG in July 2004. In other words, the MARID finale had _nothing_ to do with it. -Scott- From owner-ietf-mxcomp@mail.imc.org Sat Oct 23 08:52:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24018 for ; Sat, 23 Oct 2004 08:52:17 -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 i9NCL8hJ080799; Sat, 23 Oct 2004 05:21:08 -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 i9NCL8OI080798; Sat, 23 Oct 2004 05:21:08 -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 i9NCL7S1080792 for ; Sat, 23 Oct 2004 05:21:07 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i9NCdtcZ008091; Sat, 23 Oct 2004 05:39:55 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i9NCdtp6008087; Sat, 23 Oct 2004 05:39:55 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 23 Oct 2004 05:39:55 -0700 (PDT) From: "william(at)elan.net" To: Scott Hollenbeck cc: ietf-mxcomp@imc.org Subject: RE: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) In-Reply-To: <20041023010813.XQY28744.lakermmtao08.cox.net@A31P> 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: > This document was first published in May 2003, long before MARID existed. > IETF last call started in June 2004. It was approved by the IESG in July > 2004. In other words, the MARID finale had _nothing_ to do with it. Ah, good to know. I was afraid what happened at MARID was a very special case of how IETF system failed. I guess it is not the first time and IETF has seen it before... Still I don't particilarly like to see solution pushed through when there is no consensus on it and especially when there are strong corporate interests involved involved in the specific proposal. I think IETF should allow for determening rouch consensus not only for any specific proposal but also process to find if there is rough consensus "against" the proposal. In the case where it happens (i.e. when there is not a 50/50 split) the proposal should not be pushed through with this new "alternative decision making process". -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Tue Oct 26 18:48:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17480 for ; Tue, 26 Oct 2004 18:48: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 i9QLt4XK045388; Tue, 26 Oct 2004 14:55:04 -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 i9QLt4sw045387; Tue, 26 Oct 2004 14:55:04 -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 i9QLsxo5045323 for ; Tue, 26 Oct 2004 14:55:03 -0700 (PDT) (envelope-from matthew@elvey.com) Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id EF024C34B5D for ; Tue, 26 Oct 2004 17:54:56 -0400 (EDT) X-Sasl-enc: rmNkioq0va+NyZ8T/eqoNg 1098827694 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 0722D570159; Tue, 26 Oct 2004 17:54:53 -0400 (EDT) Message-ID: <417EC829.4030509@elvey.com> Date: Tue, 26 Oct 2004 14:56:57 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) References: In-Reply-To: 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 Generally applicable comments on 3929: 1)This scheme would put excessive power in the hands of the few: the Chairs, who are appointed (indirectly) by the elite few who can pay non-trivial sums of money to attend lots of IETF meetings, such sums generally provided by large corporations with entrenched interests. It also further empowers the chairs to determine whether rough consensus has been reached. Increasing the power of entrenched interests is DESTRUCTIVE. This plan, if implemented, will make decision-making in the IETF WORSE than it is now. 2)A major failure of , e.g. the MARID WG (including the Chairs) was the failure to encourage/require a cost (in the broadest sense of the term) analysis of the proposals. This scheme fails to encourage that too. Instead it just says "the working group chair(s) should also make an explicit call for consensus, summarizing the technical issues and the choice to be made." Cost analysis is not a technical issue. (But I hope it's in MARID's new charter if it gets re-chartered! (Anyone pushing for that?)) 3)The author fails to adequately consider the benefits of experimentation: continued experimentation and discussion is removed as an option. 4)In general, where there are competing proposals, instead of 3929, there should be a push for documents providing things such as pros and cons, cost-benefit analyses, rationale, and context that will help inform the membership and lead to consensus. MARID specific comment: What happened here doesn't seem to be a failure, but rather was a success in the following sense: There was not sufficient maturity in the proposals for a rough consensus to be reached that the proposals were adequate to meet the bare minimum of goals that they needed to meet. The process brought the fact to light that the proposals were inadequate. Many of us weren't aware of this early on. 3929 seems to assume that a failure to reach a rough consensus must mean there's a problem in the process, when in fact it could be in the proposals. >Date: Fri, 22 Oct 2004 >From: rfc-editor >To: ietf-announce >Subject: RFC 3929 ... > Odd that the post to IETF-announce came 3 months after the IESG's approval. From owner-ietf-mxcomp@mail.imc.org Wed Oct 27 07:55:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27675 for ; Wed, 27 Oct 2004 07:55:21 -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 i9RBHCwv029047; Wed, 27 Oct 2004 04:17: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 i9RBHClJ029046; Wed, 27 Oct 2004 04:17:12 -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.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RBH7fl028939 for ; Wed, 27 Oct 2004 04:17:07 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 27 Oct 2004 07:16:59 -0400 id 001EB0F8.417F83AB.00004A8E Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[10.0.1.3]; remoteip=::ffff:64.83.8.178; remotehost=; helo=[10.0.1.3]; receiver=zak.ecotroph.net; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=andy@hxr.us; remoteip=::ffff:64.83.8.178; remotehost=; helo=[10.0.1.3]; receiver=zak.ecotroph.net; In-Reply-To: <417EC829.4030509@elvey.com> References: <417EC829.4030509@elvey.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: MXCOMP From: Andrew Newton Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) Date: Wed, 27 Oct 2004 07:16:57 -0400 To: Matthew Elvey X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Oct 26, 2004, at 5:56 PM, Matthew Elvey wrote: > This scheme would put excessive power in the hands of the few: the > Chairs, who are appointed (indirectly) by the elite few who can pay > non-trivial sums of money to attend lots of IETF meetings, such sums > generally provided by large corporations with entrenched interests. Do you attend the IETF meetings on a regular basis? I ask this because at the IETF meetings I attend I have met a non-trivial number of people who work for non-profits, government agencies, academic institutions, and one-man consulting shops. I am good friends with several individuals who paid their own way to IETF meetings while unemployed, including trips abroad. While funding trips to the IETF requires real money, characterizing those who do as the "elite few" is a mischaracterization. -andy From owner-ietf-mxcomp@mail.imc.org Wed Oct 27 10:16:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06410 for ; Wed, 27 Oct 2004 10:16: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 i9RDgwRt064205; Wed, 27 Oct 2004 06:42: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 i9RDgw1w064204; Wed, 27 Oct 2004 06:42:58 -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 i9RDgnfJ064153 for ; Wed, 27 Oct 2004 06:42:51 -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 4471716C91 for ; Wed, 27 Oct 2004 09:53:20 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) In-Reply-To: Your message of "Tue, 26 Oct 2004 14:56:57 PDT." <417EC829.4030509@elvey.com> Date: Wed, 27 Oct 2004 09:53:20 -0400 Message-Id: <20041027135320.4471716C91@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Matthew Elvey wrote: > 1)This scheme would put excessive power in the hands of the few: the > Chairs, who are appointed (indirectly) by the elite few who can pay > non-trivial sums of money to attend lots of IETF meetings, such sums > generally provided by large corporations with entrenched interests. Even if what Andrew said wasn't true, how do you propose to fix this? I don't want to discuss that here, as other lists are more appropriate. But if you're tearing down the existing system without proposing a new one, that's no way to move forward. > 2)A major failure of , e.g. the MARID WG (including the Chairs) was the > failure to encourage/require a cost (in the broadest sense of the term) > analysis of the proposals. IMHO the failure to a acheive consensus was guaranteed once the consensus was to look at RFC 2822 identities. > 3)The author fails to adequately consider the benefits of > experimentation: continued experimentation and discussion is removed as > an option. .... as part of the IETF process. Nothing prevents anyone from experimenting and discussing outside of the IETF. > 4)In general, where there are competing proposals, instead of 3929, > there should be a push for documents providing things such as pros and > cons, cost-benefit analyses, rationale, and context that will help > inform the membership and lead to consensus. Such documents will simply move the failure to acheive consensus to a different position in the process. Witness the "SPF is cheap to deploy", versus "no, SPF is expensive to deploy" arguments. > 3929 seems to assume that a failure to reach a rough consensus must > mean there's a problem in the process, when in fact it could be in > the proposals. It's the same thing. The process didn't empower participants to discover problems in the proposals. Why that happened is another story. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Oct 27 11:11:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12821 for ; Wed, 27 Oct 2004 11:11: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 i9REJi47071532; Wed, 27 Oct 2004 07:19:44 -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 i9REJixJ071531; Wed, 27 Oct 2004 07:19:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [195.30.85.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9REJh4j071518 for ; Wed, 27 Oct 2004 07:19:43 -0700 (PDT) (envelope-from bulk@mehnle.net) Received: from nova (pD9E4F219.dip.t-dialin.net [::ffff:217.228.242.25]) (AUTH: LOGIN lists@mehnle.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by io.link-m.de with esmtp; Wed, 27 Oct 2004 16:19:34 +0200 id 0000BAA4.417FAE76.000033FE Reply-To: julian@mehnle.net From: "Julian Mehnle" To: "MXCOMP" Subject: RE: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) Date: Wed, 27 Oct 2004 16:19:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: <417EC829.4030509@elvey.com> Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Matthew Elvey [matthew@elvey.com] wrote: > MARID specific comment: > What happened here doesn't seem to be a failure, but rather was a > success in the following sense: There was not sufficient maturity in the > proposals for a rough consensus to be reached that the proposals were > adequate to meet the bare minimum of goals that they needed to meet. > The process brought the fact to light that the proposals were > inadequate. Many of us weren't aware of this early on. 3929 seems to > assume that a failure to reach a rough consensus must mean there's a > problem in the process, when in fact it could be in the proposals. ...or in the participants' objectives. Or in all three of them. From owner-ietf-mxcomp@mail.imc.org Wed Oct 27 11:11:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12839 for ; Wed, 27 Oct 2004 11:11:10 -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 i9REQ1Bi072417; Wed, 27 Oct 2004 07:26:01 -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 i9REQ10O072416; Wed, 27 Oct 2004 07:26:01 -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 i9REQ0N2072408 for ; Wed, 27 Oct 2004 07:26:00 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i9REjQwJ021441; Wed, 27 Oct 2004 07:45:26 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i9REjQn7021438; Wed, 27 Oct 2004 07:45:26 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 27 Oct 2004 07:45:26 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: Matthew Elvey , MXCOMP Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) In-Reply-To: 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 Wed, 27 Oct 2004, Andrew Newton wrote: > > This scheme would put excessive power in the hands of the few: the > > Chairs, who are appointed (indirectly) by the elite few who can pay > > non-trivial sums of money to attend lots of IETF meetings, such sums > > generally provided by large corporations with entrenched interests. > > Do you attend the IETF meetings on a regular basis? I ask this because > at the IETF meetings I attend I have met a non-trivial number of people > who work for non-profits, government agencies, academic institutions, > and one-man consulting shops. I am good friends with several > individuals who paid their own way to IETF meetings while unemployed, > including trips abroad. While funding trips to the IETF requires real > money, characterizing those who do as the "elite few" is a > mischaracterization. I'm one of those who pays for conferenses out of my own money and its hard thing and I always try to shave off as much of expense as possible (staying in smaller $50/day hotels if possible, driving my car to the conference if its nearby, etc). The conference itself is also expensive for those of us not working under large corporation - especailly if we have to attend it 3 times a year. Its good thing for me lately that my main clients are all doing ok (.bust seems to have stabilized into slow growth). Still Mathew is right that elite that come to every meeting are the one that make most of the decisions. Those others of us there can advise them and show support or lock of it and hope the do the right thing but if you do not attent the meeting you can't even vote the person out of IESG - do remember being able to part of selection commitee that decides on area director posts, you need to have attended 3 out of 5 meetings in person. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Oct 27 11:34:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16027 for ; Wed, 27 Oct 2004 11:34: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 i9RF4U5H081093; Wed, 27 Oct 2004 08:04:30 -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 i9RF4UTd081092; Wed, 27 Oct 2004 08:04:30 -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 i9RF4TY2081082 for ; Wed, 27 Oct 2004 08:04:29 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i9RF4QJn028810; Wed, 27 Oct 2004 08:04:26 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 27 Oct 2004 08:04:26 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Matthew Elvey'" , MXCOMP Subject: RE: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) Date: Wed, 27 Oct 2004 08:04:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Matthew Elvey > Generally applicable comments on 3929: > 1)This scheme would put excessive power in the hands of the few: the > Chairs, who are appointed (indirectly) by the elite few who can pay > non-trivial sums of money to attend lots of IETF meetings, such sums > generally provided by large corporations with entrenched > interests. I don't think that you really identify the problem here. I think that you certainly have a point on the cost issue. Even though IETF does not have a membership cost like OASIS or W3C the cost of attending meetings is a significant barrier. But I don't think that the right to participate in NOMCON is that significant. NOMCON is deliberately constructed in a way that makes the return of incumbents all but inevitable. If you choose ten people at random from an organization the chances that they will agree on upsetting the status quo is very low. Its exactly what you expect from a group of academics, its a tenure system. Its also what you would expect from a group of engineers, an environment where accountability and deadlines are always secondary to idealized technical perfection. I do not beleive that the outcome of MARID would have been any different under any other chairs. I do however think that the outcome would have been likely to have been better in a system where the group choose its own chairs rather than having them imposed by the exstablishment. This is not because I think the chairs would have been different, I suspect that the same people would have volunteered and I doubt that the election would have been contested, but the group members would have felt that they have a stake in the management of the group. People are more likely to accept decisions made by people they feel they have a stake in choosing - even when they voted for somebody else. > MARID specific comment: > What happened here doesn't seem to be a failure, but rather was a > success in the following sense: There was not sufficient maturity in the > proposals for a rough consensus to be reached that the proposals were > adequate to meet the bare minimum of goals that they needed to meet. I disagree. SenderID/SPF is currently in deployment and is working just fine in production. Maturity was not the problem. I think that there was a mismatch of expectations between people who thought that the purpose of the group was to agree on a refinement of an existing specification that had already achieved a very large degree of industry buy in and those who thought that it was an open forum to propose their alternative idea. I have never been in a standards group of the second type that has succeeded. In every case that a group has suceeded the starting point has been a specification that was already largely complete. > The process brought the fact to light that the proposals were > inadequate. Many of us weren't aware of this early on. 3929 > seems to > assume that a failure to reach a rough consensus must mean there's a > problem in the process, when in fact it could be in the proposals. I think that as a practical matter the issue of acceptable IPR terms should not be discussed at the working group level where the bargaining leverage is least. I found it practically impossible to follow the alledged discussion of technical issues due to the constant heckling and deliberate recycling of false positions. The lack of consensus inside the group did not reflect the solid industry consensus for SPF/SenderID that had already been established before MARID started. It may not seem fair but an engineer who is representing the issues of an ISP with 20 million customers has a rather larger stake in the outcome than an individual contributor responsible to nobody but themselves. From owner-ietf-mxcomp@mail.imc.org Wed Oct 27 14:21:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29083 for ; Wed, 27 Oct 2004 14:21:36 -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 i9RHYS2t016727; Wed, 27 Oct 2004 10:34: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 i9RHYSaO016726; Wed, 27 Oct 2004 10:34:28 -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 ESMTP id i9RHYRpt016709 for ; Wed, 27 Oct 2004 10:34:27 -0700 (PDT) (envelope-from sb0-0718cc3a79-johnl@iecc.com) Received: (qmail 12558 invoked by uid 100); 27 Oct 2004 17:34:30 -0000 Date: 27 Oct 2004 17:34:30 -0000 Message-ID: <20041027173430.12557.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) In-Reply-To: <417EC829.4030509@elvey.com> Organization: I.E.C.C., Trumansburg NY USA Cc: matthew@elvey.com 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 > 1)This scheme would put excessive power in the hands of the few: the > Chairs, who are appointed (indirectly) by the elite few who can pay > non-trivial sums of money to attend lots of IETF meetings, such sums > generally provided by large corporations with entrenched interests. A fair number of us go to IETF meetings and pay partly or entirely out of our own pockets. We stay in cheaper hotels or with relatives, but we go. If the IETF process is important to you, you should also go. If it's not that important to you, that's fine, too. But the category "very important but not worth my spending any money" simply doesn't exist. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Wed Oct 27 16:21:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09904 for ; Wed, 27 Oct 2004 16:21: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 i9RJqIfa047616; Wed, 27 Oct 2004 12:52:18 -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 i9RJqIba047615; Wed, 27 Oct 2004 12:52:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RJqGLO047603 for ; Wed, 27 Oct 2004 12:52:17 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 54074 invoked by uid 1013); 27 Oct 2004 19:52:20 -0000 Date: Wed, 27 Oct 2004 21:52:20 +0200 From: Markus Stumpf To: MXCOMP Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) Message-ID: <20041027195220.GI9500@Space.Net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 27, 2004 at 08:04:23AM -0700, Hallam-Baker, Phillip wrote: > recycling of false positions. The lack of consensus inside the group > did not reflect the solid industry consensus for SPF/SenderID that > had already been established before MARID started. Hmmm ... but the lack of consensus was driven by the patent policy Microsoft had. Even AOL refrained from supporting Sender-Id. But the last two days (german) IT news are fill with press reports that MS will loosen the patent policy and that AOL jumped back in. ... and that the IETF is now supporting Sender-Id? Am I missing something? \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" From owner-ietf-mxcomp@mail.imc.org Wed Oct 27 16:24:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10211 for ; Wed, 27 Oct 2004 16:24: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 i9RJkvWc046580; Wed, 27 Oct 2004 12:46:57 -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 i9RJkv2k046579; Wed, 27 Oct 2004 12:46:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RJkuZf046502 for ; Wed, 27 Oct 2004 12:46:56 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 54022 invoked by uid 1013); 27 Oct 2004 19:46:46 -0000 Date: Wed, 27 Oct 2004 21:46:46 +0200 From: Markus Stumpf To: John Levine Cc: ietf-mxcomp@imc.org Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) Message-ID: <20041027194646.GH9500@Space.Net> References: <417EC829.4030509@elvey.com> <20041027173430.12557.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041027173430.12557.qmail@xuxa.iecc.com> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 27, 2004 at 05:34:30PM -0000, John Levine wrote: > A fair number of us go to IETF meetings and pay partly or entirely out > of our own pockets. We stay in cheaper hotels or with relatives, but > we go. If the IETF process is important to you, you should also go. > If it's not that important to you, that's fine, too. But the category > "very important but not worth my spending any money" simply doesn't > exist. What you all seem to forget is that you live in the US or at least on the American continent where most of the meetings happen. Paying about half of a months income (after tax) for flight, hotel and the rest to attend one meeting and spending about half or more of my vacation days per year to travel to IETF meetings is more than I can and am willing to afford. And with the current procedure of entry to the USA for foreigners I personally feel it is kind of a frivolity to still have meetings in the USA. I wait for the time to come when you get tatooed and a chip implanted or one will not be allowed to entry. Despite the fact that least 3 or the authors of input documents to the MARID group were not from the American continent there wasn't even a poll about where to hold the interim meeting. We were presented that fact that the interim meetings tales place at this and that location and that was it. And on the meeting showed up people and names I have never seen in emails to this list or take part in a discussion but they were part of the dicision making process. Maybe if the meeting had been at XY Company and they would have had their own proposal and some 100 employees had shown up at the meeting we would have had a completely other result. This is not the topic of this (ex-) group but these are problems that IMHO showed up with this group and had IMHO quite some influence onm the results. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" From owner-ietf-mxcomp@mail.imc.org Wed Oct 27 18:46:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24792 for ; Wed, 27 Oct 2004 18:46: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 i9RMAPXG079267; Wed, 27 Oct 2004 15:10:25 -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 i9RMAPtF079266; Wed, 27 Oct 2004 15:10:25 -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 i9RMAPJh079260 for ; Wed, 27 Oct 2004 15:10:25 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9RMARxk003607; Wed, 27 Oct 2004 15:10:27 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <476C9LVQ>; Wed, 27 Oct 2004 15:10:27 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Markus Stumpf'" , MXCOMP Subject: RE: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) Date: Wed, 27 Oct 2004 15:10:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Markus Stumpf > On Wed, Oct 27, 2004 at 08:04:23AM -0700, Hallam-Baker, Phillip wrote: > > recycling of false positions. The lack of consensus inside the group > > did not reflect the solid industry consensus for SPF/SenderID that > > had already been established before MARID started. > > Hmmm ... but the lack of consensus was driven by the patent policy > Microsoft had. Even AOL refrained from supporting Sender-Id. If that was the only issue it could have been kicked up to the IESG to sort out. The point I was making is that an individual WG should not be making policy for the IETF here. First we can't bind the community to terms it will reject, second we have negligible negotiating leverage. Large companies recognize that patents are mostly a zero or less than zero sum game for them. It is not attractive for such a company to license its own patents on liberal terms unless it knows that others will do likewise in the areas they have patents. If the IETF policy on IPR was clear then we would not have needed the discussion. Phill From owner-ietf-mxcomp@mail.imc.org Thu Oct 28 04:04:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17138 for ; Thu, 28 Oct 2004 04:04:31 -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 i9S7R56m053284; Thu, 28 Oct 2004 00:27: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 i9S7R56w053283; Thu, 28 Oct 2004 00:27:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9S7R4Ms053230 for ; Thu, 28 Oct 2004 00:27:04 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i9S7RhfY005705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Oct 2004 03:27:44 -0400 Subject: RE: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) From: Paul Iadonisi To: MXCOMP In-Reply-To: References: Content-Type: text/plain Message-Id: <1098948211.10639.73.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.plus.03.pri) Date: Thu, 28 Oct 2004 03:23:32 -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 Wed, 2004-10-27 at 11:04, Hallam-Baker, Phillip wrote: [snip] > I found it practically impossible to follow the alledged discussion > of technical issues due to the constant heckling and deliberate > recycling of false positions. Hmm. Heckling and deliberating recycling of false positions. I, as one who participated in some of the last call discussion don't appreciate your revisionist history, Phil. As to the heckling, if you are referring to anti-Microsoft rants, those were actual minimal due to the fact that when they appeared, the guilty posters were roundly chastised by the co-chairs. What remained was good reasoned discussion of a specific deployment problem due to IPR issues. As to the so-called 'false positions', I can only reply in disbelief that you simply assert that those with whom you disagreed were simply wrong. Such arrogance. Arguments were repeated when they were methodically ignored by those who wanted to sweep the significant deployment IPR problem under the rug. I repeated over and over again that we had three lawyers' opinions that agreed that the patent license was unacceptable and zero lawyers' opinions that it was acceptable for a reason. It was because no one had directly responded to it. When you have an argument that carries a lot of weight that is being ignored, it bears repeating. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Thu Oct 28 09:47:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12942 for ; Thu, 28 Oct 2004 09:47: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 i9SCwqAT052320; Thu, 28 Oct 2004 05:58: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 i9SCwqh3052319; Thu, 28 Oct 2004 05:58:52 -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 i9SCwdQ3052305 for ; Thu, 28 Oct 2004 05:58:52 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 8132526C077; Thu, 28 Oct 2004 14:58:36 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 6045A26C070; Thu, 28 Oct 2004 14:58:35 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i9SCwZ8q978580; Thu, 28 Oct 2004 14:58:35 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 30B7BFEF1; Thu, 28 Oct 2004 14:58:35 +0200 (CEST) Date: Thu, 28 Oct 2004 14:58:35 +0200 From: Stephane Bortzmeyer To: Markus Stumpf Cc: MXCOMP Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) Message-ID: <20041028125835.GA21506@nic.fr> References: <20041027195220.GI9500@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041027195220.GI9500@Space.Net> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040818i 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 Wed, Oct 27, 2004 at 09:52:20PM +0200, Markus Stumpf wrote a message of 21 lines which said: > But the last two days (german) IT news are fill with press reports > that MS will loosen the patent policy I do not think that Microsoft announced anything concrete on the patent front. Does anyone has a reference? > ... and that the IETF is now supporting Sender-Id? This is certainly false. IETF supports nothing since the disbanding of the MARID Working Group (the new Microsoft Internet-Draft has not even been published by IETF, probably because it was submitted after the cutoff - http://www.ietf.org/meetings/cutoff_dates_61.html). From owner-ietf-mxcomp@mail.imc.org Thu Oct 28 10:24:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16647 for ; Thu, 28 Oct 2004 10:24: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 i9SDt44E057109; Thu, 28 Oct 2004 06:55:04 -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 i9SDt41g057108; Thu, 28 Oct 2004 06:55:04 -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 i9SDt3aG057102 for ; Thu, 28 Oct 2004 06:55:03 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i9SEEts7027717; Thu, 28 Oct 2004 07:14:55 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i9SEEsSc027714; Thu, 28 Oct 2004 07:14:54 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 28 Oct 2004 07:14:54 -0700 (PDT) From: "william(at)elan.net" To: Stephane Bortzmeyer cc: Markus Stumpf , MXCOMP Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) In-Reply-To: <20041028125835.GA21506@nic.fr> 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 Thu, 28 Oct 2004, Stephane Bortzmeyer wrote: > > On Wed, Oct 27, 2004 at 09:52:20PM +0200, > Markus Stumpf wrote > a message of 21 lines which said: > > > But the last two days (german) IT news are fill with press reports > > that MS will loosen the patent policy > > I do not think that Microsoft announced anything concrete on the > patent front. Does anyone has a reference? What they said is that they will (have already?) modify their 2nd patent application so it is not so broad and does not cover RFC2821 identities and SPF classic - http://news.zdnet.com/2100-9588_22-5426045.html "The software giant said Monday that it has rewritten Sender ID--a specification for verifying the authenticity of e-mail with Internet Protocol records--to address criticisms of the spec's earlier incarnation. Among other changes, Microsoft removed language in its pending patents for SenderID that could have included claims to Sender Permitted From, or SPF, a widely used system for e-mail authentication that was merged with Microsoft's CallerID for Email to create Sender ID, according to Microsoft's Ryan Hamlin." (P.S. I'm going to contact the author of that article to fix the last paragrapth and not mislead people to think that IETF has granted any status to the documents - in fact new senderid spec has not even been published as a draft yet) There was nothing anywhere about them changing their license agreement and they appear to have no plans for that (rumors are that some Microsoft employes who have participated in MARID did ask to get different license agreement that would work better for F/OSS software but that request has been declined at Microsoft at the very highiest level). > > ... and that the IETF is now supporting Sender-Id? > > This is certainly false. IETF supports nothing since the disbanding of > the MARID Working Group (the new Microsoft Internet-Draft has not even > been published by IETF, probably because it was submitted after the > cutoff - http://www.ietf.org/meetings/cutoff_dates_61.html). > -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Oct 28 12:34:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13084 for ; Thu, 28 Oct 2004 12:34: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 i9SFpxpt068416; Thu, 28 Oct 2004 08:51: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 i9SFpx3U068415; Thu, 28 Oct 2004 08:51:59 -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 i9SFpsBA068330 for ; Thu, 28 Oct 2004 08:51:54 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LGK4R98OY800005Q@mauve.mrochek.com> for ietf-mxcomp@imc.org; Thu, 28 Oct 2004 08:51:50 -0700 (PDT) Date: Thu, 28 Oct 2004 08:48:29 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) In-reply-to: "Your message dated Wed, 27 Oct 2004 07:16:57 -0400" To: Andrew Newton Cc: Matthew Elvey , MXCOMP Message-id: <01LGK4XZOECY00005Q@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <417EC829.4030509@elvey.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > On Oct 26, 2004, at 5:56 PM, Matthew Elvey wrote: > > This scheme would put excessive power in the hands of the few: the > > Chairs, who are appointed (indirectly) by the elite few who can pay > > non-trivial sums of money to attend lots of IETF meetings, such sums > > generally provided by large corporations with entrenched interests. > Do you attend the IETF meetings on a regular basis? I ask this because > at the IETF meetings I attend I have met a non-trivial number of people > who work for non-profits, government agencies, academic institutions, > and one-man consulting shops. I am good friends with several > individuals who paid their own way to IETF meetings while unemployed, > including trips abroad. While funding trips to the IETF requires real > money, characterizing those who do as the "elite few" is a > mischaracterization. Here's an additional data point: Back in the days when MIME was under development I paid my way to most of the meetings out of my own pocket since the college I was working for at the time was uninterested in funding the work. Subsequent to that I worked for a small company, which paid for my attendance on a regular basis. And since going to work for a large company, I've found my ability to attend meetings to be markedly diminished due to a variety of factors. Ned From owner-ietf-mxcomp@mail.imc.org Thu Oct 28 18:21:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27877 for ; Thu, 28 Oct 2004 18:21: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 i9SLfhwb052791; Thu, 28 Oct 2004 14:41:43 -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 i9SLfhKi052790; Thu, 28 Oct 2004 14:41:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SLfgiJ052760 for ; Thu, 28 Oct 2004 14:41:42 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1CNI1i-0005dQ-O4 for ietf-mxcomp@imc.org; Thu, 28 Oct 2004 16:41:53 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Thu, 28 Oct 2004 16:41:46 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 27 Oct 2004 08:04:23 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.7 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: >> MARID specific comment: >> What happened here doesn't seem to be a failure, but rather was a >> success in the following sense: There was not sufficient maturity in the >> proposals for a rough consensus to be reached that the proposals were >> adequate to meet the bare minimum of goals that they needed to meet. > > I disagree. SenderID/SPF is currently in deployment and is working just > fine in production. Maturity was not the problem. SPF-classic is currently widely deployed. SenderID, and the new SPF-classic, however, are not deployed. What little information about the performance of SenderID indicates that it is probably not as reliable as old SPF-classic. Maturity certainly was a problem. > I think that there was a mismatch of expectations between people who > thought that the purpose of the group was to agree on a refinement of > an existing specification that had already achieved a very large degree > of industry buy in and those who thought that it was an open forum to > propose their alternative idea. > > I have never been in a standards group of the second type that has > succeeded. In every case that a group has suceeded the starting point > has been a specification that was already largely complete. That is exactly what MARID did. We tried to create SenderID. Things only moved forward in fits and starts when SenderID moved closer to SPF-classic. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 01:40:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10867 for ; Fri, 29 Oct 2004 01:40: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 i9T4vdGU039485; Thu, 28 Oct 2004 21:57: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 i9T4vdVb039484; Thu, 28 Oct 2004 21:57:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [69.225.172.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T4vdUW039466 for ; Thu, 28 Oct 2004 21:57:39 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 813341D656 for ; Thu, 28 Oct 2004 21:57:52 -0700 (PDT) Date: Thu, 28 Oct 2004 21:57:55 -0700 From: Greg Connor To: MXCOMP Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) Message-ID: <3741670.1099000675@[192.168.0.2]> In-Reply-To: <417EC829.4030509@elvey.com> References: <417EC829.4030509@elvey.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Matthew Elvey wrote: > > 2)A major failure of , e.g. the MARID WG (including the Chairs) was the > failure to encourage/require a cost (in the broadest sense of the term) > analysis of the proposals. This scheme fails to encourage that too. > Instead it just says "the working group chair(s) should also make an > explicit call for consensus, summarizing the technical issues and the > choice to be made." > Cost analysis is not a technical issue. (But I hope it's in MARID's new > charter if it gets re-chartered! (Anyone pushing for that?)) A minor note, but worth noting. Cost may not be a "technical" issue but it is certainly an "engineering" issue! Some software engineers with little hardware experience might dismiss cost as an issue, but they can check with their colleagues (such as hardware engineers, mechanical engineers, etc) if they have ever been asked to design something without regard for the cost. Even "legal" or "IPR" issues can be a real-world cost, or a significant barrier to adoption, if not a dollar amount. Designing something in a vacuum to see if it works in the lab, without concern for implementation issues, is fun "science" but horrible "engineering". -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 13:25:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17233 for ; Fri, 29 Oct 2004 13:25:18 -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 i9TGh8n2070965; Fri, 29 Oct 2004 09:43:08 -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 i9TGh8AU070964; Fri, 29 Oct 2004 09:43:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from data.6o4.ca (mail.6o4.ca [24.207.0.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TGh7PB070898 for ; Fri, 29 Oct 2004 09:43:08 -0700 (PDT) (envelope-from jcouzens@6o4.ca) Received: (qmail 31443 invoked by uid 1006); 29 Oct 2004 16:43:06 -0000 Received: from unknown (HELO 192.168.160.9) (24.207.1.85) by data.6o4.ca with SMTP; 29 Oct 2004 16:43:06 -0000 Received-SPF: pass (data.6o4.ca: domain of jcouzens@6o4.ca designates 24.207.1.85 as permitted sender) receiver=data.6o4.ca; client_ip=24.207.1.85; envelope-from=jcouzens@6o4.ca; Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) From: James Couzens Reply-To: jcouzens@6o4.ca To: MXCOMP LIST In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-H3agJ3m4KCqUUK6Mpyw3" Organization: 6o4.ca Date: Fri, 29 Oct 2004 09:44:09 -0700 Message-Id: <1099068249.11011.44.camel@antitrust.6o4.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-H3agJ3m4KCqUUK6Mpyw3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-10-28 at 16:41 -0500, wayne wrote: > > I disagree. SenderID/SPF is currently in deployment and is working just= =20 > > fine in production. Maturity was not the problem.=20 SenderID !=3D SPF. Please don't associate the two. This entire merging of technologies was such a horribly stupid idea. Can someone remind me why we took a perfectly progressive, active and supported technology that was OPEN and FREE and decided to take it out back and beat the living tar out of it? Oh thats right "we" didn't make that decision. Funny how that works. > SPF-classic is currently widely deployed. SenderID, and the new > SPF-classic, however, are not deployed. What little information about > the performance of SenderID indicates that it is probably not as > reliable as old SPF-classic. >=20 > Maturity certainly was a problem. =20 I would consider DK before SenderID, its most certainly more mature and it also hasn't spent the last ~6 months beating around the proverbial bush debating stupid software patents. Cheers, James James Couzens, Programmer ^ ( ( ( =20 ((__)) __\|/__ __|+|__ '. ___ .' =20 (00) (o o) (0~0) ' (> <) ' =20 ---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo--- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- PGP: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x7A7C7DCF --=-H3agJ3m4KCqUUK6Mpyw3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBgnNZMagRinp8fc8RAuVWAKDiRkhb1+2ZRZlxUgjfHVps3WOfeQCg5DqE xe6kjOYvPF33dRQOuWsaKjU= =cPei -----END PGP SIGNATURE----- --=-H3agJ3m4KCqUUK6Mpyw3-- From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 13:52:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19351 for ; Fri, 29 Oct 2004 13:52: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 i9THQirN097862; Fri, 29 Oct 2004 10:26:44 -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 i9THQiZD097861; Fri, 29 Oct 2004 10:26:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orca.agcom.amgreetings.com (orca.ag.com [207.58.192.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THQhDd097811 for ; Fri, 29 Oct 2004 10:26:43 -0700 (PDT) (envelope-from MWeiner@ag.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) Date: Fri, 29 Oct 2004 13:26:37 -0400 Message-ID: <4FD2C985D5E2A642AE25823DFD61C2B002FADF0D@orca.agcom.amgreetings.com> Thread-Topic: RFC 3929 on Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF (fwd) Thread-Index: AcS92Dw9w1eRycmfSNGHdQsr4E8PIwABCtKg From: "MW Mike Weiner \(5028\)" To: , "MXCOMP LIST" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9THQhDd097853 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Reminds me.....MWW != SPF Michael Weiner From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 17:19:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13786 for ; Fri, 29 Oct 2004 17:19: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 i9TKjEui081019; Fri, 29 Oct 2004 13:45: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 i9TKjEDN081018; Fri, 29 Oct 2004 13:45:14 -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.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKjEig081012 for ; Fri, 29 Oct 2004 13:45:14 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.218] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 29 Oct 2004 16:45:15 -0400 id 001EB2FC.4182ABDB.000012EA Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[10.131.244.218]; remoteip=::ffff:216.168.239.87; remotehost=; helo=[10.131.244.218]; receiver=zak.ecotroph.net; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=andy@hxr.us; remoteip=::ffff:216.168.239.87; remotehost=; helo=[10.131.244.218]; receiver=zak.ecotroph.net; In-Reply-To: <1099068249.11011.44.camel@antitrust.6o4.ca> References: <1099068249.11011.44.camel@antitrust.6o4.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_zak.ecotroph.net-4842-1099082716-0001-2" Message-Id: <6EFBFBB0-29EB-11D9-B607-000A95B3BA44@hxr.us> Cc: MXCOMP LIST From: Andrew Newton Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) Date: Fri, 29 Oct 2004 16:45:13 -0400 To: jcouzens@6o4.ca X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zak.ecotroph.net-4842-1099082716-0001-2 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 29, 2004, at 12:44 PM, James Couzens wrote: > I would consider DK before SenderID, its most certainly more mature and > it also hasn't spent the last ~6 months beating around the proverbial > bush debating stupid software patents. I don't know what you mean by "debating", but you might want to take a closer look at the IPR disclosures page. -andy --=_zak.ecotroph.net-4842-1099082716-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGgTCCAzow ggKjoAMCAQICAw05ITANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDEzMjA1ODM1WhcNMDUxMDEzMjA1ODM1WjB7MQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEGCSqG SIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQxGjAYBgkqhkiG9w0BCQEWC2FuZHlAaHhyLnVz MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XTscSF9lNVyNyq7wCFwEb56C7WBLvAh BaPqdV8oOr5EroTgv+0zUfaP8kYlwavWeSu0XcWIcgd/ymt7PWOd8j/J91Y71cmsSg62gv6dhA8h wzxojj5Vp2x3TYf7dafzoVfhd/7Kzvzu6FqOn9C/9NKtZ0g0hzn6ChcgymCrcoyXQrmQI689sh4o RzIQC+kSPaWkOmA0eqbCpi8ASQfuyEBiXQAATxrBWURp+hzD8YYcnn88S/5Kd4GGMARtwsBR6Moe xF53oAUavRPfiM3ixDunUqgXOQ92noBoc3nIWmxGuLdTZPZgELHX1Q1FMi013PW3tIA9rhZATcIf PF/jOQIDAQABo2EwXzAOBgNVHQ8BAf8EBAMCB4AwEQYJYIZIAYb4QgEBBAQDAgWgMCwGA1UdEQQl MCOBFGFuZXd0b25AZWNvdHJvcGgubmV0gQthbmR5QGh4ci51czAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAJiErfGNCI9wRF0H8NmkSJCjzaH3yHfv0q1CwyJr6zZhkA2M+GcCoIr12PNP J10XG3WJ/96bLP2SxzFz1FC6CfMN2/XrOn1Su5wRdVBAr7lRkyqco9A7JXaW8rUwOm6DQ20eWZen FJMo/mwzDxgThS9Oyci/ASNT4ej+Yzcyq5kpMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNOSEwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDQxMDI5MjA0NTE0WjAjBgkqhkiG9w0BCQQxFgQUBYM+m/bMNN+vaq5UTubF dB3N49oweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw05ITB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMNOSEwDQYJKoZIhvcNAQEBBQAEggEAm7qwxbEp/66s+xPugAM/ xZgbVKrUEh5rxLxzWSKsVFgulCmcm2CeE14z4/dSON0A1id4+B+JQWhDRIIW/Dc0ovbgOZYjx2QZ X59niZyqNQv30pXBouVMSlz+Z2LwJKMyJU7BGYW5hG73w+PQPiY0cdsxPoAZ1lyWT0riJcsIrsqI V1HnxSgXt45SPWLG8emsP3e/dcup43czaJqkNzgcszE+0i19SCztJHsm3UCAd+ZunnUyhwhEfgir SRoFMvepJy+ux+c6/R58orv9iBqQC2zHjXrG8Fv4jW8+/2e8VDBJPvLJMcYnrIQc81NxaOs3tjNB Z25UEvShbgfd0w7qvgAAAAAAAA== --=_zak.ecotroph.net-4842-1099082716-0001-2-- From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 17:39:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16169 for ; Fri, 29 Oct 2004 17:39:31 -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 i9TLDBfW086880; Fri, 29 Oct 2004 14:13: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 i9TLDBCI086879; Fri, 29 Oct 2004 14:13: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 i9TLDAa6086854 for ; Fri, 29 Oct 2004 14:13:10 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i9TLX5co025541; Fri, 29 Oct 2004 14:33:05 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i9TLX5tr025538; Fri, 29 Oct 2004 14:33:05 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 29 Oct 2004 14:33:05 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: jcouzens@6o4.ca, MXCOMP LIST Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) In-Reply-To: <6EFBFBB0-29EB-11D9-B607-000A95B3BA44@hxr.us> 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 Fri, 29 Oct 2004, Andrew Newton wrote: > I don't know what you mean by "debating", but you might want to take a > closer look at the IPR disclosures page. Andrew, you should know quite well by now that just IPR is not enough and until we actually see the licese the patent issue is still there. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 17:42:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16388 for ; Fri, 29 Oct 2004 17:42:46 -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 i9TLJiJ0087994; Fri, 29 Oct 2004 14:19:44 -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 i9TLJixA087993; Fri, 29 Oct 2004 14:19:44 -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.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TLJhii087987 for ; Fri, 29 Oct 2004 14:19:43 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.218] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 29 Oct 2004 17:19:48 -0400 id 001EB2FC.4182B3F4.0000174F Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[10.131.244.218]; remoteip=::ffff:216.168.239.87; remotehost=; helo=[10.131.244.218]; receiver=zak.ecotroph.net; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=andy@hxr.us; remoteip=::ffff:216.168.239.87; remotehost=; helo=[10.131.244.218]; receiver=zak.ecotroph.net; In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_zak.ecotroph.net-5967-1099084788-0001-2" Message-Id: <42D01BA2-29F0-11D9-B607-000A95B3BA44@hxr.us> Cc: MXCOMP LIST From: Andrew Newton Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) Date: Fri, 29 Oct 2004 17:19:47 -0400 To: "william(at)elan.net" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zak.ecotroph.net-5967-1099084788-0001-2 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 29, 2004, at 5:33 PM, william(at)elan.net wrote: > > On Fri, 29 Oct 2004, Andrew Newton wrote: > >> I don't know what you mean by "debating", but you might want to take a >> closer look at the IPR disclosures page. > > Andrew, you should know quite well by now that just IPR is not enough > and > until we actually see the licese the patent issue is still there. Are we talking about the same thing? Did I dismiss any patent claims in my statement above? -andy --=_zak.ecotroph.net-5967-1099084788-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGgTCCAzow ggKjoAMCAQICAw05ITANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDEzMjA1ODM1WhcNMDUxMDEzMjA1ODM1WjB7MQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEGCSqG SIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQxGjAYBgkqhkiG9w0BCQEWC2FuZHlAaHhyLnVz MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XTscSF9lNVyNyq7wCFwEb56C7WBLvAh BaPqdV8oOr5EroTgv+0zUfaP8kYlwavWeSu0XcWIcgd/ymt7PWOd8j/J91Y71cmsSg62gv6dhA8h wzxojj5Vp2x3TYf7dafzoVfhd/7Kzvzu6FqOn9C/9NKtZ0g0hzn6ChcgymCrcoyXQrmQI689sh4o RzIQC+kSPaWkOmA0eqbCpi8ASQfuyEBiXQAATxrBWURp+hzD8YYcnn88S/5Kd4GGMARtwsBR6Moe xF53oAUavRPfiM3ixDunUqgXOQ92noBoc3nIWmxGuLdTZPZgELHX1Q1FMi013PW3tIA9rhZATcIf PF/jOQIDAQABo2EwXzAOBgNVHQ8BAf8EBAMCB4AwEQYJYIZIAYb4QgEBBAQDAgWgMCwGA1UdEQQl MCOBFGFuZXd0b25AZWNvdHJvcGgubmV0gQthbmR5QGh4ci51czAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAJiErfGNCI9wRF0H8NmkSJCjzaH3yHfv0q1CwyJr6zZhkA2M+GcCoIr12PNP J10XG3WJ/96bLP2SxzFz1FC6CfMN2/XrOn1Su5wRdVBAr7lRkyqco9A7JXaW8rUwOm6DQ20eWZen FJMo/mwzDxgThS9Oyci/ASNT4ej+Yzcyq5kpMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNOSEwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDQxMDI5MjExOTQ3WjAjBgkqhkiG9w0BCQQxFgQU8l37zu2TFsWzqmTi+1oW Bm6nbkQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw05ITB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMNOSEwDQYJKoZIhvcNAQEBBQAEggEAXSzns9Fa0p7QgZazc5A+ 0ikGKl6xx6jbKw0nkiSMkSFaMOlOtoR44xYfxB+CRltrgK6b2591b5MNaQwnJjOmRd3zzf++vNdX ficcOfTMuCCuOcqYZQ6RM2FtlJBNY+a6quHc3NiOa3ELZYq7h8S+y1Y5SdmCSMBD1Pz9qRSXksSp SzRQepc6K1oN0eg8gc06O0yJAbrRqPcJNCoKHdv5pK9t+dHA67BeSeZmZQeM1/9y5wYs6FGPkVOC 7F0HYL5AuXMke7H0ykAoydKrO++UAP+EbtJwSRj4c88EFtDpjmetsqoBCusL2CfhU624dF3jhTnL Zen8ZyZTM2KlRyo2OgAAAAAAAA== --=_zak.ecotroph.net-5967-1099084788-0001-2-- From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 18:08:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19725 for ; Fri, 29 Oct 2004 18:08: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 i9TLa61e090249; Fri, 29 Oct 2004 14:36: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 i9TLa6he090248; Fri, 29 Oct 2004 14:36:06 -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 i9TLa57V090216 for ; Fri, 29 Oct 2004 14:36:05 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i9TLu6Pi026186; Fri, 29 Oct 2004 14:56:06 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i9TLu6mr026182; Fri, 29 Oct 2004 14:56:06 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 29 Oct 2004 14:56:05 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: MXCOMP LIST Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) In-Reply-To: <42D01BA2-29F0-11D9-B607-000A95B3BA44@hxr.us> 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: Original: | On Oct 29, 2004, at 12:44 PM, James Couzens wrote: | | > I would consider DK before SenderID, its most certainly more mature and | > it also hasn't spent the last ~6 months beating around the proverbial | > bush debating stupid software patents. | | I don't know what you mean by "debating", but you might want to take a | closer look at the IPR disclosures page. | | -andy My answer (corrected spelling, missing word): | Andrew, you should know quite well by now that just IPR disclosure | is not enough and until we actually see the license the patent | issue is still there. Andrew Newton's answer to above: > Are we talking about the same thing? Yes we're talking about same thing. You seem to have applied that for WG to deal with patents most important is the IPR and then the debate and issue is over. Its actually been backwards - we knew from the start the IPR is there but the debate was not about the existance of the IPR, but about the license. Now some in IETF might say that IPR disclosure already provides information about what kind of license it would be (i.e free for all, etc) but it appears that disclosure in the IPR document is not enough and until we actually see the license, the WG can't be sure how much of an issue the patent is and this may result in intense debates at the very crucial point of the WG's work cycle. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 18:28:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21514 for ; Fri, 29 Oct 2004 18:28:44 -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 i9TM0BQD095210; Fri, 29 Oct 2004 15:00: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 i9TM0BpV095209; Fri, 29 Oct 2004 15:00:11 -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.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TM0BAr095198 for ; Fri, 29 Oct 2004 15:00:11 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.218] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 29 Oct 2004 18:00:14 -0400 id 001EB0FA.4182BD6E.00001D33 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[10.131.244.218]; remoteip=::ffff:216.168.239.87; remotehost=; helo=[10.131.244.218]; receiver=zak.ecotroph.net; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=andy@hxr.us; remoteip=::ffff:216.168.239.87; remotehost=; helo=[10.131.244.218]; receiver=zak.ecotroph.net; In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_zak.ecotroph.net-7475-1099087214-0001-2" Message-Id: Cc: MXCOMP LIST From: Andrew Newton Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) Date: Fri, 29 Oct 2004 18:00:13 -0400 To: "william(at)elan.net" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zak.ecotroph.net-7475-1099087214-0001-2 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 29, 2004, at 5:56 PM, william(at)elan.net wrote: > > Original: > > | On Oct 29, 2004, at 12:44 PM, James Couzens wrote: > | > | > I would consider DK before SenderID, its most certainly more > mature and > | > it also hasn't spent the last ~6 months beating around the > proverbial > | > bush debating stupid software patents. > | > | I don't know what you mean by "debating", but you might want to take > a > | closer look at the IPR disclosures page. > | > | -andy > > My answer (corrected spelling, missing word): > > | Andrew, you should know quite well by now that just IPR disclosure > | is not enough and until we actually see the license the patent > | issue is still there. > > Andrew Newton's answer to above: > >> Are we talking about the same thing? > > Yes we're talking about same thing. You seem to have applied that for > WG to deal with patents most important is the IPR and then the debate > and issue is over. Its actually been backwards - we knew from the start > the IPR is there but the debate was not about the existance of the IPR, > but about the license. > > Now some in IETF might say that IPR disclosure already provides > information > about what kind of license it would be (i.e free for all, etc) but it > appears that disclosure in the IPR document is not enough and until we > actually see the license, the WG can't be sure how much of an issue the > patent is and this may result in intense debates at the very crucial > point > of the WG's work cycle. No, we're not talking about the same thing. In the statement above, James used the word "debating". And when I said "I don't know what you mean by 'debating'", I meant that I didn't understand the use of the word "debating" in his sentence since it seemed to have applied to "stupid software patents" ( and not stupid software patent licenses as you seem to have further honed in upon ). However, if "stupid software patents" are the issue then I have suggested a closer look at the IPR disclosures page given James' words of "I would consider DK before SenderID". Or in other words, there is a patent covering DomainKeys. -andy --=_zak.ecotroph.net-7475-1099087214-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGgTCCAzow ggKjoAMCAQICAw05ITANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDEzMjA1ODM1WhcNMDUxMDEzMjA1ODM1WjB7MQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEGCSqG SIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQxGjAYBgkqhkiG9w0BCQEWC2FuZHlAaHhyLnVz MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XTscSF9lNVyNyq7wCFwEb56C7WBLvAh BaPqdV8oOr5EroTgv+0zUfaP8kYlwavWeSu0XcWIcgd/ymt7PWOd8j/J91Y71cmsSg62gv6dhA8h wzxojj5Vp2x3TYf7dafzoVfhd/7Kzvzu6FqOn9C/9NKtZ0g0hzn6ChcgymCrcoyXQrmQI689sh4o RzIQC+kSPaWkOmA0eqbCpi8ASQfuyEBiXQAATxrBWURp+hzD8YYcnn88S/5Kd4GGMARtwsBR6Moe xF53oAUavRPfiM3ixDunUqgXOQ92noBoc3nIWmxGuLdTZPZgELHX1Q1FMi013PW3tIA9rhZATcIf PF/jOQIDAQABo2EwXzAOBgNVHQ8BAf8EBAMCB4AwEQYJYIZIAYb4QgEBBAQDAgWgMCwGA1UdEQQl MCOBFGFuZXd0b25AZWNvdHJvcGgubmV0gQthbmR5QGh4ci51czAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAJiErfGNCI9wRF0H8NmkSJCjzaH3yHfv0q1CwyJr6zZhkA2M+GcCoIr12PNP J10XG3WJ/96bLP2SxzFz1FC6CfMN2/XrOn1Su5wRdVBAr7lRkyqco9A7JXaW8rUwOm6DQ20eWZen FJMo/mwzDxgThS9Oyci/ASNT4ej+Yzcyq5kpMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNOSEwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDQxMDI5MjIwMDEzWjAjBgkqhkiG9w0BCQQxFgQUFo41fP03b6w1u9ysV9r+ R1Qxl0MweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw05ITB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMNOSEwDQYJKoZIhvcNAQEBBQAEggEAwBBFUqGwUENSZXMx3Y8U Ze8MFWW/7XUuXnGJJzAn+VLX2vr9p8tqVw6t3x76v1lxj3g2pCVDv8NM6KZ/Es1Y86Yzj2wcFgbx Fs80fR08mn9xJZaDkNPVaC5714iC5mJalwvdc8M1VAmUhqefgTuo1ap0e5bhvU3IO7U8uLK4HYXl CGvWQhT5/+NTUFMr25s3J5xtc6mYDxkwvWHhCeYXLCy8okcN7Y3wsJCMKF5p62sYSLdKl5v/TVAR hqbrufG9kdi78xZqaMBbcfBngqdVYu4zRfxtlF0qj1bJU6nerSkU38mPTgQXWb9p9p7Pq2WHBTNX JeRRuTd6cHFXo+rNMQAAAAAAAA== --=_zak.ecotroph.net-7475-1099087214-0001-2-- From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 18:58:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23458 for ; Fri, 29 Oct 2004 18:58: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 i9TMQO9m001206; Fri, 29 Oct 2004 15:26:24 -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 i9TMQOvE001205; Fri, 29 Oct 2004 15:26:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (elginwatches.org [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TMQNHl001194 for ; Fri, 29 Oct 2004 15:26:23 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1CNfCK-0001NS-2y for ietf-mxcomp@imc.org; Fri, 29 Oct 2004 17:26:21 -0500 To: "IETF MARID WG" References: <1099068249.11011.44.camel@antitrust.6o4.ca> <6EFBFBB0-29EB-11D9-B607-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Fri, 29 Oct 2004 17:26:15 -0500 In-Reply-To: <6EFBFBB0-29EB-11D9-B607-000A95B3BA44@hxr.us> (Andrew Newton's message of "Fri, 29 Oct 2004 16:45:13 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.7 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <6EFBFBB0-29EB-11D9-B607-000A95B3BA44@hxr.us> Andrew Newton writes: > On Oct 29, 2004, at 12:44 PM, James Couzens wrote: > >> I would consider DK before SenderID, its most certainly more mature and >> it also hasn't spent the last ~6 months beating around the proverbial >> bush debating stupid software patents. > > I don't know what you mean by "debating", but you might want to take a > closer look at the IPR disclosures page. While I have problems with software patents in general, I realize that is not an issue that should be dealt with in an IETF WG. The Yahoo Domainkeys patent license is available at: http://antispam.yahoo.com/domainkeys-license-01 While I have not reviewed it closely, it is my understanding that it has no conflicts with either Free/Open Source Software, nor proprietary software. *This* was the issue that caused so much problems here. (Well, that and various unresolved technical problems with the PRA.) -wayne From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 19:09:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24310 for ; Fri, 29 Oct 2004 19:09:31 -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 i9TMkZph006115; Fri, 29 Oct 2004 15:46:35 -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 i9TMkZVQ006114; Fri, 29 Oct 2004 15:46:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TMkZMZ006106 for ; Fri, 29 Oct 2004 15:46:35 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 59491414CA; Fri, 29 Oct 2004 15:46:38 -0700 (PDT) Subject: Sender-ID != SPF From: Douglas Otis To: jcouzens@6o4.ca Cc: MXCOMP LIST In-Reply-To: <1099068249.11011.44.camel@antitrust.6o4.ca> References: <1099068249.11011.44.camel@antitrust.6o4.ca> Content-Type: text/plain Message-Id: <1099089998.6706.1453.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 29 Oct 2004 15:46:38 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-10-29 at 09:44, James Couzens wrote: > SenderID != SPF. Please don't associate the two. I agree. How does one establish a mix of divergent approaches? A chain of trust is broken when each node checks a different mailbox-domain. It is also seems inappropriate to misapply a record intended for a different mailbox-domain. Handing multiple accountable identities is daunting, especially when a change in convention between administrative domains makes spoofing easy. Correlating the mailbox-domain checked and then displayed becomes another matter. Regardless of the mailbox-domain checked, leaving authorization normally open-ended overcomes present problematic header conventions. Only institutions dealing with a phishing problem would have an incentive to tackle closing the authorization list. Changing from an address-list to a name-list overcomes exploits invited by an open-ended authorization list as well, as this would imply a separate entity is utilized for reputation. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 19:55:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27347 for ; Fri, 29 Oct 2004 19:55: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 i9TNT2eT014105; Fri, 29 Oct 2004 16:29: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 i9TNT2MV014104; Fri, 29 Oct 2004 16:29:02 -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 i9TNSxpr014079 for ; Fri, 29 Oct 2004 16:29:01 -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 0801816E2A for ; Fri, 29 Oct 2004 19:39:38 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Sender-ID != SPF In-Reply-To: Your message of "Fri, 29 Oct 2004 15:46:38 PDT." <1099089998.6706.1453.camel@ddev.mail-abuse.org> Date: Fri, 29 Oct 2004 19:39:38 -0400 Message-Id: <20041029233938.0801816E2A@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > How does one establish a mix of divergent approaches? A chain > of trust is broken when each node checks a different mailbox-domain. It > is also seems inappropriate to misapply a record intended for a > different mailbox-domain. I agree completely. We should start with fields which have simple, well-known semantics such as EHLO, and then work our way to fields which have complex, poorly understood semantics. > Handing multiple accountable identities is daunting, especially when > a change in convention between administrative domains makes spoofing > easy. If we ensure that the MTA's are individually accountable, and that each message is authenticated and tracked through the system, then spoofing becomes much more difficult. SMTP is not currently such a system. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Oct 29 21:41:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03128 for ; Fri, 29 Oct 2004 21:41:15 -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 i9U17BDD032718; Fri, 29 Oct 2004 18:07: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 i9U17BMu032717; Fri, 29 Oct 2004 18:07:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9U17AV1032711 for ; Fri, 29 Oct 2004 18:07:10 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id D0927414CA; Fri, 29 Oct 2004 18:07:16 -0700 (PDT) Subject: Re: Sender-ID != SPF From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20041029233938.0801816E2A@mail.nitros9.org> References: <20041029233938.0801816E2A@mail.nitros9.org> Content-Type: text/plain Message-Id: <1099098436.6706.1480.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 29 Oct 2004 18:07:16 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-10-29 at 16:39, Alan DeKok wrote: > Douglas Otis wrote: > > > > How does one establish a mix of divergent approaches? A chain > > of trust is broken when each node checks a different mailbox-domain. It > > is also seemingly inappropriate to misapply a record intended for a > > different mailbox-domain. > > I agree completely. > > We should start with fields which have simple, well-known semantics > such as EHLO, and then work our way to fields which have complex, > poorly understood semantics. The goal should be directed toward ensuring security and responding to apparent breaches. Reputation should be based upon the response to notifications and must directed to the entity able to take immediate action. To ensure these notifications are not based upon spoofed identifications, this identity should also be directly validated. Spammers are good at injecting noise into an abatement effort. Security is the challenge, as breaching security is the common enabler for much of the spam. > > Handing multiple accountable identities is daunting, especially when > > a change in convention between administrative domains makes spoofing > > easy. > > If we ensure that the MTA's are individually accountable, and that > each message is authenticated and tracked through the system, then > spoofing becomes much more difficult. By separating the accountable entity from a mail-channel description, individual MTA administrators are revealed. By taking this approach, the mailbox-domain compared to a mail-channel description becomes less critical, as the mail-channel is not assessed for a reputation. The mail service provider could protect themselves by asserting the large customer's domain when sending their mail. > SMTP is not currently such a system. It could be with a deceptively simple change. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Oct 30 12:15:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02297 for ; Sat, 30 Oct 2004 12:15: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 i9UFaU0M002929; Sat, 30 Oct 2004 08:36:30 -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 i9UFaUHg002928; Sat, 30 Oct 2004 08:36:30 -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 ESMTP id i9UFaTWn002916 for ; Sat, 30 Oct 2004 08:36:29 -0700 (PDT) (envelope-from sb0-0721bc1ed2-johnl@iecc.com) Received: (qmail 29920 invoked by uid 100); 30 Oct 2004 15:36:29 -0000 Date: 30 Oct 2004 15:36:29 -0000 Message-ID: <20041030153629.29919.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA 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 >SPF-classic is currently widely deployed. People have published a lot of SPF-classic records in DNS, but I wouldn't confuse that with deployment. The amount of mail going through SPF tests is still small, and only a few aggressively wacky sites block mail that fails SPF. -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711 johnl@iecc.com, Mayor, http://johnlevine.com, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail From owner-ietf-mxcomp@mail.imc.org Sat Oct 30 15:53:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15378 for ; Sat, 30 Oct 2004 15:52: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 i9UJKwdZ049712; Sat, 30 Oct 2004 12:20: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 i9UJKw3m049711; Sat, 30 Oct 2004 12:20:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UJKvBN049704 for ; Sat, 30 Oct 2004 12:20:57 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1CNymU-0003gF-Du for ietf-mxcomp@imc.org; Sat, 30 Oct 2004 14:21:01 -0500 To: "IETF MARID WG" References: <20041030153629.29919.qmail@xuxa.iecc.com> From: wayne Reply-To: "IETF MARID WG" Date: Sat, 30 Oct 2004 14:20:54 -0500 In-Reply-To: <20041030153629.29919.qmail@xuxa.iecc.com> (John Levine's message of "30 Oct 2004 15:36:29 -0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.7 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20041030153629.29919.qmail@xuxa.iecc.com> John Levine writes: >>SPF-classic is currently widely deployed. > > People have published a lot of SPF-classic records in DNS, but I wouldn't > confuse that with deployment. I am not confusing the two. Yeah, it is much easier to check how many people are publishing SPF records than checking them, but that doesn't mean that you can't get clues to the latter. > The amount of mail going through SPF tests is still small, and only a few > aggressively wacky sites block mail that fails SPF. Ok, let me ask you: How do you know that "the amount of mail going through SPF test is still small"? What do you define as "small"? How "small" is spf testing compared to other things, such as various DNSBL checks, or SpamAssassin usage, or whatever? -wayne From owner-ietf-mxcomp@mail.imc.org Sat Oct 30 18:06:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22254 for ; Sat, 30 Oct 2004 18:06: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 i9ULZSKv078463; Sat, 30 Oct 2004 14:35: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 i9ULZSMS078462; Sat, 30 Oct 2004 14:35:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from parsley.amaranth.net (parsley.amaranth.net [216.44.4.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ULZOpH078408 for ; Sat, 30 Oct 2004 14:35:28 -0700 (PDT) (envelope-from dts@senie.com) Received: from ancho.senie.com (h0006b1049b35.ne.client2.attbi.com [24.34.19.2]) (authenticated bits=0) by parsley.amaranth.net (8.12.11/8.12.11) with ESMTP id i9ULZE23020317 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 30 Oct 2004 17:35:17 -0400 Message-Id: <6.1.2.0.2.20041030173119.062b9418@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 30 Oct 2004 17:34:09 -0400 To: ietf-mxcomp@imc.org From: Daniel Senie Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... In-Reply-To: <20041030153629.29919.qmail@xuxa.iecc.com> References: <20041030153629.29919.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiVirus: checked by Vexira Milter (version: 1.1; VAE: 6.28.0.12; VDF: 6.28.0.47; host: parsley.amaranth.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:36 AM 10/30/2004, John Levine wrote: > >SPF-classic is currently widely deployed. > >People have published a lot of SPF-classic records in DNS, but I wouldn't >confuse that with deployment. > >The amount of mail going through SPF tests is still small, and only a few >aggressively wacky sites block mail that fails SPF. With the release of SA3.0, this is likely changing. We're not willing to do SPF checks during the SMTP transaction due to concerns over mailing list handling (mishandling) we've already seen in some early SPF deployments, but we are starting to use SPF checks in SpamAssassin, and expect to continue to do so. We've also started publishing some SPF records again (we'd stopped when we found several sites using the SPF records in ways that broke mailing lists). Dan From owner-ietf-mxcomp@mail.imc.org Sat Oct 30 22:20:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06602 for ; Sat, 30 Oct 2004 22:20: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 i9V1b7BF022174; Sat, 30 Oct 2004 18:37: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 i9V1b78X022173; Sat, 30 Oct 2004 18:37:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from HATL0MS22.corp.cox.com (gw1.cox.com [24.248.74.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V1awU4022102 for ; Sat, 30 Oct 2004 18:37:02 -0700 (PDT) (envelope-from dts@mail.amaranth.net) Received: from CATL1MS21.CORP.COX.COM ([10.64.200.80]) by HATL0MS22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 30 Oct 2004 21:36:06 -0400 Received: from mail pickup service by CATL1MS21.CORP.COX.COM with Microsoft SMTPSVC; Sat, 30 Oct 2004 21:36:05 -0400 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by CATL0MS20.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 30 Oct 2004 17:50:03 -0400 Received: from cox.com ([10.62.198.37]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 30 Oct 2004 17:50:03 -0400 Received: from ([208.184.76.39]) by post2.cox.com with SMTP id KP-VXB82.80456755; Sat, 30 Oct 2004 17:49:43 -0400 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 i9ULZSKv078463; Sat, 30 Oct 2004 14:35: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 i9ULZSMS078462; Sat, 30 Oct 2004 14:35:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from parsley.amaranth.net (parsley.amaranth.net [216.44.4.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ULZOpH078408 for ; Sat, 30 Oct 2004 14:35:28 -0700 (PDT) (envelope-from dts@senie.com) Received: from ancho.senie.com (h0006b1049b35.ne.client2.attbi.com [24.34.19.2]) (authenticated bits=0) by parsley.amaranth.net (8.12.11/8.12.11) with ESMTP id i9ULZE23020317 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 30 Oct 2004 17:35:17 -0400 Message-Id: <6.1.2.0.2.20041030173119.062b9418@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 30 Oct 2004 17:34:09 -0400 To: ietf-mxcomp@imc.org From: Daniel Senie Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... In-Reply-To: <20041030153629.29919.qmail@xuxa.iecc.com> References: <20041030153629.29919.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiVirus: checked by Vexira Milter (version: 1.1; VAE: 6.28.0.12; VDF: 6.28.0.47; host: parsley.amaranth.net) List-Archive: List-Unsubscribe: List-ID: X-esp: ESP<6>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<2> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-OriginalArrivalTime: 30 Oct 2004 21:50:03.0628 (UTC) FILETIME=[69860AC0:01C4BECA] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:36 AM 10/30/2004, John Levine wrote: > >SPF-classic is currently widely deployed. > >People have published a lot of SPF-classic records in DNS, but I wouldn't >confuse that with deployment. > >The amount of mail going through SPF tests is still small, and only a few >aggressively wacky sites block mail that fails SPF. With the release of SA3.0, this is likely changing. We're not willing to do SPF checks during the SMTP transaction due to concerns over mailing list handling (mishandling) we've already seen in some early SPF deployments, but we are starting to use SPF checks in SpamAssassin, and expect to continue to do so. We've also started publishing some SPF records again (we'd stopped when we found several sites using the SPF records in ways that broke mailing lists). Dan From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 00:52:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12933 for ; Sun, 31 Oct 2004 00:52: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 i9V4EvtO050445; Sat, 30 Oct 2004 21:14:57 -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 i9V4EvfM050444; Sat, 30 Oct 2004 21:14:57 -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 ESMTP id i9V4EusR050436 for ; Sat, 30 Oct 2004 21:14:56 -0700 (PDT) (envelope-from sb0-0722825225-johnl@iecc.com) Received: (qmail 6500 invoked by uid 100); 31 Oct 2004 04:15:02 -0000 Date: 31 Oct 2004 04:15:02 -0000 Message-ID: <20041031041502.6499.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... In-Reply-To: <6.1.2.0.2.20041030173119.062b9418@mail.amaranth.net> Organization: I.E.C.C., Trumansburg NY USA Cc: dts@senie.com 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 >>The amount of mail going through SPF tests is still small, and only a few >>aggressively wacky sites block mail that fails SPF. > >With the release of SA3.0, this is likely changing. Small amount of mail tested, or few wacky sites? Both, I suppose. If people really are doing tests of SPF or Sender ID or other similar schemes, I'd be most interested in hearing about the results, particularly numbers of how much legit mail is tagged valid or invalid, how much spam is tagged valid or invalid, and how spammers are adapting/ Ciphertrust says they've seen more spam than good mail pass SPF checks. That doesn't surprise me, but their numbers were so small that I'd like to see some confirmation. -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711 johnl@iecc.com, Mayor, http://johnlevine.com, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 01:50:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18070 for ; Sun, 31 Oct 2004 01:50:16 -0500 (EST) 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 i9V6Apof080659; Sat, 30 Oct 2004 23:10:51 -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 i9V6Ap19080658; Sat, 30 Oct 2004 23:10:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V6Aoej080612 for ; Sat, 30 Oct 2004 23:10:50 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i9V6Anbs007680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 31 Oct 2004 01:10:54 -0500 Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: <20041031041502.6499.qmail@xuxa.iecc.com> References: <20041031041502.6499.qmail@xuxa.iecc.com> Content-Type: text/plain Message-Id: <1099202811.19755.48.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.plus.03.pri) Date: Sun, 31 Oct 2004 01:06:51 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-10-31 at 00:15, John Levine wrote: [snip] > and how spammers > are adapting/ Ciphertrust says they've seen more spam than good mail > pass SPF checks. I hope you're not implying that that's a bad thing. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 06:24:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16220 for ; Sun, 31 Oct 2004 06:24:12 -0500 (EST) 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 i9VAnuX7098191; Sun, 31 Oct 2004 02:49:56 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VAnuep098190; Sun, 31 Oct 2004 02:49:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx.blogorama.co.uk ([212.13.197.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VAnt5b098108 for ; Sun, 31 Oct 2004 02:49:56 -0800 (PST) (envelope-from pol@geekstuff.tv) Received: from chunky.geekstuff.tv (spc2-ayle1-3-0-cust117.asfd.broadband.ntl.com [80.0.200.117]) by mx.blogorama.co.uk (Postfix) with ESMTP id 4EC295B282 for ; Sun, 31 Oct 2004 10:45:12 +0000 (GMT) From: "Paul S. Brown" Organization: Geekstuff UK To: ietf-mxcomp@imc.org Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... Date: Sun, 31 Oct 2004 10:52:10 +0000 User-Agent: KMail/1.7 References: <20041031041502.6499.qmail@xuxa.iecc.com> In-Reply-To: <20041031041502.6499.qmail@xuxa.iecc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410311052.10574.pol@geekstuff.tv> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sunday 31 October 2004 04:15, John Levine wrote: > >>The amount of mail going through SPF tests is still small, and only a few > >>aggressively wacky sites block mail that fails SPF. > > > >With the release of SA3.0, this is likely changing. > > Small amount of mail tested, or few wacky sites? Both, I suppose. > > If people really are doing tests of SPF or Sender ID or other similar > schemes, I'd be most interested in hearing about the results, > particularly numbers of how much legit mail is tagged valid or > invalid, how much spam is tagged valid or invalid, and how spammers > are adapting/ Ciphertrust says they've seen more spam than good mail > pass SPF checks. That doesn't surprise me, but their numbers were so > small that I'd like to see some confirmation. I've got an SPF setup running at the moment - not a high traffic site - around 4k messages per day. The results I'm seeing are something like: 85% - No Record 5% - Hard Fail - Breached record 10% - SoftFail Of the hard fails none are legit - I'm actually bouncing on hard fail. So far, all of the SoftFails have been eBay Phishes - I have my system set up to make sure that softfails get through, but get hammered through every evil that SpamAssassin and DSPAM can do to them. Now, granted that I have SPF as a last layer behind a couple of DNSBLs, numerous header and body checks and Greylisting, but I'd have expected something to have managed to get through that was handled in a non-optimal manner - so far nothing. P. -- If Mind over Matter is a Matter of Course Does it Matter if Nobody Minds? From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 06:24:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16240 for ; Sun, 31 Oct 2004 06:24:14 -0500 (EST) 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 i9VAl3iC096851; Sun, 31 Oct 2004 02:47:03 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VAl3pT096850; Sun, 31 Oct 2004 02:47:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VAkovl096621 for ; Sun, 31 Oct 2004 02:46:58 -0800 (PST) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id i9VAiurp049550; Sun, 31 Oct 2004 10:44:56 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.12.9-20030917/8.12.9) with ESMTP id i9VAiu27032221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Oct 2004 11:44:56 +0100 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i9VAitSZ032220; Sun, 31 Oct 2004 11:44:55 +0100 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Sun, 31 Oct 2004 11:44:55 +0100 From: Koen Martens To: John Levine Cc: ietf-mxcomp@imc.org, dts@senie.com Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... Message-ID: <20041031104455.GB32058@metro.cx> References: <6.1.2.0.2.20041030173119.062b9418@mail.amaranth.net> <20041031041502.6499.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: <20041031041502.6499.qmail@xuxa.iecc.com> User-Agent: Mutt/1.4.1i X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 31, 2004 at 04:15:02AM -0000, John Levine wrote: >=20 > >>The amount of mail going through SPF tests is still small, and only a f= ew > >>aggressively wacky sites block mail that fails SPF. > > > >With the release of SA3.0, this is likely changing. >=20 > Small amount of mail tested, or few wacky sites? Both, I suppose. >=20 > If people really are doing tests of SPF or Sender ID or other similar > schemes, I'd be most interested in hearing about the results, > particularly numbers of how much legit mail is tagged valid or > invalid, how much spam is tagged valid or invalid, and how spammers > are adapting/ Ciphertrust says they've seen more spam than good mail > pass SPF checks. That doesn't surprise me, but their numbers were so > small that I'd like to see some confirmation. For what it's worth, we've been running an end user support system for spf for about 3 weeks now. We have had about 4 requests from people who had their mail blocked by spf checking sites (and wrongly, as our subsequent investigations showed). That's out of a 30-40 requests coming in in total. I myself have been checking spf for months now, and never had someone complain about not getting through. Granted, email is not my core business and volume is relatively low. Most spam is stopped by other checks anyway. SPF is not an anti-spam solution. Koen --=20 K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBhMInktDgRrkFPpYRAveJAJ4lHoSByOT50Da/dAzdVojFhA0flgCfX60u y0tWIp+N8FUyEeU8XFfrUjA= =T8yw -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 08:05:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24471 for ; Sun, 31 Oct 2004 08:05:34 -0500 (EST) 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 i9VCRe2x058246; Sun, 31 Oct 2004 04:27:40 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VCReuh058245; Sun, 31 Oct 2004 04:27:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from data.6o4.ca (mail.6o4.ca [24.207.0.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VCRdPj058204 for ; Sun, 31 Oct 2004 04:27:39 -0800 (PST) (envelope-from jcouzens@6o4.ca) Received: (qmail 11766 invoked by uid 1006); 31 Oct 2004 12:27:40 -0000 Received: from unknown (HELO webmail) (24.85.96.241) by data.6o4.ca with SMTP; 31 Oct 2004 12:27:40 -0000 Received-SPF: pass (data.6o4.ca: domain of jcouzens@6o4.ca designates 24.85.96.241 as permitted sender) receiver=data.6o4.ca; client_ip=24.85.96.241; envelope-from=jcouzens@6o4.ca; Subject: Re: Sender-ID != SPF From: James Couzens Reply-To: jcouzens@6o4.ca To: MXCOMP LIST In-Reply-To: <1099089998.6706.1453.camel@ddev.mail-abuse.org> References: <1099068249.11011.44.camel@antitrust.6o4.ca> <1099089998.6706.1453.camel@ddev.mail-abuse.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-i7dsPtnyahGtNtyTBfqn" Organization: 6o4.ca Date: Sun, 31 Oct 2004 04:29:46 -0800 Message-Id: <1099225786.7297.108.camel@code3> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-i7dsPtnyahGtNtyTBfqn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-10-29 at 15:46 -0700, Douglas Otis wrote: > On Fri, 2004-10-29 at 09:44, James Couzens wrote: >=20 > > SenderID !=3D SPF. Please don't associate the two. >=20 > I agree. How does one establish a mix of divergent approaches? A chain > of trust is broken when each node checks a different mailbox-domain. It > is also seems inappropriate to misapply a record intended for a > different mailbox-domain. Handing multiple accountable identities is > daunting, especially when a change in convention between administrative > domains makes spoofing easy. Correlating the mailbox-domain checked and > then displayed becomes another matter. >=20 > Regardless of the mailbox-domain checked, leaving authorization normally > open-ended overcomes present problematic header conventions. Only > institutions dealing with a phishing problem would have an incentive to > tackle closing the authorization list. Changing from an address-list to > a name-list overcomes exploits invited by an open-ended authorization > list as well, as this would imply a separate entity is utilized for > reputation.=20 >=20 . o O Mmmmmm... I wonder just how it was possible that something like the KISS principle was completely cast aside instead opting to do the exact opposite. =20 I do not know about you, but if I was put in charge of getting a penguin and a misappropriated series of window frames in a room to chat about implementing a technology of which the window frames seem incapable of intelligently dealing with IPR claims to (and without involving their Media/FUD machine every time), I would try to keep things as simple as possible. =20 There exists a very amusing /. post which had a would be chat involving client's whose names represented the various parties with vested interest in the outcome of this WG's efforts. I'm not going to post it here but its exceptionally amusing, and unfortunately a very accurate representation of the events that took place here. Hopefully we won't see a repeat of this in the future.=20 Cheers, James --=20 James Couzens, Programmer ( ( ( =20 ((__)) __\|/__ __|-|__ '. ___ .' =20 (00) (o o) (0~0) ' (> <) ' =20 ---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo--- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- PGP: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x7A7C7DCF --=-i7dsPtnyahGtNtyTBfqn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBhNq6MagRinp8fc8RAglqAKDesmgBsJVIUEwJ8xWJFQM4DQ205wCg0N6j ER9wtJAaayCm9Ylkb8aZQGk= =Phuq -----END PGP SIGNATURE----- --=-i7dsPtnyahGtNtyTBfqn-- From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 08:35:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26582 for ; Sun, 31 Oct 2004 08:35:44 -0500 (EST) 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 i9VDBmua084428; Sun, 31 Oct 2004 05:11:48 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VDBmqR084427; Sun, 31 Oct 2004 05:11:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (elginwatches.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VDBlSx084348 for ; Sun, 31 Oct 2004 05:11:47 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1COFUf-0004Fg-Jc for ietf-mxcomp@imc.org; Sun, 31 Oct 2004 07:11:42 -0600 To: "IETF MARID WG" References: <20041031041502.6499.qmail@xuxa.iecc.com> From: wayne Reply-To: "IETF MARID WG" Date: Sun, 31 Oct 2004 07:11:34 -0600 In-Reply-To: <20041031041502.6499.qmail@xuxa.iecc.com> (John Levine's message of "31 Oct 2004 04:15:02 -0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.7 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20041031041502.6499.qmail@xuxa.iecc.com> John Levine writes: >>>The amount of mail going through SPF tests is still small, and only a few >>>aggressively wacky sites block mail that fails SPF. >> >>With the release of SA3.0, this is likely changing. > > Small amount of mail tested, or few wacky sites? Both, I suppose. You are the one that made the claim "The amount of mail going through SPF tests is still small, and only a few aggressively wacky sites block mail that fails SPF." Surely, you have data to back up your claim. I have some data that related to your claim, but first I want you to answer the following questions: How do you know that "the amount of mail going through SPF test is still small"? What do you define as "small"? How "small" is spf testing compared to other things, such as various DNSBL checks, or SpamAssassin usage, or whatever? -wayne From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 10:19:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05616 for ; Sun, 31 Oct 2004 10:19:32 -0500 (EST) 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 i9VEjbCa027775; Sun, 31 Oct 2004 06:45:37 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VEjbaC027774; Sun, 31 Oct 2004 06:45:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.courier-mta.com (mail.courier-mta.com [216.254.115.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VEjaVu027768 for ; Sun, 31 Oct 2004 06:45:36 -0800 (PST) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Sun, 31 Oct 2004 09:45:36 -0500 id 00000000001978D8.000000004184FA90.00007CEE X-IMAP-Sender: mrsam@courier-mta.com References: <20041031041502.6499.qmail@xuxa.iecc.com> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: ietf-mxcomp@imc.org X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... Date: Sun, 31 Oct 2004 09:45:36 -0500 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-31126-1099233936-0007"; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. --=_mimegpg-commodore.email-scan.com-31126-1099233936-0007 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Disposition: inline X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg Content-Transfer-Encoding: quoted-printable John Levine writes: > >>>The amount of mail going through SPF tests is still small, and only a few >>>aggressively wacky sites block mail that fails SPF. >> >>With the release of SA3.0, this is likely changing. > > Small amount of mail tested, or few wacky sites? Both, I suppose. > > If people really are doing tests of SPF or Sender ID or other similar > schemes, I'd be most interested in hearing about the results, > particularly numbers of how much legit mail is tagged valid or > invalid, how much spam is tagged valid or invalid, and how spammers > are adapting/ Ciphertrust says they've seen more spam than good mail > pass SPF checks. That doesn't surprise me, but their numbers were so > small that I'd like to see some confirmation. After DNSBLs, SPF is my most successful spam filter. Here's my latest mail report (# of messages rejected/reason). 7951=09550 User unknown. 6182=09517 HELO mismatch 1310=09502 ESMTP command error 1171=09511 Blocked by www.spambag.org : Blocked 839=09517 Sender Policy Framework error 81=09551 DNS lookup failure 74=09558-500-sam:558 500 Message rejected by recipient's mail filter (BCC). 67=09Connection timed out 35=09500 Microsoft virus refused. 22=09550-The headers in this message contain improperly-formatted binary=E2=80= =A6 21=09513 Relaying denied. 21=09550-This message contains improperly-formatted binary content=E2=80=A6 20=09550-This message contains text that uses unnecessary base64=E2=80=A6 14=09517 Syntax error. <=3D 10=0979 errors for 44 types SPF blocks ten times more spam than the next most common spam filter. Also,= a fairly good portion of the "HELO mismatch" rejects would've probably been caught by the SPF checks too. I have occasional reports of false positives, but they were related to other= causes. No false positives reported for SPF. --=_mimegpg-commodore.email-scan.com-31126-1099233936-0007 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBhPqQx9p3GYHlUOIRAsfmAJ9cIv/WmDW7n3T+WG5cyuLmnDNzJwCdE+c/ kiQA1ksBkrUKKJMd3+Glx88= =70BK -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-31126-1099233936-0007-- From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 10:25:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06102 for ; Sun, 31 Oct 2004 10:25:28 -0500 (EST) 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 i9VExMdK031494; Sun, 31 Oct 2004 06:59:22 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VExMaJ031493; Sun, 31 Oct 2004 06:59:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from data.6o4.ca (mail.6o4.ca [24.207.0.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VExLP1031478 for ; Sun, 31 Oct 2004 06:59:21 -0800 (PST) (envelope-from jcouzens@6o4.ca) Received: (qmail 17565 invoked by uid 1006); 31 Oct 2004 14:59:26 -0000 Received: from unknown (HELO webmail) (24.85.96.241) by data.6o4.ca with SMTP; 31 Oct 2004 14:59:26 -0000 Received-SPF: pass (data.6o4.ca: domain of jcouzens@6o4.ca designates 24.85.96.241 as permitted sender) receiver=data.6o4.ca; client_ip=24.85.96.241; envelope-from=jcouzens@6o4.ca; Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... From: James Couzens Reply-To: jcouzens@6o4.ca To: LIST@above.proper.com, MXCOMP LIST In-Reply-To: References: <20041031041502.6499.qmail@xuxa.iecc.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TULCQBq2G2Jd5tQfpapb" Organization: 6o4.ca Date: Sun, 31 Oct 2004 07:01:31 -0800 Message-Id: <1099234891.7316.139.camel@code3> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-TULCQBq2G2Jd5tQfpapb Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable On Sun, 2004-10-31 at 09:45 -0500, Sam Varshavchik wrote: > After DNSBLs, SPF is my most successful spam filter. Here's my=20 > latest mail report (# of messages rejected/reason). >=20 > 7951 550 User unknown. > 6182 517 HELO mismatch > 1310 502 ESMTP command error > 1171 511 Blocked by www.spambag.org : Blocked > 839 517 Sender Policy Framework error > 81 551 DNS lookup failure > 74 558-500-sam:558 500 Message rejected by recipient's mail filter (BCC). > 67 Connection timed out > 35 500 Microsoft virus refused. > 22 550-The headers in this message contain improperly-formatted binary=85 > 21 513 Relaying denied. > 21 550-This message contains improperly-formatted binary content=85 > 20 550-This message contains text that uses unnecessary base64=85 > 14 517 Syntax error. > <=3D 10 79 errors for 44 types >=20 >=20 > SPF blocks ten times more spam than the next most common spam filter. Al= so,=20 > a fairly good portion of the "HELO mismatch" rejects would've probably be= en=20 > caught by the SPF checks too. >=20 > I have occasional reports of false positives, but they were related to ot= her=20 > causes. No false positives reported for SPF. I'm curious about your "error". These are FAIL, SOFTFAIL, UNKNOWN, ERROR or ?. I'd appreciate any clarification you can specify here. Cheers, James --=20 James Couzens, Programmer ( ( ( =20 ((__)) __\|/__ __|-|__ '. ___ .' =20 (00) (o o) (0~0) ' (> <) ' =20 ---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo--- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- PGP: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x7A7C7DCF --=-TULCQBq2G2Jd5tQfpapb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBhP5LMagRinp8fc8RAtfpAJ9CmGf/J9f0EgL8TdyldWQxqNkwZQCgvWMu zrCGcKioNY66yfe2l8GYmEE= =wMiQ -----END PGP SIGNATURE----- --=-TULCQBq2G2Jd5tQfpapb-- From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 10:53:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08377 for ; Sun, 31 Oct 2004 10:53:02 -0500 (EST) 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 i9VFIq1e036669; Sun, 31 Oct 2004 07:18:52 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VFIq0G036668; Sun, 31 Oct 2004 07:18:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.courier-mta.com (mail.courier-mta.com [216.254.115.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VFIoqq036648 for ; Sun, 31 Oct 2004 07:18:51 -0800 (PST) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Sun, 31 Oct 2004 10:18:53 -0500 id 00000000001978D8.000000004185025D.00000874 X-IMAP-Sender: mrsam@courier-mta.com References: <20041031041502.6499.qmail@xuxa.iecc.com> <1099234891.7316.139.camel@code3> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: MXCOMP LIST X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... Date: Sun, 31 Oct 2004 10:18:53 -0500 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-31126-1099235933-0008"; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. --=_mimegpg-commodore.email-scan.com-31126-1099235933-0008 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Disposition: inline X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg Content-Transfer-Encoding: quoted-printable James Couzens writes: > On Sun, 2004-10-31 at 09:45 -0500, Sam Varshavchik wrote: > >> After DNSBLs, SPF is my most successful spam filter. Here's my >> latest mail report (# of messages rejected/reason). >> >> 7951=09550 User unknown. >> 6182=09517 HELO mismatch >> 1310=09502 ESMTP command error >> 1171=09511 Blocked by www.spambag.org : Blocked >> 839=09517 Sender Policy Framework error >> 81=09551 DNS lookup failure >> 74=09558-500-sam:558 500 Message rejected by recipient's mail filter (BCC= ). >> 67=09Connection timed out >> 35=09500 Microsoft virus refused. >> 22=09550-The headers in this message contain improperly-formatted binary=E2= =80=A6 >> 21=09513 Relaying denied. >> 21=09550-This message contains improperly-formatted binary content=E2=80=A6= >> 20=09550-This message contains text that uses unnecessary base64=E2=80=A6= >> 14=09517 Syntax error. >> <=3D 10=0979 errors for 44 types >> >> >> SPF blocks ten times more spam than the next most common spam filter. Al= so, >> a fairly good portion of the "HELO mismatch" rejects would've probably be= en >> caught by the SPF checks too. >> >> I have occasional reports of false positives, but they were related to ot= her >> causes. No false positives reported for SPF. > > I'm curious about your "error". These are FAIL, SOFTFAIL, UNKNOWN, > ERROR or ?. I'd appreciate any clarification you can specify here. I reject FAIL and SOFTFAIL. I accept UNKNOWN and ERROR. --=_mimegpg-commodore.email-scan.com-31126-1099235933-0008 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBhQJdx9p3GYHlUOIRAsNQAJ9v8i37Xlo1nf/ydrqt/xDtHfS7ZwCfaHly 60/0/HmxH+j58GRKls+cq7c= =6GZC -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-31126-1099235933-0008-- From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 11:06:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09498 for ; Sun, 31 Oct 2004 11:06:26 -0500 (EST) 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 i9VFeLkE043066; Sun, 31 Oct 2004 07:40:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VFeL2j043065; Sun, 31 Oct 2004 07:40:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VFeJ4L043024 for ; Sun, 31 Oct 2004 07:40:20 -0800 (PST) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i9VFeIwK027301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 31 Oct 2004 10:40:19 -0500 Subject: Re: Sender-ID != SPF From: Paul Iadonisi To: MXCOMP LIST In-Reply-To: <1099225786.7297.108.camel@code3> References: <1099068249.11011.44.camel@antitrust.6o4.ca> <1099089998.6706.1453.camel@ddev.mail-abuse.org> <1099225786.7297.108.camel@code3> Content-Type: text/plain Message-Id: <1099236977.1580.31.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.plus.03.pri) Date: Sun, 31 Oct 2004 10:36:17 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-10-31 at 07:29, James Couzens wrote: [snip] > There exists a very amusing /. post which had a would be chat involving > client's whose names represented the various parties with vested > interest in the outcome of this WG's efforts. I'm not going to post it > here but its exceptionally amusing, and unfortunately a very accurate > representation of the events that took place here. Hopefully we won't > see a repeat of this in the future. Unfortunately, with the apparent power-grab of RFC3929, I think we're likely to see much, much worse. I was skeptical of those who said that many see the IETF as losing its relevance. I fear that if RFC3929 moves beyond experimental status, then that will come true very quickly, if it's not already. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 12:28:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15275 for ; Sun, 31 Oct 2004 12:28:28 -0500 (EST) 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 i9VGqhhv068456; Sun, 31 Oct 2004 08:52:43 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VGqhpY068455; Sun, 31 Oct 2004 08:52:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9VGqbPW068255 for ; Sun, 31 Oct 2004 08:52:42 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 2E05E1A6D0; Sun, 31 Oct 2004 17:52:30 +0100 (CET) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id F17DB1A6C7 for ; Sun, 31 Oct 2004 17:52:27 +0100 (CET) Message-Id: Date: Sun, 31 Oct 2004 17:52:27 +0100 From: Arnt Gulbrandsen To: ietf-mxcomp@imc.org Subject: Re: Sender-ID != SPF References: <1099068249.11011.44.camel@antitrust.6o4.ca> <1099089998.6706.1453.camel@ddev.mail-abuse.org> <1099225786.7297.108.camel@code3> <1099236977.1580.31.camel@va.local.linuxlobbyist.org> In-Reply-To: <1099236977.1580.31.camel@va.local.linuxlobbyist.org> Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9VGqhPW068450 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Paul Iadonisi writes: > Unfortunately, with the apparent power-grab of RFC3929, I think > we're likely to see much, much worse. «In no way should this experiment or any future BCP for this small number of cases take precedence over the IETF's normal mode of operation.» So, basically, if we can't agree on the mailing list, 3929 experimentally suggests trying a different way. Some power grab. Arnt From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 13:09:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18306 for ; Sun, 31 Oct 2004 13:09:18 -0500 (EST) 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 i9VHYe71083614; Sun, 31 Oct 2004 09:34:40 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VHYeK1083613; Sun, 31 Oct 2004 09:34:40 -0800 (PST) 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 ESMTP id i9VHYaUu083579 for ; Sun, 31 Oct 2004 09:34:36 -0800 (PST) (envelope-from sb0-0722825225-johnl@iecc.com) Received: (qmail 11314 invoked by uid 100); 31 Oct 2004 17:34:33 -0000 Date: 31 Oct 2004 17:34:33 -0000 Message-ID: <20041031173433.11313.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... In-Reply-To: <1099202811.19755.48.camel@va.local.linuxlobbyist.org> Organization: I.E.C.C., Trumansburg NY USA Cc: pri.marid@iadonisi.to 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 >> and how spammers are adapting/ Ciphertrust says they've seen more >> spam than good mail pass SPF checks. > I hope you're not implying that that's a bad thing. No, of course not. But it reminds us that anyone who thinks he's going to block a lot of spam merely by rejecting mail that fails SPF or any other sender/IP check is likely to be disappointed. It may block some now, but spammers have reminded us that they'll adapt. -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711 johnl@iecc.com, Mayor, http://johnlevine.com, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 15:57:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03502 for ; Sun, 31 Oct 2004 15:57:28 -0500 (EST) 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 i9VKMvO7042774; Sun, 31 Oct 2004 12:22:57 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VKMvuB042773; Sun, 31 Oct 2004 12:22:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VKMuKx042734 for ; Sun, 31 Oct 2004 12:22:56 -0800 (PST) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i9VKMuLM002112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 31 Oct 2004 15:22:57 -0500 Subject: Re: Sender-ID != SPF From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: References: <1099068249.11011.44.camel@antitrust.6o4.ca> <1099089998.6706.1453.camel@ddev.mail-abuse.org> <1099225786.7297.108.camel@code3> <1099236977.1580.31.camel@va.local.linuxlobbyist.org> Content-Type: text/plain Message-Id: <1099253933.1580.65.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.plus.03.pri) Date: Sun, 31 Oct 2004 15:18:53 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-10-31 at 11:52, Arnt Gulbrandsen wrote: [snip] > Some power grab. Elsewhere in the RFC it is an acknowledged risk that an individual can game the system with this approach. That's enough of red flag for me. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 16:42:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06788 for ; Sun, 31 Oct 2004 16:42:20 -0500 (EST) 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 i9VL8xk9059108; Sun, 31 Oct 2004 13:08:59 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VL8xE0059107; Sun, 31 Oct 2004 13:08:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from lv-svr.lumenvox.com (mail.lumenvox.com [206.169.193.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VL8wHt059061 for ; Sun, 31 Oct 2004 13:08:58 -0800 (PST) (envelope-from ThomasGal@LumenVox.com) Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 31 Oct 2004 12:59:56 -0800 Reply-To: From: "Thomas Gal" To: "'Paul Iadonisi'" , "'MXCOMP LIST'" Subject: RE: Sender-ID != SPF Date: Sun, 31 Oct 2004 13:08:24 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB0263AED9@svr-exc.domain.com> Thread-Index: AcS/YmcPrmYcGtzKQxmWviuvjXfCGgAHsiPg Message-ID: X-OriginalArrivalTime: 31 Oct 2004 20:59:56.0859 (UTC) FILETIME=[93C340B0:01C4BF8C] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From 3929: "In discussions regarding this document, several points have been raised about the viability of any mechanism that requires consensus to use an alternative to consensus-based decision making. Some individuals have pointed out that groups having trouble achieving consensus on a technical matter may have similar problems achieving consensus on a procedural matter. Others have been concerned that this will be used as an attempt to end-run around rough consensus. These are valid concerns, and they point both to the need to retain rough consensus as the baseline mechanism and the need to exercise caution when using these alternate methods. More importantly though, they highlight the nature of these alternatives. They are primarily mechanisms that allow people to recognize the need for compromise in a new way, by backing away from entrenched technical positions and by putting the technical choice in the hands of the broader community. They highlight that the choice for each participant is now between achieving a result and failure. There is a fundamental tension between the IETF community's desire to get the best decision for a particular technical problem and its desire to get a decision that has community buy-in in the form of rough consensus. These mechanisms cannot resolve that fundamental tension. They may, however, provide a way forward in some situations that might otherwise end in a deadlock or stagnation." That's a power grab? Personally it seems it's only a power grab in the case of politikers stubbornly refusing consensus for bad reasons, or fear of people not deeply involved making an unbiased decision that can't be blocked. I've not read many documents that were so passive in just suggesting a solution to a problem that can *optionally* be implemented if it helps. On another note, usage of "The IETF will become irelevant if _______" prognostication seems to be proliferating these days. -Tom thomasgal@lumenvox.com > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Paul Iadonisi > Sent: Sunday, October 31, 2004 7:36 AM > To: MXCOMP LIST > Subject: Re: Sender-ID != SPF > > > On Sun, 2004-10-31 at 07:29, James Couzens wrote: > > [snip] > > > There exists a very amusing /. post which had a would be chat > > involving client's whose names represented the various parties with > > vested interest in the outcome of this WG's efforts. I'm > not going to > > post it here but its exceptionally amusing, and > unfortunately a very > > accurate representation of the events that took place here. > Hopefully > > we won't see a repeat of this in the future. > > Unfortunately, with the apparent power-grab of RFC3929, I > think we're likely to see much, much worse. > I was skeptical of those who said that many see the IETF as > losing its relevance. I fear that if RFC3929 moves beyond > experimental status, then that will come true very quickly, > if it's not already. > > -- > -Paul Iadonisi > Senior System Administrator > Red Hat Certified Engineer / Local Linux Lobbyist Ever see > a penguin fly? -- Try Linux. > GPL all the way: Sell services, don't lease secrets > From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 17:07:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08383 for ; Sun, 31 Oct 2004 17:07:19 -0500 (EST) 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 i9VLaUDw067554; Sun, 31 Oct 2004 13:36:30 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VLaUTc067553; Sun, 31 Oct 2004 13:36:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from lv-svr.lumenvox.com (mail.lumenvox.com [206.169.193.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VLaTfb067519 for ; Sun, 31 Oct 2004 13:36:30 -0800 (PST) (envelope-from ThomasGal@LumenVox.com) Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 31 Oct 2004 13:27:57 -0800 Reply-To: From: "Thomas Gal" To: "'Paul Iadonisi'" , Subject: RE: Sender-ID != SPF Date: Sun, 31 Oct 2004 13:36:24 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB0263AEE5@svr-exc.domain.com> Thread-Index: AcS/iw6gvBMupe2BRnSlXu/4Jt2yQAAAsmCw Message-ID: X-OriginalArrivalTime: 31 Oct 2004 21:27:57.0171 (UTC) FILETIME=[7D4E8430:01C4BF90] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Elsewhere in the RFC it is an acknowledged risk that an > individual can game the system with this approach. That's > enough of red flag for me. No, elsewhere in the document (and I just quoted it on another email 10 minutes ago ironically) it noted that care should be taken when using this approach to make sure that someone DOESN'T game the approach. In the same paragraph it also mentions: "the need to retain rough consensus as the baseline mechanism and the need to exercise caution when using these alternate methods" > So, basically, if we can't agree on the mailing list, 3929 > experimentally suggests trying a different way. > > Some power grab. Exactly. Whereas it seems your saying something could go through working group last call, fail to reach consensus, people would come to consensus to use an alternative method, a final document would be agreed on through the alternative resolution method(one of which may be do nothing as 3929 explicitly states), it would get through the IESG, nobody would think to appeal it at any level of the process (the appeals process is also still included as stated in 3929), and then proceed to widespread adoption without anyone noticing. Yes....someone COULD game the system, I agree. As for the entire IETF community overlooking this happening at every level in the process, it's mention in 3929 is pretty clearly indicative of that not happening. -Tom thomasgal@lumenvox.com From owner-ietf-mxcomp@mail.imc.org Sun Oct 31 19:56:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20040 for ; Sun, 31 Oct 2004 19:56:56 -0500 (EST) 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 iA10JHC1015644; Sun, 31 Oct 2004 16:19:17 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA10JHbJ015643; Sun, 31 Oct 2004 16:19:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.courier-mta.com (mail.courier-mta.com [216.254.115.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA10JGix015620 for ; Sun, 31 Oct 2004 16:19:16 -0800 (PST) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Sun, 31 Oct 2004 19:19:19 -0500 id 00000000001978D9.0000000041858107.0000139D X-IMAP-Sender: mrsam@courier-mta.com References: <20041031173433.11313.qmail@xuxa.iecc.com> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: ietf-mxcomp@imc.org X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: SPF deployment, was RFC 3929 on Alternative Decision ... Date: Sun, 31 Oct 2004 19:19:18 -0500 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-31126-1099268358-0010"; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. --=_mimegpg-commodore.email-scan.com-31126-1099268358-0010 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit John Levine writes: > >>> and how spammers are adapting/ Ciphertrust says they've seen more >>> spam than good mail pass SPF checks. > >> I hope you're not implying that that's a bad thing. > > No, of course not. But it reminds us that anyone who thinks he's > going to block a lot of spam merely by rejecting mail that fails SPF > or any other sender/IP check is likely to be disappointed. It may > block some now, but spammers have reminded us that they'll adapt. And, when they do, the methods used to fight them will adapt also. --=_mimegpg-commodore.email-scan.com-31126-1099268358-0010 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBhYEHx9p3GYHlUOIRAq5xAJ4hKLilOwLq8gadpcNnYhAqwMMrMwCdGa21 /fO+8uJlVtAGRgT1SvxDtCc= =1dCY -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-31126-1099268358-0010--