From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 00:49: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 AAA05402 for ; Wed, 1 Sep 2004 00:49: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 i814DWvc068278; Tue, 31 Aug 2004 21:13:32 -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 i814DW3j068277; Tue, 31 Aug 2004 21:13:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i814DUur068250 for ; Tue, 31 Aug 2004 21:13:31 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i814Cj42010035 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Sep 2004 00:12:49 -0400 Date: Wed, 1 Sep 2004 00:12:45 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Roy Badami cc: Paul Iadonisi , Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) In-Reply-To: <16693.11406.185197.719219@giles.gnomon.org.uk> 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, 1 Sep 2004, Roy Badami wrote: > >>>>> "Dean" == Dean Anderson writes: > > Dean> This is completely wrong. You are confusing a license with > Dean> a contract. Patent laws in various countries prohibit use > Dean> of patented technology and intentional violations have > Dean> severe penalties, where unintentional violations have > Dean> economic penalties and injunction. > > I think you're missing my point. I fully realize that distributing > software may violate patent law. > > However a lot of discussion here has focussed on whether the existence > of the Sender ID license causes distribution of software to be > contrary to the GPL. Ahh. Yes, I missed that. I think the GPL specifically answers this question: http://www.fsf.org/copyleft/gpl.html "Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all." If you've written code, released it under the GPL, and it needs to be free without encumbrances. You can't secretly add encumbrances to it. That would be dishonest. > My point is: clearly, if you aren't a party to the patent license then > its wording can't have any effect on you. Either the GPL allows you > to distribute software that might have claims on it or it doesn't. I certainly can have effect on you. I thought I was clear: A patent has effect on you regardless of whether you are a party to a license. It effects _everyone_ in the realm of the patent jurisdiction for 21 years. > Distributing software may (obviously) be unlawful under patent law, > but the wording of a license you haven't agreed to isn't going to > affect your rights under the GPL. I think you missed the point: You don't "agree" to a patent license any more than you agree to abide by the speed limit. You either accept the terms of a license or you don't use the patented technology. Unlicensed use of patented technology may result in injuctions, damages, back royalties, and attorneys fees. You keep trying to put things in terms of contracts: If you don't agree to a contract, you aren't bound by it. By contrast, patents are mandates. You must comply with patent law whether you agree or not. Your choice is to either obtain a license or not use the patented technology. This is, of course, why software patents are so oppressive. --Dean From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 09:17: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 JAA03442 for ; Wed, 1 Sep 2004 09:17:04 -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 i817j5nf068130; Wed, 1 Sep 2004 00:45: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 i817j5Er068129; Wed, 1 Sep 2004 00:45:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i817j2Ab068076 for ; Wed, 1 Sep 2004 00:45:02 -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 i817ri2x026833; Wed, 1 Sep 2004 00:53:45 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i817rfge026829; Wed, 1 Sep 2004 00:53:41 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 1 Sep 2004 00:53:41 -0700 (PDT) From: "william(at)elan.net" To: Paul Vixie , Dean Anderson , cc: IETF MARID WG Subject: Re: How IETF treats contributors 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, 1 Sep 2004, Dean Anderson wrote: > This is a personal message, and doesn't qualify as being published. You > mentioned that you failed to follow up. That may be true. And that's why > you shouldn't be credited for originating the idea, and why David Green > and later Hadmut Danisch should be credited. They did the work, and > unlike you, took it to the IETF, and published it first. What you did in > secret is irrelevant. You should have published it. > > That's just your oversight. However, the Namedroppers archives show that > you __replied__ to Green's proposal. He was __first__ to publish. Maybe > you had Miller's draft in the wings since 1997. But you didn't get it it > first. To be able to claim that somebody first discovered it, the person would have to either file a patent (and have patent filing date prior to when the idea is first discussed on introduced in public) or to actually post an idea in public forum (either internet or journal, etc). So I hate to say it, but it looks like Dean Anderson is right and based on the facts presented David Green should be credited as first person that introduced what is now being developed by MARID. I recommend MARID chairs or authors of the drafts make an appropriate changes to the Acknoledgement section of both core and protocol drafts, something like this (text mostly combination of what was in protocol and core acknoledgements sections): This design is based on earlier work published in 2003 in [RMX] and [DMP] drafts (by Hadmut Danisch and Gordon Fecyk respectively). The idea of using a DNS record to check the legitimacy of an email address traces its ancestry to "Repudiating Mail-From" draft by Paul Vixie [Vixie] (based on suggestion by Jim Miller) and to "Domain-Authorized SMTP Mail" draft by David Green [Green] who first introduced this idea on namedroppes maillist in 2002. With references as follows: [Green] http://www.atm.tut.fi/list-archive/namedroppers/msg01636.html [Vixie] http://www.atm.tut.fi/list-archive/namedroppers/msg01638.html And these acknolidgements should probably be the same for both marid-protocol and marid-core drafts. Although protocol can list additional people who contributed to design of SPF while marid-core may list those who contributed to caller-id. P.S. While the original thread started was more general question on "How IETF treats contributors", this has now become a discussion that is very particular to MARID WG documents. I think it might be appropriate that those wishing to participate and discuss futher what acknolidgement section of MARID drafts should say, should do it on MARID mail list, rather then on IETF general list, especially since only discussions there would count and we are already on the last week of "Last Call" on these drafts. Please see http://www.ietf.org/html.charters/marid-charter.html for information on how to participate in this WG to discuss these documents. I also would like to urge other IETF participants to look at some of the latest archives as we're discussing number of problems with these drafts and its important for WG chairs to hear from wide audience as to if we should proceed considering how many problems have been found already. Of great importance are also issues due to IPR claimed by Microsoft for something that many on the list said is obvious derivitive from RFC2822. Microsoft also provided license which is overly restrictive and would not allow to support new protocol by any software that is licensed under GNU or simular public source licenses and this has raised questions as to if we should proceed futher with these drafts considering possibility that protocol may not be adapted by large portion of internet community. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 09:57:36 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 JAA13997 for ; Wed, 1 Sep 2004 09:57:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81DUUcM068578; Wed, 1 Sep 2004 06:30: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 i81DUUb8068577; Wed, 1 Sep 2004 06:30:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81DUTZE068571 for ; Wed, 1 Sep 2004 06:30:29 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Sep 2004 09:30:31 -0400 Message-ID: <4135CEF7.6070207@hepcoe.com> Date: Wed, 01 Sep 2004 09:30:31 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Malayter CC: IETF MARID WG , arnt@gulbrandsen.priv.no Subject: Re: Sendmail releases open source Sender ID milter for testing References: <792DE28E91F6EA42B4663AE761C41C2A02CEB56C@cliff.bai.org> In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB56C@cliff.bai.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2004 13:30:31.0492 (UTC) FILETIME=[DA5DC840:01C49027] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yes, they have the permission of the copyright holders, but they do not have a license from the (alleged) patent holder. I don't think that the definition of "distribute" means any different in copyright law than in patent law. If you distribute software that contains patented technology without a license, you are still running afoul of the law regardless of what the copyright holder says. Ryan Malayter wrote: >[Arnt Gulbrandsen] > > >>If you think offering software downloads to the general public isn't >>redistributing, I dare you to put your Windows CDs on your web site. >> >> > >There's a big difference between the situations: Sourceforge is being >used as a transmission agent by, and is authorized by, the copyright >holders of the Sendmail software. If I posted my Windows CDs, I would be >transmitting the software without MS's permission. > >I think the "courier" analogy I used before still applies. > > -Ryan- > > > > From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 10:39:26 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 KAA19665 for ; Wed, 1 Sep 2004 10:39:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81E8KZx073060; Wed, 1 Sep 2004 07:08:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i81E8KZe073059; Wed, 1 Sep 2004 07:08:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81E8HsJ073045 for ; Wed, 1 Sep 2004 07:08:17 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 1 Sep 2004 07:08:19 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Sep 2004 07:08:18 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Sep 2004 07:08:19 -0700 Received: from df-dogbert-msg.exchange.corp.microsoft.com ([157.54.5.14]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Sep 2004 07:08:31 -0700 Content-class: urn:content-classes:message Subject: RE: How IETF treats contributors MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 1 Sep 2004 07:08:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V8.0.155.1 Message-ID: Thread-Topic: How IETF treats contributors thread-index: A8+P+g/jW/+6d8gUSF+zVRsMzTpi6QAMs9Jw From: "Jim Lyon" To: "william\(at\)elan.net" , "Paul Vixie" , "Dean Anderson" , Cc: "IETF MARID WG" X-OriginalArrivalTime: 01 Sep 2004 14:08:31.0809 (UTC) FILETIME=[298A8B10:01C4902D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i81E8HsJ073047 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, September 01, 2004 at 12:54 AM, William(at)elan.net wrote: > I recommend MARID chairs or authors of the drafts make an appropriate > changes to the Acknoledgement section of both core and protocol drafts, > something like this (text mostly combination of what was in protocol > and core acknoledgements sections): > > This design is based on earlier work published in 2003 in [RMX] and > [DMP] drafts (by Hadmut Danisch and Gordon Fecyk respectively). > The idea of using a DNS record to check the legitimacy of an email > address traces its ancestry to "Repudiating Mail-From" draft by Paul > Vixie [Vixie] (based on suggestion by Jim Miller) and to > "Domain-Authorized SMTP Mail" draft by David Green [Green] who first > introduced this idea on namedroppes maillist in 2002. > > With references as follows: > [Green] http://www.atm.tut.fi/list-archive/namedroppers/msg01636.html > [Vixie] http://www.atm.tut.fi/list-archive/namedroppers/msg01638.html > > And these acknolidgements should probably be the same for both > marid-protocol and marid-core drafts. Although protocol can list > additional people who contributed to design of SPF while marid-core > may list those who contributed to caller-id. I would be happy to do this in the next draft of -core. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 11:38: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 LAA29196 for ; Wed, 1 Sep 2004 11:38: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 i81D1BGl066364; Wed, 1 Sep 2004 06:01: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 i81D1BSu066363; Wed, 1 Sep 2004 06:01:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81D16VV066338 for ; Wed, 1 Sep 2004 06:01:06 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Sendmail releases open source Sender ID milter for testing Date: Wed, 1 Sep 2004 08:01:01 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEB56C@cliff.bai.org> Thread-Topic: Sendmail releases open source Sender ID milter for testing thread-index: AcSPm9pfUP49rzp6RFufe+PmqaE47QAhu2Jg From: "Ryan Malayter" To: "IETF MARID WG" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i81D16VV066354 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Arnt Gulbrandsen] >If you think offering software downloads to the general public isn't >redistributing, I dare you to put your Windows CDs on your web site. There's a big difference between the situations: Sourceforge is being used as a transmission agent by, and is authorized by, the copyright holders of the Sendmail software. If I posted my Windows CDs, I would be transmitting the software without MS's permission. I think the "courier" analogy I used before still applies. -Ryan- From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 13:27: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 NAA13279 for ; Wed, 1 Sep 2004 13:27: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 i81H2b1B086781; Wed, 1 Sep 2004 10:02:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i81H2b8S086780; Wed, 1 Sep 2004 10:02:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81H2b4q086766 for ; Wed, 1 Sep 2004 10:02:37 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 1 Sep 2004 10:02:40 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Sep 2004 10:02:40 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Sep 2004 10:02:43 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Sep 2004 10:02:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Microsoft Claimed IP, License Terms, etc. Date: Wed, 1 Sep 2004 10:02:36 -0700 Message-ID: Thread-Topic: Microsoft Claimed IP, License Terms, etc. thread-index: AcSNtORlWqR12rmvR3q2CHnpOV54UgBJYRXA From: "Harry Katz" To: "Nick Shelness" , X-OriginalArrivalTime: 01 Sep 2004 17:02:40.0004 (UTC) FILETIME=[7D269440:01C49045] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i81H2b4q086772 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On August 29, 2004 3:27 AM, Nick Shelness wrote: > All, > > I don't really want to enter this discussion, but I believe > it is necessary. > > For those that don't know me, I'm the ex-CTO of Lotus (98-01) > and thus someone who professionally had to spend a great deal > of time (too much) worrying about IP issues, and consulting > with IP lawyers. I was also the source of a private > suggestion to Harry Katz that [E]SMTP be extended to identify > the email submitter as an alternative to mucking about with RFC > [2]822 headers. At the time, Harry indicated that this idea > was new to him and Microsoft. I leave it to Harry to indicate > whether he has subsequently encountered a prior claim to this idea. I agree with Nick's account of our conversation and his suggestion of an ESMTP extension. Around the same time (I can't remember the precise chronological order) Pete Resnick suggested on this list that the existing ORCPT parameter could be used in a similar way. At the MARID interim meeting in May at Qualcomm HQ in Campbell, CA, this idea was discussed further and it was agreed that Eric Allman and I would co-author an Internet Draft. Thus was born the SUBMITTER extension. Nick and Pete are both named in the acknowledgements section of the draft. My thanks again to both of them. From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 13:28:34 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 NAA13367 for ; Wed, 1 Sep 2004 13:28:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81Gtqqv086296; Wed, 1 Sep 2004 09:55: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 i81GtqRU086295; Wed, 1 Sep 2004 09:55:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81GtqaR086289 for ; Wed, 1 Sep 2004 09:55:52 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 1 Sep 2004 09:55:55 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Sep 2004 09:55:55 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Sep 2004 09:55:58 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Sep 2004 09:55:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Sendmail releases open source Sender ID milter for testing Date: Wed, 1 Sep 2004 09:55:52 -0700 Message-ID: Thread-Topic: Sendmail releases open source Sender ID milter for testing thread-index: AcSPKYDcNQs6ZSbrRy2C08v334KDxQBGd37g From: "Harry Katz" To: "Rand Wacker" , X-OriginalArrivalTime: 01 Sep 2004 16:55:54.0944 (UTC) FILETIME=[8BB75400:01C49044] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i81GtqaR086290 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, August 30, 2004 11:42 PM, Rand Wacker wrote: > As part of our broad-reaching effort to spur the testing and > eventual broad adoption of sender-based email authentication > to address fraud and spam in email, Sendmail, Inc. is > releasing an open source implementation of the IETF's Sender > ID specification for testing on the Internet. I want to congratulate Sendmail on the completion and release of their Sender ID milter. I think this is a great step forward! I'd also like to address a number of points that have been made on this thread and on others in recent days. First, a reminder. Answer 4 of the FAQ which I published to this list on August 23 (available at http://www.imc.org/ietf-mxcomp/mail-archive/msg03497.html) says: "At this time Microsoft is only aware of pending patent application claims that cover its submission of the Sender ID specification. Because Microsoft is not aware of any issued patent claims, Microsoft does not require any one to sign a license with Microsoft to implement the Sender ID specification or any part of it that is incorporated into IETF working drafts. In conformance with the IETF IPR policy Microsoft has disclosed the existence of those pending patent claims and has provided its assurance that if such claims are granted Microsoft will make licenses available on reasonable and non-discriminatory terms. Microsoft has also gone beyond the IETF's requirements by clarifying that its licenses will requires no fees or other royalties, and further, to make a license available to early adopters who wish at their option to clarify their rights with Microsoft with respect to early implementations. Typically patent holders do not make their license terms available until after the standard has been adopted and until after their patent claims have been granted, leaving early implementers to speculate as to the ultimate terms of the license. " Second as per the terms of the license itself, End Users who are recipients of a licensed implementation of Sender ID and distributors who are redistributing a branded licensed implementation do not need to separately sign this License Agreement. Finally we have committed to a royalty free license. That means Microsoft will never charge a royalty or licensing fee to anyone using the Sender ID necessary patent claims to implement the Sender ID specification. From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 13:41:36 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 NAA14217 for ; Wed, 1 Sep 2004 13:41:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81HFwo8087987; Wed, 1 Sep 2004 10:15: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 i81HFwFD087986; Wed, 1 Sep 2004 10:15:58 -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 i81HFvcl087979 for ; Wed, 1 Sep 2004 10:15:58 -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 i81HD7wJ014557; Wed, 1 Sep 2004 10:13:07 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Sep 2004 10:13:07 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , Roy Badami Cc: Paul Iadonisi , ietf-mxcomp@imc.org Subject: RE: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) Date: Wed, 1 Sep 2004 10:13:06 -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: > Ahh. Yes, I missed that. I think the GPL specifically answers this > question: > > http://www.fsf.org/copyleft/gpl.html > > "Finally, any free program is threatened constantly by > software patents. > We wish to avoid the danger that redistributors of a free > program will > individually obtain patent licenses, in effect making the program > proprietary. To prevent this, we have made it clear that > any patent must > be licensed for everyone's free use or not licensed at all." Sender-ID is licensed for everyone's free use and it is not necessary for individual users or distributors of the program to obtain independent licenses. It is very clear to me that the SenderID license is not a genuine impediment here. The impediments are being created by people who want to see them. From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 14:15: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 OAA17554 for ; Wed, 1 Sep 2004 14:15:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81Hos7E090265; Wed, 1 Sep 2004 10:50:54 -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 i81HosWm090264; Wed, 1 Sep 2004 10:50:54 -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 i81HorXV090253 for ; Wed, 1 Sep 2004 10:50:53 -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 1C2ZFw-0001ab-2P for ietf-mxcomp@imc.org; Wed, 01 Sep 2004 12:50:54 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Wed, 01 Sep 2004 12:50:35 -0500 In-Reply-To: (Harry Katz's message of "Wed, 1 Sep 2004 09:55:52 -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: Sendmail releases open source Sender ID milter for testing 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.6 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 "Harry Katz" writes: > I'd also like to address a number of points that have been made on this > thread and on others in recent days. Thank you for answering some of the questions. > First, a reminder. Answer 4 of the FAQ which I published to this list > on August 23 (available at > http://www.imc.org/ietf-mxcomp/mail-archive/msg03497.html) says: > > [no license is required right now because no patent has been > granted] True, but for all I know, MS has been granted a license 5 minutes ago. This is a time bomb. > Second as per the terms of the license itself, End Users who are > recipients of a licensed implementation of Sender ID and distributors > who are redistributing a branded licensed implementation do not need to > separately sign this License Agreement. If redistributing source does not need a license, why does the license say "If you would like a license from Microsoft (e.g. rebrand, redistribute), you need to contact Microsoft directly."? > > Finally we have committed to a royalty free license. That means > Microsoft will never charge a royalty or licensing fee to anyone using > the Sender ID necessary patent claims to implement the Sender ID > specification. While MS will not charge a licensing fee, there are costs to obtaining a license, both in terms of time and the money needed to send certified letters and such. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 14:25: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 OAA18455 for ; Wed, 1 Sep 2004 14:25: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 i81I1klV091148; Wed, 1 Sep 2004 11:01:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i81I1ko9091147; Wed, 1 Sep 2004 11:01:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.simkin.ca (IDENT:zOzJqR0KXYR0oeMssnKAQxUNRqFa0mVs@skynet.simkin.ca [199.175.137.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81I1j8W091140 for ; Wed, 1 Sep 2004 11:01:45 -0700 (PDT) (envelope-from ahodgson@simkin.ca) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.simkin.ca (Postfix) with ESMTP id 5262EFAAD for ; Wed, 1 Sep 2004 11:01:46 -0700 (PDT) Received: from mail.simkin.ca ([127.0.0.1]) by localhost (skynet.simkin.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17350-10 for ; Wed, 1 Sep 2004 11:01:38 -0700 (PDT) Received: by mail.simkin.ca (Postfix, from userid 509) id 70CE0FB78; Wed, 1 Sep 2004 11:01:38 -0700 (PDT) Date: Wed, 1 Sep 2004 11:01:38 -0700 From: Alan Hodgson To: ietf-mxcomp@imc.org Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) Message-ID: <20040901180138.GC14823@simkin.ca> Reply-To: Alan Hodgson References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SPF-Protected: True (see http://spf.pobox.com/) Organization: Simkin Network Consulting Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 01, 2004 at 10:13:06AM -0700, Hallam-Baker, Phillip wrote: > Sender-ID is licensed for everyone's free use and it is not > necessary for individual users or distributors of the program > to obtain independent licenses. The license claims to grant a "non-transferable, non-sublicenseable" right to distribute source code copies of Licensed Implementations. That strongly implies, to me at least (IANAL), that distributors require their own licences. Legal opinions provided on the list to date appear to agree. -- "Government big enough to supply everything you need is big enough to take everything you have ... the course of history shows that as a government grows, liberty decreases." -- Thomas Jefferson From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 14:26: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 OAA18523 for ; Wed, 1 Sep 2004 14:26:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81I3S5a091346; Wed, 1 Sep 2004 11:03: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 i81I3SU8091345; Wed, 1 Sep 2004 11:03:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81I3RPf091337 for ; Wed, 1 Sep 2004 11:03:28 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Sep 2004 14:03:31 -0400 Message-ID: <41360EF3.2010102@hepcoe.com> Date: Wed, 01 Sep 2004 14:03:31 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Updated Sender-ID License Faq (was acceptable use) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2004 18:03:31.0370 (UTC) FILETIME=[FD88D0A0:01C4904D] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: >>Ahh. Yes, I missed that. I think the GPL specifically answers this >>question: >> >>http://www.fsf.org/copyleft/gpl.html >> >> "Finally, any free program is threatened constantly by >>software patents. >> We wish to avoid the danger that redistributors of a free >>program will >> individually obtain patent licenses, in effect making the program >> proprietary. To prevent this, we have made it clear that >>any patent must >> be licensed for everyone's free use or not licensed at all." >> >> > >Sender-ID is licensed for everyone's free use and it is not >necessary for individual users or distributors of the program >to obtain independent licenses. > > > Royalty-free does not mean "free". In exchange for one of these licenses, you give up significant rights. >It is very clear to me that the SenderID license is not a >genuine impediment here. The impediments are being created by >people who want to see them. > > > > Perhaps you haven't read Microsoft's updated Sender-ID license FAQ: Q15: Is Microsoft s Royalty Free Sender ID Patent License compatible with the GPL? A: Unlike other open source software licenses, the GPL includes a provision that appears to prohibit the distribution of code that is subject to patent licenses that are not sub-licensable and/or are limited for a particular purpose like implementing a specification. While almost all open source licenses require that the code be freely modifiable and redistributable with or without modification, only the GPL appears to expressly prohibit distribution of code if those requirements can not be satisfied. Microsoft's Royalty Free Sender ID Patent License Agreement does not prohibit the use of any open source license including the GPL. However, because the Royalty Free Sender ID Patent License Agreement is offered for implementation, distribution and use of the specification, Microsoft believes that the GPL would prohibit the distribution of this patented technology. (Although I believe that use of this text falls under 'fair use', I may be in violation of Microsoft's copyrights by pasting this excerpt from their FAQ. To mitigate my own and your liability, please snip this section from any replies) From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 14:38: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 OAA19926 for ; Wed, 1 Sep 2004 14:38:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81IGXJR092216; Wed, 1 Sep 2004 11:16:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i81IGXKg092215; Wed, 1 Sep 2004 11:16:33 -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 i81IGWIg092206 for ; Wed, 1 Sep 2004 11:16:33 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.254.82] (host66.209-113-184.oem.net [209.113.184.66]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i81IFWBp003463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Sep 2004 14:15:34 -0400 Subject: RE: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1094062593.3683.17.camel@tuxtop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 01 Sep 2004 14:16:34 -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-09-01 at 13:13, Hallam-Baker, Phillip wrote: [snip] > It is very clear to me that the SenderID license is not a > genuine impediment here. The impediments are being created by > people who want to see them. So because there are many people, include three attorneys, who disagree with your interpretation, they just 'want to see them'? In other words, are you saying they are imagined impediments? I, for one, am getting a little tired of seeing posts like this that basically accuse those opposed of this license of making things up. -- -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 Wed Sep 1 14:39: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 OAA19967 for ; Wed, 1 Sep 2004 14:39: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 i81ICVxx092029; Wed, 1 Sep 2004 11:12:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i81ICV1a092028; Wed, 1 Sep 2004 11:12:31 -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 i81ICUZU092020 for ; Wed, 1 Sep 2004 11:12:30 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.254.82] (host66.209-113-184.oem.net [209.113.184.66]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i81IBP3h003254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Sep 2004 14:11:31 -0400 Subject: RE: Sendmail releases open source Sender ID milter for testing From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1094062345.3683.12.camel@tuxtop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 01 Sep 2004 14:12:26 -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-09-01 at 12:55, Harry Katz wrote: [snip] > Second as per the terms of the license itself, End Users who are > recipients of a licensed implementation of Sender ID and distributors > who are redistributing a branded licensed implementation do not need to > separately sign this License Agreement. This *still* completely ignores the discussion on various threads on this list that at least with respect to the GPL, and probably many other FOSS licenses, the distinction between end users and intermediate developers/re-distributors is non-existent. Because of this, and because the published patent license makes this distinction, it makes it impossible for end users of GPL licensed MTAs that might implement Sender-ID to exercise a freedom given to them by the GPL: to modify it and redistribute without permission from a third party. > Finally we have committed to a royalty free license. That means > Microsoft will never charge a royalty or licensing fee to anyone using > the Sender ID necessary patent claims to implement the Sender ID > specification. Most of the discussion has not been about fees, but about freedom granted by various FOSS licenses being taken away by this patent licenses. -- -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 Wed Sep 1 14:43: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 OAA20305 for ; Wed, 1 Sep 2004 14:43:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81IKWmj092429; Wed, 1 Sep 2004 11:20:32 -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 i81IKW4p092427; Wed, 1 Sep 2004 11:20:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81IKVXC092419 for ; Wed, 1 Sep 2004 11:20:31 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-092-187.area3.spcsdns.net ([68.245.102.182]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2Zii-0007fb-M3; Wed, 01 Sep 2004 14:20:33 -0400 Message-ID: <413612E0.1080600@solidmatrix.com> Date: Wed, 01 Sep 2004 14:20:16 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Harry Katz CC: ietf-mxcomp@imc.org Subject: Re: Sendmail releases open source Sender ID milter for testing References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Harry Katz wrote: > > First, a reminder. Answer 4 of the FAQ which I published to this list > on August 23 (available at > http://www.imc.org/ietf-mxcomp/mail-archive/msg03497.html) says: > ... One more thing, Harry. The FAQ states that Microsoft is not aware of any opinions that Sender-ID license is not compatible with certain open source software. In light of the statements from FSF and OSI lawyers, that part of the FAQ needs to be updated. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 15:10: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 PAA22212 for ; Wed, 1 Sep 2004 15:10: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 i81IhvcB094448; Wed, 1 Sep 2004 11:43: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 i81IhvEd094447; Wed, 1 Sep 2004 11:43:57 -0700 (PDT) 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 i81Ihuug094420 for ; Wed, 1 Sep 2004 11:43:56 -0700 (PDT) (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 i81Ihoue080070; Wed, 1 Sep 2004 18:43:50 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 i81IhoD6003864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Sep 2004 20:43:50 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i81Ihouq003863; Wed, 1 Sep 2004 20:43:50 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Wed, 1 Sep 2004 20:43:50 +0200 From: Koen Martens To: Harry Katz Cc: ietf-mxcomp@imc.org Subject: Re: Sendmail releases open source Sender ID milter for testing Message-ID: <20040901184350.GA3780@metro.cx> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 01, 2004 at 09:55:52AM -0700, Harry Katz wrote: > Finally we have committed to a royalty free license. That means > Microsoft will never charge a royalty or licensing fee to anyone using > the Sender ID necessary patent claims to implement the Sender ID > specification. Then why all the secrecy? Why the license? Why the frustration of the process?? Frankly, this makes it a little hard to keep the illusion that microsoft acts in good faith a little hard to keep up. I'm sorry, but all this scares away a lot of people, even some who are already rejecting anything remotely connected to senderid, such as spf. Why not just make a license that says microsoft donates the patent royalty free, which is signed once and for all by i don't know who can make this legal and be done with it? Why insisting on a license that needs signing by every little chain in the development/distributing process?? Frankly, this whole ordeal disgusts me. I'm already pulling sendmail out of production on all servers I maintain, because they so openly endorse this nail to the foundations of open source. Also, I will not contribute with code to spf anymore, since there is the risk that microsoft will all of a sudden pop up with some patent and demand me to sign some license. Leave it to microsoft to ruin a perfectly simple, unencumbered, working protocol! Thanks guys! Koen Martens -- 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/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 15:21:41 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 PAA23237 for ; Wed, 1 Sep 2004 15:21:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81IoWkx094958; Wed, 1 Sep 2004 11:50:32 -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 i81IoW7N094957; Wed, 1 Sep 2004 11:50:32 -0700 (PDT) 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 i81IoVbA094938 for ; Wed, 1 Sep 2004 11:50:32 -0700 (PDT) (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 i81IoUww080318; Wed, 1 Sep 2004 18:50:30 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 i81IoUD6003889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Sep 2004 20:50:30 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i81IoTik003888; Wed, 1 Sep 2004 20:50:29 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Wed, 1 Sep 2004 20:50:29 +0200 From: Koen Martens To: Alan Hodgson Cc: ietf-mxcomp@imc.org Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) Message-ID: <20040901185029.GB3780@metro.cx> References: <20040901180138.GC14823@simkin.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901180138.GC14823@simkin.ca> 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 01, 2004 at 11:01:38AM -0700, Alan Hodgson wrote: > On Wed, Sep 01, 2004 at 10:13:06AM -0700, Hallam-Baker, Phillip wrote: > > Sender-ID is licensed for everyone's free use and it is not > > necessary for individual users or distributors of the program > > to obtain independent licenses. > > The license claims to grant a "non-transferable, non-sublicenseable" right to > distribute source code copies of Licensed Implementations. That strongly > implies, to me at least (IANAL), that distributors require their own licences. > Legal opinions provided on the list to date appear to agree. That is how I understand the license too. Sure, microsoft may not sue just anybody who does not comply with their terms, but if they can for their own benefit they will. If they can damage for example linux in any way by misusing this patent ordeal, they will! Please don't give me this 'assume all members of the list act in good faith': microsoft is not even a member of this list. Really, i've had it with this workgroup. Despite a flood of messages protesting against senderid both technically and on the matter of licenses, the chairs keep pushing for senderid, which in my turn makes me wonder who really runs this show: the ietf or microsoft. And if you're not in favour of senderid, you are kindly asked to just leave. Well, maybe that's what we all should do, that'll surely get MARID adopted world-wide. Good bye. -- 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/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 15:30: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 PAA24293 for ; Wed, 1 Sep 2004 15:30:45 -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 i81J15tc095781; Wed, 1 Sep 2004 12:01: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 i81J15su095780; Wed, 1 Sep 2004 12:01:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81J14Nw095765 for ; Wed, 1 Sep 2004 12:01:04 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-092-187.area3.spcsdns.net ([68.245.102.182]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2aLy-0001Rx-PH for ietf-mxcomp@imc.org; Wed, 01 Sep 2004 15:01:09 -0400 Message-ID: <41361C61.4080901@solidmatrix.com> Date: Wed, 01 Sep 2004 15:00:49 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: >>Ahh. Yes, I missed that. I think the GPL specifically answers this >>question: >> >>http://www.fsf.org/copyleft/gpl.html >> >> "Finally, any free program is threatened constantly by >>software patents. >> We wish to avoid the danger that redistributors of a free >>program will >> individually obtain patent licenses, in effect making the program >> proprietary. To prevent this, we have made it clear that >>any patent must >> be licensed for everyone's free use or not licensed at all." > > > Sender-ID is licensed for everyone's free use and it is not > necessary for individual users or distributors of the program > to obtain independent licenses. > While that may be true, nevertheless several attorneys have stated that Sender-ID is not compatible with the GPL and other open source licenses. With all due respect, until I hear from another attorney otherwise, those opinions carry a lot of weight over others who are not attorneys including myself. Add to this the opinion of Microsoft lawyers as well. Perhaps Verisign's legal counsel disagrees and we'll be happy to hear his or her opinion, if you can obtain it for us. In the context of this standard, once again the question is whether the IPR issue cause problems with deployment. Judging from announcements made by various companies in the last few days, it seems that the big boys have no problems with this. However, ISPs and domain owners are the ones who will be publishing these records, and it remains to be seen whether the IPR issue will delay their rollout. The very fact that people are confused about the license, already points to potential problems. > It is very clear to me that the SenderID license is not a > genuine impediment here. The impediments are being created by > people who want to see them. > In my personal opinion any IPR Microsoft may be claiming can only be based directly on ASRG discussions and other related mailing lists, as well as IETF drafts. I also agree with Hadmut that the PRA "agorithm" is too obvious and additionally, it looks very much like fetchmail's "algorithm". Therefore, IMHO, this situtation is starting to smell just like the case of the IDN WG described in RFC 3669 - a company following progress of the working group (or in this case a research group) and then patenting ideas coming up in the discussion. In the case of IDN, the IPR claims were dismissed as worthless and the standard moved along. Whether this is a viable option for this WG, is something that remains to be seen. One thing that keeps bugging me is how hiddenly all of this came about. Phil, you of all people always made sure to include a disclaimer on any potential idea that Verisign might seek to patent coming out of ASRG discussions. Microsoft employees did not do that simple courtesy (whether Microsoft's lack of disclosure granted rights to the IETF is something I will leave to the lawyers). This creates a precedent and a chilling effect on the operation of the entire IETF community which *is not a good thing*. Should we now worry about every single potential patent that might be filed on our discussions just because some company decides to sic their lawyers on it? I am not blaming any of the Microsoft employees that were involved in this. Quite the opposite, I am very impressed with what they have done for us and the steps they took. I would like to commend Bob, Harry, George, Jim and others for pushing this and agreeing to work within the IETF process when other options were available. Nevertheless, whoever is responsible for this IPR issue at Microsoft, perhaps the lawyers, should have told us earlier about this, and published the license long before the last call period started. It would have made things much easier for all parties involved. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 16:41: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 QAA00103 for ; Wed, 1 Sep 2004 16:41: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 i81KBwxT001177; Wed, 1 Sep 2004 13:11: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 i81KBwig001176; Wed, 1 Sep 2004 13:11:58 -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 i81KBv22001170 for ; Wed, 1 Sep 2004 13:11:57 -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 i81KC1tL026902 for ; Wed, 1 Sep 2004 13:12:02 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Sep 2004 13:12:01 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MARID WG Subject: RE: Updated Sender-ID License Faq (was acceptable use) Date: Wed, 1 Sep 2004 13:12:01 -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: The issue here is whether it is possible to add Sender-ID technology to a GPL licensed mailer and distribute the technology with the mailer itself. Let us for the sake of argument stipulate that there is a conflict, that it is not possible to distribute the technology itself under the GPL. My point is that the GPL does not prevent the distribution of Sender-ID technology for GPL licensed mailers. It is still possible to distribute the code under a separate OSS license. Since most OSS mailers appear to already be taking the same approach with SSL (another patent encumbered technology) this does not seem to be a big deal. It is also possible for the copyright holder to vary the license. VeriSign has distributed the same code under the GPL and a commercial license for several years, there is nothing in the GPL to prohibit this, the copyright was never transfered to the FSF. The terms of the license itself are only invariant if the code distribution has forked so that there is a QMail type situation where the party that holds the copyright is not the party wanting to maintain the code. What we have here is like someone claiming that the telephone system discriminates against themselves because they have made a vow of silence. One of the reasons we chose making the CERN libwww code (the basis for Mosaic) public domain, not GPL was because we thought GPL too restrictive. It is rather ironic that the GPL seems to insist on patents being put in the public domain in their entirety in order to allow the distribution of copyright code. The GPL dates from an era when code was expensive and there were few patent rights. The logical approach for the GPL to take would be to treat patents in the same way as code, with a viral poison pill defense. Instead the demand is for unilateral disarmament. I think that people are missing the real threat here. Let us assume that the precedent is set that absolutely no encumbered technology of any sort is going to be allowed in an IETF spec, regardless of the license terms offered. It seems to me that this would provide a very effective way to shut down all future developoment of OSS, merely claiming to have applied for a patent would be sufficient to stop any and every new development. As the problem of patent trolls increases the chances of any new technology being entirely unencumbered becomes vanishingly small. From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 17:48: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 RAA07582 for ; Wed, 1 Sep 2004 17:48:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81LMBJk006932; Wed, 1 Sep 2004 14:22: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 i81LMB41006931; Wed, 1 Sep 2004 14:22:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.simkin.ca (IDENT:219d4l2FkjJHKPz/0Bva+azZi+/YeRqf@skynet.simkin.ca [199.175.137.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81LMAZK006925 for ; Wed, 1 Sep 2004 14:22:10 -0700 (PDT) (envelope-from ahodgson@simkin.ca) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.simkin.ca (Postfix) with ESMTP id 9EA64FA95 for ; Wed, 1 Sep 2004 14:22:14 -0700 (PDT) Received: from mail.simkin.ca ([127.0.0.1]) by localhost (skynet.simkin.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14865-14 for ; Wed, 1 Sep 2004 14:22:03 -0700 (PDT) Received: by mail.simkin.ca (Postfix, from userid 509) id B486FFB80; Wed, 1 Sep 2004 14:22:02 -0700 (PDT) Date: Wed, 1 Sep 2004 14:22:02 -0700 From: Alan Hodgson To: IETF MARID WG Subject: Re: Updated Sender-ID License Faq (was acceptable use) Message-ID: <20040901212202.GD11900@simkin.ca> Reply-To: Alan Hodgson References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SPF-Protected: True (see http://spf.pobox.com/) Organization: Simkin Network Consulting Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 01, 2004 at 01:12:01PM -0700, Hallam-Baker, Phillip wrote: > > The issue here is whether it is possible to add Sender-ID technology > to a GPL licensed mailer and distribute the technology with the > mailer itself. > > Let us for the sake of argument stipulate that there is a conflict, > that it is not possible to distribute the technology itself under > the GPL. My point is that the GPL does not prevent the distribution > of Sender-ID technology for GPL licensed mailers. > I don't see how this solves the problem. The problem is that the license appears to prohibit source code redistribution. This would affect all FOSS products equally. Yes, you can make a Sender-ID implementation available, but you can only distribute it directly to end users. It doesn't seem to matter what license you put on it, so I don't see why the emphasis here is on the GPL. Much of the value of open source is the multitude of distributions, mirrors and sites like Sourceforge that distribute the code to users. So, while it is perfectly possible to do so, I believe this will unreasonably inhibit adoption of the standard. Sender-ID will likely not appear in open source OS distributions. Sender-ID will likely not appear in standard distributions of MTA's and MUA's, Webmail systems, etc. Even the Sendmail statement said they'd have to make it available as a separate download. Sure, people who really want it might be able to get it, but that isn't going to result in widespread adoption. Without MTA adoption, the incentive to publish is low. I suggest, therefore, that with the current license requirements, that this standard be rejected and a non-encumbered alternative be considered. -- "You can only protect your liberties in this world by protecting the other man's freedom. You can only be free if I am free." -- Clarence Darrow From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 18:02: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 SAA09000 for ; Wed, 1 Sep 2004 18:02:45 -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 i81LcPOP008163; Wed, 1 Sep 2004 14:38: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 i81LcPCP008162; Wed, 1 Sep 2004 14:38:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81LcOuP008145 for ; Wed, 1 Sep 2004 14:38:25 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so299002rnl for ; Wed, 01 Sep 2004 14:38:26 -0700 (PDT) Received: by 10.38.70.76 with SMTP id s76mr665688rna; Wed, 01 Sep 2004 14:38:26 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Wed, 1 Sep 2004 14:38:26 -0700 (PDT) Message-ID: <94df60cf040901143863b721a1@mail.gmail.com> Date: Wed, 1 Sep 2004 17:38:26 -0400 From: Reply-To: To: MARID Subject: DEPLOY: Significant Sender ID license issues at universities Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I am a professor at New York University, and also the author of an open-source SMTP server called Mail Avenger. I'd like Mail Avenger to support whatever standard emerges from the MARID working group, and so have looked into getting NYU to sign Microsoft's patent license agreement. In general, NYU has a pretty good history of supporting open-source software--for example a lot of the early work on gcc2 happened here. Thus, while different universities may react differently to Microsoft's agreement, I would expect NYU to fall towards the more accommodating end of the spectrum. Because the agreement potentially gives Microsoft a license to NYU's patents, it must be signed by our Office of Industrial Liaisons (OIL)--what many universities call the "tech transfer office." I spoke with someone from the OIL today. While we did not fully resolve the issue, I did learn several interesting things. First, while NYU has of course signed many different license agreements in the past, there is no precedent for granting this kind of blanket license to all applicable patents. Thus, at the very least, we're entering uncharted territory. Second, the fact the license applies not just to Microsoft, but also to all of Microsoft's licensees, is also unusual. Third, the fact that paragraph 1.6 defines Necessary Claims as applying to patents owned or controlled "at any future time" significantly complicates matters. It's one thing for NYU to take stock of all current patents and applications and either decide they don't apply or should be licensed to Microsoft and Microsoft's licensees. Committing to do so for future claims could, however, affect researchers NYU hasn't even hired yet. Given the unusual nature of the agreement and the unknown effect on future hires, getting such a license executed would at the very least require a "big push." The agreement would also have to be vetted by NYU's office of legal counsel. My interpretation of our discussion is the license terms created an uncomfortable and difficult situation, and raised questions far broader than a single faculty member's research. Thus, because Sender ID has not been standardized yet, and because I'm starting to think there are technically equivalent or superior solutions that don't infringe on Microsoft's pending patents (or at least on the subset of Microsoft's claims that they are offering to license with this agreement), I did not deem it worth pushing the matter further at this time. (Also, because of the GPL question and the extensible nature of Mail Avenger that easily allows for non-compliant uses of the same technology, I'm not 100% sure I could implement Sender ID anyway, so I didn't want to waste too many people's time.) If there are any other university faculty or staff members on the list, would you be willing to inquire at your institutions to get a sense of what it would take to execute Microsoft's Sender ID agreement? At this point, I'm guessing that, depending on the university, the answer will lie somewhere between "major headache" and impossible. When evaluating the Sender ID proposal and licensing restrictions, I would urge people to keep in mind just how much mail software has originated from a university environment. In particular, if you simply counted the number of running MTAs in the world, I suspect there are many more machines running sendmail--which originated from Berkeley--than Microsoft exchange. For that reason alone, I think it would be bad to standardize on a technology that shuts out or vastly complicates life for people releasing software at universities, unless there is some truly compelling technical advantage to the proprietary technology. While I have seen several arguments for Sender ID on this list, none has really made the case that it is a vastly superior technology. Perhaps the best argument is that Microsoft will more likely adopt Sender ID than an alternative technology. While it would be great for Microsoft to adopt whatever standard MARID produces, they will still be free to do so even if the standard isn't covered by their patents. Conversely, it may be much harder or impossible to produce standards-compliant software at universities if doing so requires executing Microsoft's agreement. Also keep in mind that even for sendmail, Sender ID will be an add-on package. If it's not on by default in all OS distributions, this will further reduce deployment. Another argument for Sender ID is that it may be better for MUA support. Certainly Microsoft has a bigger share of the MUA market than the MTA market. There is also value in being able to show a golden padlock or some similar icon by an email address in MUAs. However, MUAs are not directly covered by the charter of the MARID group. (The "M", after all, stands for MTA...) I also don't think this is an issue if the MTA supports the standard--for instance SPF-classic specifies a header that can contain information, like mail-from address, that might otherwise not be available to the MUA. Another argument for Sender ID is that sites won't implement SRS or something equivalent required for SPF-classic. However, first of all, experience has shown that people are willing to implement SRS or equivalent; a lot of forwarders have already stopped "forging" mail-from addresses. Second, independent of Sender ID, it's fairly clear from list discussions that there is a serious need to block mail-from forgery because of joe jobs, viruses, and possibly even questions of legal liability. Whether efforts to do so are officially blessed by some future IETF standard, or else take the form of SPF-classic becoming a de-facto standard, or worse take the form of hard-coded ad-hoc rules for high-profile domains in people's spam filters, the fact is that one way or another people who routinely forge mail-from addresses are going to have reliability problems if they don't already. Yet another argument for Sender ID is that Microsoft's patents may cover more than just core and PRA, or that somebody else's patents may cover other technology. However, the scope of Microsoft's license is clearly restricted to core and PRA. Thus, adopting Sender ID as a standard does not help people if Microsoft's patent claims somehow cover, say, the SPF record format. It's also doubtful that Microsoft's agreement would offer much protection against third party patent claims. After all, why would someone intent on enforcing a patent claim covering the MARID standard even execute Microsoft's agreement in the first place? On top of that, it seems that the non-infringing SPF-classic offers better protection against viruses and joe jobs, and has already enjoyed small-scale but successful implementation and deployment. Doing the cost-benefit analysis, it's hard to support adopting Sender ID unless there is some compelling technical advantage to the technology. In discussions, I've seen vague references to banks and third party mailers, but no concrete scenarios for which Sender ID is really necessary. For example, in this previous message: http://www.imc.org/ietf-mxcomp/mail-archive/msg03912.html I explore an example with a bank and third-party sender and find roughly equivalent solutions with both SPF-classic and Sender ID. Before standardizing the infringing technology, can people come up with compelling scenarios that really require Sender ID? Moreover, can we convince ourselves that these scenarios couldn't also be satisfied through small, non-infringing enhancements to one of the other proposals? David From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 18:07: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 SAA09950 for ; Wed, 1 Sep 2004 18:06: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 i81LgDBW008385; Wed, 1 Sep 2004 14:42:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i81LgDnl008384; Wed, 1 Sep 2004 14:42:13 -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 i81LgCDF008374 for ; Wed, 1 Sep 2004 14:42:12 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 71A1C40C6 for ; Wed, 1 Sep 2004 14:42:10 -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: IETF MARID WG From: Mark Lentczner Subject: DEPLOY: A personal take on the IPR topic Date: Wed, 1 Sep 2004 14:42:08 -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 As the chairs have asked for information about personal deployment, I wanted to share my view on the topic of IPR: In light of the license terms, I will not be coding any implementation of the portions of SenderID that are covered by the IPR claim. I do not come to this conclusion lightly, or happily. It took quite some time to read and digest the Microsoft IPR license, and to consider the review by open source lawyers that I respect (specifically Larry Rosen and Eben Moglen). All my computer work these days is for free. And, as I don't work on mail code that will have direct end-users, all my work in this area is for inclusion in yet other projects. Hence, anything I wrote for SenderID would require a new license by anyone who choose to incorporate my work. I do not wish to encumber my work this way. I do support SenderID, and hope the current set of drafts (or something close) will be promoted by this working group. I am also glad that others will undertake to write free software (in the general sense) that will implement it within the bounds of the license. I will, as an end-user, run such software on my servers. I will continue to work on the protocol aspects of SenderID, since these are not covered by the IPR. I will continue to edit the draft as co-author, and will continue work on various implementations of it (such as record parsers and generators.) - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 18:14:44 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 SAA11060 for ; Wed, 1 Sep 2004 18:14:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81Lmxpk008824; Wed, 1 Sep 2004 14:48: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 i81LmxjT008823; Wed, 1 Sep 2004 14:48:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81LmwLs008811 for ; Wed, 1 Sep 2004 14:48:58 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so16496rnk for ; Wed, 01 Sep 2004 14:48:58 -0700 (PDT) Received: by 10.38.164.76 with SMTP id m76mr2460520rne; Wed, 01 Sep 2004 14:48:57 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Wed, 1 Sep 2004 14:48:57 -0700 (PDT) Message-ID: <94df60cf04090114481fb2b2f9@mail.gmail.com> Date: Wed, 1 Sep 2004 17:48:57 -0400 From: Reply-To: To: Harry Katz Subject: Re: Sendmail releases open source Sender ID milter for testing Cc: Rand Wacker , ietf-mxcomp@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 1 Sep 2004 09:55:52 -0700, Harry Katz wrote: > > Second as per the terms of the license itself, End Users who are > recipients of a licensed implementation of Sender ID and distributors > who are redistributing a branded licensed implementation do not need to > separately sign this License Agreement. I understand your the point about End Users, but could you clarify how the license exempts distributors? Specifically, my concern is that while section 2.1 allows indirect distribution of object code, section 2.2, which applies to source code, does not. David From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 18:19:24 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 SAA11627 for ; Wed, 1 Sep 2004 18:19: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 i81LuPKO009348; Wed, 1 Sep 2004 14:56: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 i81LuP5D009347; Wed, 1 Sep 2004 14:56:25 -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 i81LuOK4009335 for ; Wed, 1 Sep 2004 14:56:25 -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 i81LtOFe012525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Sep 2004 17:55:27 -0400 Subject: RE: Updated Sender-ID License Faq (was acceptable use) From: Paul Iadonisi To: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1094075681.23164.34.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 01 Sep 2004 17:54:41 -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-09-01 at 16:12, Hallam-Baker, Phillip wrote: > The issue here is whether it is possible to add Sender-ID technology > to a GPL licensed mailer and distribute the technology with the > mailer itself. It is more than that. I bring up the GPL more than anything else because it is the license I know best. As others have pointed out, the GPL is not the only license with which this patent license is incompatible. > Let us for the sake of argument stipulate that there is a conflict, > that it is not possible to distribute the technology itself under > the GPL. It is much more than 'for the sake of argument'. You are implying what you have asserted elsewhere: that they are not incompatible. Yet you have only asserted it and have not successfully countered what three lawyers have said and zero lawyers have countered: that the patent license is not only incompatible with the GPL, but many, if not all other FOSS licenses. > My point is that the GPL does not prevent the distribution > of Sender-ID technology for GPL licensed mailers. Like others before you, you are forgetting about aggregations. This patent license does not meet the standards for distribution with Red Hat's Fedora Core, or Debian GNU/Linux and no software encumbered by it can be (re)distributed with either collection, and I'm sure many others. > It is still possible to distribute the code under a separate OSS > license. Since most OSS mailers appear to already be taking the > same approach with SSL (another patent encumbered technology) this > does not seem to be a big deal. I am not aware of what patents cover SSL, but your argument is incomplete without a description of the license terms. This is, I fully acknowledge, something I am not too familiar with and intend to read up on, especially since there is a work in progress library (gnutls) that is intended to replace openssl, if I'm not mistaken. I hope you are not referring to the RSA patent, as I'm sure you are aware that it is expired. The RSA patent is also a prime example of how a patent demonstrably *hindered* adoption. FOSS operating system vendors began including the algorithms soon after the patent expired. Yes, US export laws hindered it as well, but the patent clearly had a negative effect. > It is also possible for the copyright holder to vary the license. > VeriSign has distributed the same code under the GPL and a commercial > license for several years, there is nothing in the GPL to prohibit > this, the copyright was never transfered to the FSF. What code are you talking about? Was any of the technology covered by patents? Were they Verisign's own patents? If they were Verisign's own patents, then how is this argument relevant? In this case, all you are saying is that Microsoft is allowed to distribute a GPLed implementation of the patented technology. With the current licenses, this would make no sense, i.e.: You can modify the code and redistribute without permission (pursuant to the GPL) but you can't modify the code and redistribute without a separate license from Microsoft (pursuant to the patent license). And Microsoft GPLing the code would not allow the restriction to 'only what is necessary to implement Sender-ID'. By the time they were done with all the legalese, it would be clear that using the GPL would only be for show as there would be so many contradictions that it would essentially NOT be GPLed. > The terms of the license itself are only invariant if the code > distribution has forked so that there is a QMail type situation > where the party that holds the copyright is not the party wanting > to maintain the code. If I'm understanding the above, then there are several thousand packages that fit this description within Debian, Fedora Core, Mandrake SUSE Linux, and others, because of the simple fact that a good percentage of packages are patched by distributors. > What we have here is like someone claiming that the telephone > system discriminates against themselves because they have made a > vow of silence. I don't follow this logic, though it's probably not relevant. > One of the reasons we chose making the CERN libwww code (the > basis for Mosaic) public domain, not GPL was because we thought > GPL too restrictive. This adds nothing to your argument. No one is asking that anyone GPL anything. Only that those of us you choose the GPL license to license our own, copyrighted code are allowed to continue to do so if we implement Sender-ID. The current patent license does not allow this, as three attorneys so far have stated. > It is rather ironic that the GPL seems to insist on patents being > put in the public domain in their entirety in order to allow the > distribution of copyright code. The GPL dates from an era when > code was expensive and there were few patent rights. The logical > approach for the GPL to take would be to treat patents in the > same way as code, with a viral poison pill defense. Instead the > demand is for unilateral disarmament. Well, if we are to assume you are correct in your analysis above, considering that those who wield the arms (software patents) are almost universally those with the deep pockets to carry out the litigation, then I wouldn't call that an unreasonable demand at all. But again, that doesn't really add much to this discussion. > I think that people are missing the real threat here. Let us > assume that the precedent is set that absolutely no encumbered > technology of any sort is going to be allowed in an IETF spec, > regardless of the license terms offered. It seems to me that > this would provide a very effective way to shut down all > future developoment of OSS, merely claiming to have applied > for a patent would be sufficient to stop any and every new > development. Have you considered that this may have the opposite effect? Namely that if that precedent were set, perhaps the people that matter (legislators, judges, the USPTO, voters) would wake up and see just how much harm software patents cause? Personally, I think this distracts from the matter at hand: should MARID approve a standard that is encumbered in such a way as to ghetto-ize several MTAs. My recommendation is an emphatic "NO." > As the problem of patent trolls increases the chances of any new > technology being entirely unencumbered becomes vanishingly small. Agreed. But that is a battle for another forum. It does not bolster your argument in any way I can see. -- -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 Wed Sep 1 19:00: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 TAA14818 for ; Wed, 1 Sep 2004 19:00: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 i81MViAN012055; Wed, 1 Sep 2004 15:31: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 i81MVinV012054; Wed, 1 Sep 2004 15:31:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp-out-2001.amazon.com (smtp-out-2001.amazon.com [207.171.160.37]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81MVhLu012042 for ; Wed, 1 Sep 2004 15:31:44 -0700 (PDT) (envelope-from jonagard@amazon.com) Received: from smtp-in-2004.iad2.amazon.com by smtp-out-2001.amazon.com with ESMTP (peer crosscheck: smtp-in-2004.iad2.amazon.com) X-Amazon-Corporate-Relay: smtp-out-2001.iad2.amazon.com X-AMAZON-TRACK: Received: from ex-gate-02.ant.amazon.com by smtp-in-2004.iad2.amazon.com with ESMTP (crosscheck: app-good-01.ant.amazon.com [10.16.148.40] (may be forged)) id i81MVFjH030437 for ; Wed, 1 Sep 2004 22:31:39 GMT Received: from jonagard.desktop.amazon.com ([10.21.12.165]) by ex-gate-02.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Sep 2004 15:32:00 -0700 From: Jonathan Gardner Organization: Amazon To: IETF MARID WG Subject: Motion to abandon Sender ID Date: Wed, 1 Sep 2004 15:31:36 -0700 User-Agent: KMail/1.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Message-Id: <200409011531.38815.jonagard@amazon.com> X-OriginalArrivalTime: 01 Sep 2004 22:32:00.0145 (UTC) FILETIME=[7F1CD010:01C49073] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i81MViLu012049 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I will argue here for abandoning Sender ID. I make some assumptions which could be refuted, but I believe that they are correct based on my experience. I encourage those who respond negatively to attack the particular points I am making and refute the facts I claim. We already agree to the fact that most Open Source licenses, especially the GPL, are not compatible with the terms of the Sender ID license. However, additional software could be downloaded and installed on existing platforms to run with software that is licensed under incompatible terms. For instance, a sendmail milter, or a perl script to filter all mail, or any number of possibilities. I would like to inform the chairs that the distribution of the technology in Linux and BSD distributions is critical for the widespread adoption of the technology among the open source community. Most people who use Linux or BSD do not add software to their installation. They expect everything to be tightly integrated together within the distribution. When software is released as part of the distribution, it shows that a certain amount of testing and work has gone into making it a part of the distribution. Adding additional software to an installation generally brings instability and requires additional resources. This is why people generally don't install additional software to their installation. Experience within the community shows that software that is not part of the major distributions is not considered standard, supporting this claim. Therefore, I claim it as a fact that software that is not distributed as part of the major distributions is not standard, and can never be a standard unless it finds a way to be included within the major distributions. If Sender ID technology cannot be distributed under the same terms by which most Linux and BSD distributions are distributed, then to include it the terms of the distributions must be modified. I don't believe it will be possible to convince the major Linux and BSD distributors to comply with Microsoft's Sender ID License in order to integrate the Sender ID technology in the distribution. I claim it as a fact that the Linux and BSD distributors will not modify their distribution terms to satisfy the Sender ID license. Therefore, since the terms of the license prevent it from being distributed under the terms of most Linux and BSD distributions, combined with the fact that changing the terms of distribution will not be possible, and combined with the fact that generally people don't include software on their machines that are not part of the distribution, the logical conclusion is that Sender ID will not be adopted as a standard by the open source community. In short, Microsoft's License for patent claims made on Sender ID prevent it from being a standard in the open source sommunity. Can we recommend a standard we know will not be a standard in the open source community? Open source software dominates the internet landscape, especially in the MTA realm. If the proposal cannot become a standard in the open source community, can it be a standard in the community as a whole? It cannot. Our efforts will be in vain unless we propose a standard that can be adopted by the open source community. If Microsoft would like to propose a different license, or surrender their claims to unspecified IP in Sender ID, then I believe that Sender ID could become a standard in the open source community. However, Microsoft has very little time to propose a new license, and judging by past experience with their legal department, I don't think they will be able to do so within a reasonable time frame. Perhaps Microsoft will immediately surrender their patent claims, but I doubt that. Therefore, I move that Sender ID be removed from the MARID recommendations because it can never be a standard in the open source community due to its licensing terms and the uncertainty of pending patent claims. In its place, we should recommend SPF version 1, or SPF "classic", as currently adopted and implemented by over 70,000 recorded domains. - -- Jonathan M. Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBNk3IBFeYcclU5Q0RAgX6AKCIxwjKvkc+LvhRZlugZsHk+bQ+LACgl4Px KZYCr1v/QXJf0E8VteCgr2E= =o1NT -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 19:22: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 TAA16047 for ; Wed, 1 Sep 2004 19:22: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 i81MvqMd013560; Wed, 1 Sep 2004 15:57: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 i81MvqvE013559; Wed, 1 Sep 2004 15:57:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81MvpJ5013552 for ; Wed, 1 Sep 2004 15:57:51 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-092-187.area3.spcsdns.net ([68.245.102.182]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2e37-0005lD-2r; Wed, 01 Sep 2004 18:57:54 -0400 Message-ID: <413653DC.20609@solidmatrix.com> Date: Wed, 01 Sep 2004 18:57:32 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Alan Hodgson CC: IETF MARID WG Subject: Re: Updated Sender-ID License Faq (was acceptable use) References: <20040901212202.GD11900@simkin.ca> In-Reply-To: <20040901212202.GD11900@simkin.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan Hodgson wrote: > I suggest, therefore, that with the current license requirements, that this > standard be rejected and a non-encumbered alternative be considered. > Keep in mind that there is at least another alternative: ignore the IPR claims as irrelevant and frivilous, and go ahead with the standard anyway like the example given in RFC 3669. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 19:53:40 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 TAA17906 for ; Wed, 1 Sep 2004 19:53:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81NSix8016124; Wed, 1 Sep 2004 16:28: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 i81NSigH016123; Wed, 1 Sep 2004 16:28:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81NShHS016116 for ; Wed, 1 Sep 2004 16:28:43 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-092-187.area3.spcsdns.net ([68.245.102.182]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2eX4-0007Ua-F3; Wed, 01 Sep 2004 19:28:51 -0400 Message-ID: <41365B20.8080204@solidmatrix.com> Date: Wed, 01 Sep 2004 19:28:32 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Jonathan Gardner CC: IETF MARID WG Subject: Re: Motion to abandon Sender ID References: <200409011531.38815.jonagard@amazon.com> In-Reply-To: <200409011531.38815.jonagard@amazon.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jonathan Gardner wrote: > > Therefore, I move that Sender ID be removed from the MARID recommendations > because it can never be a standard in the open source community due to its > licensing terms and the uncertainty of pending patent claims. In its place, > we should recommend SPF version 1, or SPF "classic", as currently adopted > and implemented by over 70,000 recorded domains. > A few comments. First of all, we do not know whether the IPR claims extend to SPF classic or not. While the IPR disclosure does not mention the SPF draft, I have contacted Microsoft's legal department several times in the past 9 months to obtain a clear answer as to whether all of the drafts produced in the ASRG as input to MARID including RMX, SPF and others, are in fact covered or not covered. To date, I have not received an answer, and we have not heard directly from the legal department. However, it does happen often that IPR claims are submitted even after the standard is published as mentioned in RFC 3669, so SPF classic might not be any better than Sender-ID. Here is a copy of the email I sent and a reply I received: > -------- Original Message -------- > Subject: RE: Caller ID license > Date: Mon, 1 Mar 2004 15:58:00 -0800 > From: Dawna Hoerle (LCA) > To: Yakov Shafranovich > CC: Microsoft Standards Inquiries > > > Thank you for your inquiry. I will route your request to the appropriate > persons, who will respond to you as quickly as possible. > > Dawna > -----Original Message----- > From: Yakov Shafranovich > Sent: Monday, March 01, 2004 2:27 PM > To: Microsoft Standards Inquiries > Subject: Caller ID license > > I co-chair the Anti-Spam Research Group (ASRG) of the IRTF > (www.irtf.org/asrg/). My question is regarding the Caller ID proposal > that Microsoft has recently published (www.microsoft.com/spam/). I want > to know whether you are going to be claiming similar IP claims on the > following IETF drafts: > > MTAMARK - draft-stumpf-dns-mtamark-01.txt > DRIP - draft-brand-drip-02.txt > RMX - draft-danisch-dns-rr-smtp-03.txt > DMP - draft-fecyk-dmp-01.txt > SPF - draft-mengwong-spf-00.txt > FSV - draft-levine-fsv-00.txt > > Yakov Second point - at this time Microsoft has no patent or any other IP relevant to this and is not forcing anyone to take out a license. Therefore, no license is required as of today. We are talking about a *possible* patent that *may be* approved in the future. As Microsoft states in their FAQ: > Q4: When do you need to execute a license with Microsoft? > A: At this time Microsoft is only aware of pending patent application claims that cover its > submission of the Sender ID specification. Because Microsoft is not aware of any issued patent > claims, Microsoft does not require any one to sign a license with Microsoft to implement the > Sender ID specification or any part of it that is incorporated into IETF working drafts. Third point - as others and I posted before, there is serious doubt as to whether this patent is actually valid or enforceble in light of possible prior art. As of today, this technology is not encumbered by any patents and may stay that away if the patent application is not approved. Additionally, it is feasible that at least some of the claims if not all are deriving from the discussions in the ASRG and other groups, and therefore may be complete frivilous. The IDN WG faced that situation before as described in RFC 3669 and chose to ignore the claims. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 20:43:50 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 UAA20702 for ; Wed, 1 Sep 2004 20:43:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i820I7x2020143; Wed, 1 Sep 2004 17:18: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 i820I7do020142; Wed, 1 Sep 2004 17:18:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i820I68t020128 for ; Wed, 1 Sep 2004 17:18:06 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so10787rnk for ; Wed, 01 Sep 2004 17:18:06 -0700 (PDT) Received: by 10.38.171.20 with SMTP id t20mr2523723rne; Wed, 01 Sep 2004 17:18:06 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Wed, 1 Sep 2004 17:18:06 -0700 (PDT) Message-ID: <94df60cf04090117181823dee6@mail.gmail.com> Date: Wed, 1 Sep 2004 20:18:06 -0400 From: Reply-To: To: Yakov Shafranovich Subject: Re: Motion to abandon Sender ID Cc: Jonathan Gardner , IETF MARID WG In-Reply-To: <41365B20.8080204@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200409011531.38815.jonagard@amazon.com> <41365B20.8080204@solidmatrix.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 01 Sep 2004 19:28:32 -0400, Yakov Shafranovich wrote: > > A few comments. First of all, we do not know whether the IPR claims > extend to SPF classic or not. You are correct that we don't know whether SPF or SPF2 is covered by pending patent claims from Microsoft. However, we *do* know that any such claims are *not* covered by Microsoft's license agreement. Thus, even if we were to adopt Sender ID as the standard, should Microsoft subsequently be granted a patent covering the SPF2 record format, it would no longer be possible to deploy Sender ID without a new license from Microsoft. If, at this point, sender ID were derailed by a patent from Microsoft over SPF, I think this would pretty clearly demonstrate bad faith on Microsoft's part. Since we have been instructed to assume good faith on the part of all parties, I think this means operating under the assumption that: 1) The pending patent rights granted by Microsoft's Sender ID agreement are sufficient to deploy Sender ID (at least for the subset of software authors who find the conditions of the agreement acceptable), and therefore 2) Microsoft does not have any pending claims over the SPF record format. So yes, anybody, even Microsoft, might have patent claims that might prohibit just about any recommendation of the MARID working group. But we still have to make progress, and the best we can do is deal with the most likely scenario, which is that Microsoft probably has applied for patents, that the patents probably cover the portions of Sender ID they have offered to license--namely the pra and or core documents--and finally that until we have more information, none of the MARID proposals is any more or less likely to be affected by third-party patent holders. David From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 20:57:41 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 UAA21477 for ; Wed, 1 Sep 2004 20:57:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i820XcAG021313; Wed, 1 Sep 2004 17:33: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 i820XcXR021312; Wed, 1 Sep 2004 17:33:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i820Xcws021306 for ; Wed, 1 Sep 2004 17:33:38 -0700 (PDT) (envelope-from csm@moongroup.com) Received: from [192.168.0.10] (rdu74-170-067.nc.rr.com [24.74.170.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1.moongroup.com (Postfix) with ESMTP id 8889C1182400E for ; Wed, 1 Sep 2004 20:33:43 -0400 (EDT) Message-ID: <41366A66.1070909@moongroup.com> Date: Wed, 01 Sep 2004 20:33:42 -0400 From: Chuck Mead Organization: MoonGroup.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Sender-ID or SPF Classic X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All: at present it appears to me that we are being forced by the Microsoft license to leave Sender-ID behind. If we do not we will cause implementation problems for a huge community of people running OSS MTA's (the majority of internet MTA's in fact). This means that this working group has a clear decision to make. Do we continue to press on with Sender-ID and cause this problem or do we choose SPF-Classic and move forward with it. In my own mind the choice is clear and I strongly urge the group to support SPF-Classic and put this forward as our standard. - -- csm@moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBNmpmv6Gjsf2pQ0oRAiVFAJ9JUD/iiN5X3Fy++wLnN37CH/ybYQCeNmHI qetvIbjJiBx5BWVlGrWSPhM= =AfhK -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 21:50: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 VAA24416 for ; Wed, 1 Sep 2004 21:50: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 i821QwkE025949; Wed, 1 Sep 2004 18:26: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 i821QwJp025948; Wed, 1 Sep 2004 18:26:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i821Qv91025939 for ; Wed, 1 Sep 2004 18:26:57 -0700 (PDT) (envelope-from george@m5p.com) Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by mailhost.m5p.com (8.12.11/8.12.11) with ESMTP id i821QupM036320 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Wed, 1 Sep 2004 18:26:58 -0700 (PDT) Received: (from defang@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i821MAEl036265 for ; Wed, 1 Sep 2004 18:22:10 -0700 (PDT) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (MIMEDefang) with ESMTP id i821MAYq036263; Wed, 01 Sep 2004 18:22:10 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i821M9LE026582; Wed, 1 Sep 2004 18:22:09 -0700 (PDT) Date: Wed, 1 Sep 2004 18:22:09 -0700 (PDT) From: George Mitchell Message-Id: <200409020122.i821M9LE026582@m5p.com> To: ietf-mxcomp@imc.org, jonagard@amazon.com Subject: Re: Motion to abandon Sender ID In-Reply-To: <200409011531.38815.jonagard@amazon.com> X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I will argue here for abandoning Sender ID. I make some assumptions which > could be refuted, but I believe that they are correct based on my > experience. I encourage those who respond negatively to attack the > particular points I am making and refute the facts I claim. I second Mr. Gardner's motion. -- George Mitchell From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 22:03: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 WAA25160 for ; Wed, 1 Sep 2004 22:03: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 i821aUb7026954; Wed, 1 Sep 2004 18: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 i821aUh6026953; Wed, 1 Sep 2004 18:36:30 -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 i821aT5f026946 for ; Wed, 1 Sep 2004 18:36:29 -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 1C2gWc-00070V-6M for ietf-mxcomp@imc.org; Wed, 01 Sep 2004 20:36:35 -0500 To: "IETF MARID WG" References: <20040901212202.GD11900@simkin.ca> <413653DC.20609@solidmatrix.com> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 01 Sep 2004 20:36:20 -0500 In-Reply-To: <413653DC.20609@solidmatrix.com> (Yakov Shafranovich's message of "Wed, 01 Sep 2004 18:57:32 -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: Updated Sender-ID License Faq (was acceptable use) 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.6 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 <413653DC.20609@solidmatrix.com> Yakov Shafranovich writes: > Alan Hodgson wrote: >> I suggest, therefore, that with the current license requirements, that this >> standard be rejected and a non-encumbered alternative be considered. > > Keep in mind that there is at least another alternative: ignore the > IPR claims as irrelevant and frivilous, and go ahead with the standard > anyway like the example given in RFC 3669. Thanks to your (Yakov's) fine efforts, it does appear that the MS is likely to be worse than the typical patent-the-obvious type patent, but is much closer to what PHB calls a patent troll. They may well have taken ideas discussed in the ASRG and, after the fact and without telling anyone, patented them. The problem is that even if Microsoft is being a patent troll, they would be a patent troll with very deep pockets. If they chose to sue for ignoring "their" IPR, they could bankrupt even medium to large companies with lawyer fees. A cease and desist from a tiny patent troll may well be ignored by most open source mirror sites, but I doubt that it would be ignored if it came from MS. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 22:08:54 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 WAA27690 for ; Wed, 1 Sep 2004 22:08:54 -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 i821ilJp028647; Wed, 1 Sep 2004 18:44:47 -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 i821ilqd028646; Wed, 1 Sep 2004 18:44:47 -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 i821ikeq028640 for ; Wed, 1 Sep 2004 18:44:46 -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 1C2gec-00073u-Dj for ietf-mxcomp@imc.org; Wed, 01 Sep 2004 20:44:52 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Wed, 01 Sep 2004 20:44:46 -0500 In-Reply-To: (Mark Lentczner's message of "Wed, 1 Sep 2004 14:42:08 -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: DEPLOY: A personal take on the IPR topic 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.6 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 Mark Lentczner writes: > As the chairs have asked for information about personal deployment, I > wanted to share my view on the topic of IPR: > > In light of the license terms, I will not be coding any implementation > of the portions of SenderID that are covered by the IPR claim. I will add my own personal deployment take. I am the co-author of one of the most widely used SPF implementations. Since I wrote the implementation in order to help out with the spam/forgery problem, it is important to me to have this implementation distributed far and wide. It is also important for me to run my own code. I do not believe that the current SenderID license will be accepted by most Linux and *BSD distributions and code requiring that license would be excluding from those distributions. A great deal of work has been done by others to get this SPF implementation into various distributions and patches written for most MTAs. It I believe that it would therefore be counter productive to develope or deploy SenderID. I believe that this will likely slow the deployment by many others. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 22:36: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 WAA08396 for ; Wed, 1 Sep 2004 22:36:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i822Du30030496; Wed, 1 Sep 2004 19:13: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 i822Dufk030495; Wed, 1 Sep 2004 19:13:56 -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 i822DtBc030488 for ; Wed, 1 Sep 2004 19:13:56 -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 1C2h6r-0007PK-Nx for ietf-mxcomp@imc.org; Wed, 01 Sep 2004 21:14:02 -0500 To: "IETF MARID WG" References: <200409011531.38815.jonagard@amazon.com> <41365B20.8080204@solidmatrix.com> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 01 Sep 2004 21:13:57 -0500 In-Reply-To: <41365B20.8080204@solidmatrix.com> (Yakov Shafranovich's message of "Wed, 01 Sep 2004 19:28:32 -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: Motion to abandon Sender ID 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.6 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 <41365B20.8080204@solidmatrix.com> Yakov Shafranovich writes: > Second point - at this time Microsoft has no patent or any other IP > relevant to this and is not forcing anyone to take out a > license. Therefore, no license is required as of today. We are talking > about a *possible* patent that *may be* approved in the future. As > Microsoft states in their FAQ: This just makes the SenderID license requirement a time bomb waiting to go off. For all I know, the patent was granted 5 minutes ago. (I would address the other things that Yakov said, but mazieres@gmail.com did a great job already.) -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 1 23:15: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 XAA11227 for ; Wed, 1 Sep 2004 23:15: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 i822kjkX032600; Wed, 1 Sep 2004 19:46: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 i822kjPh032599; Wed, 1 Sep 2004 19:46:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i822kit9032591 for ; Wed, 1 Sep 2004 19:46:45 -0700 (PDT) (envelope-from madman@myeastside.com) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i822knpA019597 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 1 Sep 2004 19:46:49 -0700 Message-ID: <00e701c49097$22faa6d0$3201a8c0@rasta> From: "Harold A'Hole" To: "IETF MARID WG" References: <200409011531.38815.jonagard@amazon.com><41365B20.8080204@solidmatrix.com> Subject: Re: Motion to abandon Sender ID Date: Wed, 1 Sep 2004 19:47:07 -0700 Organization: http://madman.myeastside.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > Second point - at this time Microsoft has no patent or any other IP > > relevant to this and is not forcing anyone to take out a > > license. Therefore, no license is required as of today. We are talking > > about a *possible* patent that *may be* approved in the future. As > > Microsoft states in their FAQ: > This just makes the SenderID license requirement a time bomb waiting > to go off. For all I know, the patent was granted 5 minutes ago. But the worst case is that you'd then need to fax in the license. I'd bet MSFT would be willing to allow software containing it to be distributed as long as those who deploy it get a license. And what would MSFT really do if you didn't get a license? I mean, would they really prosecute a user of an international standard over IP that they freely give away to anybody who sends in a fax (or I'd bet even signing online would be offered soon enough) -- with the IP implemented in many SenderID implementations? But there's also a chance that the IP claimed won't be patented for a long time, if at all. Harry From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 00:02:55 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 AAA14287 for ; Thu, 2 Sep 2004 00:02:54 -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 i823dNSQ035756; Wed, 1 Sep 2004 20:39:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i823dNjb035755; Wed, 1 Sep 2004 20:39:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i823dMii035745 for ; Wed, 1 Sep 2004 20:39:22 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 03:39:24 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: Subject: RE: Motion to abandon Sender ID Date: Wed, 1 Sep 2004 21:39:32 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200409020122.i821M9LE026582@m5p.com> X-OriginalArrivalTime: 02 Sep 2004 03:39:24.0668 (UTC) FILETIME=[70E7ABC0:01C4909E] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jonathan M. Gardner wrote: >Therefore, I move that Sender ID be removed from the MARID recommendations >because it can never be a standard in the open source community due to its >licensing terms and the uncertainty of pending patent claims. In its place, >we should recommend SPF version 1, or SPF "classic", as currently adopted >and implemented by over 70,000 recorded domains. George Mitchell wrote: >I second Mr. Gardner's motion. -- George Mitchell I third Jonathan Gardner's motion. Not just because of Sender ID's license and patent problems, but also due to Sender ID's various forged DSN injection security problems. SPF "classic" (AFAIK) has none of these problems, has had much greater testing and experimentation, and has several working MTA implementations. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 00:33: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 AAA16595 for ; Thu, 2 Sep 2004 00:33: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 i824AKmT037877; Wed, 1 Sep 2004 21:10:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i824AKat037876; Wed, 1 Sep 2004 21:10:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gizmo07ps.bigpond.com (gizmo07ps.bigpond.com [144.140.71.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i824AJ7U037868 for ; Wed, 1 Sep 2004 21:10:19 -0700 (PDT) (envelope-from ian.peter@ianpeter.com) Received: (qmail 20092 invoked from network); 2 Sep 2004 04:10:14 -0000 Received: from unknown (HELO psmam10.bigpond.com) (144.135.25.97) by gizmo07ps.bigpond.com with SMTP; 2 Sep 2004 04:10:14 -0000 Received: from cpe-144-136-148-138.qld.bigpond.net.au ([144.136.148.138]) by psmam10.bigpond.com(MAM REL_3_4_2a 216/33654087) with SMTP id 33654087; Thu, 02 Sep 2004 14:10:14 +1000 From: "Ian Peter" To: "'IETF MARID WG'" Subject: RE: DEPLOY: Resolving IPR issues Date: Thu, 2 Sep 2004 14:10:13 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcSQh77XWwMqN5ZbQA2xBqYya/tnZwAGQZXg In-Reply-To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I am hoping for a breakthrough here. Attached a copy of my email to Bill Gates - I suggest similar emails to senior executives at Microsoft might be useful, especially if you have personal contacts, because I feel sure we are dealing with bureaucratic defensive legal tendencies here rather than managerial policy decisions. That might be able to be reversed. My email said basically "Bill, The adoption of Sender-ID seems under threat at IETF because of a defensive patent/licensing condition Microsoft's legal people seem intent on pushing. The patent claim appears to be scant in any case because of prior art. I believe that it might be time for a policy decision to be taken to override this - that Microsoft intends to drop any legal rights it might have in this case to co-operate with the rest of the Internet community in fighting spam. That sounds like good public relations to me and I believe Microsoft stands to gain rather than lose by not imposing license conditions which are seen as threatening by many in the open source community. Your Harry Katz and Jim Lyons and others have done great work in co-operating with the rest of the community to bring out a suitable standard. It would be a pity if any of this effort to deal with the most significant problem facing email users was at all undermined by your standard legal procedures. I think 5 minutes of your time could yield enormous benefits here." Ian Peter Senior Partner Ian Peter and Associates Pty Ltd P.O. Box 10670 Adelaide St Brisbane 4000 Australia Tel (617) 3870 1181 Mobile (614) 1966 7772 www.ianpeter.com www.nethistory.info www.theinternettapes.com (check out the new Internet history Audio CD and Ebook at this site) > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of wayne > Sent: Thursday, 2 September 2004 11:45 AM > To: IETF MARID WG > Subject: Re: DEPLOY: A personal take on the IPR topic > > > In Mark > Lentczner writes: > > > As the chairs have asked for information about personal > deployment, I > > wanted to share my view on the topic of IPR: > > > > In light of the license terms, I will not be coding any > implementation > > of the portions of SenderID that are covered by the IPR claim. > > > I will add my own personal deployment take. > > > I am the co-author of one of the most widely used SPF implementations. > Since I wrote the implementation in order to help out with > the spam/forgery problem, it is important to me to have this > implementation distributed far and wide. It is also > important for me to run my own code. > > I do not believe that the current SenderID license will be > accepted by most Linux and *BSD distributions and code > requiring that license > would be excluding from those distributions. A great deal of work > has been done by others to get this SPF implementation into > various distributions and patches written for most MTAs. > > It I believe that it would therefore be counter productive to > develope or deploy SenderID. I believe that this will likely > slow the deployment by many others. > > > > -wayne > > > From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 00:40:11 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 AAA16945 for ; Thu, 2 Sep 2004 00:40:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i824DfvO038132; Wed, 1 Sep 2004 21:13: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 i824DfIP038130; Wed, 1 Sep 2004 21:13:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i824De9T038119 for ; Wed, 1 Sep 2004 21:13:40 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so323250rnl for ; Wed, 01 Sep 2004 21:13:42 -0700 (PDT) Received: by 10.38.70.76 with SMTP id s76mr824072rna; Wed, 01 Sep 2004 21:13:42 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Wed, 1 Sep 2004 21:13:42 -0700 (PDT) Message-ID: <94df60cf04090121134d45980a@mail.gmail.com> Date: Thu, 2 Sep 2004 00:13:42 -0400 From: Reply-To: To: ietf-mxcomp@imc.org Subject: Re: Sender-ID or SPF Classic In-Reply-To: <41366A66.1070909@moongroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41366A66.1070909@moongroup.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 01 Sep 2004 20:33:42 -0400, Chuck Mead wrote: > > In my own mind the choice is clear and I strongly urge > the group to support SPF-Classic and put this forward as our standard. At this point, I'm inclined agree with you. The Sender ID license is definitely going to cause a lot of headaches (as I found out today when inquiring about executing the license at my university). Those headaches have to be weighed against the benefit gained from Sender ID over other alternatives. From my point of view, the cost-benefit analysis does not favor Sender ID. Of course, I'm biased by the fact that pending patent claims may adversely affect my own software by preventing me from complying with a Sender ID standard. I appreciate the fact that other people have pretty different perspectives. However, even leaving aside the highly contentious issue of how "bad" the license terms are, I still see two possible arguments for adopting something like SPF-classic. First, I have not yet seen a convincing usage scenario that truly requires Sender ID. For every Sender ID usage scenario I can think of (e.g., bank bulk mailing statements through a third party), something equivalent can be achieved with an SPF-classic deployment, though there would be slight differences. If, in fact, SPF-classic is sufficient for all usage scenarios (and that's a big if), then it certainly makes sense to go with a standard that has fewer known IPR issues. (Any surprise patent covering SPF-classic would also very likely cover Sender ID, so in that sense the two are equally vulnerable to unknown IPR issues.) Conversely, even if Sender ID were adopted, I think from discussions here that something like SPF-classic would still be needed to thwart viruses and joe jobs, as well as possibly to shift liability more squarely onto "bad guys". [I'm sure that as soon as Sender ID is deployed, viruses will start including "Resent-Sender: virus@com" or equivalent headers to avoid Failing Sender ID tests.] Thus, adopting SPF-classic now, particularly with its deployment momentum already gaining, would be an entirely good thing. Even if a year later we also want to standardize Sender ID, the SPF-classic effort will definitely not have been a waste. I am, of course, still open to hearing about a "killer" Sender ID application that really requires Sender ID. David From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 00:42: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 AAA17094 for ; Thu, 2 Sep 2004 00:42:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i824M2gg038617; Wed, 1 Sep 2004 21:22: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 i824M2nW038616; Wed, 1 Sep 2004 21:22:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i824M1BA038610 for ; Wed, 1 Sep 2004 21:22:01 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 68775 invoked from network); 2 Sep 2004 04:22:06 -0000 Received: from unknown (HELO vaio) (203.115.130.41) by relay.pair.com with SMTP; 2 Sep 2004 04:22:06 -0000 X-pair-Authenticated: 203.115.130.41 Message-Id: <4.1.20040902122701.03da53e0(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 02 Sep 2004 12:33:27 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: SenderID for the greater good? 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: I just finished reading a reasonably significant portion of the relevant comments in the ietf-mxcomp archives: http://www.imc.org/ietf-mxcomp/mail-archive/threads.html IMHO, the two "successful" arguments for continuing with SenderID that must be refuted are: 1. Companies of importance, e.g. AOL, will have no problem with the SenderID license. 2. Anti-forgery with SenderID will gain adoption much faster with Microsoft's influence and help. IMHO, the rest of the arguments for SenderID were already reasonably refuted. Here is my opinion on how to refute these: 1. A standard should be implementable by all, or at least most. Even though for example AOL claims they can implement as a receiver without IPR problems, they and we all should IMHO also be concerned about implementation of other receivers, because AOL and all of us are also a senders of e-mail. 2. But under Microsoft's control with the added leverage of being endorsed as public standard, which is IMHO not the spirit of internet standards. In general I think it is not wise, nor consistent with the RFCs under which IETF supposedly operates, to create "internet standards" which give leverage to one competitor over **ALL** others, by "standardizing" on one competitor's license. The larger question though is the greater good helped more than hurt? IMHO, anti-forgery (especially per-domain anti-forgery) is not a complete solution to spam, and thus doing any action that would could stifle the diversity of competition in anti-spam, is very dangerous to the greater good. AccuSpam is an example of a anti-spam receiver which may not be able to implement SenderID if it requires signing a license with Microsoft, because it is possible that Microsoft may one day view AccuSpam as a competitor to some anti-spam product from Microsoft and AccuSpam might not want to give Microsoft the leverage of an executed license. Regards, Shelby Moore From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 01:04:55 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 BAA18260 for ; Thu, 2 Sep 2004 01:04:54 -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 i824exOR040029; Wed, 1 Sep 2004 21:40: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 i824exuB040028; Wed, 1 Sep 2004 21:40:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i824ewpV040018 for ; Wed, 1 Sep 2004 21:40:58 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i824ew3V010385 for ; Wed, 1 Sep 2004 21:40:58 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id A282984F81C; Wed, 1 Sep 2004 21:40:58 -0700 (PDT) Date: Wed, 1 Sep 2004 21:40:58 -0700 From: "Mark C. Langston" To: IETF MARID WG Subject: Re: Motion to abandon Sender ID Message-ID: <20040902044058.GB659@bitshift.org> References: <200409011531.38815.jonagard@amazon.com> <41365B20.8080204@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 9:36PM up 3:33, 5 users, load averages: 0.05, 0.05, 0.01 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 01, 2004 at 09:13:57PM -0500, wayne wrote: > > In <41365B20.8080204@solidmatrix.com> Yakov Shafranovich writes: > > > Second point - at this time Microsoft has no patent or any other IP > > relevant to this and is not forcing anyone to take out a > > license. Therefore, no license is required as of today. We are talking > > about a *possible* patent that *may be* approved in the future. As > > Microsoft states in their FAQ: > > This just makes the SenderID license requirement a time bomb waiting > to go off. For all I know, the patent was granted 5 minutes ago. > it won't make any difference, but I had dinner tonight with a friend of mine who's a partner in a fairly substantial and rather well-known IP law firm. I described the current situation to her, and the terms of the MS license. Granted, she hasn't read the actual license terms (I'm going to send them to her later this evening), but she stated that, given the circumstances of the license and the undisclosed claims, she would advise against going forward with Sender ID. Her wording was a bit stronger than "advise against". -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 01:05:24 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 BAA18296 for ; Thu, 2 Sep 2004 01:05: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 i824fxhK040082; Wed, 1 Sep 2004 21:41:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i824fxQh040081; Wed, 1 Sep 2004 21:41:59 -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 i824fx0x040074 for ; Wed, 1 Sep 2004 21:41:59 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i824g4Vv012792 for ; Wed, 1 Sep 2004 21:42:04 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: Motion to abandon Sender ID Date: Wed, 1 Sep 2004 21:42:03 -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 This may be naive in terms of the workings of the group, and protocol...but rather than abandon Sender I.D., why not contact MS and explain to them the concerns, and let them clarify? Ask them to put in writing explicitly what their patent covers with respect to the items of concern (or, conversely, to put in writing expressly those things which the patent is warranted to *not* cover), and ask them to further rewrite the license to address and clarify those areas of concern as well? They have obviously put a lot of time and effort in to this, and while I absolutely agree there are problems with things as they stand today, and fully expect MS, as any other company, to cover their investments and their asterisks, in any negotiation, and at this point this is what it is, it makes sense to say to them "here are the problems which keep it from moving forward - will you address those problems, or do we need to abandon it and move on?" Yes, I said I didn't understand why we were looking at this *given the problems* when we had SPF which had no such problems, but now it's not clear to me whether they have been given an opportunity to rectify these problems; have they? Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy Professor of Law, Lincoln Law School of SJ From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 02:00:24 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 CAA21227 for ; Thu, 2 Sep 2004 02:00:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i825c1Rn057610; Wed, 1 Sep 2004 22:38: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 i825c1is057608; Wed, 1 Sep 2004 22:38:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i825c0bC057517 for ; Wed, 1 Sep 2004 22:38:00 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id B7B7C28B11 for ; Thu, 2 Sep 2004 07:37:12 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26077-04 for ; Thu, 2 Sep 2004 07:37:09 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 678062840B; Thu, 2 Sep 2004 07:37:09 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Thu, 2 Sep 2004 07:37:09 +0200 (CEST) Message-ID: <34624.127.0.0.1.1094103429.squirrel@127.0.0.1> In-Reply-To: <200409011531.38815.jonagard@amazon.com> References: <200409011531.38815.jonagard@amazon.com> Date: Thu, 2 Sep 2004 07:37:09 +0200 (CEST) Subject: Re: Motion to abandon Sender ID From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Gardner a écrit : > > Therefore, I move that Sender ID be removed from the MARID > recommendations because it can never be a standard in the open source > community due to its licensing terms and the uncertainty of pending > patent claims. In its place, we should recommend SPF version 1, or SPF > "classic", as currently adopted and implemented by over 70,000 recorded > domains. I strongly support this motion. - -- Michel Bouissou OpenPGP ID 0xDDE8AC6E -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkE2sYUACgkQLMiNUd3orG7LiQCeKcRuiqiUotLhLSIhCKTdymMC n1MAoJawLsiOv15m29uwZTOgCjp3Fxcy =7fEI -----END PGP SIGNATURE----- chronophage : qui vous bouffe du temps From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 02:09:34 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 CAA00623 for ; Thu, 2 Sep 2004 02:09:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i825mUvk064427; Wed, 1 Sep 2004 22:48: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 i825mU9L064426; Wed, 1 Sep 2004 22:48:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i825mTq2064400 for ; Wed, 1 Sep 2004 22:48:30 -0700 (PDT) (envelope-from gordonf@pan-am.ca) Received: from kielas1 ([69.179.0.180] unverified) by mail.pan-am.ca over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Sep 2004 00:48:34 -0500 Message-ID: <002401c490b0$c314ca60$6401a8c0@kielas1> From: "Gordon Fecyk" To: "IETF MARID WG" References: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> Subject: Another Rambus, Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 00:50:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 02 Sep 2004 05:48:34.0459 (UTC) FILETIME=[7C23EEB0:01C490B0] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > This may be naive in terms of the workings of the group, > and protocol...but rather than abandon Sender I.D., why > not contact MS and explain to them the concerns, and > let them clarify? I believe it is not in their best interest to do so or Harry and crew would have released those clarifications by this time. Knowing the GPL is designed exactly to counter the kinds of practices Microsoft, Oracle and other [pure or mostly] software companies routinely use, we should expect any Sender ID license will never be GPL compatible. It's not going to happen. The GPL is not the only open source license that Sender ID's terms run afoul of, if I read the noise in MARID correctly. And apparently some prior works, including the input documents for this working group, could be subject to patents applied for. That includes the original SPF. I see another Rambus in the making here, exactly the same concern I brought up with the BOF chairs back at IETF 59, where I was assured the IETF didn't tolerate such behaviour. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 02:10: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 CAA01107 for ; Thu, 2 Sep 2004 02:10: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 i825ltRN064203; Wed, 1 Sep 2004 22:47:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i825ltxc064202; Wed, 1 Sep 2004 22:47:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i825lsZU064190 for ; Wed, 1 Sep 2004 22:47:54 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-092-187.area3.spcsdns.net ([68.245.102.182]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2kS4-0000CI-R4; Thu, 02 Sep 2004 01:48:06 -0400 Message-ID: <4136B403.208@solidmatrix.com> Date: Thu, 02 Sep 2004 01:47:47 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Anne P. Mitchell, Esq." CC: "IETF MXCOMP (E-mail)" Subject: Re: Motion to abandon Sender ID References: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> <4136B34A.5070104@solidmatrix.com> In-Reply-To: <4136B34A.5070104@solidmatrix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yakov Shafranovich wrote: > Anne P. Mitchell, Esq. wrote: > >> >> >> This may be naive in terms of the workings of the group, and >> protocol...but rather than abandon Sender I.D., why not contact MS and >> explain to them the concerns, and let them clarify? Ask them to put >> in writing explicitly what their patent covers with respect to the >> items of concern (or, conversely, to put in writing expressly those >> things which the patent is warranted to *not* cover), and ask them to >> further rewrite the license to address and clarify those areas of >> concern as well? >> >> They have obviously put a lot of time and effort in to this, and while >> I absolutely agree there are problems with things as they stand today, >> and fully expect MS, as any other company, to cover their investments >> and their asterisks, in any negotiation, and at this point this is >> what it is, it makes sense to say to them "here are the problems which >> keep it from moving forward - will you address those problems, or do >> we need to abandon it and move on?" >> > > I agree with Anne here - I want to do the same. If we can resolve these > issues and move forward, it would be very helpful. > On a followup note, I sincerely hope that this quote is NOT entirely true (http://www.eweek.com/article2/0,1759,1639576,00.asp): "Allman also isn't optimistic about Microsoft making Sender ID open-source friendly. "It's pretty clear that it's going to take an act of whatever deity Microsoft worships in order to get them to back down on the sublicensing issue. They made it absolutely clear to us that they were not even going to consider changing this, and the legal folks made it further clear that they would rather see Sender ID die than back down." Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 02:11: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 CAA02633 for ; Thu, 2 Sep 2004 02:11: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 i825j98Z063053; Wed, 1 Sep 2004 22:45: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 i825j9DU063052; Wed, 1 Sep 2004 22:45:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i825j8KL063021 for ; Wed, 1 Sep 2004 22:45:08 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-092-187.area3.spcsdns.net ([68.245.102.182]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2kPH-0008VO-2v; Thu, 02 Sep 2004 01:45:12 -0400 Message-ID: <4136B34A.5070104@solidmatrix.com> Date: Thu, 02 Sep 2004 01:44:42 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Anne P. Mitchell, Esq." CC: "George Webb" , Harry Katz , "IETF MXCOMP (E-mail)" Subject: Re: Motion to abandon Sender ID References: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> In-Reply-To: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne P. Mitchell, Esq. wrote: > > > This may be naive in terms of the workings of the group, and > protocol...but rather than abandon Sender I.D., why not contact MS and > explain to them the concerns, and let them clarify? Ask them to put in > writing explicitly what their patent covers with respect to the items of > concern (or, conversely, to put in writing expressly those things which > the patent is warranted to *not* cover), and ask them to further rewrite > the license to address and clarify those areas of concern as well? > > They have obviously put a lot of time and effort in to this, and while I > absolutely agree there are problems with things as they stand today, and > fully expect MS, as any other company, to cover their investments and > their asterisks, in any negotiation, and at this point this is what it > is, it makes sense to say to them "here are the problems which keep it > from moving forward - will you address those problems, or do we need to > abandon it and move on?" > I agree with Anne here - I want to do the same. If we can resolve these issues and move forward, it would be very helpful. I would go a step further - I challenge Microsoft to participate in a conference call or a Jabber chat on this. Perhaps, if we can get the relevant parties together including Microsoft lawyers and lawyers from OSI and FSF, AND the policy makers at Microsoft, as well as members of this group, we can explain the issues to each side in a more clear fashion. > Yes, I said I didn't understand why we were looking at this *given the > problems* when we had SPF which had no such problems, but now it's not > clear to me whether they have been given an opportunity to rectify these > problems; have they? > In general, delaying the license change until the last minute right before the last call period started does not sound like acting in good faith. I find it very hard to believe that highly paid lawyers at Microsoft took such long time to do the changes. But in any case, why not give them another chance? On a related note, keep in mind that approval by this WG is only the first step. There is still approval by the IESG in the future, if ever, and that takes time as well. Plus the various appeal processes, etc. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 02:11:34 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 CAA02674 for ; Thu, 2 Sep 2004 02:11:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i825qW5S066422; Wed, 1 Sep 2004 22:52:32 -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 i825qWSP066421; Wed, 1 Sep 2004 22:52:32 -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 i825qVY7066403 for ; Wed, 1 Sep 2004 22:52:31 -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 1C2kWO-00017F-Tv for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 00:52:39 -0500 To: "IETF MARID WG" References: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 02 Sep 2004 00:52:32 -0500 In-Reply-To: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> (Anne P. Mitchell's message of "Wed, 1 Sep 2004 21:42:03 -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: Motion to abandon Sender ID 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.6 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 <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> "Anne P. Mitchell, Esq." writes: > This may be naive in terms of the workings of the group, and > protocol...but rather than abandon Sender I.D., why not contact MS and > explain to them the concerns, and let them clarify? [...] > > Yes, I said I didn't understand why we were looking at this *given the > problems* when we had SPF which had no such problems, but now it's not > clear to me whether they have been given an opportunity to rectify > these problems; have they? Yes, Microsoft has been given plenty of notice about the problems with their license and given many opportunities to address the issues. Lawyers from the FSF and OSI have been working with MS lawyers for *months*. The hard deadline of Aug 23 given by the co-chairs for any revised IPR license was actually the *second* deadline given to MS. IPR issues were discussed at the interim meeting this spring and at the IETF-60 session. This is not a case of MS being ambushed by people who just suddenly decided to raise concerns about the license. Rather, this is a case where MS long considered the issue and has drawn a line in the sand and said "if you want SenderID, you must accept our license terms. That is our final offer." So, here were are, almost to the end of the Last Call on these Internet-Drafts for potential RFCs. We are trying to determine if the benefits of using the patent encumbered PRA algorithm is enough better than the alternatives to outweigh the costs. In order to advance the marid-pra and marid-core I-Ds, there needs to be a rough consensus from this working group that they should advance. From what I can see, there is no consensus that they should advance, if anything, there is a rough consensus that they should not advance. Of course, it is all up to the opinions of the co-chairs as to whether there is a rough consensus. As Phillip Hallam-Baker can tell you, there are some "wonderful" stories about co-chairs of IETF working groups deciding on the issue of rough consensuses. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 02:40:14 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 CAA07261 for ; Thu, 2 Sep 2004 02:40: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 i826JnBg079989; Wed, 1 Sep 2004 23:19: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 i826JnTM079988; Wed, 1 Sep 2004 23:19:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i826JnhZ079979 for ; Wed, 1 Sep 2004 23:19:49 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-092-187.area3.spcsdns.net ([68.245.102.182]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2kwq-0001t9-MY for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 02:19:53 -0400 Message-ID: <4136BB73.6080208@solidmatrix.com> Date: Thu, 02 Sep 2004 02:19:31 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Motion to abandon Sender ID References: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > In order to advance the marid-pra and marid-core I-Ds, there needs to > be a rough consensus from this working group that they should > advance. From what I can see, there is no consensus that they should > advance, if anything, there is a rough consensus that they should not > advance. Of course, it is all up to the opinions of the co-chairs as > to whether there is a rough consensus. As Phillip Hallam-Baker can > tell you, there are some "wonderful" stories about co-chairs of IETF > working groups deciding on the issue of rough consensuses. > Given that only five days are left until the end of the last call period, perhaps the chairs can tell us what they feel the consensus is as of right now. As for those "wonderful" stories, there is always appeals :) Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 02:47: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 CAA07735 for ; Thu, 2 Sep 2004 02:47: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 i826R46a082788; Wed, 1 Sep 2004 23:27: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 i826R4aQ082787; Wed, 1 Sep 2004 23:27:04 -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 i826R2wF082741 for ; Wed, 1 Sep 2004 23:27:03 -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 i826Q0RD004449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Sep 2004 02:26:01 -0400 Subject: Re: Motion to abandon Sender ID From: Paul Iadonisi To: "IETF MXCOMP (E-mail)" In-Reply-To: <4136B403.208@solidmatrix.com> References: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> <4136B34A.5070104@solidmatrix.com> <4136B403.208@solidmatrix.com> Content-Type: text/plain Message-Id: <1094106313.23164.69.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 02 Sep 2004 02:25:14 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-09-02 at 01:47, Yakov Shafranovich wrote: [snip] > On a followup note, I sincerely hope that this quote is NOT entirely > true (http://www.eweek.com/article2/0,1759,1639576,00.asp): > > "Allman also isn't optimistic about Microsoft making Sender ID > open-source friendly. "It's pretty clear that it's going to take an act > of whatever deity Microsoft worships in order to get them to back down > on the sublicensing issue. They made it absolutely clear to us that they > were not even going to consider changing this, and the legal folks made > it further clear that they would rather see Sender ID die than back down." It would be nice to get a confirmation from Eric Allman as to whether or not this article got it right or misquoted him. Because if it is true, I would like to know why the Sendmail, Inc. position on Sender-ID posted opened with: "Sendmail, Inc. has worked with Microsoft to help them produce a patent license that will be acceptable for ourselves, the IETF and the open source community at large." because the two statements are clearly not consistent. Please, if we are to assume participants in this list are acting in good faith, then all members need to honor that. If Microsoft never had any intention of making this license FOSS friendly, then why wasn't that stated from the beginning? I agree with Gordon Fecyk in this case. I smell another Rambus. And I do hope the IETF follows through with what Gordon was assured of at IETF 59...that this behaviour willl not be tolerated. And from http://www.imc.org/ietf-mxcomp/mail-archive/msg03750.html: "Finally, some participants have outright stated that they are interested only in the advancement of a competing specification to Sender ID while others have not said so much but have taken a similar tone. This is most offensive and counter to the notion of finding a consensus-based standard. Many individuals in this working group have worked very hard to find common ground, and this unilateralism is unfair to them. If it is your intent to be unwavering and steadfast in your opinion no matter the discourse of the issues, we ask that you disengage from this working group." If the article has it right about what Eric said and Eric has it right about what Microsoft (and particularly its legal folks) said, then I'd say the above statement about being 'unwavering and steadfast in your opinion no matter the discourse of the issues' applies to this situation quite readily. (Though I'm not all impying anything about Harry, Jim, or any other Microsoft employees on this list.) -- -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 Sep 2 03:13: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 DAA08745 for ; Thu, 2 Sep 2004 03:13:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i826qbkE091993; Wed, 1 Sep 2004 23:52:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i826qbNU091992; Wed, 1 Sep 2004 23:52:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i826qapM091967 for ; Wed, 1 Sep 2004 23:52:36 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 57379 invoked from network); 2 Sep 2004 06:52:31 -0000 Received: from unknown (HELO vaio) (203.115.130.41) by relay.pair.com with SMTP; 2 Sep 2004 06:52:31 -0000 X-pair-Authenticated: 203.115.130.41 Message-Id: <4.1.20040902145413.00a68de0(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 02 Sep 2004 15:03:51 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: Motion to abandon Sender ID In-Reply-To: <1094106313.23164.69.camel@va.local.linuxlobbyist.org> References: <4136B403.208@solidmatrix.com> <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> <4136B34A.5070104@solidmatrix.com> <4136B403.208@solidmatrix.com> 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: >And from http://www.imc.org/ietf-mxcomp/mail-archive/msg03750.html: > > "Finally, some participants have outright stated that they are > interested only in the advancement of a competing specification > to Sender ID while others have not said so much but have taken > a similar tone. This is most offensive and counter to the notion > of finding a consensus-based standard. Many individuals in this > working group have worked very hard to find common ground, and > this unilateralism is unfair to them. If it is your intent to be > unwavering and steadfast in your opinion no matter the discourse > of the issues, we ask that you disengage from this working group." I add my vote to this motion for reasons I previously stated: http://www.imc.org/ietf-mxcomp/mail-archive/msg04008.html and AccuSpam has no particular attachment to any competing standard for PER-DOMAIN anti-forgery. I also find no major objection if Microsoft can eliminate the need to sign (fax or otherwise agree to) a patent license in order to distribute products which implement SenderID. Else I think we should be patient to standardize on an alternative which is clearly in the public domain. In the meantime, we have de facto standards, such as SPF, which can are gaining adoption (especially among anti-spam) and can protect senders who are being phished. Additionally, the issue of deploying per-domain anti-forgery out to all senders is a complex one that is not completely solved with MSFT's PR apparatus and influence. -Shelby Moore From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 05:38: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 FAA16347 for ; Thu, 2 Sep 2004 05:38:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i829Edwx042112; Thu, 2 Sep 2004 02:14: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 i829Edhm042111; Thu, 2 Sep 2004 02:14:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from suntzu.lyra.org (suntzu.lyra.org [198.144.203.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i829EaPj042080 for ; Thu, 2 Sep 2004 02:14:38 -0700 (PDT) (envelope-from gstein@apache.org) Received: from suntzu.lyra.org (localhost.localdomain [127.0.0.1]) by suntzu.lyra.org (8.12.11/8.12.11) with ESMTP id i8299AEV004709 for ; Thu, 2 Sep 2004 02:09:10 -0700 Received: (from gstein@localhost) by suntzu.lyra.org (8.12.11/8.12.11/Submit) id i829992X004707 for ietf-mxcomp@imc.org; Thu, 2 Sep 2004 02:09:09 -0700 X-Authentication-Warning: suntzu.lyra.org: gstein set sender to gstein@apache.org using -f Date: Thu, 2 Sep 2004 02:09:09 -0700 From: Greg Stein To: ietf-mxcomp@imc.org Subject: DEPLOY: Apache projects unable to deploy Sender ID Message-ID: <20040902090909.GB4253@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-URL: http://www.lyra.org/greg/ Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message summarizes the position of the Apache Software Foundation, the Apache SpamAssassin Project Management Committee, and the Apache JAMES Project Management Committee. The Apache Software Foundation (ASF) delivers enterprise-grade, open source software products that attract large communities of users. The pragmatic Apache License makes it easy for all users, commercial and individual, to deploy Apache products including Apache SpamAssassin (an extensible email filter which is used to identify spam) and Apache JAMES (the Java Apache Mail Enterprise Server). The current Microsoft Royalty-Free Sender ID Patent License Agreement terms are a barrier to any ASF project which wants to implement Sender ID. We believe the current license is generally incompatible with open source, contrary to the practice of open Internet standards, and specifically incompatible with the Apache License 2.0. Therefore, we will not implement or deploy Sender ID under the current license terms. We raised these concerns with the IETF ASRG chairs on March 1st and we had assurances from the ASRG chairs that these matters would be addressed, but they haven't been. We feel that dismissal of unspecified, pending, patent claims recklessly shifts the risk and potential burden onto implementors. We began working with Larry Rosen, general counsel of the Open Source Initiative, on June 9th, to coordinate our efforts to resolve the patent licensing issues. And since July 20th, Larry Rosen has been negotiating with Michele Herman at Microsoft, but most of the major barriers are still present. We are in agreement with Larry's analysis of the incompatibilities of the current license: ------------------------------------------------------------------------ From: "Lawrence Rosen" Subject: RE: Microsoft's amended Sender ID license Date: Tue, 24 Aug 2004 10:15:12 -0700 The open source development and distribution process works as well as it does because everyone treats open source licenses as sublicenseable, and most of them are expressly so. Open source licenses contemplate that anyone who receives the software under license may himself or herself become a contributor or distributor. Software freedom is inherited by downstream sublicensees. Meanwhile, the Microsoft Sender ID patent license continues the convenient fiction that there are "End Users" (S1.5) who receive limited rights. That is unacceptable in open source licenses. I have explained to Microsoft that their license is expressly incompatible with the warranty of provenance in the Academic Free License and the Open Software License: "Licensor warrants that the copyright in and to the Original Work and the patent rights granted herein by Licensor are owned by the Licensor or are sublicensed to You under the terms of this License with the permission of the contributor(s) of those copyrights and patent rights." (AFL/OSL S7) The "nontransferable, non-sublicenseable" language in their reciprocal patent license (S2.3) also imposes an impossible administrative burden on the open source development community and, in essence, creates additional downstream patent licenses that will be incompatible with the AFL/OSL and similar open source licenses, and with the open source development process. The requirement that Microsoft Sender ID patent licenses be formally executed (e.g., S6.10) is incompatible with the way the open source development and distribution process actually works. Furthermore, the requirement that "If you would like a license from Microsoft (e.g., rebrand, redistribute), you need to contact Microsoft directly" (S2.2) gives Microsoft information about its competitors' plans that it has no reason to know. No open source license -- and *all* of them allow rebranding and redistribution -- can be conditioned on informing Microsoft of anything at all. Other proposed licenses have been rejected by OSI and FSF because they required licensees to notify the licensor of their intentions. The requirement that Microsoft's patent licensing notice be placed "in close proximity to" the license agreement (S4.3) is, as a practical matter, impossible for most open source licenses posted on the OSI or other websites. There is no reason for that requirement other than to burden open source licenses with Microsoft notices. One final point: Open source licenses must be worldwide. The Microsoft license, however, makes licensees subject to U.S. Export Administration Regulations (S6.2). Similar provisions have been rejected by OSI in many other licenses. Instead, Microsoft should simply make licensees responsible to obey the relevant export control laws and leave it at that. We all understand that an open source license doesn't override local laws. ------------------------------------------------------------------------ We believe there are additional problems with license and the process. Some of these include: * Microsoft has not disclosed information about their pending patents that cover areas of -core and -pra. It is generally accepted that the PRA algorithm is covered, but any patents covering -core could cover far more than PRA. * Where the Sender ID specification includes additional optional features or suggests variations and alternatives to techniques needed to implement the specification (or where such variations or alternatives are obvious to an implementor), no license is granted. Only patents necessary to implement the specification are clearly licensed; * The licenses are said to be "personal" (though a reciprocally granted license is not required to be), which prevent assignment to an acquiring party, so open source projects may not be able to transfer a license to new maintainers or organizations. * The scope of the patent license is limited to compliant implementations. This is incompatible with the broad grant of open source licenses to create any derivative work whatsoever. In addition, as Internet software is often non-compliant for many possible different reasons, this would restrict the use of Sender ID unacceptably. In addition: - Measurement of compliance is a problem. - If compliance is needed to get a license, then it's a problem. If compliance is not needed to get a license, then the clause should just be dropped. - Full compliance might be difficult to achieve for technical or resource reasons. - Obvious extensions (many already under discussion) could be subject to unknown additional patents. - Accepted best practices often exceed or conflict with compliance for Internet standards. * It's conceivable that someone might want (or defensively, need) to enforce a patent related to Sender ID, but not "necessarily infringed" by an implementation of the specification, against Microsoft, but doing so would allow Microsoft to terminate. The agreement is lopsided and will probably give Microsoft a competitive advantage in the Sender ID marketplace that is not warranted given the open standards that form the basis for Sender ID. * We are also concerned by the rush to adopt this standard in spite of technical concerns, lack of experience in the field, and a lack of consensus in the IETF MARID WG. We will not be implementing support for Sender ID until such time as the issues with the license are fixed and acceptable to the Apache James and Apache SpamAssassin Project Management Committees. We believe the first step is fixing Larry Rosen's concerns. As an alternative resolution, we would find it acceptable if the pending patents were granted to a non-profit organization such as ISOC and licensed under sufficiently open terms. Finally, as developers of open source e-mail technologies, we are concerned that no company should be permitted IP rights over core Internet infrastructure. We believe the IETF needs to revamp its IPR policies to ensure that the core Internet infrastructure remain unencumbered. Greg Stein Chairman, Apache Software Foundation Serge Knystautas V.P., Apache JAMES Daniel Quinlan V.P., Apache SpamAssassin cc: http://www.apache.org/foundation/docs/sender-id-position.html From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 08:29: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 IAA27914 for ; Thu, 2 Sep 2004 08:29: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 i82BrDP2079733; Thu, 2 Sep 2004 04:53:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82BrDso079732; Thu, 2 Sep 2004 04:53:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82BrCSZ079726 for ; Thu, 2 Sep 2004 04:53:12 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i82C2fdb011124; Thu, 2 Sep 2004 08:02:41 -0400 From: To: "'George Mitchell'" , , Subject: RE: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 07:51:19 -0400 Message-ID: <00ba01c490e3$29c26c40$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200409020122.i821M9LE026582@m5p.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I also second the motion. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of George Mitchell > Sent: Wednesday, September 01, 2004 9:22 PM > To: ietf-mxcomp@imc.org; jonagard@amazon.com > Subject: Re: Motion to abandon Sender ID > > > > > I will argue here for abandoning Sender ID. I make some > assumptions which > > could be refuted, but I believe that they are correct based on my > > experience. I encourage those who respond negatively to attack the > > particular points I am making and refute the facts I claim. > > I second Mr. Gardner's motion. -- George Mitchell > From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 08:35:04 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 IAA28251 for ; Thu, 2 Sep 2004 08:35:04 -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 i82CEIDA080973; Thu, 2 Sep 2004 05: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 i82CEILi080972; Thu, 2 Sep 2004 05:14:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.well.com (smtp.well.com [206.14.209.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82CEHYM080960 for ; Thu, 2 Sep 2004 05:14:17 -0700 (PDT) (envelope-from cpm@well.com) X-WELL-Auth: Yes Received: from [192.168.0.9] (orthanc.avwashington.com [199.227.4.34]) by smtp.well.com (8.13.0/8.13.0) with ESMTP id i82CE7AD018307 for ; Thu, 2 Sep 2004 05:14:09 -0700 (PDT) Message-ID: <41370E4E.6050706@well.com> Date: Thu, 02 Sep 2004 08:13:02 -0400 From: Chip Mefford User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: IETF MARID WG Subject: Re: Motion to abandon Sender ID References: <200409011531.38815.jonagard@amazon.com> <41365B20.8080204@solidmatrix.com> In-Reply-To: <41365B20.8080204@solidmatrix.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on smtp X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yakov Shafranovich wrote: | there is serious doubt as | to whether this patent is actually valid or enforceble in light of | possible prior art. As of today, this technology is not encumbered by | any patents and may stay that away if the patent application is not | approved. Maybe. I'm not betting on it. There is a lot of vagueness in your statement. Their lawyers are bigger than my lawyers. No thanks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBNw5Na44x14FCa6ARArNBAJ9dMgIWZFz32tLDIk01DPTLH9ZrtwCffvha 6jtjP06clPINbmvTtgLkxbE= =QWb0 -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 08:37:24 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 IAA28466 for ; Thu, 2 Sep 2004 08:37:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82CGAwh081066; Thu, 2 Sep 2004 05:16:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82CGAO6081065; Thu, 2 Sep 2004 05:16:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82CG9Te081058 for ; Thu, 2 Sep 2004 05:16:10 -0700 (PDT) (envelope-from SRS0=GCSjlzKs=LX=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i82CG8tJ009976 for ; Thu, 2 Sep 2004 14:16:08 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409021216.I82CG7XH009960@asarian-host.net> Date: Thu, 02 Sep 2004 12:16:08 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: Motion to abandon Sender ID X-Trace: dzZMkqJTSM9aRzUv7xdM/2CITe3By/Av5+OYH48xDMh7sP1D3CXKI0NVXY3yVOu23iXMUwB26TjtSC3KkwiyaA== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <200409011531.38815.jonagard@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQTcPCDFqW1BleBN9AQELowf6Ahe3kWlUzR1Ue/xlYpUAZM0OHQaPyzc9 Rn2Rd01Bh3vVlDiSPeMBkszq1+KBiHkoBEHQNh1IpS/8HrRzObaJrJxYGfaEObXH csL1mFLk91Ax3cyMtHCm9j5fexZ4NMVTOEM+1jkS3eESszWwYCQt8Hxe5Wx5LyqJ /T48y7mLo1uI9l4rVZcJGACVf6vZNa/Kow9Dugac4NcIF/QdQ5N7kZ0iH1fooI1z 9alO1GGmY8jgIbg0dh47uaic8F0szh6o7tu0erI7YPwEzHvcj8veu+sGswCMkrEB IVHnb2n+zRUx7v+RqWMALctCgB023nx0oBfHJg+6K2+vPr5WjY2b9g== =nMdc Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jonathan Gardner wrote: > Therefore, I move that Sender ID be removed from the MARID > recommendations because it can never be a standard in the open source > community due to its licensing terms and the uncertainty of pending > patent claims. I strongly support this motion. > In its place, we should recommend SPF version 1, or > SPF "classic", as currently adopted and implemented by over 70,000 > recorded domains. I am very much in favor of this. Perhaps MARID could further recommend the use of SUBMITTER/RFROM, in conjunction with "classic" SPF, as an elegant alternative to using SRS1. - Mark From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 09:03: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 JAA00447 for ; Thu, 2 Sep 2004 09:03: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 i82CfJf3082654; Thu, 2 Sep 2004 05:41:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82CfJC7082653; Thu, 2 Sep 2004 05:41:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82CfJjn082645 for ; Thu, 2 Sep 2004 05:41:19 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 08:41:20 -0400 Message-ID: <413714F0.30704@hepcoe.com> Date: Thu, 02 Sep 2004 08:41:20 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: [DEPLOY] Personal testimony Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Sep 2004 12:41:20.0600 (UTC) FILETIME=[25E92580:01C490EA] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit To add to the personal testimony called for by the chairs, I would like to make the following statements: 1. In my professional capacity as a network analyst for a medium-sized company (400+ employees), I use the GPL licensed Exim MTA. I believe that since Exim could not directly include Sender-ID code itself, my choices for implementing Sender-ID in my company would be to replace the MTA or try to find a Sender-ID add-on for Exim. The first option would entail significant expense and thus would probably fail a cost/benefit analysis and therefore likely would not happen. The second option may be impossible since such an add-on may never be created and even if it is, the expense of adding a third party module may fail a cost/benefit analysis. Based on this, I am pretty confident that my company will never implement encumbered Sender-ID or at best it will be a very much delayed implementation. 2. In my personal capacity as an Internet email user, my ISP is Primus Canada, which uses the Exim MTA. Because of this, my ISP may never implement Sender-ID since it would entail the same type of work as noted above. In any case, an implementation would be delayed and it is possible that if they had to migrate to a proprietary MTA, the expenses they incur would be passed on to me and I would see my Internet costs rise. 3. Although I am not currently an active developer, I have done a fair bit of programming in the past and given some spare time I may be inclined to participate in a development project. I have in fact contributed in other ways to a few existing projects such as Snort and SpamAssassin. As my interests lie in security, email, and anti-spam, it's likely that any such future development contributions would be products that include MARID. However, I would not be able to work on any projects that contain Sender-ID as I would refuse to sign a license for it. My reason for doing so is based on my past assertion that "royalty-free" does not mean "free" and that the benefit of being able to implement Sender-ID is outweighed by the value of the rights that I would be waiving, particularly: - Despite not being a citizen of the USA, agreeing to be bound by US Export Administration regulations - Agreeing to only use the code to implement the Sender-ID specification - Agreeing to give up all rights under the license if I sue Microsoft - Agreeing to distribute my code only under a license that is not "inconsistent" with displaying Microsoft's IPR notice - Agreeing to distribute my code only under a license that does not guarantee that all recipients of the code have the same rights - Agreeing that any dispute be settled in the state of Washington and waiving all defenses of lack of personal jurisdiction and forum nonconveniens - Agreeing that my name can be used as part of Microsoft's PR (by being listed as a licensee of MS IPR on their web site or elsewhere) Kevin From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 09:10: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 JAA00990 for ; Thu, 2 Sep 2004 09:10:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82CiuM5082888; Thu, 2 Sep 2004 05:44: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 i82Ciu1W082887; Thu, 2 Sep 2004 05:44:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82Cit5w082878 for ; Thu, 2 Sep 2004 05:44:56 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: (from hadmut@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) id i82CilAQ004580; Thu, 2 Sep 2004 14:44:47 +0200 From: Hadmut Danisch Date: Thu, 2 Sep 2004 14:44:47 +0200 To: Jonathan Gardner Cc: IETF MARID WG Subject: Re: Motion to abandon Sender ID Message-ID: <20040902124447.GA4471@danisch.de> References: <200409011531.38815.jonagard@amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409011531.38815.jonagard@amazon.com> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Interesting point, I agree with you. And you gave me some inspiration: Is it possible that this all was meant as an attack against the Linux/GPL-World? That this was meant to undermine the GPL-based Linux distributions and to abuse a technology, which would surely be deployed very fast and widely, everyone would have to use it, to piggyback some anti-GPL-antidote, to start softening the pure-GPL world? Just a thought... regards Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 09:31: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 JAA02498 for ; Thu, 2 Sep 2004 09:31: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 i82D4Y2e083811; Thu, 2 Sep 2004 06:04:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82D4X0X083810; Thu, 2 Sep 2004 06:04:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82D4X04083803 for ; Thu, 2 Sep 2004 06:04:33 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 09:04:34 -0400 Message-ID: <41371A62.20307@hepcoe.com> Date: Thu, 02 Sep 2004 09:04:34 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: [DEPLOY] Motion to abandon Sender ID References: <200409011531.38815.jonagard@amazon.com> In-Reply-To: <200409011531.38815.jonagard@amazon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Sep 2004 13:04:34.0288 (UTC) FILETIME=[649D0F00:01C490ED] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I concur. It appears to me that the only thing that could save Sender-ID right now is if Microsoft immediately announces that they are dropping the licensing requirements and will donate their patent directly to the IETF or the FSF or some such. Even a simple promise from them that they will revise their license isn't going to work; they've known for too long now about the problems with it and we have hearsay that MS Legal would rather let it die than back down on the provisions that make it hostile toward open source. The notion that this WG can decide that Microsoft's pending patents will be invalidated by prior art and obviousness and therefore push the standard forward is mistaken. Nobody is going to simply ignore MS's claims and their license on the basis of the opinion of the IETF. I therefore recommend that the chairs elect to move ClassicSPF forward as an experimental standard and let Sender-ID die. I would hope that if this is the case that Microsoft accepts the decision and backs the standard without attempting to assert any further IP rights over it or "embracing and extending" it. Doing so would be graceful on their part and would go a long way in alleviating the deep misgivings that many techies and developers have about Microsoft. Kevin Peuhkurinen From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 09:58:51 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 JAA04164 for ; Thu, 2 Sep 2004 09:58:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82DSVER086259; Thu, 2 Sep 2004 06:28:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82DSVpq086258; Thu, 2 Sep 2004 06:28:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.salmark.net (mail.salmark.net [64.23.85.10] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82DSU2x086241 for ; Thu, 2 Sep 2004 06:28:30 -0700 (PDT) (envelope-from peter@bowyer.org) Received: from [64.23.81.33] (port=3002 helo=newwebmail.salmark.net) by mail.salmark.net with smtp (Exim 4.41) id 1C2rdd-00010l-9A for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 09:28:29 -0400 Received: from 193.132.24.18 (SquirrelMail authenticated user peter@bowyer.org) by newwebmail.salmark.net with HTTP; Thu, 2 Sep 2004 13:28:29 -0000 (GMT) Message-ID: <50734.193.132.24.18.1094131709.squirrel@newwebmail.salmark.net> Date: Thu, 2 Sep 2004 13:28:29 -0000 (GMT) Subject: DEPLOY: My testimony From: "Peter Bowyer" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I am co-owner and designer of an email forwarding service which has been deployed in various instances to support email handling for upwards of 1000 domains. The design is based around, and dependent on, the Exim MTA, which is licensed under the GPL. Our service publishes SPF-Classic records for a subset of our domains, performs SPF-Classic checking on incoming email, and uses the results as one input to our spam classification algorithm. Since the maintainer of Exim has announced his view that Sender-ID cannot be implemented in Exim because of the incompatability of the Microsoft license with the GPL (http://www.imc.org/ietf-mxcomp/mail-archive/msg03884.html), the adoption of Sender-ID by our service and the domains we serve would involve (at least) a change of MTA, which is a not inconsiderable task given the dependency we have on Exim. Accordingly, it is unlikely that we would adopt Sender-ID. Peter Bowyer From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 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 KAA06425 for ; Thu, 2 Sep 2004 10:16: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 i82DpXcE088195; Thu, 2 Sep 2004 06:51:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82DpX59088194; Thu, 2 Sep 2004 06:51:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82DpVdY088186 for ; Thu, 2 Sep 2004 06:51:33 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id AAF3128BB5 for ; Thu, 2 Sep 2004 15:50:36 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07485-03 for ; Thu, 2 Sep 2004 15:50:31 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 72BC928B53; Thu, 2 Sep 2004 15:50:31 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Thu, 2 Sep 2004 15:50:31 +0200 (CEST) Message-ID: <38053.127.0.0.1.1094133031.squirrel@127.0.0.1> In-Reply-To: <41371A62.20307@hepcoe.com> References: <200409011531.38815.jonagard@amazon.com> <41371A62.20307@hepcoe.com> Date: Thu, 2 Sep 2004 15:50:31 +0200 (CEST) Subject: Re: [DEPLOY] Motion to abandon Sender ID From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Kevin Peuhkurinen a écrit : > > I therefore recommend that the chairs elect to move ClassicSPF forward > as an experimental standard Yes. > and let Sender-ID die. It is already dead and has been for long . The only thing is that is took some time for some folks to realize it. I'm always amazed to see how hard and long is learning for some obvious lessons... -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 10:33: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 KAA07906 for ; Thu, 2 Sep 2004 10:33: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 i82E1xjb088826; Thu, 2 Sep 2004 07:01: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 i82E1xsW088825; Thu, 2 Sep 2004 07:01:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from Garovirus.uqss.uquebec.ca (garovirus.uqss.uquebec.ca [192.77.51.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82E1wgW088812 for ; Thu, 2 Sep 2004 07:01:58 -0700 (PDT) (envelope-from gfk@logidac.com) Received: from maestro ([132.214.200.206]) by Garovirus.uqss.uquebec.ca (8.12.10/8.12.8) with SMTP id i82E1mWj017073 for ; Thu, 2 Sep 2004 10:01:49 -0400 Message-ID: <005101c490f5$6f108f40$cec8d684@sraq.intra> From: "Guillaume Filion" To: "IETF MARID WG" References: <200409011531.38815.jonagard@amazon.com> Subject: Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 10:02:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Garovirus-MailScanner: Found to be clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "Jonathan Gardner" wrote: > Therefore, I move that Sender ID be removed from the MARID recommendations > because it can never be a standard in the open source community due to its > licensing terms and the uncertainty of pending patent claims. I agree with the motion. I still think that Sender-ID is technically superior to SPF classic, but as Wayne said, it's a ticking bomb and I'm not willing to sit on it hoping that it won't blow off. I'm not against proposing a "last" deadline to Microsoft to come with a new license if it has a spirit similar to: We are going to trash Sender-ID on September 15th if Microsoft does not offer a license fully compatible with the major Open Source licenses, including the GNU Public License, before that date." > In its place, > we should recommend SPF version 1, or SPF "classic", as currently adopted > and implemented by over 70,000 recorded domains. I would rather go with SPF Unified (http://spf.pobox.com/unified/). In any way, if we decide to trash Sender-ID, we'll clearly miss the deadline and we should take the time to discuss and test an alternative solution. I'd rather have an unencumbered final draft by Christmas than Sender-ID as it is right now. My 2 cents, GFK's -- Guillaume Filion, ing. jr Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 10:34: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 KAA08112 for ; Thu, 2 Sep 2004 10:34: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 i82E9m0a089408; Thu, 2 Sep 2004 07:09: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 i82E9m6b089407; Thu, 2 Sep 2004 07:09:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from p03m105.mxlogic.net (p03m105.mxlogic.net [216.183.119.105]) by above.proper.com (8.12.11/8.12.9) with SMTP id i82E9lbt089387 for ; Thu, 2 Sep 2004 07:09:47 -0700 (PDT) (envelope-from sbryant@mxlogic.com) Received: from unknown [63.78.249.241] (EHLO mxlhq-exch-fe.corp.mxlogic.com) by p03m105.mxlogic.net (mxl_mta-1.3.8-10p4) with ESMTP id ea927314.13523.006.p03m105.mxlogic.net; Thu, 02 Sep 2004 08:09:50 -0600 (MDT) Received: from mxlhq-exch01.corp.mxlogic.com ([10.30.0.246]) by mxlhq-exch-fe.corp.mxlogic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Sep 2004 08:09:27 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Motion to abandon Sender ID X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 2 Sep 2004 08:09:27 -0600 Message-ID: <0B34A6972BF39E4CB465A64DBBAD2BB96259@mxlhq-exch01.corp.mxlogic.com> Thread-Topic: Motion to abandon Sender ID Thread-Index: AcSQ7vSH/MQsj34UTWCc6Ovztam9FAABsTZA From: "Shaun Bryant" To: "IETF MARID WG" X-OriginalArrivalTime: 02 Sep 2004 14:09:27.0989 (UTC) FILETIME=[7570AE50:01C490F6] X-MX-Spam: final=0.0100000000; stat=0.0100000000 X-MX-MAIL-FROM: X-MX-SOURCE-IP: [63.78.249.241] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82E9mbt089399 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit One additional point to this, for those in the "it's just a fax" camp; Look at it this way. Microsoft will get to know who all of your customers whom you give the right to sublicense your technology, if those customers are to use your Sender-ID implementation as bundled into your MTA. There's no prevision preventing Microsoft from using that information to promote its own technology solution to your customers. Just my 2 cents. Shaun -------------- Shaun Bryant Director of Threat Management 720-895-5710 Direct 303-908-5073 Cell 303-221-4930 Fax 877-695-6442 Toll Free sbryant@mxlogic.com Your first line of email defense http://www.mxlogic.com -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Hadmut Danisch Sent: Thursday, September 02, 2004 06:45 To: Jonathan Gardner Cc: IETF MARID WG Subject: Re: Motion to abandon Sender ID Interesting point, I agree with you. And you gave me some inspiration: Is it possible that this all was meant as an attack against the Linux/GPL-World? That this was meant to undermine the GPL-based Linux distributions and to abuse a technology, which would surely be deployed very fast and widely, everyone would have to use it, to piggyback some anti-GPL-antidote, to start softening the pure-GPL world? Just a thought... regards Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 11:21: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 LAA12160 for ; Thu, 2 Sep 2004 11:21: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 i82Eqa6M093447; Thu, 2 Sep 2004 07:52:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82EqaTF093446; Thu, 2 Sep 2004 07:52:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82EqaPD093436 for ; Thu, 2 Sep 2004 07:52:36 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i82EqX3V023392 for ; Thu, 2 Sep 2004 07:52:33 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 6AB5384F81C; Thu, 2 Sep 2004 07:52:33 -0700 (PDT) Date: Thu, 2 Sep 2004 07:52:33 -0700 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: DEPLOY: personal testimony Message-ID: <20040902145233.GG659@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Uptime: 7:44AM up 13:40, 7 users, load averages: 0.02, 0.04, 0.01 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I am the primary author of GOSSiP, a distributed, peer-to-peer reputation system for MTAs. Due to the overwhelming legal analysis of the Sender-ID licensing terms and the vagueness surrounding the actual IPR claims, I cannot in good conscience implement Sender-ID checks in my products. As the Senior Unix Systems Administrator for the SETI Institute, I'm concerned that a quick hack I may script up to check for Sender-ID would require agreement to those terms, thereby forcing me to use an "off-the-shelf" solution if I prefer to avoid those terms and still make Sender-ID checks. I'm further concerned that ANY quick hack I may script up to do sender checks may infringe Microsoft's yet-to-be-revealed IPR claims, and thus jeopardize my employment and my employer. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 11:35:23 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 LAA13127 for ; Thu, 2 Sep 2004 11:35:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82F7Tfx094715; Thu, 2 Sep 2004 08:07:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82F7Tbt094714; Thu, 2 Sep 2004 08:07:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82F7S1a094708 for ; Thu, 2 Sep 2004 08:07:28 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-096-691.area3.spcsdns.net ([68.245.120.60]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2t9Y-0000Tl-6D; Thu, 02 Sep 2004 11:05:35 -0400 Message-ID: <41373716.8010001@solidmatrix.com> Date: Thu, 02 Sep 2004 11:07:02 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Hadmut Danisch CC: Jonathan Gardner , IETF MARID WG Subject: Re: Motion to abandon Sender ID References: <200409011531.38815.jonagard@amazon.com> <20040902124447.GA4471@danisch.de> In-Reply-To: <20040902124447.GA4471@danisch.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hadmut Danisch wrote: > > Interesting point, I agree with you. > > And you gave me some inspiration: > > Is it possible that this all was meant as an attack > against the Linux/GPL-World? That this was meant to > undermine the GPL-based Linux distributions and to > abuse a technology, which would surely be deployed > very fast and widely, everyone would have to use it, > to piggyback some anti-GPL-antidote, to start softening > the pure-GPL world? > > Just a thought... > I am sure that we can come up with multiple conspiracy theories for this. For now, lets stay above the fray and assume that perhaps Microsoft was acting in good faith. Descending into conspiracy theories will not make this any better, and quite the opposite, will make the entire discussion appear unprofessional. Microsoft knows what the issues are, they are receiving comments from multiple people and sources. The decision on the license is upto them. The decision on the standard on the other hand is upto the us. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 12:21: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 MAA15660 for ; Thu, 2 Sep 2004 12:21: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 i82Frf62099271; Thu, 2 Sep 2004 08:53: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 i82Frf1A099270; Thu, 2 Sep 2004 08:53:41 -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 i82Frf6e099263 for ; Thu, 2 Sep 2004 08:53:41 -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 i82FrhjV013915 for ; Thu, 2 Sep 2004 08:53:43 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 08:53:43 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MARID WG Subject: The SSL license offer. Date: Thu, 2 Sep 2004 08:53:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82Frf6e099265 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I am not aware of what patents cover SSL, but your argument is > incomplete without a description of the license terms. This > is, I fully > acknowledge, something I am not too familiar with and intend > to read up > on, especially since there is a work in progress library (gnutls) that > is intended to replace openssl, if I'm not mistaken. The patent is held by Netscape (AOL) and covers transport layer security. The terms are considerably more vague than in the SenderID case. Netscape does not promise to offer a sublicensable patent or even to offer reasonable or non discriminatory terms. Netscape Communications has issued the following statement: Intellectual Property Rights Secure Sockets Layer The United States Patent and Trademark Office ("the PTO") recently issued U.S. Patent No. 5,657,390 ("the SSL Patent") to Netscape for inventions described as Secure Sockets Layers ("SSL"). The IETF is currently considering adopting SSL as a transport protocol with security features. Netscape encourages the royalty-free adoption and use of the SSL protocol upon the following terms and conditions: If you already have a valid SSL Ref license today which includes source code from Netscape, an additional patent license under the SSL patent is not required. @ If you don't have an SSL Ref license, you may have a royalty free license to build implementations covered by the SSL Patent Claims or the IETF TLS specification provided that you do not to assert any patent rights against Netscape or other companies for the implementation of SSL or the IETF TLS recommendation. What are "Patent Claims": Patent claims are claims in an issued foreign or domestic patent that: 1) must be infringed in order to implement methods or build products according to the IETF TLS specification; or 2) patent claims which require the elements of the SSL patent claims and/or their equivalents to be infringed. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 12:21: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 MAA15694 for ; Thu, 2 Sep 2004 12:21: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 i82Fxxch099654; Thu, 2 Sep 2004 08:59: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 i82Fxxqo099651; Thu, 2 Sep 2004 08:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82FxwVS099639 for ; Thu, 2 Sep 2004 08:59:58 -0700 (PDT) (envelope-from madman@myeastside.com) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i82G01pA024703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 2 Sep 2004 09:00:01 -0700 Message-ID: <01a301c49105$f33b72c0$3201a8c0@rasta> From: "Harold A'Hole" To: "IETF MARID WG" References: <0B34A6972BF39E4CB465A64DBBAD2BB96259@mxlhq-exch01.corp.mxlogic.com> Subject: Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 09:00:13 -0700 Organization: http://madman.myeastside.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > One additional point to this, for those in the "it's just a fax" camp; > Look at it this way. > > Microsoft will get to know who all of your customers whom you give the > right to sublicense your technology, if those customers are to use your > Sender-ID implementation as bundled into your MTA. There's no prevision > preventing Microsoft from using that information to promote its own > technology solution to your customers. Nobody ever says why MSFT would prosecute someone who didn't have the license. In court, it would be pointed out: * MSFT does not charge anything for the license, so its damages would be non-existent * MSFT gives the technology away freely to those who send in a fax * MSFT clearly intended it to be royalty free as it was given over to an international standards body So in court they'd have to show why a particular user who hadn't sent in a fax should be prosecuted? They would have to show harm done to them. It could easily be remedied by sending in the fax or by no longer using the code. MSFT would be a pariah for such an attack. They already have monopoly issues, and spending good money to prosecute over a free license is simply absurd. The fear is just fear mongering, like worrying that the U.S. will turn its military against its own citizens. It could happen, but it won't because it's politically untenable and legally weak. Harry From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 12:24:17 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 MAA15903 for ; Thu, 2 Sep 2004 12:24: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 i82FvGuQ099501; Thu, 2 Sep 2004 08:57: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 i82FvG8u099499; Thu, 2 Sep 2004 08:57:16 -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 i82FvGm3099493 for ; Thu, 2 Sep 2004 08:57:16 -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; Thu, 02 Sep 2004 11:57:06 -0400 id 0016BD8D.413742DD.000001A2 In-Reply-To: <4136BB73.6080208@solidmatrix.com> References: <6F85C4FB-FC9A-11D8-BA2B-000A95AC5778@isipp.com> <4136BB73.6080208@solidmatrix.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: IETF MARID WG From: Andrew Newton Subject: Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 11:57:00 -0400 To: Yakov Shafranovich 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 Sep 2, 2004, at 2:19 AM, Yakov Shafranovich wrote: > Given that only five days are left until the end of the last call > period, perhaps the chairs can tell us what they feel the consensus is > as of right now. As for those "wonderful" stories, there is always > appeals :) The recent messages from Mark Lentczner and the Apache Software Foundation say a lot. -andy From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 12:25: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 MAA15997 for ; Thu, 2 Sep 2004 12:25: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 i82FxDP2099581; Thu, 2 Sep 2004 08:59:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82FxDIa099580; Thu, 2 Sep 2004 08:59:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bellwfep2-srv.bellnexxia.net (bellwfep2-srv.bellnexxia.net [207.236.237.108]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82FxCWI099574 for ; Thu, 2 Sep 2004 08:59:12 -0700 (PDT) (envelope-from jonathan.curtis@bell.ca) Received: from dm3cnd.bell.ca ([206.47.0.146]) by bellwfep2-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040902155908.NTLX17451.bellwfep2-srv.bellnexxia.net@dm3cnd.bell.ca>; Thu, 2 Sep 2004 11:59:08 -0400 Received: from 142.182.89.79dm3cnd.bell.ca with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.0)); Thu, 02 Sep 2004 11:58:58 -0400 X-Server-Uuid: F7F6AAF0-A437-4F8E-BDFA-B18CACF73C6B Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 11:58:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 11:58:56 -0400 Message-ID: Thread-Topic: Motion to abandon Sender ID Thread-Index: AcSQ/0A4JeIBUAsqTh+IJoVazqdQ4gAALh4w From: jonathan.curtis@bell.ca To: research@solidmatrix.com, hadmut@danisch.de cc: jonagard@amazon.com, ietf-mxcomp@imc.org X-OriginalArrivalTime: 02 Sep 2004 15:58:58.0484 (UTC) FILETIME=[C1C2A740:01C49105] X-WSS-ID: 6D299CC81153933-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82FxDWI099575 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit >> > >I am sure that we can come up with multiple conspiracy >theories for this. For now, lets stay above the fray and >assume that perhaps Microsoft was acting in good faith. >Descending into conspiracy theories will not make this any >better, and quite the opposite, will make the entire >discussion appear unprofessional. > >Microsoft knows what the issues are, they are receiving >comments from multiple people and sources. The decision on >the license is upto them. >The decision on the standard on the other hand is upto the us. > >Yakov > > IMHO...(short version) I will recommending that we move forward with the implementation of SenderID within Bell Canada (over 35,000 domains) as I believe the licensing component has zero to do with the technology and cost of implemention. The support that Microsoft will generate over night for this solution will drive global adoptation - something this solution is going to need to be successful. Jonathan From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 12:27: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 MAA16087 for ; Thu, 2 Sep 2004 12:27:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82G1Zd4099741; Thu, 2 Sep 2004 09:01: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 i82G1ZRb099740; Thu, 2 Sep 2004 09:01:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i82G1YIk099729 for ; Thu, 2 Sep 2004 09:01:34 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 19124 invoked from network); 2 Sep 2004 16:01:33 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 2 Sep 2004 16:01:33 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "IETF MXCOMP \(E-mail\)" Subject: TECH-OMISSION:Submitter concept should be expanded to include Peristent User Accounts (PUA) Date: Thu, 2 Sep 2004 12:01:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <41349EEC.8000407@solidmatrix.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I wasn't sure to post this as a deployment issue, a DOC-BUG issue or a tech-omission issue, my apologies if this isn't the right one. Currently it is very difficult for small domain owners, such as myself, who use a shared MTA to construct a record that will produce a pass result without also opening ourselves up to forgery from other legitimate (i.e. the MTA owner has authorized them to use the MTA) users of the shared MTA. The reason for this is that virtually no shared MTA providers that allow domains other than their own in mail from or from restrict them at all. This limitation applies equally to SPF classic as well. In a recent discussion on this topic on the spf-discuss list (with ~1,000 subscribers) only one provider that would prevent cross-customer forgery was identified. The result of this is a record that looks like this (I'm using an abbreviated generic version of my SPF classic record since I haven't created a Sender-ID record - the point's the same either way): "v=spf1 include:webmail.hostco.com ?a:relay.hostco.com ?mx ?include:isp.net -all" There are three possible solutions to this problem that I can see: 1. Shared MTA providers only allow their customers to send e-mail from domains for which they have a legitimate right to do so. I believe this would be very cumbersome for large providers to do. How would they know what domains different users had access to? If I use my hosting company's MTA, then they could know reasonably easily, but how about the ISP? I can see this leading to a situation where MTA providers would only allow mail from domains they host. That would cost people in situations like me redundancy. I generally send through my hosting company's MTA, but if it's down, I can send via the ISP's MTA. Combined with port blocking, this might also force small businesses to host their domains with their ISP. 2. Businesses that want to get a pass result need to set up their own dedicated MTA. The reason that small busnisses don't do this now is they have neither the time nor the expertise. This approach will no doubt result in even more poorly configured and inadequately maintained MTAs appearing on the internet. 3. Explicitly add a third possible source for submitter, the Persistent User Account (PUA). This would allow providers of shared MTA services to add as a submitter the local (to the shared MTA) e-mail address of the user that submitted the message to the MTA. This was discussed on the list in July. Here is the start of the thread: http://www.imc.org/ietf-mxcomp/mail-archive/msg02633.html This would seem to be a much simpler solution for shared MTA providers to implement than trying to determine which domains their customers are authorized to send from. It also gives a full address (no just a domain) that has agreed to be responsible for the message. Also, if Submitter failed a check during 2821 checking, I believe the message could be rejected before data. This approach is hinted at in the examples (see the last paragraph of Page 7), but use in this manner is never described in the actual specification. The reason I was thinking this might be a DOC-BUG is that examples shouldn't introduce new functionality. Proposed spec changes: Page 2: Change the paragraph that begins "Broadly speaking, ..." to: Broadly speaking, there are two possible approaches for determining the purported responsible address from existing SMTP information; either from RFC 2821 [SMTP] protocol data or from RFC 2822 [MSG-FORMAT] message headers. Each approach has certain advantages and disadvantages. Page 4: Change the paragraph that begins "SMTP clients MUST set..." to: SMTP clients MUST set the SUMBITTER parameter value to the purported responsible address of the message as defined in this RFC or [PRA]. This also applies to messages containing a null reverse-path. Add a new paragraph to follow that one: If an SMTP client is accepting a new message for transmission and the MUA is authorized to submit the message based on an e-mail address that does not appear in the RFC 2822 [MSG-FORMAT] message headers, then the SMTP client MUST set the SUBMITTER parameter value to the address used to validate the MUA's access to the SMTP client through whatever local means are used (such SMTP Authentication [SMTPAUTH]). I'd be willing to settle for MAY here instead of MUST, but if we are going to explicitly include this option, then I can't think of a strong reason that it shouldn't be a MUST. Page 5: Add a sentence to the end of Paragraph 5.1: If the e-mail address used for validation did not appear in the RFC 2822 headers, then appropriate RFC 2822 headers would be added and that e-mail address would be used for the SUBMITTER parameters for subsequent transmission of the message. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 12:38:40 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 MAA16680 for ; Thu, 2 Sep 2004 12:38:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GDufS000563; Thu, 2 Sep 2004 09:13: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 i82GDuJh000562; Thu, 2 Sep 2004 09:13:56 -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 i82GDtKx000554 for ; Thu, 2 Sep 2004 09:13:55 -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 i82GDvNb015166; Thu, 2 Sep 2004 09:13:58 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 09:13:57 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , IETF MARID WG Subject: RE: Another Rambus, Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 09:13:57 -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: > I see another Rambus in the making here, exactly the same > concern I brought > up with the BOF chairs back at IETF 59, where I was assured > the IETF didn't > tolerate such behaviour. The allegations in the Rambus case were that Rambus had not revealed their patent application to the committee and had participated in WG discussions on the spec. That is not the case here. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 12:43: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 MAA17292 for ; Thu, 2 Sep 2004 12:43: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 i82GKT4r000905; Thu, 2 Sep 2004 09:20:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82GKTnV000904; Thu, 2 Sep 2004 09:20:29 -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 i82GKScJ000898 for ; Thu, 2 Sep 2004 09:20:28 -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 i82GKQFD003400; Thu, 2 Sep 2004 09:20:27 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 09:20:26 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , Hadmut Danisch Cc: Jonathan Gardner , IETF MARID WG Subject: RE: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 09:20:17 -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: > Microsoft knows what the issues are, they are receiving comments from > multiple people and sources. The decision on the license is > upto them. > The decision on the standard on the other hand is upto the us. Actually from a standards process point of view the only body with actual decision making power is the IESG. This is not a technical issue, it is the type of issue the IESG should be involved with instead of making technical comments on the WG output. The problem here is that a bad precedent was set with the RSA patent. There are two types of patent at issue, casual patents and fundamental ones. Fundamental patents are very very rare. Perhaps 1 out of 10,000. They are the patents that describe the only possible way to do something. Casual patents are much more common, and will become increasingly so. They describe one way of doing something, not the only way. The fear is that a casual patent be turned into a fundamental one by virtue of it being made into a standard. The RAMBUS concern is a real one. This is something that I believe should be decided at the level of the community as a whole rather than one working group and further should allow for license terms to be accepted on a general basis so that we do not have this issue in every case. We might be able to get further if we knew the reason for Microsoft's insistence on explicit execution of a contract. They appear to me to have a concern about notice of the contract terms and believe that constructive notice may not be effective in achieving reciprocity. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:07: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 MAA15679 for ; Thu, 2 Sep 2004 12:21:54 -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 i82FxxVE099653; Thu, 2 Sep 2004 08:59: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 i82FxxR8099652; Thu, 2 Sep 2004 08:59:59 -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 i82FxwaI099640 for ; Thu, 2 Sep 2004 08:59:58 -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 i82G01fL014307 for ; Thu, 2 Sep 2004 09:00:01 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 09:00:01 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: Updated Sender-ID License Faq (was acceptable use) Date: Thu, 2 Sep 2004 09:00:01 -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: > Thanks to your (Yakov's) fine efforts, it does appear that the MS is > likely to be worse than the typical patent-the-obvious type patent, > but is much closer to what PHB calls a patent troll. They may well > have taken ideas discussed in the ASRG and, after the fact and without > telling anyone, patented them. Patent trolls simply file patents, they do not makestuff, they often don't even invent stuff. All they do is to look for ways to turn roads created at public expense into toll roads. Neither Microsoft, nor IBM (which has a huge licensing business) are patent trolls by that definition. The problem with the USPTO is that the only real defense against a patent troll is to have a prior patent. Prior art only works if you are prepared to put down $5 million to fight a case. This means that it has become necessary to file for defensive patents on every idea, regardless of how frivolous it might seem. The underlying problem is that the only party who can bring the USPTO to court is an applicant who claims to have been unfairly denied a patent claim or had a patent claim cancelled. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:08: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 NAA19146 for ; Thu, 2 Sep 2004 13:08: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 i82GI3Gi000792; Thu, 2 Sep 2004 09:18:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82GI3XD000791; Thu, 2 Sep 2004 09:18:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GI2br000784 for ; Thu, 2 Sep 2004 09:18:02 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 3C2B228BB5 for ; Thu, 2 Sep 2004 18:17:06 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11741-04 for ; Thu, 2 Sep 2004 18:17:02 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 0FF8728B53; Thu, 2 Sep 2004 18:17:02 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Thu, 2 Sep 2004 18:17:02 +0200 (CEST) Message-ID: <38910.127.0.0.1.1094141822.squirrel@127.0.0.1> In-Reply-To: <01a301c49105$f33b72c0$3201a8c0@rasta> References: <0B34A6972BF39E4CB465A64DBBAD2BB96259@mxlhq-exch01.corp.mxlogic.com> <01a301c49105$f33b72c0$3201a8c0@rasta> Date: Thu, 2 Sep 2004 18:17:02 +0200 (CEST) Subject: Re: Motion to abandon Sender ID From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Harold A'Hole a écrit : > > Nobody ever says why MSFT would prosecute someone who didn't have the > license. In court, it would be pointed out: [...] > So in court they'd have to show why a particular user who hadn't sent in a > fax should be prosecuted? They would have to show harm done to them. [...] The problem is that a standard cannot be decided based on "woulds", "shoulds" or suppositions... It must be based on facts. What is in written in the license is facts, and makes it unacceptable for a large part of the Internet community. The past behaviour of a given company is facts. The rest are just suppositions. > MSFT would be a pariah for such an attack. Aren't they already ? I may have been misinformed ;-) > They already have monopoly issues, and spending good money to prosecute > over a free license is simply absurd. The fear is just fear mongering, > like worrying that the U.S. will turn its military against its own > citizens. It could happen, but it won't because it's politically > untenable and legally weak. Well, the fact that the U.S. would use its military to bomb and invade a foreign country that hadn't attacked them and didn't represent any threat to them, giving big lies to the world about the reasons by the voice of the U.S. govt would have seemed "politically untenable and legally weak", as you say. Know what ? It happened. And they're still there. But I believe this is quickly drifting out of the topic of this list, so I apologize in advance for this drift -- just answering your statement. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E Aurais-je manque une loi permettant a n'iumporte que CON (excusez moi, mais je vois pas d'autre terme) à salir et à insulter les marques des sociétés connues ? -+- JD-P in NPC : Dura lex basta crapoto, et que ça saute ! -+- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:09:26 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 NAA19186 for ; Thu, 2 Sep 2004 13:09:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GR5qI001162; Thu, 2 Sep 2004 09: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 i82GR5dN001161; Thu, 2 Sep 2004 09:27:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GR4tj001150 for ; Thu, 2 Sep 2004 09:27:05 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: The SSL license offer. Date: Thu, 2 Sep 2004 11:27:04 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEB896@cliff.bai.org> Thread-Topic: The SSL license offer. thread-index: AcSRBeQd6Q/29UbMT5+8do/CR+FjxwAAkrKw From: "Ryan Malayter" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82GR5tj001156 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Hallam-Baker, Phillip] >The patent is held by Netscape (AOL) and covers transport layer >security. The terms are considerably more vague than in the SenderID >case. Netscape does not promise to offer a sublicensable patent or >even to offer reasonable or non discriminatory terms. Very interesting. If OpenSSL can be included in Linux distributions, why can't SenderID? The SSL license would seem to have tproblems with the GPL similar to those that the SenderID license does. -- Ryan From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:16: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 NAA20362 for ; Thu, 2 Sep 2004 13:16:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GQS1M001134; Thu, 2 Sep 2004 09:26: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 i82GQSH5001133; Thu, 2 Sep 2004 09:26:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.undergrid.net (adsl-216-102-208-65.dsl.snfc21.pacbell.net [216.102.208.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GQR30001121 for ; Thu, 2 Sep 2004 09:26:27 -0700 (PDT) (envelope-from Jeremy.Bouse@UnderGrid.net) Received: from shell1.undergrid.net (root@shell1.undergrid.net [192.168.112.10]) by mail.undergrid.net (8.12.11/8.12.11/Debian-5) with ESMTP id i82GHRZG011629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Sep 2004 09:18:47 -0700 Received: from shell1.undergrid.net (undrgrid@localhost [127.0.0.1]) by shell1.undergrid.net (8.12.11/8.12.11/Debian-5) with ESMTP id i82GGBxR028424 for ; Thu, 2 Sep 2004 09:16:45 -0700 Received: (from undrgrid@localhost) by shell1.undergrid.net (8.12.11/8.12.11/Debian-5) id i82GFVGO028422 for ietf-mxcomp@imc.org; Thu, 2 Sep 2004 09:15:31 -0700 Date: Thu, 2 Sep 2004 09:13:22 -0700 From: "Jeremy T. Bouse" To: IETF MARID WG Subject: Re: Motion to abandon Sender ID Message-ID: <20040902161322.GB28381@UnderGrid.net> Mail-Followup-To: IETF MARID WG References: <200409011531.38815.jonagard@amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409011531.38815.jonagard@amazon.com> 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 . X-GPG-Debian: 1024D/29AB4CDD C745 FA35 27B4 32A6 91B3 3935 D573 D5B1 29AB 4CDD X-GPG-General: 1024D/62DBDF62 E636 AB22 DC87 CD52 A3A4 D809 544C 4868 62DB DF62 User-Agent: Mutt/1.5.6+20040722i X-UnderGrid-MailScanner: Found to be clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would concur with this motion as well. I see no further point in trying to continue with Sender-ID with it's licensing issue which make it unusable with GPL or other OSS licenses. I think SPF classic can be adopted and if needed modified to meet the goals of MARID without the inclusion of Sender-ID. Regards, Jeremy From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:29: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 NAA21319 for ; Thu, 2 Sep 2004 13:29: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 i82GjSS9003156; Thu, 2 Sep 2004 09:45: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 i82GjScr003155; Thu, 2 Sep 2004 09:45:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GjRFX003149 for ; Thu, 2 Sep 2004 09:45:27 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-096-691.area3.spcsdns.net ([68.245.120.60]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2ugR-00075f-CL; Thu, 02 Sep 2004 12:43:36 -0400 Message-ID: <41374E15.1070605@solidmatrix.com> Date: Thu, 02 Sep 2004 12:45:09 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Harold A'Hole" CC: IETF MARID WG Subject: Re: Motion to abandon Sender ID References: <0B34A6972BF39E4CB465A64DBBAD2BB96259@mxlhq-exch01.corp.mxlogic.com> <01a301c49105$f33b72c0$3201a8c0@rasta> In-Reply-To: <01a301c49105$f33b72c0$3201a8c0@rasta> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Harold A'Hole wrote: >>One additional point to this, for those in the "it's just a fax" camp; >>Look at it this way. >> >>Microsoft will get to know who all of your customers whom you give the >>right to sublicense your technology, if those customers are to use your >>Sender-ID implementation as bundled into your MTA. There's no prevision >>preventing Microsoft from using that information to promote its own >>technology solution to your customers. > > > Nobody ever says why MSFT would prosecute someone who didn't have the > license. In court, it would be pointed out: > > * MSFT does not charge anything for the license, so its damages would be > non-existent > * MSFT gives the technology away freely to those who send in a fax > * MSFT clearly intended it to be royalty free as it was given over to an > international standards body > > So in court they'd have to show why a particular user who hadn't sent in a > fax should be prosecuted? They would have to show harm done to them. It > could easily be remedied by sending in the fax or by no longer using the > code. MSFT would be a pariah for such an attack. They already have > monopoly issues, and spending good money to prosecute over a free license is > simply absurd. The fear is just fear mongering, like worrying that the U.S. > will turn its military against its own citizens. It could happen, but it > won't because it's politically untenable and legally weak. > While all of that may be true, what matters is what implementors think. If the entire licensing issue muddles the waters to a point where significant deployment problems will occur, it is something we should take into consideration. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:30: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 NAA21362 for ; Thu, 2 Sep 2004 13:30: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 i82Gpf9q003649; Thu, 2 Sep 2004 09:51: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 i82Gpf5X003648; Thu, 2 Sep 2004 09:51:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GpeYW003641 for ; Thu, 2 Sep 2004 09:51:40 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-096-691.area3.spcsdns.net ([68.245.120.60]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2umV-0007aD-IP; Thu, 02 Sep 2004 12:49:52 -0400 Message-ID: <41374F8C.2090506@solidmatrix.com> Date: Thu, 02 Sep 2004 12:51:24 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'Gordon Fecyk'" , IETF MARID WG Subject: Re: Another Rambus, Re: Motion to abandon Sender ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > >>I see another Rambus in the making here, exactly the same >>concern I brought >>up with the BOF chairs back at IETF 59, where I was assured >>the IETF didn't >>tolerate such behaviour. > > > The allegations in the Rambus case were that Rambus had not > revealed their patent application to the committee and had > participated in WG discussions on the spec. > > That is not the case here. > I am alledging this in regards to the ASRG discussions. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:34: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 NAA21729 for ; Thu, 2 Sep 2004 13:34:32 -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 i82H4xOn004501; Thu, 2 Sep 2004 10:04: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 i82H4xZw004500; Thu, 2 Sep 2004 10:04:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82H4wGF004493 for ; Thu, 2 Sep 2004 10:04:58 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-096-691.area3.spcsdns.net ([68.245.120.60]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2uzM-0008TE-AN; Thu, 02 Sep 2004 13:03:09 -0400 Message-ID: <413752A8.206@solidmatrix.com> Date: Thu, 02 Sep 2004 13:04:40 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: Hadmut Danisch , Jonathan Gardner , IETF MARID WG Subject: Re: Motion to abandon Sender ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > The fear is that a casual patent be turned into a fundamental one > by virtue of it being made into a standard. The RAMBUS concern is > a real one. > > This is something that I believe should be decided at the level > of the community as a whole rather than one working group and > further should allow for license terms to be accepted on a > general basis so that we do not have this issue in every case. > I agree with Phil that this is something should be raised on a community level for the entire IETF since it is bound to come up again. But that might be something more suitable for another forum. The question is what are we supposed to do in regards to Sender-ID? Approving it on the WG level might be considered "final approval" and alienate sizable portions of the community. Not approving it, will push Microsoft and others away. I don't know if either side will bother taking into account the finer distinctions of the IETF approval process. Kind of a catch-22? Perhaps guidance from the IESG might be helpful here. > > We might be able to get further if we knew the reason for Microsoft's > insistence on explicit execution of a contract. They appear to me > to have a concern about notice of the contract terms and believe > that constructive notice may not be effective in achieving > reciprocity. > They are reading the list. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:34:36 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 NAA21747 for ; Thu, 2 Sep 2004 13:34: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 i82H5iXT004576; Thu, 2 Sep 2004 10:05: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 i82H5ine004575; Thu, 2 Sep 2004 10:05:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82H5h6N004568 for ; Thu, 2 Sep 2004 10:05:43 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 13:05:46 -0400 Message-ID: <413752EA.2070004@hepcoe.com> Date: Thu, 02 Sep 2004 13:05:46 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jonathan.curtis@bell.ca CC: ietf-mxcomp@imc.org Subject: Re: Motion to abandon Sender ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Sep 2004 17:05:46.0428 (UTC) FILETIME=[16AE5FC0:01C4910F] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Jonathan. Thanks for your input. You say that you are going to recommend going forward with Sender-ID, even though it has gone through no real testing and has not been adopted as a standard yet. Is your recommendation based solely on the belief that Microsoft's backing will ensure it's success despite the resistance from the open source camp or do you feel that it is a superior technology to, say, SPF? Also, I have noticed that the MTAs that Bell uses includes the GPL'ed Exim and the ASL licensed InterMail. Do you expect to have to replace these with Sendmail? Thanks, Kevin jonathan.curtis@bell.ca wrote: > >> > > >>I am sure that we can come up with multiple conspiracy >>theories for this. For now, lets stay above the fray and >>assume that perhaps Microsoft was acting in good faith. >>Descending into conspiracy theories will not make this any >>better, and quite the opposite, will make the entire >>discussion appear unprofessional. >> >>Microsoft knows what the issues are, they are receiving >>comments from multiple people and sources. The decision on >>the license is upto them. >>The decision on the standard on the other hand is upto the us. >> >>Yakov >> >> >> >> > >IMHO...(short version) > >I will recommending that we move forward with the implementation of >SenderID within Bell Canada (over 35,000 domains) as I believe the >licensing component has zero to do with the technology and cost of >implemention. The support that Microsoft will generate over night for >this solution will drive global adoptation - something this solution is >going to need to be successful. > > >Jonathan > > > > > > > From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13: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 NAA21776 for ; Thu, 2 Sep 2004 13:34:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GshpB003855; Thu, 2 Sep 2004 09:54: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 i82GshjH003854; Thu, 2 Sep 2004 09:54:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from corpmx.savicom.net (corpmx.savicom.net [216.39.113.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82GshCb003846 for ; Thu, 2 Sep 2004 09:54:43 -0700 (PDT) (envelope-from ken@savicom.net) Received: from ken (office.mindsharedesign.com [216.39.112.17]) by corpmx.savicom.net (8.12.9/8.12.3) with ESMTP id i82GqiGn027868 for ; Thu, 2 Sep 2004 09:52:49 -0700 (PDT) (envelope-from ken@savicom.net) From: "Ken" To: Subject: RE: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 09:48:07 -0700 Message-ID: <001d01c4910c$9fa60830$2600a8c0@ken> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I encourage the MARID working group, it's Chairs and the IETF to embrace SenderID and help to promote it as a standard. There is wide agreement, myself included, that the Microsoft IPR license would be best removed from the proposal. However, SenderID is a good solution and the it's the best that we can offer the internet user community at this time. We can work through the licensing, it cannot be a deal breaker. MARID's objective is to put forth an authentication solution that can be a best first-step in solving the spam problem that plagues all of us. Whether we represent the open source community or the furtune 500, we have a responsibility to the users of the internet and to protect the email medium. The IETF and the MARID group is comprised of individuals who are involved in *developing* and *improving* the internet. The IETF has a long tradition of significant contributions to the internet. The internet would not be relevant today, if not for the IETF, and the IETF is relevant to the internet. We have a responsibility to the *users* of the internet. If the MARID chairs abandon SenderID, SenderID will not die. Microsoft will move forward with SenderID at MSN, HotMail, within Outlook and Exchange. SendMail will move forward with SenderID. That represents enough user email boxes that the spam-fighters BrightMail, CloudMark, Senderbase, Tumbleweed have already announced SenderID support. The Email Service Provider Coalition, representing a very significant portion of legitimate commercial email will publish SenderID in DNS. ISP's that want their users email to reach inboxes at MSN, HotMail, Exchange or SendMail supported email boxes may want to publish SenderID records in DNS. My company will certainly publish both SPF1 and SPF2 regardless of the MARID decision. If MARID abandons SenderID, it might be a step towards IETF irrelevance, as both SPF Classic and SenderID will live on. If MARID embraces SenderID, with it's flaws, there is hope for a unified approach to solving the SPAM problem (SenderID as step 1). The flaws can be addressed, the licensing can be addressed, the solution must start now. We all know that the solution starts with authentication; it can be improved with accreditation and reputation. Thank you for your consideration. --KEN Ken Schmidt VP Operations Savicom From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:35: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 NAA21839 for ; Thu, 2 Sep 2004 13:35: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 i82GruQQ003813; Thu, 2 Sep 2004 09:53: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 i82GruW8003812; Thu, 2 Sep 2004 09:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i82GrtZd003804 for ; Thu, 2 Sep 2004 09:53:55 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-9.tower-48.messagelabs.com!1094144036!4713483 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 9290 invoked from network); 2 Sep 2004 16:53:56 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-9.tower-48.messagelabs.com with SMTP; 2 Sep 2004 16:53:56 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Sep 2004 17:53:56 +0100 Received: (qmail 7369 invoked from network); 1 Sep 2004 16:49:23 -0000 Received: from unknown (HELO ?10.191.100.31?) (10.191.100.31) by matt?dev.int.star.co.uk with SMTP; 1 Sep 2004 16:49:23 -0000 Date: Thu, 2 Sep 2004 17:53:55 +0100 (BST) From: Matt Sergeant X-X-Sender: matt@localhost.localdomain To: ietf-mxcomp@imc.org Subject: DEPLOY: Conversation with MSFT regarding license Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 02 Sep 2004 16:53:56.0099 (UTC) FILETIME=[6F4AC530:01C4910D] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some people on this list will be aware that yesterday Microsoft held an event in Redmond to assist people in moving forward on implementing Sender-ID. There was nothing on the agenda discussing licensing, but clearly this is a key issue, so I raised the issue three times during the day - twice during the conference itself, and later as a casual conversation with Craig Spietzle over drinks. First my disclosure: My employer is MessageLabs, one of the largest MX filtering companies in the world - largest in terms of number of customers. The license is compatible with our company in terms of implementation, however I went to the sender-id summit with a specific goal to discuss the deployment issues regarding open source software. We are both a major user of open source software, and a contributor (I'm a developer of an open source SMTPd and an ex SpamAssassin developer), and should sender-id fail because of Microsoft's unwillingness to negotiate the terms of their license then that would be bad for the entire industry. What I write here is my interpretation of events. There were witnesses to everything written here, and I welcome them to correct things should I have misremembered (given that I had to travel 48+ hours for this one day event, I hope people will forgive me if I have some things mixed up). I would also like to point out that I am not trying to bash anyone here - I appreciate the effort Microsoft is putting in here, and I do not wish to appear to be attacking them in any way. This note is merely to inform those not present at the Sender-ID summit of what transpired there from my personal perspective. o o o o During the course of the day, licensing was mentioned a couple of times as I recall it. The first time was a "Licensing Reality" slide which declared that everything was OK and we shouldn't worry (I'm massively paraphrasing of course). Sendmail Inc also spoke about how it was a non-issue because you simply didn't need to get a license (a fact with which I disagree), which is the stance they have taken with their Sender-ID implementation. During a section of the day regarding deployment I decided it was time to open this issue up to the audience. After all, the licensing issues are all about deployment. I raised the well known issues discussed on this list (incompatibilities with open source licenses). The Microsoft response appeared to be that they would fix the FAQ and confirm that they would never ever charge for Sender-ID licenses. The charging issue appeared to be held on to toward the end of the day, when Microsoft declared that they would never charge, and would email mxcomp in that regard (I believe Harry Katz has done so). However, charging was NEVER the issue with open source licenses, and this was either a smokescreen or a fundamental misunderstanding of the issues. Craig Spietzle requested that I discuss this with him offline so they could continue the conference, so in the evening I took some time to discuss it with him, in the presence of Wietse Venema and the author of the Port25 mailer (who's name I have temporarily forgotten - apologies). We discussed a number of issues, not all of which I can recall now. Most certainly I put it to him that cost was not the issue and that there was a fundamental incompatibility with open source licenses. On the cost issue I believe that sunk in. On the incompatibility issue I don't believe we managed to agree with each other. Ultimately I put it to him that the license would have to change should open source implementations of Sender-ID be a requirement for adoption. I pressed him: "Will you fix the license?". I never really got a confirmed yes or no, but my feeling was "no" when we ended the conversation. I suggested that they give their IP to the IETF (such as I believe there is precedence of - I know that IBM has committed patents to the public domain before in a similar act of openness), to which I was told that Craig believed this was a reasonable idea, but that Bill Gates himself had vetoed that idea because of the current focus on patent gathering and IPR issues at Microsoft. We ended the conversation with my suggestion that Microsoft work with Larry Rosen to fix the license, and Craig telling me that they had already worked really hard with Larry, and that they had "met halfway" with Larry's requests. Craig did suggest that some of Larry's requests were not reasonable and had nothing to do with making the Sender-ID license compatible with open source. I am not privy to the details though. There appeared to be an element of "We've worked really hard on this and we don't want to have to do-over" in Craig's responses. Ultimately I do feel that Craig Spietzle listened very carefully to my points, and I am grateful to him for that, and if I have mis-characterised anything he said to me in the above text I will stand corrected. But I do not personally believe the position Microsoft is taking on this is working for this project. While there are other IETF standards that are IPR encumbered and require a license, they are not standards which have as wide-reaching an effect as Sender-ID, and I think we have to get this one right. Matt Sergeant Senior Anti-Spam Technologist MessageLabs. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:44: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 NAA22263 for ; Thu, 2 Sep 2004 13:44: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 i82HJmrC006346; Thu, 2 Sep 2004 10:19: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 i82HJmpk006345; Thu, 2 Sep 2004 10:19:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82HJk9E006336 for ; Thu, 2 Sep 2004 10:19:47 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id CFE5F28BB5 for ; Thu, 2 Sep 2004 19:18:49 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13031-04 for ; Thu, 2 Sep 2004 19:18:37 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 4254628B53; Thu, 2 Sep 2004 19:18:37 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Thu, 2 Sep 2004 19:18:37 +0200 (CEST) Message-ID: <39327.127.0.0.1.1094145517.squirrel@127.0.0.1> In-Reply-To: <001d01c4910c$9fa60830$2600a8c0@ken> References: <001d01c4910c$9fa60830$2600a8c0@ken> Date: Thu, 2 Sep 2004 19:18:37 +0200 (CEST) Subject: RE: Motion to abandon Sender ID From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Ken a écrit : > > I encourage the MARID working group, it's Chairs and the IETF to embrace > SenderID and help to promote it as a standard. [...] > If the MARID chairs abandon SenderID, SenderID will not die. Microsoft > will move forward with SenderID at MSN, HotMail, within Outlook and > Exchange. SendMail will move forward with SenderID. [...] What I read above is "Resistance is futile. You will be assimilated.", or am I mistaken ? Is it really the role of IETF to "follow what BigCompany decides, because they'll do it anyway" ? -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:46: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 NAA22473 for ; Thu, 2 Sep 2004 13:46:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82HNkOC006742; Thu, 2 Sep 2004 10:23: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 i82HNk2c006741; Thu, 2 Sep 2004 10:23:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vodka.at-once.com (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82HNjCu006731 for ; Thu, 2 Sep 2004 10:23:45 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vodka.at-once.com (8.12.11/8.12.11) with ESMTP id i82HNXMY017961; Thu, 2 Sep 2004 10:23:33 -0700 Subject: RE: Motion to abandon Sender ID From: Ryan Ordway To: jonathan.curtis@bell.ca Cc: research@solidmatrix.com, hadmut@danisch.de, jonagard@amazon.com, ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1094145812.17694.14.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 02 Sep 2004 10:23:32 -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-09-02 at 08:58, jonathan.curtis@bell.ca wrote: > >> > > > >I am sure that we can come up with multiple conspiracy > >theories for this. For now, lets stay above the fray and > >assume that perhaps Microsoft was acting in good faith. > >Descending into conspiracy theories will not make this any > >better, and quite the opposite, will make the entire > >discussion appear unprofessional. > > > >Microsoft knows what the issues are, they are receiving > >comments from multiple people and sources. The decision on > >the license is upto them. > >The decision on the standard on the other hand is upto the us. > > > >Yakov > > > > > > IMHO...(short version) > > I will recommending that we move forward with the implementation of > SenderID within Bell Canada (over 35,000 domains) as I believe the > licensing component has zero to do with the technology and cost of > implemention. The support that Microsoft will generate over night for > this solution will drive global adoptation - something this solution is > going to need to be successful. Gee, amazing how the Internet ever managed to come into existence without Microsoft! A big company's backing does not a successful protocol make. More likely, if certain key ISPs were to start checking MARID records and making actual decisions based upon their content, this would drive support for the protocol. From -rationale-00: 7.2. Marketing Analysis: Chasm Theory The designed product, and the augmentations that surround it, must survive each phase of Geoffrey Moore's Chasm model. The core specification should be attractive enough to the visionaries to seed the fax effect by publishing records and writing libraries. After an initial round of discovery and experimentation by the early adopters, the mainstream must be encouraged to start publishing records. This is the first chasm, on the publishing side. They need the assurance that publishing records will, first, do no harm. The beachhead for crossing the publishing-side chasm turned out to be industry leaders. When enough well known domains published records, they seeded the second round of the fax effect. The second round turns potential receiver-side implementors into actual implementors: the early adopters here are the makers of antispam email appliances and edge MTAs such as CipherTrust, IronPort, Postini, and Brightmail. They are ideally positioned to implement Sender ID checking on inbound mail and have a business reason to do so. The second chasm, on the receiving side, requires major ISPs to start implementing inbound checking. Their initial motivation is to reduce the costs of whitelisting. Major ISPs negotiate email peering relationships with major senders and maintain, often by hand, whitelists of IP addresses. Conversion to Sender ID-based whitelisting is an obvious step. Note that while Sender ID is often viewed as an anti-forgery mechanism, using it as a whitelisting mechanism is simply the other side of the coin. After these chasms are crossed, there remains the challenge of getting publishers to transition through increasing levels of severity: from "?" to "~" to "-". This effort requires cooperation from receivers. I see no mention of Microsoft in there anywhere! My apologies if I dripped any sarcasm on you. Ryan -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 13:48:40 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 NAA22760 for ; Thu, 2 Sep 2004 13:48:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82HQg1O007244; Thu, 2 Sep 2004 10:26:42 -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 i82HQggf007243; Thu, 2 Sep 2004 10:26:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from Garovirus.uqss.uquebec.ca (garovirus.uqss.uquebec.ca [192.77.51.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82HQfcp007088 for ; Thu, 2 Sep 2004 10:26:41 -0700 (PDT) (envelope-from gfk@logidac.com) Received: from maestro ([132.214.200.206]) by Garovirus.uqss.uquebec.ca (8.12.10/8.12.8) with SMTP id i82HQZWj005149 for ; Thu, 2 Sep 2004 13:26:36 -0400 Message-ID: <00ef01c49112$0ad16370$cec8d684@sraq.intra> From: "Guillaume Filion" To: "IETF MARID WG" References: <792DE28E91F6EA42B4663AE761C41C2A02CEB896@cliff.bai.org> Subject: Re: The SSL license offer. Date: Thu, 2 Sep 2004 13:26:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Garovirus-MailScanner: Found to be clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "Ryan Malayter" wrote: > Very interesting. If OpenSSL can be included in Linux distributions, why > can't SenderID? > > The SSL license would seem to have tproblems with the GPL similar to > those that the SenderID license does. I may be talking throught my hat, but reading the SSL patent license, I see no restriction on redistribution. The Sender-ID license allows (re)distribution only for those who sign the license and fax it to them. In my understanding, this is the main incompatibility with the GPL. Here's the part of the SSL License I'm refering to: If you don't have an SSL Ref license, you may have a royalty free license to build implementations covered by the SSL Patent Claims or the IETF TLS specification provided that you do not to assert any patent rights against Netscape or other companies for the implementation of SSL or the IETF TLS recommendation. Best, GFK's -- Guillaume Filion, ing. jr Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 14:15: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 OAA25168 for ; Thu, 2 Sep 2004 14:15: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 i82HqA5X010072; Thu, 2 Sep 2004 10:52:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82HqAW2010071; Thu, 2 Sep 2004 10:52:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82Hq9R3010058 for ; Thu, 2 Sep 2004 10:52:09 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: The SSL license offer. Date: Thu, 2 Sep 2004 12:52:10 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEB8CB@cliff.bai.org> Thread-Topic: The SSL license offer. thread-index: AcSREnYIzeirEaKnR1um+gpqoY5BNgAAbSPw From: "Ryan Malayter" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82Hq9R3010066 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Guillaume Filion] > I may be talking throught my hat, but reading the SSL patent > license, I see > no restriction on redistribution. I thought that all rights were reserved unless specifically granted. If so, it would seem the SSL license grants NO rights to redistribute whatsoever. Perhaps I am wrong. In any case, I cannot seem to find an "official" version of this license on the netscape or AOL sites, so who the hell knows. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 14:20: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 OAA25428 for ; Thu, 2 Sep 2004 14:20:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82HxoNb011178; Thu, 2 Sep 2004 10:59:50 -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 i82HxoRS011177; Thu, 2 Sep 2004 10:59:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp-out-1002.amazon.com (smtp-out-1002.amazon.com [207.171.160.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82HxnsV011158 for ; Thu, 2 Sep 2004 10:59:49 -0700 (PDT) (envelope-from jonagard@amazon.com) Received: from smtp-in-2001.iad2.amazon.com by smtp-out-1002.amazon.com with ESMTP (peer crosscheck: smtp-in-2001.iad2.amazon.com) X-Amazon-Corporate-Relay: smtp-out-1002.vdc.amazon.com X-AMAZON-TRACK: ietf-mxcomp@imc.org Received: from ex-gate-02.ant.amazon.com by smtp-in-2001.iad2.amazon.com with ESMTP (crosscheck: app-good-01.ant.amazon.com [10.16.148.40] (may be forged)) id i82Hxg3v004171; Thu, 2 Sep 2004 17:59:42 GMT Received: from jonagard.desktop.amazon.com ([10.21.12.165]) by ex-gate-02.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Sep 2004 11:00:04 -0700 From: Jonathan Gardner Organization: Amazon To: Yakov Shafranovich Subject: Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 10:59:40 -0700 User-Agent: KMail/1.6 References: <200409011531.38815.jonagard@amazon.com> <20040902124447.GA4471@danisch.de> <41373716.8010001@solidmatrix.com> In-Reply-To: <41373716.8010001@solidmatrix.com> Cc: IETF MARID WG MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200409021059.41477.jonagard@amazon.com> X-OriginalArrivalTime: 02 Sep 2004 18:00:04.0769 (UTC) FILETIME=[ACCDC110:01C49116] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82HxosV011172 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 02 September 2004 08:07 am, Yakov Shafranovich wrote: > > I am sure that we can come up with multiple conspiracy theories for > this. For now, lets stay above the fray and assume that perhaps > Microsoft was acting in good faith. Descending into conspiracy theories > will not make this any better, and quite the opposite, will make the > entire discussion appear unprofessional. > I agree. Let's leave the conspiracy theories for Slashdot. We shouldn't attribute to malice what can be attributed to ignorance, or in this case, inexperience with the open source community. > Microsoft knows what the issues are, they are receiving comments from > multiple people and sources. The decision on the license is upto them. > The decision on the standard on the other hand is upto the us. > The only problem I see is time constraints. I doubt that Microsoft will be able to come up with a new license and still give us time to examine and debate it. That's why we should hold off on Sender ID until we get a license that will allow it to become a standard. The other alternative is for Microsoft to abandon their pending patent application. I highly doubt Microsoft will do that, but that is their decision. - -- Jonathan M. Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBN1+MBFeYcclU5Q0RAmWcAJ9ueZTo8MYbopVojVgfQgSzFMpTJgCg6KG+ WyD6bMuzhvoXRgKsNV7XTJc= =i40j -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 14:24: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 OAA25665 for ; Thu, 2 Sep 2004 14:24:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82I1m7F011356; Thu, 2 Sep 2004 11: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 i82I1mSS011354; Thu, 2 Sep 2004 11: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 i82I1mt5011348 for ; Thu, 2 Sep 2004 11:01:48 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i82I1q5m018159 for ; Thu, 2 Sep 2004 11:01:52 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2AB71632-FD0A-11D8-BA2B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 11:01:51 -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 > Nobody ever says why MSFT would prosecute someone who didn't have the > license. In court, it would be pointed out: > > * MSFT does not charge anything for the license, so its damages would > be > non-existent > * MSFT gives the technology away freely to those who send in a fax > * MSFT clearly intended it to be royalty free as it was given over to > an > international standards body > > So in court they'd have to show why a particular user who hadn't sent > in a > fax should be prosecuted? They would have to show harm done to them. This is completely incorrect. This would be true for a breach of contract case (or also a tort case), but not here. In the case of someone taking or duplicating something without a license, it's piracy. And there are statutory damages available for both piracy and malactions against intellectual property (in fact the latter is precisely on what our "register your domain for trademark protection to sue spoofers" service is founded - showing actual damage in these cases can be difficult - which is precisely why there are statutory damages available). Even if they did have to show damages, it would be easily done by the loss of ability to track who is using their product, and, by extension then, who may be diluting it by altering it and still distributing it as a "Microsoft product" (and if not as a "Microsoft product", then we get to areas of infringement). Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy Professor of Law, Lincoln Law School of SJ Committee Member, Asilomar Microcomputer Workshop From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 14:36: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 OAA26355 for ; Thu, 2 Sep 2004 14:36:58 -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 i82IDA45012485; Thu, 2 Sep 2004 11:13:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82IDAl2012484; Thu, 2 Sep 2004 11:13:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ms-smtp-04.nyroc.rr.com (ms-smtp-04.nyroc.rr.com [24.24.2.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82ID9Pu012475 for ; Thu, 2 Sep 2004 11:13:09 -0700 (PDT) (envelope-from jthughes@maine.rr.com) Received: from JTHSony (ptd-204-210-94-155.maine.rr.com [204.210.94.155]) by ms-smtp-04.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id i82ID9t2008358 for ; Thu, 2 Sep 2004 14:13:11 -0400 (EDT) From: "J. Trevor Hughes" To: Subject: (DEPLOY) In Support of Sender ID Date: Thu, 2 Sep 2004 14:13:13 -0400 Message-ID: <008801c49118$8321a780$6401a8c0@JTHSony> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01C490F6.FC100780" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0089_01C490F6.FC100780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I write as the executive director of the Email Service Provider = Coalition (ESPC). The ESPC is a trade association made up of 54 email service providers. We estimate that our members provide delivery services to = over 250,000 senders in the US alone. And according to Ironport's = SenderBase, our members deliver approximately 12% of all email. =20 Both in a personal capacity and as a trade association, I write today to express strong support for Sender ID. The ESPC has been advocating for authenticated email solutions for almost two years and feel that this is = a critical first step toward more comprehensive solutions to the spam = problem. Last year, the ESPC published a white paper on our vision for = authenticated email (Project Lumos, authored by Hans Peter Brondmo and Margaret = Olson). =20 Within our organization, we have had three corporate attorneys from = member companies review the Microsoft license (I too am an attorney, although = not trained or licensed in patent law). Resoundingly, we have found that = the issues raised within MARID are addressable, or at worst understandable, given the context of situation. I personally believe that Microsoft is acting in good faith and in a rational manner and has moved forward with patent protections as a defensive response to very real risks. (See http://www.groklaw.net/article.php?story=3D20040901004705872 for a = decent discussion on the reasoning behind a defensive patent claim on an = otherwise "free" license.) =20 Based on our review, the license terms have been deemed acceptable. The fact that pending patent claims are present is nothing new to the IETF. Many RFCs have gone forward with IPR claims. The issue should then = distill to whether the license presented is consistent with IETF standards. I believe that Microsoft has complied with, and indeed exceeded, the standards. The IETF has been notified of the IPR claims and = royalty-free, non-discriminatory license terms have been offered. What more is = required? =20 Much has been made of the fact that the pending patent content has not = been disclosed. While this may be disconcerting to some, it represents a balanced strategy to protect against predatory claims downstream. A = patent application is the first time that a company exposes proprietary information. Any attorney representing a corporation would counsel = against disclosure of the patent at this stage in the process. Suggestions that this inappropriate (particularly from attorneys) fail to recognize the = risks associated with disclosure of the patent content. =20 Even more has been said about the sub-licensing of Sender ID. While I = do acknowledge the concerns of many on this list, we feel that the friction caused by sub-licensing is a worthwhile quid pro quo for the greater = value of broad implementation of an authenticated email solution. Again, any attorney acting as counsel for a corporation would seek such terms. = They are neither surprising, nor objectionable. =20 I do want to raise one issue that has not been discussed on MARID yet = (at least as far as I have seen). The eyes of the world are upon industry = at this time and great expectations have been created for authenticated = email technologies to emerge quickly and broadly. The Federal Trade = Commission recently issued a report to Congress and strongly advocated for authenticated email solutions. They will be holding a workshop on the = topic later this fall. Failure to move forward with Sender ID at this = juncture will likely put us back at least 6 months and perhaps more. Such a = delay will only invite interference from legislators and regulators. I = certainly do not think that is in the best interests on anyone! =20 Finally, I want to share a dystopian vision of how things may play out = if we fail to move Sender ID forward. Multiple IP-based authentication = mechanisms will be a disaster for email. We run the risk of balkanized ISP = solutions - and the ensuing demands of multiple protocols on all senders. Not a = good result coming out of an effort to create a standard! =20 I urge the participants on this list to consider the greater good that = will be borne from the wide adoption of Sender ID. This is a good tool. The actions of the various parties involved are understandable and = reasonable. The license terms are workable and within the scope of IETF standards = and history. And it will have a positive effect on our ability to reduce phishing and protect legitimate email. =20 J. Trevor Hughes Executive Director NAI =20 207 351 1500 (o) 207 351 1501 (f) thughes@networkadvertising.org =20 ------=_NextPart_000_0089_01C490F6.FC100780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I write as the executive director of the Email = Service Provider Coalition (ESPC).  The ESPC is a trade association made up = of 54 email service providers.  We estimate that our members provide = delivery services to over 250,000 senders in the US = alone.  And according to Ironport’s SenderBase, our members deliver approximately 12% of = all email.

 

Both in a personal capacity and as a trade = association, I write today to express strong support for Sender ID.  The ESPC has = been advocating for authenticated email solutions for almost two years and = feel that this is a critical first step toward more comprehensive solutions to the = spam problem.  Last year, the ESPC published a white paper on our vision = for authenticated email (Project Lumos, authored by Hans Peter Brondmo and = Margaret Olson).

 

Within our organization, we have had three corporate attorneys from member companies review the Microsoft license (I too am = an attorney, although not trained or licensed in patent law). =  Resoundingly, we have found that the issues raised within MARID are addressable, or at = worst understandable, given the context of situation.  I personally = believe that Microsoft is acting in good faith and in a rational manner and has moved forward with patent protections as a defensive response to very real = risks.  (See htt= p://www.groklaw.net/article.php?story=3D20040901004705872 for a decent discussion on the reasoning behind a defensive patent claim = on an otherwise “free” license.)

 

Based on our review, the license terms have been = deemed acceptable.  The fact that pending patent claims are present is = nothing new to the IETF.  Many RFCs have gone forward with IPR = claims.  The issue should then distill to whether the license presented is consistent = with IETF standards.  I believe that Microsoft has complied with, and = indeed exceeded, the standards.  The IETF has been notified of the IPR = claims and royalty-free, non-discriminatory license terms have been offered.  = What more is required?

 

Much has been made of the fact that the pending = patent content has not been disclosed.  While this may be disconcerting to = some, it represents a balanced strategy to protect against predatory claims downstream.  A patent application is the first time that a company = exposes proprietary information.  Any attorney representing a corporation = would counsel against disclosure of the patent at this stage in the process.  Suggestions that this inappropriate (particularly from attorneys) fail = to recognize the risks associated with disclosure of the patent = content.

 

Even more has been said about the sub-licensing of = Sender ID.  While I do acknowledge the concerns of many on this list, we = feel that the friction caused by sub-licensing is a worthwhile quid pro quo = for the greater value of broad implementation of an authenticated email = solution.  Again, any attorney acting as counsel for a corporation would seek such terms.  They are neither surprising, nor = objectionable.

 

I do want to raise one issue that has not been = discussed on MARID yet (at least as far as I have seen).  The eyes of the world = are upon industry at this time and great expectations have been created for = authenticated email technologies to emerge quickly and broadly.  The Federal = Trade Commission recently issued a report to Congress and strongly advocated for = authenticated email solutions.  They will be holding a workshop on the topic = later this fall.  Failure to move forward with Sender ID at this juncture will = likely put us back at least 6 months and perhaps more.  Such a delay will = only invite interference from legislators and regulators.  I certainly = do not think that is in the best interests on anyone!

 

Finally, I want to share a dystopian vision of how = things may play out if we fail to move Sender ID forward.  Multiple = IP-based authentication mechanisms will be a disaster for email.  We run the = risk of balkanized ISP solutions – and the ensuing demands of multiple = protocols on all senders.  Not a good result coming out of an effort to = create a standard!

 

I urge the participants on this list to consider the = greater good that will be borne from the wide adoption of Sender ID.  This = is a good tool.  The actions of the various parties involved are = understandable and reasonable.  The license terms are workable and within the = scope of IETF standards and history.  And it will have a positive effect on = our ability to reduce phishing and protect legitimate = email.

 

J. Trevor = Hughes

Executive Director

NAI

 

207 351 1500 (o)

207 351 1501 (f)

thughes@networkadvertising.org

 

------=_NextPart_000_0089_01C490F6.FC100780-- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 14:44:36 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 OAA27024 for ; Thu, 2 Sep 2004 14:44: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 i82IM5VG013052; Thu, 2 Sep 2004 11:22: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 i82IM5DF013051; Thu, 2 Sep 2004 11:22:05 -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 i82IM5Cw013044 for ; Thu, 2 Sep 2004 11:22:05 -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 4F781414C5; Thu, 2 Sep 2004 11:22:07 -0700 (PDT) Subject: Re: TECH-OMISSION:Submitter concept should be expanded to include Peristent User Accounts (PUA) From: Douglas Otis To: Scott Kitterman Cc: "IETF MXCOMP (E-mail)" In-Reply-To: References: Content-Type: text/plain Message-Id: <1094149325.19890.82.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 02 Sep 2004 11:22:05 -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-09-02 at 09:01, Scott Kitterman wrote: > I wasn't sure to post this as a deployment issue, a DOC-BUG issue or a > tech-omission issue, my apologies if this isn't the right one. > > Currently it is very difficult for small domain owners, such as myself, who > use a shared MTA to construct a record that will produce a pass result > without also opening ourselves up to forgery from other legitimate (i.e. the > MTA owner has authorized them to use the MTA) users of the shared MTA. The > reason for this is that virtually no shared MTA providers that allow domains > other than their own in mail from or from restrict them at all. > > This limitation applies equally to SPF classic as well. In a recent > discussion on this topic on the spf-discuss list (with ~1,000 subscribers) > only one provider that would prevent cross-customer forgery was identified. > The result of this is a record that looks like this (I'm using an > abbreviated generic version of my SPF classic record since I haven't created > a Sender-ID record - the point's the same either way): > > "v=spf1 include:webmail.hostco.com ?a:relay.hostco.com ?mx > ?include:isp.net -all" > > There are three possible solutions to this problem that I can see: > > 1. Shared MTA providers only allow their customers to send e-mail from > domains for which they have a legitimate right to do so. I believe this > would be very cumbersome for large providers to do. How would they know > what domains different users had access to? If I use my hosting company's > MTA, then they could know reasonably easily, but how about the ISP? I can > see this leading to a situation where MTA providers would only allow mail > from domains they host. That would cost people in situations like me > redundancy. I generally send through my hosting company's MTA, but if it's > down, I can send via the ISP's MTA. Combined with port blocking, this might > also force small businesses to host their domains with their ISP. > > 2. Businesses that want to get a pass result need to set up their own > dedicated MTA. The reason that small busnisses don't do this now is they > have neither the time nor the expertise. This approach will no doubt result > in even more poorly configured and inadequately maintained MTAs appearing on > the internet. > > 3. Explicitly add a third possible source for submitter, the Persistent > User Account (PUA). This would allow providers of shared MTA services to > add as a submitter the local (to the shared MTA) e-mail address of the user > that submitted the message to the MTA. This was discussed on the list in > July. Here is the start of the thread: > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02633.html A small business wanting to specify their "permitted or nominal" outbound MTA servers, would not be concerned should the MTA receive the reputation, where these servers are shared and administered by others. When an MTA is spoofing headers or not disabling abusive accounts, the MTA reputation handles this problem directly. It could be the underlying problem is a compromise or misconfiguration of the MTA. If the headers are trustworthy, based upon knowing the reputation of the MTA, then the origin of the mail can be determined by the headers. There is no need to add yet another field. If the name of the MTA were authenticated, then listing the "permitted or nominal" outbound servers would only require creating a name list, and not require a redirected lookup or the repeated listings of addresses that creates support issues and potentially high overhead for mail recipients. As example, the SPF records could become something like: _mp._smtp.small-business.com. PTR hostco.com. PTR isp.net. This does not require any additional lookups to determine what MTAs are permitted to send mail on behalf of small-business.com nor does this require keeping address records synchronized with the host addresses. A flag can indicate this list is to be considered comprehensive (permitted) to enable rejection of mail not originating from MTAs having a name from that does not include one of these top level domains. If the list is to be considered not comprehensive (normative), then only when mail is coming from these prescribed MTA servers would the mail receive a higher level of "certainty." Including within the CSV-CSA record specification an indication that the MTA relays multiple domains, could lower the "certainty" rating for mail traveling through shared servers. There could be another indication that specifies all relayed mail is domain "restricted" meaning the MTA checks to ensure only specific sources for a domain are allowed, to restore the level of certainty. In other works, it checks the policy records for the mailbox domains. The mailbox restrictions could be either the RFC2821 MAIL FROM or the RFC2822 From. A restriction on the RFC2822 From may be desired for financial institutions for specific sub-domains as a means to offer increased protection of these specific domains. I expect most domains would be happy using the SPF mode of only restricting the MAIL FROM. By limiting reputation to the MTA name, non-restricted mailbox domains do not offer a means to exploit that domain. A reputation service will still be able to block mail from any domain of course, but it would be at the channel level. Reputation blocking needs a higher level of certainty than that offered by examining just mailbox domains. Establishing a relationship with the MTA and the mailbox domain however, enables the prevention of mailbox spoofing as an independent function of reputation. By keeping these function separate, the problems with a shared MTA servers goes away. By authenticating the name of the MTA, reputation services are made much less expensive to maintain and polices are easier to enforce. By using the name of the MTA, a history can be established and "new" names can be readily detected. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:00:04 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 PAA27890 for ; Thu, 2 Sep 2004 15:00: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 i82IXNN5014292; Thu, 2 Sep 2004 11:33:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82IXNHc014291; Thu, 2 Sep 2004 11:33:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from corpmx.savicom.net (corpmx.savicom.net [216.39.113.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82IXMDU014282 for ; Thu, 2 Sep 2004 11:33:23 -0700 (PDT) (envelope-from ken@savicom.net) Received: from ken (office.mindsharedesign.com [216.39.112.17]) by corpmx.savicom.net (8.12.9/8.12.3) with ESMTP id i82IVLGn041366; Thu, 2 Sep 2004 11:31:25 -0700 (PDT) (envelope-from ken@savicom.net) From: "Ken" To: "'Michel Bouissou'" , Subject: RE: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 11:26:44 -0700 Message-ID: <003401c4911a$66c3c620$2600a8c0@ken> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <39327.127.0.0.1.1094145517.squirrel@127.0.0.1> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82IXNDU014285 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Michel: I'd say a more precise interpretation of the extracted sentences would be: "Think about the consequences of our actions. Imagine what the world will be like following a MARID abandonment of SenderID?" You do not have to be assimilated, but it seems unrealistic to believe that SenderID will die. It's a good technical solution for today. --KEN > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Michel Bouissou > Sent: Thursday, September 02, 2004 10:19 AM > To: ietf-mxcomp@imc.org > Subject: RE: Motion to abandon Sender ID > > > > Ken a écrit : > > > > I encourage the MARID working group, it's Chairs and the IETF to > > embrace SenderID and help to promote it as a standard. > [...] > > If the MARID chairs abandon SenderID, SenderID will not die. > > Microsoft will move forward with SenderID at MSN, HotMail, within > > Outlook and Exchange. SendMail will move forward with > SenderID. [...] > > What I read above is "Resistance is futile. You will be > assimilated.", or am I mistaken ? > > Is it really the role of IETF to "follow what BigCompany > decides, because they'll do it anyway" ? > > -- > Michel Bouissou OpenPGP ID 0xDDE8AC6E > > From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:11:23 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 PAA28997 for ; Thu, 2 Sep 2004 15:11:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82IkEH7015240; Thu, 2 Sep 2004 11:46: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 i82IkEFS015239; Thu, 2 Sep 2004 11:46:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.salmark.net (mail.salmark.net [64.23.85.10] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82IkD8m015233 for ; Thu, 2 Sep 2004 11:46:13 -0700 (PDT) (envelope-from peter@bowyer.org) Received: from [212.158.247.25] (port=10828 helo=pbdesktop) by mail.salmark.net with asmtp (Exim 4.41) id 1C2wbA-0001bI-SZ for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 14:46:17 -0400 Message-ID: <083701c4911d$45511f80$0a46a8c0@pbdesktop> From: "Peter Bowyer" To: References: <003401c4911a$66c3c620$2600a8c0@ken> Subject: Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 19:47:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ken wrote: > Michel: > > I'd say a more precise interpretation of the extracted sentences would > be: > > "Think about the consequences of our actions. Imagine what the world > will be like following a MARID abandonment of SenderID?" You do not > have to be assimilated, but it seems unrealistic to believe that > SenderID will die. It's a good technical solution for today. Technically, there is far less of an issue. But what am I, and the thousands like me, to do when I cannot implement the acknowledged good technology because the maintainer of my MTA cannot incorporate it for non-technical reasons? The solution has to be technically sound AND deployable. Peter From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:13: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 PAA29233 for ; Thu, 2 Sep 2004 15:13:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82Ipxob015642; Thu, 2 Sep 2004 11: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 i82IpxR0015641; Thu, 2 Sep 2004 11:51:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82IpwE7015634 for ; Thu, 2 Sep 2004 11:51:58 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 34DAA28B3E for ; Thu, 2 Sep 2004 20:51:00 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14992-06-2 for ; Thu, 2 Sep 2004 20:50:56 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id BB60728A79; Thu, 2 Sep 2004 20:50:56 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Thu, 2 Sep 2004 20:50:56 +0200 (CEST) Message-ID: <39844.127.0.0.1.1094151056.squirrel@127.0.0.1> In-Reply-To: <003401c4911a$66c3c620$2600a8c0@ken> References: <39327.127.0.0.1.1094145517.squirrel@127.0.0.1> <003401c4911a$66c3c620$2600a8c0@ken> Date: Thu, 2 Sep 2004 20:50:56 +0200 (CEST) Subject: RE: Motion to abandon Sender ID From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Ken a écrit : > > Michel: > > I'd say a more precise interpretation of the extracted sentences would > be: > > "Think about the consequences of our actions. Imagine what the world > will be like following a MARID abandonment of SenderID?" Will it be that terrible ? Will the world collaYou are presenting things as if there were no alternative, as if we were in a "Sender-ID or nothing" situation. But this is not the case. There are numerous possible alternatives, which may be as efficient or possibly better than the (yet untested on a large scale) Sender-ID. Among them SPF-Classic, which has a true (presumably happy, at least, I am) installed base, and is unencumbered. > You do not have to be assimilated, but it seems unrealistic to believe > that SenderID will die. It's a good technical solution for today. I don't care whether it actually dies or not as a technical solution, but I care that a "solution" that is encumbered in such way, and that serves the interests of a single big company at the detriment of the rest of the community, should never be raised to a "standard". -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:26:14 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 PAA00395 for ; Thu, 2 Sep 2004 15:26:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82IvEsA016148; Thu, 2 Sep 2004 11:57: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 i82IvD2X016147; Thu, 2 Sep 2004 11:57:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82IvBjc016118 for ; Thu, 2 Sep 2004 11:57:12 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 14:57:12 -0400 Message-ID: <41376D09.1000400@hepcoe.com> Date: Thu, 02 Sep 2004 14:57:13 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID References: <008801c49118$8321a780$6401a8c0@JTHSony> In-Reply-To: <008801c49118$8321a780$6401a8c0@JTHSony> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Sep 2004 18:57:12.0728 (UTC) FILETIME=[A806C980:01C4911E] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit J. Trevor Hughes wrote: > Even more has been said about the sub-licensing of Sender ID. While I > do acknowledge the concerns of many on this list, we feel that the > friction caused by sub-licensing is a worthwhile quid pro quo for the > greater value of broad implementation of an authenticated email > solution. Again, any attorney acting as counsel for a corporation > would seek such terms. They are neither surprising, nor objectionable. > They may not be surprising, but they are objectionable to a significant portion of the people who would be developing and implementing MARID. > I do want to raise one issue that has not been discussed on MARID yet > (at least as far as I have seen). The eyes of the world are upon > industry at this time and great expectations have been created for > authenticated email technologies to emerge quickly and broadly. The > Federal Trade Commission recently issued a report to Congress and > strongly advocated for authenticated email solutions. They will be > holding a workshop on the topic later this fall. Failure to move > forward with Sender ID at this juncture will likely put us back at > least 6 months and perhaps more. Such a delay will only invite > interference from legislators and regulators. I certainly do not think > that is in the best interests on anyone! > Not true. SPF is more mature than Sender-ID. > Finally, I want to share a dystopian vision of how things may play out > if we fail to move Sender ID forward. Multiple IP-based authentication > mechanisms will be a disaster for email. We run the risk of balkanized > ISP solutions – and the ensuing demands of multiple protocols on all > senders. Not a good result coming out of an effort to create a standard! > This is the most troubling issue that I forsee, I agree. However, I have to wonder why everyone who is pro-Sender-ID doesn't feel it necessary to try to pressure Microsoft into adopting SPF instead. To my mind, there are ZERO hinderences to Microsoft adopting SPF, but there are plenty of hinderences for most everyone else to adopt the encumbered Sender-ID. > I urge the participants on this list to consider the greater good that > will be borne from the wide adoption of Sender ID. This is a good > tool. The actions of the various parties involved are understandable > and reasonable. The license terms are workable and within the scope of > IETF standards and history. And it will have a positive effect on our > ability to reduce phishing and protect legitimate email. > And I urge Microsoft to consider the greater good and drop their licensing requirements or else adopt SPF instead. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:29:57 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 PAA00601 for ; Thu, 2 Sep 2004 15:29: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 i82J5s5x017390; Thu, 2 Sep 2004 12:05:54 -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 i82J5smB017389; Thu, 2 Sep 2004 12:05:54 -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 i82J5s7M017382 for ; Thu, 2 Sep 2004 12:05:54 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i82J5oPl027105; Thu, 2 Sep 2004 12:05:50 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 12:05:50 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ryan Malayter'" , IETF MARID WG Subject: RE: The SSL license offer. Date: Thu, 2 Sep 2004 12:05:48 -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: I don't think that there is actually a license published. All that Netscape provided was an offer to provide a license on terms that were not defined except with regards to cost. I don't know which parties if any executed such an agreement, but a patent certainly was issued. Since we are talking about security we should be talking about probabilities, not possibilities. Sure it is possible that Microsoft would decide to drop $5 million on a patent infringement lawsuit, but it is not very likely that they would recover their legal costs let alone expenses and in the process would cost themselves a huge amount in bad PR. > [Guillaume Filion] > > I may be talking throught my hat, but reading the SSL patent > > license, I see > > no restriction on redistribution. > > I thought that all rights were reserved unless specifically > granted. If > so, it would seem the SSL license grants NO rights to redistribute > whatsoever. Perhaps I am wrong. > > In any case, I cannot seem to find an "official" version of > this license > on the netscape or AOL sites, so who the hell knows. > From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:31: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 PAA00657 for ; Thu, 2 Sep 2004 15:31:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82J8rNj017688; Thu, 2 Sep 2004 12:08: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 i82J8rwP017687; Thu, 2 Sep 2004 12:08:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82J8qXc017680 for ; Thu, 2 Sep 2004 12:08:52 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-096-691.area3.spcsdns.net ([68.245.120.60]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2wvB-0007Ga-VI; Thu, 02 Sep 2004 15:07:00 -0400 Message-ID: <41376FB0.1090607@solidmatrix.com> Date: Thu, 02 Sep 2004 15:08:32 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "J. Trevor Hughes" CC: ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID References: <008801c49118$8321a780$6401a8c0@JTHSony> In-Reply-To: <008801c49118$8321a780$6401a8c0@JTHSony> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit J. Trevor Hughes wrote: > > Based on our review, the license terms have been deemed acceptable. The > fact that pending patent claims are present is nothing new to the IETF. > Many RFCs have gone forward with IPR claims. The issue should then > distill to whether the license presented is consistent with IETF > standards. I believe that Microsoft has complied with, and indeed > exceeded, the standards. The IETF has been notified of the IPR claims > and royalty-free, non-discriminatory license terms have been offered. > What more is required? > > You are making a mistake. The main question the IETF considers in regards to the IPR is not "whether the license presented is consistent with IETF standards". It is rather described in section 5.3 of RFC 3669: " The issue is not whether a particular piece of technology is IPR-impacted -- we use IPR-impacted technology every minute. The question is how much the IPR protection will limit the technology's usefulness in building a robust, highly useful Internet. " In this specific case, even though Microsoft may have satisfied the letter of the law so to speak, that might not be good enough. If the IPR protection will hinder deployment that "will limit the technology's usefulness". That is the main question and unfortunatly, the licensing as it stands now presents a significant deployment barrier to a sizable portion of the Internet community. I urge you to reread RFCs 2026, 3667, 3668 and 3669. > > > Even more has been said about the sub-licensing of Sender ID. While I > do acknowledge the concerns of many on this list, we feel that the > friction caused by sub-licensing is a worthwhile quid pro quo for the > greater value of broad implementation of an authenticated email > solution. Again, any attorney acting as counsel for a corporation would > seek such terms. They are neither surprising, nor objectionable. > If it hinders deployment, it is a problem even if it is "neither surprising, nor objectionable". I think that is the point that is hard to hammer through here - this is not a regular standard, and it requires much more committment and different handling, than anything any corporate lawyers have done before. > > I do want to raise one issue that has not been discussed on MARID yet > (at least as far as I have seen). The eyes of the world are upon > industry at this time and great expectations have been created for > authenticated email technologies to emerge quickly and broadly. The > Federal Trade Commission recently issued a report to Congress and > strongly advocated for authenticated email solutions. They will be > holding a workshop on the topic later this fall. Failure to move > forward with Sender ID at this juncture will likely put us back at least > 6 months and perhaps more. Such a delay will only invite interference > from legislators and regulators. I certainly do not think that is in > the best interests on anyone! > At this point its a catch-22. Not approving the standard will cause problem. But you should also take into account that *approving* it will cause problems as well. Deployment of this standard will not happen until both the commercial and FOSS sides have been satisfied. As much as some of us may hate it, but this is one area where the commercial world and the FOSS *must* work together. Approval of the standard on the MARID WG level means nothing. The final approval rests with the IESG and that will still take time. Any kind of approval or lack of therefore, will cause further friction among the parties, including possible appeals to the IESG and IAB. It might come hard to believe to the commercial world, but the role FOSS software plays in the Internet architechture is larger than any other area today. Majority of the architechture is built on FOSS such as BIND, Apache, sendmail, etc. You cannot simply ignore it and hope it will go away. Both commercial and FOSS sides *must* be willing to negotiate on this issue, and work on this together. Otherwise, even if this standard is approved, and not deployed, it would be useless. And then the senators will jump in anyway. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:34: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 PAA00845 for ; Thu, 2 Sep 2004 15:34: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 i82JE1sc018292; Thu, 2 Sep 2004 12:14: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 i82JE11N018291; Thu, 2 Sep 2004 12:14:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JE134018284 for ; Thu, 2 Sep 2004 12:14:01 -0700 (PDT) (envelope-from csm@moongroup.com) Received: from [192.168.0.10] (rdu74-170-067.nc.rr.com [24.74.170.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1.moongroup.com (Postfix) with ESMTP id 8AB5A1182403E for ; Thu, 2 Sep 2004 15:14:04 -0400 (EDT) Message-ID: <413770FB.3080206@moongroup.com> Date: Thu, 02 Sep 2004 15:14:03 -0400 From: Chuck Mead Organization: MoonGroup.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID References: <008801c49118$8321a780$6401a8c0@JTHSony> In-Reply-To: <008801c49118$8321a780$6401a8c0@JTHSony> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 J. Trevor Hughes wrote: | I urge the participants on this list to consider the greater good that will | be borne from the wide adoption of Sender ID. Speaking *for* (in whatever capacity I may do so) the OSS community members participating in this process I acknowledge everything you have said and I agree with it, except for this part. My reasoning is fundamental but IMHO if there are impediments at the licensing level which affect Sender ID's adoption in open source software then when will we see this "wide adoption" that you speak of? Thus far the clear answer to that question is never. The redistribution issues caused by the license are the direct root cause of this situation. I am given to understand by communications from many sources that a great deal of work is going on quietly, behind the scenes, trying to work out this issue and I commend Microsoft for their willingness to discuss them... that said we aren't there yet and I do not see how you can believe that Sender-ID will be *widely adopted* given the current license situation. What is the current installed base of the major pieces of mail related open sourse software? I don't know and I dare say that no one truly does but I *DO* believe that it would be more than fair to say that the base is huge and represents a vast majority on today's internet. With regard to your position quoted above I remain wholly unconvinced and would prefer that this body adopt SPF-Classic if the license terms remain unchanged. It does what we need and it is unencumbered with IPR issues so far as anybody knows! For my own part I have already implemented SPF-Classic in production and have been running it for months with nothing but positive effects. - -- csm@moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBN3D7v6Gjsf2pQ0oRAt8ZAJ9NZkZPul7UHW/qjr7ZkqR5HwtHYQCfZKZj UohCL232qFkR7sdYhVA8nLk= =fIdg -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:35: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 PAA00909 for ; Thu, 2 Sep 2004 15:35:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JBvRK018035; Thu, 2 Sep 2004 12:11: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 i82JBv0H018034; Thu, 2 Sep 2004 12:11:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JBvSY018028 for ; Thu, 2 Sep 2004 12:11:57 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 2 Sep 2004 12:12:01 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Sep 2004 12:12:01 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Sep 2004 12:12:00 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 12:11:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 12:12:02 -0700 Message-ID: Thread-Topic: Motion to abandon Sender ID thread-index: AcSQhFAW0QNC6LLaQ9O+t7j6JrVBiwAm5JcQ From: "Harry Katz" To: , "Yakov Shafranovich" , "IETF MARID WG" X-OriginalArrivalTime: 02 Sep 2004 19:11:59.0950 (UTC) FILETIME=[B8DA1EE0:01C49120] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82JBvSY018029 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, September 01, 2004 5:18 PM, mazieres@gmail.com wrote: > On Wed, 01 Sep 2004 19:28:32 -0400, Yakov Shafranovich > wrote: > > > > A few comments. First of all, we do not know whether the IPR claims > > extend to SPF classic or not. > > You are correct that we don't know whether SPF or SPF2 is > covered by pending patent claims from Microsoft. However, we > *do* know that any such claims are *not* covered by > Microsoft's license agreement. Thus, even if we were to > adopt Sender ID as the standard, should Microsoft > subsequently be granted a patent covering the SPF2 record > format, it would no longer be possible to deploy Sender ID > without a new license from Microsoft. > > If, at this point, sender ID were derailed by a patent from > Microsoft over SPF, I think this would pretty clearly > demonstrate bad faith on Microsoft's part. Since we have > been instructed to assume good faith on the part of all > parties, I think this means operating under the assumption that: > > 1) The pending patent rights granted by Microsoft's Sender ID > agreement are sufficient to deploy Sender ID (at least for > the subset of software authors who find the conditions of the > agreement acceptable), and therefore > > 2) Microsoft does not have any pending claims over the SPF > record format. > > So yes, anybody, even Microsoft, might have patent claims > that might prohibit just about any recommendation of the > MARID working group. > But we still have to make progress, and the best we can do is > deal with the most likely scenario, which is that Microsoft > probably has applied for patents, that the patents probably > cover the portions of Sender ID they have offered to > license--namely the pra and or core documents--and finally > that until we have more information, none of the MARID > proposals is any more or less likely to be affected by > third-party patent holders. Our IPR disclosure filed with the IETF and available at http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-marid-core.txt is quite specific and covers the marid-core and marid-pra specs used in combination. That's all. We do not, to the best of my knowledge, have any IPR claims related to either marid-protocol, which describes the SPF2 record format, or marid-submitter. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:42: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 PAA01459 for ; Thu, 2 Sep 2004 15:42: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 i82JKAuj018782; Thu, 2 Sep 2004 12:20:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82JKApO018781; Thu, 2 Sep 2004 12:20:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bellwfep4-srv.bellnexxia.net (bellwfep4-srv.bellnexxia.net [207.236.237.110]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JK9Ri018770 for ; Thu, 2 Sep 2004 12:20:09 -0700 (PDT) (envelope-from jonathan.curtis@bell.ca) Received: from dm3cn8.bell.ca ([206.47.0.145]) by bellwfep4-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040902192007.PWYM19705.bellwfep4-srv.bellnexxia.net@dm3cn8.bell.ca>; Thu, 2 Sep 2004 15:20:07 -0400 Received: from 142.182.89.88dm3cn8.bell.ca with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.0)); Thu, 02 Sep 2004 15:20:01 -0400 X-Server-Uuid: D4A4E604-913A-4A1B-8C07-2866D92AD410 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC908.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 15:20:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 15:20:00 -0400 Message-ID: Thread-Topic: Motion to abandon Sender ID Thread-Index: AcSRDxbV2ANQ+v6OQwivoyWt8PARxwABzkpA From: jonathan.curtis@bell.ca To: kevin.peuhkurinen@hepcoe.com cc: ietf-mxcomp@imc.org X-OriginalArrivalTime: 02 Sep 2004 19:20:01.0120 (UTC) FILETIME=[D7A6D600:01C49121] X-WSS-ID: 6D29ADEB1029138-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82JK9Ri018776 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Kevin, I knew giving my short version humble opinion would raise more questions than answers, not to mention my jet-lagged brain for the typo's. To clarify, the purpose of this forum is not to discuss what software Bell Canada plans to use to implement SenderID. If SenderID receives the blessing of the IETF - we will create a plan to deploy it on Bell's network. If you want to have an offline discussion on how/when we would do this, I'd be more than happy to chat with you. Most of the proposals have had limited testing, until we start to support one standard as an industry - we'll remain in a holding pattern. The holding pattern is a world where we turn our backs on phishing and fraud. Please allow me to rephrase my comment on Microsoft's support of the protocol...Microsoft will help drive the adaptation, they won't act alone. The open source community is one of the corner stones of the Internet and never under estimate the power which they have over issues such as this one. Thanks, Jonathan >-----Original Message----- >From: Kevin Peuhkurinen [mailto:kevin.peuhkurinen@hepcoe.com] >Sent: September 2, 2004 1:06 PM >To: Curtis, Jonathan (P010329) >Cc: ietf-mxcomp@imc.org >Subject: Re: Motion to abandon Sender ID > >Hi Jonathan. Thanks for your input. You say that you are going to >recommend going forward with Sender-ID, even though it has >gone through >no real testing and has not been adopted as a standard yet. Is your >recommendation based solely on the belief that Microsoft's >backing will ensure it's success despite the resistance from >the open source camp or do you feel that it is a superior >technology to, say, SPF? > >Also, I have noticed that the MTAs that Bell uses includes the GPL'ed >Exim and the ASL licensed InterMail. Do you expect to have >to replace >these with Sendmail? > >Thanks, >Kevin > >jonathan.curtis@bell.ca wrote: > >> >> >> >> >>>I am sure that we can come up with multiple conspiracy theories for >>>this. For now, lets stay above the fray and assume that perhaps >>>Microsoft was acting in good faith. >>>Descending into conspiracy theories will not make this any >better, and >>>quite the opposite, will make the entire discussion appear >>>unprofessional. >>> >>>Microsoft knows what the issues are, they are receiving >comments from >>>multiple people and sources. The decision on the license is >upto them. >>>The decision on the standard on the other hand is upto the us. >>> >>>Yakov >>> >>> >>> >>> >> >>IMHO...(short version) >> >>I will recommending that we move forward with the implementation of >>SenderID within Bell Canada (over 35,000 domains) as I believe the >>licensing component has zero to do with the technology and cost of >>implemention. The support that Microsoft will generate over night for >>this solution will drive global adoptation - something this >solution is >>going to need to be successful. >> >> >>Jonathan >> >> >> >> >> >> >> > From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:43:36 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 PAA01590 for ; Thu, 2 Sep 2004 15:43:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JOdaH019539; Thu, 2 Sep 2004 12:24: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 i82JOdcS019538; Thu, 2 Sep 2004 12:24:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JOcUQ019532 for ; Thu, 2 Sep 2004 12:24:39 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i82JY7db007405; Thu, 2 Sep 2004 15:34:07 -0400 From: To: "'Ken'" , "'Michel Bouissou'" , Subject: RE: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 15:22:43 -0400 Message-ID: <002401c49122$39e45f40$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <003401c4911a$66c3c620$2600a8c0@ken> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Ken > Sent: Thursday, September 02, 2004 2:27 PM > To: 'Michel Bouissou'; ietf-mxcomp@imc.org > Subject: RE: Motion to abandon Sender ID > > > > Michel: > > I'd say a more precise interpretation of the extracted sentences would > be: > > "Think about the consequences of our actions. Imagine what the world > will be like following a MARID abandonment of SenderID?" You do not > have to be assimilated, but it seems unrealistic to believe that > SenderID will die. It's a good technical solution for today. So is SPF Classic, but without encumberances. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > > > --KEN > > > > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Michel Bouissou > > Sent: Thursday, September 02, 2004 10:19 AM > > To: ietf-mxcomp@imc.org > > Subject: RE: Motion to abandon Sender ID > > > > > > > > Ken a écrit : > > > > > > I encourage the MARID working group, it's Chairs and the IETF to > > > embrace SenderID and help to promote it as a standard. > > [...] > > > If the MARID chairs abandon SenderID, SenderID will not die. > > > Microsoft will move forward with SenderID at MSN, HotMail, within > > > Outlook and Exchange. SendMail will move forward with > > SenderID. [...] > > > > What I read above is "Resistance is futile. You will be > > assimilated.", or am I mistaken ? > > > > Is it really the role of IETF to "follow what BigCompany > > decides, because they'll do it anyway" ? > > > > -- > > Michel Bouissou OpenPGP ID 0xDDE8AC6E > > > > > > From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:54:22 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 PAA02286 for ; Thu, 2 Sep 2004 15:54:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JXIPN020688; Thu, 2 Sep 2004 12:33: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 i82JXIR6020687; Thu, 2 Sep 2004 12:33:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JXHH6020681 for ; Thu, 2 Sep 2004 12:33:17 -0700 (PDT) (envelope-from madman@myeastside.com) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i82JXLpA026310 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 2 Sep 2004 12:33:21 -0700 Message-ID: <030d01c49123$c0cdc450$3201a8c0@rasta> From: "Harold A'Hole" To: "IETF MARID WG" References: <2AB71632-FD0A-11D8-BA2B-000A95AC5778@isipp.com> Subject: Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 12:31:54 -0700 Organization: http://madman.myeastside.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > This is completely incorrect. This would be true for a breach of > contract case (or also a tort case), but not here. In the case of > someone taking or duplicating something without a license, it's piracy. Pirating a freely available, open source solution that was written by another party and simply had some IP that MSFT may or may not even own would be hard piracy to battle. There's no loss on MSFT's part. Heck, the solution provider could have acquired the license themselves (I'm sure sendmail and other OSS systems and all commercial email providers would have no trouble sending in the free fax). While I don't doubt the actual law as you are suggesting, the key question is what would MSFT really do. Again, since the "license" costs nothing and is given to all parties without bias, the loss of having a license wouldn't impact MSFT at all. > And there are statutory damages available for both piracy and > malactions against intellectual property (in fact the latter is > precisely on what our "register your domain for trademark protection to > sue spoofers" service is founded - showing actual damage in these cases > can be difficult - which is precisely why there are statutory damages > available). Again, the IP argument would hold if they sold the IP. When you give it away freely, it's pretty hard to defend that you were harmed by a user who downloaded sendmail and it contained infringing code. It would be hard enough to prove the the user of the software even knew about it. And the remedy would be a simple fax. Why would MSFT spend legal dollars after they have said they want it to be a freely deployed standard? > Even if they did have to show damages, it would be easily done by the > loss of ability to track who is using their product, and, by extension > then, who may be diluting it by altering it and still distributing it > as a "Microsoft product" (and if not as a "Microsoft product", then we > get to areas of infringement). But this isn't MSFT's product at all. There's no copyright on the code itself (such as within sendmail) MSFT would not own any of that code. And right now, MSFT doesn't even have such a patent, so the license is only to give you permission in case they get the patent. But this pressure is good because I do believe that MSFT will come up with something more open. It's in their best interests and there's really nothing for them to gain since they are giving it away anyway. While smart (and therefore unlikely to be done by a bunch of IP attorneys at a big monopoly), they'd simply request the group/organization/company that DEVELOPS code that uses the IP should acquire the free license and then allow them to distribute it to all users without further obligation. After all, that's how ALL OTHER IP is ever handled when it's integrated inside a computer system. It's rare for the software manufacturer to require each of its users to acquire separate licenses from a variety of vendors that may have known IP within their own code. Harry From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:58: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 PAA02480 for ; Thu, 2 Sep 2004 15:58: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 i82Jb4mt021034; Thu, 2 Sep 2004 12:37: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 i82Jb49Z021033; Thu, 2 Sep 2004 12:37:04 -0700 (PDT) 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 i82Jb24t021011 for ; Thu, 2 Sep 2004 12:37:03 -0700 (PDT) (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 i82Jar06031168 for ; Thu, 2 Sep 2004 19:36:53 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 i82JarJQ002611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Sep 2004 21:36:53 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i82Jarvm002610 for ietf-mxcomp@imc.org; Thu, 2 Sep 2004 21:36:53 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Thu, 2 Sep 2004 21:36:53 +0200 From: Koen Martens To: IETF MARID WG Subject: DEPLOY senderid is not the answer Message-ID: <20040902193653.GE2373@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Although I have more than once made my opinion clear, I am now doing this in a format that will hopefully meat with the last call requirements and as such will be taken into account by the chairs. While I do believe SenderID would be a step in the right direction, I don't think it's an appropriate standard. I say this because I have doubts about the legal repercusions implementation for me would have, as well as doubts about the technical issues. Senderid is not the only proposal, and surely not technologically superior to the other proposals. In particular, I think Unified-SPF is far more promising than senderid. I have serious problems with the legal entanglements that cloud over SenderID. I am an active developer for sendmail patches for one of the popular SPF-Classic and SRS implementations, and I'm looking into other MTA's that do not have an compiled-in spf implementation yet. As an implementor, I presumably would have to sign the license to be able to implement SenderID. I have studied the license, read the discussions on this list and other lists, and still am not exactly sure what my rights are and what microsoft's rights are. What I do know, is that microsoft will use their large funds to squash any serious competition. A particular example of how microsoft does so is a recent ruling by the Dutch court against Lindows Inc (http://zdnet.com.com/2100-1104_2-5151087.html) . Although I am not all in favour of how Lindows (or Linspire as it is now called) does business, I'm quite appauled that microsoft has succesfully blocked the sale of linspire in The Netherlands. This is only one of the incidents which make me doubt that microsoft will not mis-use their licenses and patents for the same purpose: squashing competition. Having a party sign the license might give microsoft the power to revoke the license if competition is becoming more than a very minor annoyance. The anology of 'signing a pact with the devil' seems appropriate enough to me: you get the immediate benefit of being able to implement senderid, but you don't know what bad things hang over your head until it's time for microsoft to 'cash in on the pact'. It is already common knowledge that microsoft's initial reaction to spf was to sue it to a silent death. Furthermore, microsoft is even now claiming sender-id as their own invention, not acknowledging the IETF, not acknowledging Meng Weng Wong. Eg, http://www.infoworld.com/article/04/08/31/HNspammerstudy_1.html claims that 'New technology for identifying the sender of e-mail messages has not been widely adopted despite backing from software giant Microsoft Corp.'. It is to me obvious this refers to SPF, which is being deployed despite microsoft's attempts to frustrate development. I can get more url's by just browsing back in the archive of the spf-discuss list, where skepticism about microsoft's intentions is not considered an 'emotional reaction'. Let the facts speak for themselves. I have doubts about all of this, however if I have to find a lawyer to clear this up for me, the fun is off. I will not be able to develop for senderid. If that is the case, I will also not publish senderid records on my own domains or the domains of customers and neither will I install software that checks senderid records. Note that this is not a rant against microsoft, this is a enumeration of a number of facts which have helped form my opinion about microsoft. It seems foolish to ignore these (and all the other) facts, even though we've been promised all this past behaviour is not representative of how microsoft will act in regard to senderid. I have seen _no_ evidence that microsoft will not continue the trend it has been setting for years. Furthermore, the fact that senderid does not protect me against 2821 forgery is also a barrier to me deploying the standard. Now there are two roads that could be taken from that observation: senderid could be extended by 2821 checking, or a 2821 checking proposal can be extended to also check 2822 entities. The former is, for reasons stated above, not my preffered option. The latter, however, is promising. SPF-Classic is already widely deployed, and extension of SPF-Classic to 2822 entities by ways of Unified-SPF seems very promising. I truly hope that 1. The IETF/MARID will come to it's senses and consider the overwhelming amount of statements that senderid is undeployable except by the fortune-500 companies, or at the least has a serious problem with development and distribution outside the world of commercial, closed-source software. 2. Development of SPF-Unified will be continued by Meng Weng Wong and Mark Lentczner, and will be picked up by the ever-growing spf community. I for one, considering myself a member of that community, will put my resources into making Unified SPF a reality if senderid continues to be surrounded by all the fog. Koen Martens -- 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/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 15:58: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 PAA02527 for ; Thu, 2 Sep 2004 15:58:32 -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 i82JdwQX021222; Thu, 2 Sep 2004 12:39: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 i82JdvEs021221; Thu, 2 Sep 2004 12:39:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp-out-1002.amazon.com (smtp-out-1002.amazon.com [207.171.160.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82Jdvdm021211 for ; Thu, 2 Sep 2004 12:39:57 -0700 (PDT) (envelope-from jonagard@amazon.com) Received: from smtp-in-1003.vdc.amazon.com by smtp-out-1002.amazon.com with ESMTP (peer crosscheck: smtp-in-1003.vdc.amazon.com) X-Amazon-Corporate-Relay: smtp-out-1002.vdc.amazon.com X-AMAZON-TRACK: ietf-mxcomp@imc.org Received: from ex-gate-02.ant.amazon.com by smtp-in-1003.vdc.amazon.com with ESMTP (crosscheck: app-good-01.ant.amazon.com [10.16.148.40] (may be forged)) id i82JdtpC023681; Thu, 2 Sep 2004 19:39:55 GMT Received: from jonagard.desktop.amazon.com ([10.21.12.165]) by ex-gate-02.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Sep 2004 12:40:18 -0700 From: Jonathan Gardner Organization: Amazon To: jonathan.curtis@bell.ca Subject: Re: Motion to abandon Sender ID Date: Thu, 2 Sep 2004 12:39:53 -0700 User-Agent: KMail/1.6 Cc: ietf-mxcomp@imc.org References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200409021239.54719.jonagard@amazon.com> X-OriginalArrivalTime: 02 Sep 2004 19:40:18.0143 (UTC) FILETIME=[AD0DCEF0:01C49124] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82Jdvdm021216 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 02 September 2004 08:58 am, jonathan.curtis@bell.ca wrote: > > I will recommending that we move forward with the implementation of > SenderID within Bell Canada (over 35,000 domains) as I believe the > licensing component has zero to do with the technology and cost of > implemention. The support that Microsoft will generate over night for > this solution will drive global adoptation - something this solution is > going to need to be successful. > Jonathan, I believe that Bell can successfully implement Sender ID, and sign whatever agreements need to be signed with Microsoft ot license their patent (pending, yada yada yada). However, the problem isn't with individual email service providers who don't use open source software to run their email services. It is with those people who use major Linux and BSD distributions to run their email services. Take the example of a small company that hosts their own email services in house. Their email server is installed with a standard Linux or BSD distribution. For the sake of argument, let's take my situation at my home business. I run Red Hat Fedora Core 1 on my server. While I am able to download, compile, and install additional software, I prefer not to on my email server. The reason is that I need the updates that flow through the channels. I need the testing and the configuration that others have put into the distribution. It's also much easier to use the software management system (in this case, RPM and Yum) that comes with the distribution. Therefore, my policy is not to install anything that is not part of the standard distribution. In fact, I favor sendmail over the other MTA servers because it is the default and has a larger base, and it thus gets more testing and more configuration documentation is available on the internet. I probably won't be able to maintain a Sender ID compliant MTA. At best, I would have to download additional RPMs from a licensed distributor. That's not a big problem. The big problem comes with whether or not there is a large enough number of people doing the same thing. I need to rely on their testing and their configuration experience in setting up my experience. Since this software will have to be downloaded seperately, it will never get a large installed base among Fedora users. But also consider the extra time it takes to locate the package and find the right one, or the one with the latest updates. That can be a problem, and it will at the very least take some time, and at worst, take a lot of time. That's time I don't have to spend right now. I admit that I am using the SPF milter software available in RPM form. However, I haven't been able to upgrade recently because compatibility with my fedora core installation has become an issue. So I haven't upgraded for some time. Unlike Sender ID, SPF stands a very good chance of becoming part of the distribution itself, and perhaps part of the default MTA installation. Because it isn't right now, that is harming the adoption of SPF being incorporated into the MTAs on Fedora. If the Sender ID technology could be incorporated into the Fedora distribution, it will get a much larger user, and thus, testing base. More documentation will be available. Also, if it is part of the default MTA installation, more people would use it, and it would become the de facto standard for Fedora users. The same is true for any other distribution. - -- Jonathan M. Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBN3cJBFeYcclU5Q0RAs/0AJ4r6ExOL4TZ3gFMVI6BjmTc36gPTwCguVcW XIX6fNVnHhACdd/9Ealb0Lg= =lJWh -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:15: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 QAA03566 for ; Thu, 2 Sep 2004 16:15: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 i82JsQBK022332; Thu, 2 Sep 2004 12:54:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82JsQSF022331; Thu, 2 Sep 2004 12:54:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JsQ5b022324 for ; Thu, 2 Sep 2004 12:54:26 -0700 (PDT) (envelope-from csm@moongroup.com) Received: from [192.168.0.10] (rdu74-170-067.nc.rr.com [24.74.170.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1.moongroup.com (Postfix) with ESMTP id 54A1F1182403E for ; Thu, 2 Sep 2004 15:54:30 -0400 (EDT) Message-ID: <41377A75.8030902@moongroup.com> Date: Thu, 02 Sep 2004 15:54:29 -0400 From: Chuck Mead Organization: MoonGroup.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Motion to abandon Sender ID References: In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harry Katz wrote: | Our IPR disclosure filed with the IETF and available at | http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-marid-core.txt is | quite specific and covers the marid-core and marid-pra specs used in | combination. That's all. We do not, to the best of my knowledge, have | any IPR claims related to either marid-protocol, which describes the | SPF2 record format, or marid-submitter. Harry, ~ Thank you veeeeeeeeeeeeeeerrrrrry much for this! This is the clearest statement I have seen yet about what's covered in the Patent App and a clear signal to me that I've been right about what I've been saying about SPF. THANK YOU! - -- csm@moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBN3p1v6Gjsf2pQ0oRAjbyAKCQs5rg4a49CLnFx4oIenkoiTeiswCfV2fS swKlGAGDQOJG6Pal55JHLAw= =DPfL -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:15: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 QAA03584 for ; Thu, 2 Sep 2004 16:15:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JrcMa022284; Thu, 2 Sep 2004 12:53: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 i82JrbG4022283; Thu, 2 Sep 2004 12:53:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JrbNg022269 for ; Thu, 2 Sep 2004 12:53:37 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-096-691.area3.spcsdns.net ([68.245.120.60]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2xcc-0000ql-DX; Thu, 02 Sep 2004 15:51:51 -0400 Message-ID: <41377A35.6070003@solidmatrix.com> Date: Thu, 02 Sep 2004 15:53:25 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Harry Katz CC: mazieres@gmail.com, IETF MARID WG Subject: Re: Motion to abandon Sender ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Harry Katz wrote: > Our IPR disclosure filed with the IETF and available at > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-marid-core.txt is > quite specific and covers the marid-core and marid-pra specs used in > combination. That's all. We do not, to the best of my knowledge, have > any IPR claims related to either marid-protocol, which describes the > SPF2 record format, or marid-submitter. > Your IPR disclosure does not stop IPR claims coming later on. What I am wondering if whether your lawyers can provide a written statement stating with absolute certainty that no other drafts are affected. I contacted your legal department back in March of 2004 on this. I still did not receive a "no" on this. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:16: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 QAA03769 for ; Thu, 2 Sep 2004 16:16: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 i82JpHLv022075; Thu, 2 Sep 2004 12:51:17 -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 i82JpH9D022074; Thu, 2 Sep 2004 12:51:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JpFdW022068 for ; Thu, 2 Sep 2004 12:51:16 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i82JpFMU012926 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Sep 2004 12:51:15 -0700 Date: Thu, 2 Sep 2004 12:51:15 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Kevin Peuhkurinen cc: ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID In-Reply-To: <41376D09.1000400@hepcoe.com> Message-ID: References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376D09.1000400@hepcoe.com> 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, 2 Sep 2004, Kevin Peuhkurinen wrote: > This is the most troubling issue that I forsee, I agree. However, I have > to wonder why everyone who is pro-Sender-ID doesn't feel it necessary to > try to pressure Microsoft into adopting SPF instead. To my mind, there > are ZERO hinderences to Microsoft adopting SPF, but there are plenty of > hinderences for most everyone else to adopt the encumbered Sender-ID. ^Microsoft^the Internet at large SPF and Sender ID solve different problems. Sender ID authenticates the message, SPF authenticates the channel. While channel authentication is useful for some purposes, message-based authentication of something the end-user can see is much more desirable to many senders and recipients to control spoofing of user-visible headers. In that regards, the Sender ID technology presents the best IP-based message authentication I have seen, and can provide an immediate benefit to a large majority of message paths. In the long run, a crypto-based solution for message authentication is of course the best solution, and we are all working on those as well. When we start discussing channel authentication then we should compare SPF and CSV, but SPF doesn't solve the immediate problems of header spoofing that I want to address right now. -Rand From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:19:09 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 QAA04205 for ; Thu, 2 Sep 2004 16: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 i82JvF7S022622; Thu, 2 Sep 2004 12:57:15 -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 i82JvFcd022621; Thu, 2 Sep 2004 12:57:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82JvEU0022608 for ; Thu, 2 Sep 2004 12:57:14 -0700 (PDT) (envelope-from roy+dated+1096747029.bdd354@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i82Jvase085345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Sep 2004 19:57:42 GMT (envelope-from roy+dated+1096747029.bdd354@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i82Jv9qQ039741 for ; Thu, 2 Sep 2004 20:57:09 +0100 (BST) (envelope-from roy+dated+1096747029.bdd354@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i82Jv9mE039740 for ietf-mxcomp@imc.org; Thu, 2 Sep 2004 20:57:09 +0100 (BST) (envelope-from roy+dated+1096747029.bdd354@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 02 Sep 2004 20:57:08 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.31508.283052.57253@giles.gnomon.org.uk> Date: Thu, 2 Sep 2004 20:57:08 +0100 To: "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: The SSL license offer. In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Hallam-Baker," == Hallam-Baker, Phillip writes: Hallam-Baker,> The patent is held by Netscape (AOL) and covers Hallam-Baker,> transport layer security. The terms are Hallam-Baker,> considerably more vague than in the SenderID Hallam-Baker,> case. Netscape does not promise to offer a Hallam-Baker,> sublicensable patent or even to offer reasonable or Hallam-Baker,> non discriminatory terms. Hmm, I guess we won't be seeing STARTTLS support in OSS MTAs any time soon then... :-) -roy From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:20:54 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 QAA04447 for ; Thu, 2 Sep 2004 16:20: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 i82K1d0f023488; Thu, 2 Sep 2004 13:01: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 i82K1dD5023487; Thu, 2 Sep 2004 13:01:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82K1ctJ023451 for ; Thu, 2 Sep 2004 13:01:38 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (DEPLOY) In Support of Sender ID Date: Thu, 2 Sep 2004 15:01:42 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEB944@cliff.bai.org> Thread-Topic: (DEPLOY) In Support of Sender ID thread-index: AcSRHzD+ObMGLPrhTRKg90SFQIEMPwABzahg From: "Ryan Malayter" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82K1ctJ023482 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Kevin Peuhkurinen] >To my mind, there are ZERO hinderences to Microsoft >adopting SPF, but there are plenty of hinderences >for most everyone else to adopt the encumbered >Sender-ID. SPFv1 does not address email header forging at all. So SPFv1 does very little to prevent forging of the "from" addresses seen by the user in 99% of MUAs. SPFv1 therefore does very little to prevent phishing scams. This is why Microsoft came up with CallerID for email, and why Meng and MS decided to merge the best parts of SPF and Caller ID into SenderID approaches. So yes, there are very big hinderances to MS and everyone else adopting SPF classic - it doesn't solve a big part of the email forging problem. Even "Unified SPF" still defines the PRA algorithm for use in verifying mail headers, and therefor is also incumbered by the Microsoft IP. -- Ryan From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:20:55 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 QAA04450 for ; Thu, 2 Sep 2004 16:20:54 -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 i82JvrMa022695; Thu, 2 Sep 2004 12:57: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 i82JvrF3022694; Thu, 2 Sep 2004 12:57:53 -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 i82Jvq6E022684 for ; Thu, 2 Sep 2004 12:57:52 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.254.82] (host66.209-113-184.oem.net [209.113.184.66]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i82Juoas028857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Sep 2004 15:56:55 -0400 Subject: RE: The SSL license offer. From: Paul Iadonisi To: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1094155071.3335.45.camel@tuxtop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 02 Sep 2004 15:57:51 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A close look at the openssl package bundled with Fedora Core 2 from Red Hat reveals that the patents in question appear to cover MDC-2, IDEA, RC5, and EC. All of these are disabled (i.e.: not even built) in the Fedora Core 2 version of openssl. There is a even a short comment section at the top of the 'hobble-openssl' script with some patent numbers and expiration dates. So the patent question is answered to my satisfaction regarding SSL in at least Fedora Core 2. I don't know what other FOSS operating systems do, but if they do what some are doing with MP3 then they are risking litigation by the patent holders. That is their choice. Why anyone would hold that choice up as an example of what people think is okay is a stretch. Nor do I think it is advisable for this working group to force FOSS developers into the position of making this choice. Those that make that choice with respect to MP3 and SSL may be just taking a calculated risk. No one knows until someone asks. There is also the question of GPL compatibility and SSL. I see no reason why SSL as a standard would not be, provided that the patented algorithms are not implemented. It is apparent from the Fedora Core 2 package that they are not needed, anyhow. But when it comes to the licensing of OpenSSL and the linking of GPLed applications with it, the FAQ included with OpenSSL states what I expected it would: ... [LEGAL] Legal questions ... * Can I use OpenSSL with GPL software? ... * Can I use OpenSSL with GPL software? On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using libraries that are part of the normal operating system distribution). On other systems, the situation is less clear. Some GPL software copyright holders claim that you infringe on their rights if you use OpenSSL with their software on operating systems that don't normally include OpenSSL. If you develop open source software that uses OpenSSL, you may find it useful to choose an other license than the GPL, or state explicitly that "This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed." If you are using GPL software developed by others, you may want to ask the copyright holder for permission to use their software with OpenSSL. ... Hence the motivation for GNUTLS. Between the patented algorithms being disabled in OpenSSL (at least on Fedora Core 2) and the development of GNUTLS, I'd say the FOSS community is pretty proactive in solving problems like this when they are known. Which is why many are opposed to this Sender-ID patent license. We don't want another one that we need to work around, particular one that may not be possible to work around. -- -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 Sep 2 16:29:24 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 QAA05604 for ; Thu, 2 Sep 2004 16:29:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82K76qZ023925; Thu, 2 Sep 2004 13:07: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 i82K76Jr023924; Thu, 2 Sep 2004 13:07:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82K76be023915 for ; Thu, 2 Sep 2004 13:07:06 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so67142rnk for ; Thu, 02 Sep 2004 13:07:02 -0700 (PDT) Received: by 10.38.164.76 with SMTP id m76mr3028745rne; Thu, 02 Sep 2004 13:07:02 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Thu, 2 Sep 2004 13:07:02 -0700 (PDT) Message-ID: <94df60cf04090213075c5f93cf@mail.gmail.com> Date: Thu, 2 Sep 2004 16:07:02 -0400 From: Reply-To: To: "Harold A'Hole" Subject: Re: Motion to abandon Sender ID Cc: IETF MARID WG In-Reply-To: <030d01c49123$c0cdc450$3201a8c0@rasta> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2AB71632-FD0A-11D8-BA2B-000A95AC5778@isipp.com> <030d01c49123$c0cdc450$3201a8c0@rasta> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2 Sep 2004 12:31:54 -0700, Harold A'Hole wrote: > > Pirating a freely available, open source solution that was written by > another party and simply had some IP that MSFT may or may not even own would > be hard piracy to battle. There's no loss on MSFT's part. Heck, the > solution provider could have acquired the license themselves (I'm sure > sendmail and other OSS systems and all commercial email providers would have > no trouble sending in the free fax). Do you have much experience with patent cases? I don't think you need to show actual monetary damages either to recover statutory damages, or to get an injunction against further infringing activities. Also, as I've made clear in previous messages, sending in the "free fax" is not so easy if you work for a university. That said, since several people are so sure Microsoft would never pursue this kind of case, I'm wondering if anyone out there would be interested in indemnifying me against patent suits by Microsoft for distributing a Sender-ID-compliant SMTP server? In exchange for signing a legal agreement, I'll be glad to give you an unlimited, non-exclusive, royalty free, and even sublicensable right to use, copy and distribute a very cool SMTP server. Before you indemnify me, though, you might want to take some history into account. Remember that Microsoft didn't use to be a very litigious company at all. Then one day they decided it was in their strategic interest to enforce their patent rights on video codecs. Who knows what's going to happen in the next 20 years? Is it really so hard to imagine a scenario in which, say, a popular open-source mail server uses a small but highly effective extension of Sender ID to thwart spam, and Microsoft believes distribution of this software is not in their strategic interest? (Remember, the license only allows strict compliance with the standard.) From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:30: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 QAA05755 for ; Thu, 2 Sep 2004 16:30: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 i82KATCB024139; Thu, 2 Sep 2004 13:10:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82KAT1F024138; Thu, 2 Sep 2004 13:10:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82KARn3024131 for ; Thu, 2 Sep 2004 13:10:28 -0700 (PDT) (envelope-from ogud@ogud.com) Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i82K927k010584; Thu, 2 Sep 2004 16:09:02 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040901094534.02cf2e98@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Thu, 02 Sep 2004 16:08:53 -0400 To: "Jim Lyon" , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= , "IETF MARID WG" , "Mark Lentczner" From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: RE: TECH-ERROR: DNS Record Types In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Scanned-By: MIMEDefang 2.44 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82KASn3024132 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 19:50 31/08/2004, Jim Lyon wrote: > On Saturday, August 28, 2004 at 7:56 PM, Ólafur Guðmundsson wrote > (about DNS record types): > > The fundamental difference between your position and mine is > > you: want everyone to be compliant at all times. > > me: Specify clearly fully compliant state and tolerate non compliance > > during phase-in. > >This is the crux of the disagreement. However, there are at least two >relevant phase-in periods: > >1. In the first phase-in, mail senders begin to publish records, and >those mail senders who need to begin to add additional headers. > >2. In the second phase-in (more relevant to this discussion), people with >"challenged" DNS implementations begin to publish and/or query for the new >record type. > >The problem is that the first phase-in lasts months, but the second >phase-in lasts many years. (As I mentioned previously, it's at least 10 >years before the number of installed Microsoft OS's with lousy DNS >implementations becomes small enough to ignore.) > >So, given that Ólafur's "short term" isn't in fact short, my point still >stands. Require (MUST) TXT records and encourage (SHOULD) new record types. I disagree: we are designing a protocol for use on the Internet, as explained to your colleague before on this mailing list in: http://www.imc.org/ietf-mxcomp/mail-archive/msg01853.html your set up its classified as "not being on the Internet" as you are sitting behind a broken middle box. IMHO we need to document protocols in such a way that it is clear the middle box is the BROKEN component. That is what the current text does. A number of working groups have faced a similar issues before, whether to include constants placed by exiting limited functionality middle boxes in the protocol or to force updates. In every case I have seen so far the WG's have gone with "update or no play". There are number of other possible solutions then just upgrading all of your infrastructure. Those include: + placing a modern DNS recursive caching server inside your firewall and query it instead off what you're querying now. (I'm aware of at least 5 different ones that pass unknown types that are available today including one from Microsoft). + another alternative it is to use a more modern Windows DNS library than you are using today. In short there are other ways to quickly overcome your current bad design. If fighting SPAM is important to this particular organization we have to assume that they are willing to make changes to take advantage of SPF records sooner than in 10 years. Its counterproductive to keep harping on the same points that had been rebutted number of times both on the mailing list and in the working group meeting in San Diego. Unless other members off the working group come forward and say they had the same problem there is no need to tune a protocol around somebody's bad implementation choice! >Ólafur also worries that if we go this route, there will never be a time >when publishing only an SPF2 record becomes acceptable. This isn't >necessarily so. There are two possible futures: > >a. "Challenged" DNS implementations get fixed over time, and more and more >people come to query/use SPF2 records. Eventually, a new standards action >requires the new record type and deprecates use of TXT records. > >b. "Challenged" DNS implementations continue to be plentiful over >time. In this case, we'd sure look stupid of we followed Ólafur's approach. Below (in PS) is a simple script that uses nslookup to check if your host can get unknown types from my DNS server. Just open Command Prompt window and after typing "nslookup" paste this text, if the output scrolls over many pages, you get unknown types. >Assuming that we go with MUST for TXT records now, I submit that a >built-in opportunity to revisit the issue is when SenderId is considered >for advancement from Proposed Standard to Draft Standard or Internet >Standard. Should upgrades to DNS servers proceed faster than the >standards track, it's not hard to convene a working group to reconsider >this issue. process issue: changing the SHOULD and MUST around will likely require that the documents be recycled at proposed standard. Olafur PS: Commands for nslookup to check if a query will return UNKNOWN types. ----cut here-- set debug set type=txt set class=chaos version.bind. set type=any set class=in set domain=test.ogud.com. ssh unknown --- end of cut --- First this script attempts to get version information from server. Then it queries for all types at two names, one contains SSHFP RR that was defined this year (not yet an RFC) but type code allocated. The second name is contains lots of records of different types and results in a 782 byte answer. If the only RR you see is the TXT Record then you are behind one of the evil bad Middle boxes. Feel free to send me the results of running this nscommand or the corresponding Unix shell script at this link: http://stora.ogud.com/DNSSEC/unkown/unknown-types-script.sh Here is the Nslookup command sequence: http://stora.ogud.com/DNSSEC/unkown/nslookup.cmds From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:47:54 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 QAA09124 for ; Thu, 2 Sep 2004 16:47: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 i82KSk5N025684; Thu, 2 Sep 2004 13:28: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 i82KSk4I025683; Thu, 2 Sep 2004 13:28:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82KSjqM025667 for ; Thu, 2 Sep 2004 13:28:45 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so304270rnk for ; Thu, 02 Sep 2004 13:28:46 -0700 (PDT) Received: by 10.38.11.79 with SMTP id 79mr120095rnk; Thu, 02 Sep 2004 13:28:46 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Thu, 2 Sep 2004 13:28:46 -0700 (PDT) Message-ID: <94df60cf04090213282ae5c57b@mail.gmail.com> Date: Thu, 2 Sep 2004 16:28:46 -0400 From: Reply-To: To: Rand Wacker Subject: Re: (DEPLOY) In Support of Sender ID Cc: Kevin Peuhkurinen , ietf-mxcomp@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376D09.1000400@hepcoe.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2 Sep 2004 12:51:15 -0700 (PDT), Rand Wacker wrote: > > SPF and Sender ID solve different problems. Sender ID authenticates the > message, SPF authenticates the channel. While channel authentication is > useful for some purposes, message-based authentication of something the > end-user can see is much more desirable to many senders and recipients to > control spoofing of user-visible headers. I agree that SPF and Sender ID solve slightly different problems, but saying one authenticates the channel and the other the message is a bit of a simplification. (If anything, domain keys actually authenticates the message.) It's not any easier for the end-user to see one than the other. In one case, the MUA has to extract the envelope sender from the SPF-Received header, in the other case, the MUA has to select one of the From, Sender, Resent-From, or Resent-Sender headers to highlight. Patent claims aside, neither seems particularly hard to implement in an MUA. But that issue is somewhat irrelevant, because last I checked the M in MARID stands for MTA and the charter says, "The primary current use case for this facility is to allow recipient MTAs to confirm that peer MTAs' actions are authorized by specific domains or networks." Sure, if the MTA can determine this, it can and should let the end user know, but the main point here is not end users. What I'd really like to hear about is an actual usage scenario in which a message author (say a bank sending out statements) actually requires Sender ID, and could not get the same effect with SPF-classic. Basically there are outsourcing scenarios where in Sender ID you have to publish a TXT record in DNS, and with SPF-classic you either have to publish a CNAME or a TXT and MX record. But so what? The mechanisms are different, but the effects are the same. David From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:48:34 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 QAA09335 for ; Thu, 2 Sep 2004 16:48:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82KS0xp025632; Thu, 2 Sep 2004 13:28:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82KS0sD025631; Thu, 2 Sep 2004 13:28:00 -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 i82KS0sN025622 for ; Thu, 2 Sep 2004 13:28:00 -0700 (PDT) (envelope-from jcouzens@6o4.ca) Received: (qmail 25582 invoked by uid 1006); 2 Sep 2004 20:28:02 -0000 Received: from unknown (HELO ?192.168.160.9?) (24.207.1.85) by data.6o4.ca with SMTP; 2 Sep 2004 20:28:02 -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: Motion to abandon Sender ID From: James Couzens Reply-To: jcouzens@6o4.ca To: ietf-mxcomp@imc.org In-Reply-To: <94df60cf04090213075c5f93cf@mail.gmail.com> References: <2AB71632-FD0A-11D8-BA2B-000A95AC5778@isipp.com> <030d01c49123$c0cdc450$3201a8c0@rasta> <94df60cf04090213075c5f93cf@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-L1xKp2Hn3TCEQp0dMcQR" Message-Id: <1094156915.7516.30.camel@antitrust.6o4.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 02 Sep 2004 13:28:35 -0700 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-L1xKp2Hn3TCEQp0dMcQR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-09-02 at 13:07, mazieres@gmail.com wrote: > Before you indemnify me, though, you might want to take some history > into account. Remember that Microsoft didn't use to be a very > litigious company at all. Then one day they decided it was in their > strategic interest to enforce their patent rights on video codecs.=20 > Who knows what's going to happen in the next 20 years? Is it really > so hard to imagine a scenario in which, say, a popular open-source > mail server uses a small but highly effective extension of Sender ID > to thwart spam, and Microsoft believes distribution of this software > is not in their strategic interest? (Remember, the license only > allows strict compliance with the standard.) *cough* FAT32 and flash disks *cough* 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 --=-L1xKp2Hn3TCEQp0dMcQR 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) iD8DBQBBN4JzMagRinp8fc8RAt0FAKCnMs2jU6m4Kka1F5l/u81a4AxPpgCgrTmq puTmijNXr1BtuXu6OpC+L1I= =pFXw -----END PGP SIGNATURE----- --=-L1xKp2Hn3TCEQp0dMcQR-- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:49: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 QAA09512 for ; Thu, 2 Sep 2004 16:49: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 i82KUqWQ025886; Thu, 2 Sep 2004 13:30: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 i82KUqRj025885; Thu, 2 Sep 2004 13:30:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vodka.at-once.com (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82KUpPj025872 for ; Thu, 2 Sep 2004 13:30:51 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vodka.at-once.com (8.12.11/8.12.11) with ESMTP id i82KUoTI019413; Thu, 2 Sep 2004 13:30:50 -0700 Subject: Re: (DEPLOY) In Support of Sender ID From: Ryan Ordway To: Yakov Shafranovich Cc: "J. Trevor Hughes" , ietf-mxcomp@imc.org In-Reply-To: <41376FB0.1090607@solidmatrix.com> References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376FB0.1090607@solidmatrix.com> Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1094157049.17694.44.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 02 Sep 2004 13:30: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 Thu, 2004-09-02 at 12:08, Yakov Shafranovich wrote: > J. Trevor Hughes wrote: > > > > I do want to raise one issue that has not been discussed on MARID yet > > (at least as far as I have seen). The eyes of the world are upon > > industry at this time and great expectations have been created for > > authenticated email technologies to emerge quickly and broadly. The > > Federal Trade Commission recently issued a report to Congress and > > strongly advocated for authenticated email solutions. They will be > > holding a workshop on the topic later this fall. Failure to move > > forward with Sender ID at this juncture will likely put us back at least > > 6 months and perhaps more. Such a delay will only invite interference > > from legislators and regulators. I certainly do not think that is in > > the best interests on anyone! ... > It might come hard to believe to the commercial world, but the role FOSS > software plays in the Internet architechture is larger than any other > area today. Majority of the architechture is built on FOSS such as BIND, > Apache, sendmail, etc. You cannot simply ignore it and hope it will go > away. Both commercial and FOSS sides *must* be willing to negotiate on > this issue, and work on this together. Otherwise, even if this standard > is approved, and not deployed, it would be useless. And then the > senators will jump in anyway. Well said. I would also pose the question, what percentage of the arguable majority of deployed SMTP servers that run FOSS MTA software do so as a direct result of said FOSS MTA being distributed with the FOSS Operating System that they run on (some form of GNU/Linux, *BSD, etc.)? In the US it's an election year and I'm sure that there are legislators on both sides of the aisle that would love to add "Spam Slayer" to their political resumes. You can rest assured that there will be interference from legislators irregardless of SenderID's being adopted or not. It might explain the apparent hurry to push this standard, ANY standard, through despite the IPR issues. Ryan -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:57: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 QAA10653 for ; Thu, 2 Sep 2004 16:57: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 i82KUOBj025839; Thu, 2 Sep 2004 13:30: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 i82KUOpk025838; Thu, 2 Sep 2004 13:30:24 -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 i82KUO7X025832 for ; Thu, 2 Sep 2004 13:30:24 -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 3F9C3414C4; Thu, 2 Sep 2004 13:30:29 -0700 (PDT) Subject: Re: (DEPLOY) In Support of Sender ID From: Douglas Otis To: Rand Wacker Cc: Kevin Peuhkurinen , MARID In-Reply-To: References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376D09.1000400@hepcoe.com> Content-Type: text/plain Message-Id: <1094157027.19890.91.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 02 Sep 2004 13:30:27 -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-09-02 at 12:51, Rand Wacker wrote: > On Thu, 2 Sep 2004, Kevin Peuhkurinen wrote: > > > This is the most troubling issue that I forsee, I agree. However, I have > > to wonder why everyone who is pro-Sender-ID doesn't feel it necessary to > > try to pressure Microsoft into adopting SPF instead. To my mind, there > > are ZERO hinderences to Microsoft adopting SPF, but there are plenty of > > hinderences for most everyone else to adopt the encumbered Sender-ID. > > ^Microsoft^the Internet at large > > SPF and Sender ID solve different problems. Sender ID authenticates the > message, SPF authenticates the channel. While channel authentication is > useful for some purposes, message-based authentication of something the > end-user can see is much more desirable to many senders and recipients to > control spoofing of user-visible headers. > > In that regards, the Sender ID technology presents the best IP-based > message authentication I have seen, and can provide an immediate benefit > to a large majority of message paths. In the long run, a crypto-based > solution for message authentication is of course the best solution, and we > are all working on those as well. > > When we start discussing channel authentication then we should compare SPF > and CSV, but SPF doesn't solve the immediate problems of header spoofing > that I want to address right now. I have introduced the MPR draft to illustrate how to arrive at either the SPF level of RFC2821 MAIL FROM as well as the RFC2822 From building upon the CSV standard. This also overcomes problems of the indeterminate DNS overhead, replication of DNS addresses, "open" lists creating spam exploits, and removes an ability to hide listing by way of macros. One fundamental difference is the treatment of reputation as a separate function from that of mailbox domain to outbound server association. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 16:57: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 QAA10705 for ; Thu, 2 Sep 2004 16:57:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82KaOBd026224; Thu, 2 Sep 2004 13:36: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 i82KaOpL026223; Thu, 2 Sep 2004 13:36:24 -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 i82KaO8m026213 for ; Thu, 2 Sep 2004 13:36:24 -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 4EBAA414C8; Thu, 2 Sep 2004 13:36:29 -0700 (PDT) Subject: RE: (DEPLOY) In Support of Sender ID From: Douglas Otis To: Ryan Malayter Cc: MARID , kevin.peuhkurinen@HEPCOE.com In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB944@cliff.bai.org> References: <792DE28E91F6EA42B4663AE761C41C2A02CEB944@cliff.bai.org> Content-Type: text/plain Message-Id: <1094157387.19890.97.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 02 Sep 2004 13:36:27 -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-09-02 at 13:01, Ryan Malayter wrote: > [Kevin Peuhkurinen] > >To my mind, there are ZERO hinderences to Microsoft > >adopting SPF, but there are plenty of hinderences > >for most everyone else to adopt the encumbered > >Sender-ID. > > SPFv1 does not address email header forging at all. So SPFv1 does very > little to prevent forging of the "from" addresses seen by the user in > 99% of MUAs. SPFv1 therefore does very little to prevent phishing scams. > This is why Microsoft came up with CallerID for email, and why Meng and > MS decided to merge the best parts of SPF and Caller ID into SenderID > approaches. > > So yes, there are very big hinderances to MS and everyone else adopting > SPF classic - it doesn't solve a big part of the email forging problem. > > Even "Unified SPF" still defines the PRA algorithm for use in verifying > mail headers, and therefor is also incumbered by the Microsoft IP. I have introduced the MPR draft to illustrate how to arrive at either the SPF level of RFC2821 MAIL FROM as well as the RFC2822 From building upon the CSV standard to achieve the same goals as both SPF and Sender-ID. This does not use the PRA algorithm, as it expects From restriction to be made for exceptional uses. This also overcomes problems of the indeterminate and potentially very high DNS overhead, replication of DNS addresses, "open" lists creating spam exploits, dangers of harm by misapplication of reputation, and removes an ability to hide listing by way of macros. One fundamental difference is the treatment of reputation as a separate function from that of mailbox domain to outbound server association. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 17:27: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 RAA13068 for ; Thu, 2 Sep 2004 17:27: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 i82L5oID028477; Thu, 2 Sep 2004 14:05:50 -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 i82L5ouu028476; Thu, 2 Sep 2004 14:05:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82L5nVc028470 for ; Thu, 2 Sep 2004 14:05:49 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i82L5Ls1029073 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Sep 2004 14:05:21 -0700 Date: Thu, 2 Sep 2004 14:05:20 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: terry@ashtonwoodshomes.com cc: "'Ken'" , "'Michel Bouissou'" , ietf-mxcomp@imc.org Subject: RE: Motion to abandon Sender ID In-Reply-To: <002401c49122$39e45f40$2766f30a@development.greatgulfhomes.com> Message-ID: References: <002401c49122$39e45f40$2766f30a@development.greatgulfhomes.com> 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, 2 Sep 2004 terry@ashtonwoodshomes.com wrote: > > [If the IETF were to abandon it] > > SenderID will die. It's a good technical solution for today. > > So is SPF Classic, but without encumberances. And which solves a different problem. -Rand From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 17:29: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 RAA13234 for ; Thu, 2 Sep 2004 17:29: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 i82L9CIZ028780; Thu, 2 Sep 2004 14:09:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82L9CnH028779; Thu, 2 Sep 2004 14:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.ironport.com (a50.ironport.com [63.251.108.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82L9Blt028769 for ; Thu, 2 Sep 2004 14:09:12 -0700 (PDT) (envelope-from ctaylor@ironport.com) Received: from anakin.ironport.com (HELO anakin.ironportsystems.com) (10.1.1.166) by smtp.ironport.com with ESMTP; 02 Sep 2004 14:09:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49131.1695CFF6" Subject: In support of SenderID Date: Thu, 2 Sep 2004 14:09:09 -0700 Message-ID: <65D2600546E11444960D957CFF5B644FAE9361@anakin.ironportsystems.com> Thread-Topic: In support of SenderID Thread-Index: AcSRMQ+1rINhqSPgQB6dy7hTZtYXTA== From: "Craig Taylor" To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C49131.1695CFF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It might be worth bringing back into the discussion that the standard consists of 4 parts. The framework (core) and the SPF record definition provides benefits for everyone and we should encourage their adoption by the IETF. The PRA algorithm is one of many schemes that receivers might choose to authenticate a sender. Receivers can decide what authentication schemes work and are reasonable to license. The PRA algorithm is specifically targeted at phishing. If Microsoft changes the rules of the game for the PRA, receivers can and will move to a new scheme. Yahoo's domainkeys attack the same problem with a solution that is ultimately better but requires more effort to deploy. SenderID is a good first step, it is the core and the record definitions that will out live the individual authentication schemes that use them. If people feel the core is too encumbered then we might need to restart with the original work done by Meng and Mark. It would be unfortunate if we can't use the current momentum. =20 At Ironport we support 5 out of the top 10 ISP and many of the F500. These companies want additional layers of defense. We will support our customers and implement some kind of receiver side authentication, based on SPF records. SenderID is just a first step, Meng has proposed a unified SPF where the PRA is just one of the authentication schemes in the stack. =20 Getting the framework and the record type standardized should be the focus of the working group. As both Philip Hallam-Baker and Yakov Shafranovich have eloquently discussed, the larger philosophical issues should be debate in a broader community forum. =20 Craig Taylor VP, Technology Ironport System ------_=_NextPart_001_01C49131.1695CFF6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It might be=20 worth bringing back into the discussion that the standard consists of 4=20 parts.  The framework (core) and the SPF record definition = provides=20 benefits for everyone and = we should=20 encourage their adoption by the IETF.  The PRA algorithm is one of = many=20 schemes that receivers might choose to authenticate a sender.  = Receivers=20 can decide what authentication schemes work and are reasonable to = license. =20 The PRA algorithm is specifically targeted at phishing.  If = Microsoft=20 changes the rules of the game for the PRA, receivers can and will move = to a new=20 scheme. Yahoo's domainkeys attack the same problem with a solution = that=20 is ultimately better but requires more effort to deploy.  = SenderID=20 is a good first step, it is the = core and=20 the record definitions that will out live the individual authentication = schemes=20 that use them.  If people feel the core is too encumbered then we = might=20 need to restart with the original work done by Meng and Mark.  = It=20 would be unfortunate if we can't use the current=20 momentum.
 
At = Ironport we=20 support 5 out of the top 10 ISP and many of the F500.  These = companies want=20 additional layers of defense.  We will support our customers and = implement=20 some kind of receiver side authentication, based on SPF records.  = SenderID=20 is just a first step, Meng has proposed a unified SPF where the PRA is = just one=20 of the authentication schemes in the stack.
 
Getting the=20 framework and the record type standardized should be the focus of the = working=20 group.  As both Philip=20 Hallam-Baker and Yakov = Shafranovich have=20 eloquently discussed, the = larger=20 philosophical issues should be debate in a broader community=20 forum.
 
Craig=20 Taylor
VP,=20 Technology
Ironport=20 System
------_=_NextPart_001_01C49131.1695CFF6-- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 17:39: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 RAA13984 for ; Thu, 2 Sep 2004 17:39:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82LKILP030112; Thu, 2 Sep 2004 14:20: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 i82LKIVq030111; Thu, 2 Sep 2004 14:20:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82LKIbU030105 for ; Thu, 2 Sep 2004 14:20:18 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i82LKEoL032041 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Sep 2004 14:20:14 -0700 Date: Thu, 2 Sep 2004 14:20:14 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: mazieres@gmail.com cc: Kevin Peuhkurinen , ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID In-Reply-To: <94df60cf04090213282ae5c57b@mail.gmail.com> Message-ID: References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376D09.1000400@hepcoe.com> <94df60cf04090213282ae5c57b@mail.gmail.com> 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, 2 Sep 2004 mazieres@gmail.com wrote: > What I'd really like to hear about is an actual usage scenario in > which a message author (say a bank sending out statements) actually > requires Sender ID, and could not get the same effect with > SPF-classic. I've talked to numerous large banks and consumer-oriented companies -- big ones, the kind that run ads on TV -- and they've done the analysis on their customer email address lists that a large majority (more than 50%) go only one hop to large ISPs that don't allow forwarding, and to large enterprises that discourage such. So, for these sites, a majority of their customers will be very well served by accurately authenticating the From: address which is shown in their MUA *today*. This is something that SPF-classic can not provide today. Another use case has to do with changes forwarders have to make so that they don't create false positives. The 2822 header additions required by Sender ID are much less invasive than the 2821 MAIL FROM rewriting (SRS) that SPF Classic requires, and the Sender ID changes do not change the well understood and sometimes depended on MAIL FROM bounce address. What still needs to be done is assess what types of paths either of these solutions might break (I like that CSV doesn't have the potential to do that). -Rand From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 17:39: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 RAA13989 for ; Thu, 2 Sep 2004 17:39:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82LCZOp029127; Thu, 2 Sep 2004 14:12: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 i82LCZXK029126; Thu, 2 Sep 2004 14:12:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82LCZ8F029116 for ; Thu, 2 Sep 2004 14:12:35 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 2 Sep 2004 14:12:39 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Sep 2004 14:12:29 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Sep 2004 14:12:36 -0700 Received: from df-dogbert-msg.exchange.corp.microsoft.com ([157.54.5.14]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 14:12:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V8.0.155.1 Content-class: urn:content-classes:message Subject: RE: TECH-ERROR: DNS Record Types MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 2 Sep 2004 14:12:33 -0700 Message-ID: Thread-Topic: TECH-ERROR: DNS Record Types thread-index: A8+RK+VziH0Fz+/cQ6+QxksEak/JzQABh9/w From: "Jim Lyon" To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , "IETF MARID WG" , "Mark Lentczner" X-OriginalArrivalTime: 02 Sep 2004 21:12:35.0712 (UTC) FILETIME=[91B3C800:01C49131] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82LCZ8F029119 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, September 02, 2004 at 1:09 PM, Ólafur Guðmundsson wrote: > I disagree: we are designing a protocol for use on the Internet, > ... your set up its classified as "not being on the Internet" In other words, you're willing to pretend the problem doesn't exist, by declaring that everyone with the problem isn't on the Internet. The real issue here is that this technology isn't useful unless almost all mail senders publish records. Telling people that they can't publish before upgrading software (and changing vendors too) means that they just won't publish. > Its counterproductive to keep harping on the same points that had > been rebutted number of times both on the mailing list and in the > working group meeting in San Diego. My recollection of the meeting in San Diego was that the consensus favored what the protocol-02 draft said, which is quite different from the current draft. > Below (in PS) is a simple script that uses nslookup to check if your > host can get unknown types from my DNS server. Here are results (debugging output removed for brevity) from my run of your script: C:\projects> nslookup Default Server: red-dns-01.redmond.corp.microsoft.com Address: 157.55.254.211 > set debug > set type=txt > set class=chaos > version.bind. Server: red-dns-01.redmond.corp.microsoft.com Address: 157.55.254.211 *** red-dns-01.redmond.corp.microsoft.com can't find version.bind.: Not implemented > set type=any > set class=in > set domain=test.ogud.com. > ssh Server: red-dns-01.redmond.corp.microsoft.com Address: 157.55.254.211 *** red-dns-01.redmond.corp.microsoft.com can't find ssh: Non-existent domain > unknown Server: red-dns-01.redmond.corp.microsoft.com Address: 157.55.254.211 *** red-dns-01.redmond.corp.microsoft.com can't find unknown: Non-existent domain > ^Z In other words, I'm behind one of your "evil, bad middleboxes". The only way to access your DNS server is through the Windows APIs, not by directly sending DNS packets. The point is that many other people are too. If the goal is interoperation, we need to take these people into account. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 17:42:23 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 RAA14267 for ; Thu, 2 Sep 2004 17:42:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82LIeDT029856; Thu, 2 Sep 2004 14:18:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82LIeRC029855; Thu, 2 Sep 2004 14:18:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82LIe0b029842 for ; Thu, 2 Sep 2004 14:18:40 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i82LId3V016407 for ; Thu, 2 Sep 2004 14:18:40 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id DDD7884F866; Thu, 2 Sep 2004 14:18:39 -0700 (PDT) Date: Thu, 2 Sep 2004 14:18:39 -0700 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: In support of SenderID Message-ID: <20040902211839.GN659@bitshift.org> References: <65D2600546E11444960D957CFF5B644FAE9361@anakin.ironportsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65D2600546E11444960D957CFF5B644FAE9361@anakin.ironportsystems.com> User-Agent: Mutt/1.4.1i X-Uptime: 2:14PM up 20:11, 7 users, load averages: 0.01, 0.03, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 02, 2004 at 02:09:09PM -0700, Craig Taylor wrote: > > Getting the framework and the record type standardized should be the > focus of the working group. As both Philip Hallam-Baker and Yakov > Shafranovich have eloquently discussed, the larger philosophical issues > should be debate in a broader community forum. Then let's approve just -core and -protocol and ditch the PRA document. Since Microsoft's IPR is supposedly only for the combo of -core AND -submitter, there should be no encumbrance on -core or -protocol in isolation. I'd be fine with that. ...unless the argument then becomees that -core and/or -protocol may also be encumbered, at which point I say scrap them all and start over with SPF-Classic. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 17:48: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 RAA14785 for ; Thu, 2 Sep 2004 17:48:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82LRe2G030801; Thu, 2 Sep 2004 14:27:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82LReiP030800; Thu, 2 Sep 2004 14:27:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82LRdLu030776 for ; Thu, 2 Sep 2004 14:27:39 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 21:27:36 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "Ryan Malayter" Subject: RE: (DEPLOY) In Support of Sender ID Date: Thu, 2 Sep 2004 15:27:47 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB944@cliff.bai.org> X-OriginalArrivalTime: 02 Sep 2004 21:27:36.0148 (UTC) FILETIME=[AA676940:01C49133] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Kevin Peuhkurinen wrote: >To my mind, there are ZERO hinderences to Microsoft >adopting SPF, but there are plenty of hinderences >for most everyone else to adopt the encumbered >Sender-ID. Ryan Malayter: >SPFv1 does not address email header forging at all. So SPFv1 does very >little to prevent forging of the "from" addresses seen by the user in >99% of MUAs. SPFv1 therefore does very little to prevent phishing scams. >This is why Microsoft came up with CallerID for email, and why Meng and >MS decided to merge the best parts of SPF and Caller ID into SenderID >approaches. SPF protects envelope forging correctly. SenderID doesn't. While SPF doesn't prevent forging of 2822 addresses seen by 99% of MUAs, the same could be said of SenderID. I don't know of any MUAs which display the PRA as described by SenderID. So, either way, it means upgrading all the MUAs. IMHO, if we are going to upgrade the MUAs to prevent phishing, we should look towards a stronger crypto/signing solution, not the flimsy solution provided by SenderID. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 18:01:59 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 SAA15436 for ; Thu, 2 Sep 2004 18:01:58 -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 i82LdXuE031778; Thu, 2 Sep 2004 14:39:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82LdXYb031777; Thu, 2 Sep 2004 14:39:33 -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 i82LdWPY031771 for ; Thu, 2 Sep 2004 14:39:32 -0700 (PDT) (envelope-from bong@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 i82LdbYF009786 for ; Thu, 2 Sep 2004 14:39:37 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 14:39:37 -0700 Message-ID: <12A2A091AAD1294A86D28FA9A37A40DF41689C@mou1wnexm10.vcorp.ad.vrsn.com> From: "Ong, Bruce" To: ietf-mxcomp@imc.org Subject: [Deploy] VeriSign's support of Sender ID Date: Thu, 2 Sep 2004 14:39:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I write as the technical product manager for VeriSign's Email Security Services to express our support for Sender ID. VeriSign's Email Security Service is a MX filtering based, managed anti-spam/anti-virus service. We announced our intention to support Sender ID when we first launched our service in June of this year (http://www.verisign.com/verisign-inc/news-and-events/news-archive/us-news-2 004/page_005051.html). We see Sender ID as a good, easy to implement solution to stop email domain spoofing, and an important first step towards truly authenticating the sending party. We are looking forward to seeing the finalized Sender ID specification from IETF, and plan to integrate and deploy Sender ID checking in our managed anti-spam service in our infrastructure to benefit our customers. Bruce Ong Sr. Product Manager Authentication and Email Security Services Verisign Inc. +1.650.426.3232 (w) +1.650.426.5195 (f) From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 18:02: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 SAA15454 for ; Thu, 2 Sep 2004 18:02: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 i82LaqrI031572; Thu, 2 Sep 2004 14:36: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 i82LaqBP031571; Thu, 2 Sep 2004 14:36:52 -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 i82LaoCB031554 for ; Thu, 2 Sep 2004 14:36:51 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.254.82] (host66.209-113-184.oem.net [209.113.184.66]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i82LZobC001537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Sep 2004 17:35:53 -0400 Subject: Re: In support of SenderID From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: <65D2600546E11444960D957CFF5B644FAE9361@anakin.ironportsystems.com> References: <65D2600546E11444960D957CFF5B644FAE9361@anakin.ironportsystems.com> Content-Type: text/plain Message-Id: <1094161010.3335.62.camel@tuxtop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 02 Sep 2004 17:36:50 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-09-02 at 17:09, Craig Taylor wrote: [snip] > As both Philip Hallam-Baker and Yakov Shafranovich have eloquently > discussed, the larger philosophical issues should be debate in a > broader community forum. Disagree with this final statement, but only insofar as it implies that it *shouldn't* be discussed here. Yes, those larger issues should be discussed in a broader community forum, but we have a problem here: this WG is in its last call stage. These issues need to be discussed here at least with respect to how they relate to these proposals and the IPR problems embedded in them. And given that last call is only two weeks, I have to believe that if the co-chairs haven't put a stop to this discussion by now, (with the period more than half over), then they have spoken simply by their silence. The co-chairs have put a stop to this type of discussion earlier, but now that we are in last call, I've seen no such postings from them asking that the discussion be taken elsewhere. -- -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 Sep 2 18:23:51 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 SAA18182 for ; Thu, 2 Sep 2004 18:23:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82M2M0c033851; Thu, 2 Sep 2004 15:02:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82M2MWP033850; Thu, 2 Sep 2004 15:02:22 -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 i82M2Lon033843 for ; Thu, 2 Sep 2004 15:02:22 -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 1C2zev-0003xF-T7 for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 17:02:24 -0500 To: "IETF MARID WG" References: <792DE28E91F6EA42B4663AE761C41C2A02CEB896@cliff.bai.org> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 02 Sep 2004 17:02:21 -0500 In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB896@cliff.bai.org> (Ryan Malayter's message of "Thu, 2 Sep 2004 11:27:04 -0500") 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: The SSL license offer. 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=-4.2 required=4.0 tests=AWL,BAYES_00,DIG_UP_INFO, GREYLIST_ISWHITE autolearn=no 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 <792DE28E91F6EA42B4663AE761C41C2A02CEB896@cliff.bai.org> "Ryan Malayter" writes: > [Hallam-Baker, Phillip] >>The patent is held by Netscape (AOL) and covers transport layer >>security. The terms are considerably more vague than in the SenderID >>case. Netscape does not promise to offer a sublicensable patent or >>even to offer reasonable or non discriminatory terms. The terms "reasonable" and "non descriminatory" of RAND are almost meaningless. > > Very interesting. If OpenSSL can be included in Linux distributions, why > can't SenderID? > > The SSL license would seem to have tproblems with the GPL similar to > those that the SenderID license does. The problem isn't the patents, the problem is the license. It is the terms of the licenses that make the SenderID patent license incompatible with the GPL and causes folks like sourceforge need a license in order to redistribute the senderid-milter. The OpenSSL TLS patent and license dates 1996 or 1997. It is hard to even dig up information to refresh my memory about this issue. I think this is all a red herring though. The question before this working group is not what has been done in the past, but whether the costs associated with the SenderID license are more than offset by the benefits of using the patented PRA algorithm when compared with other proposals that are not encumbered. Since I believe that there are unencumbered alternatives to the PRA algorithm that are *better*, the cost of the license would have to be negative. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 18:27:26 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 SAA18449 for ; Thu, 2 Sep 2004 18:27:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82M892w034556; Thu, 2 Sep 2004 15:08: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 i82M89Kj034555; Thu, 2 Sep 2004 15:08:09 -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 i82M882x034549 for ; Thu, 2 Sep 2004 15:08:08 -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 1C2zkV-00040a-VO for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 17:08:13 -0500 To: "IETF MARID WG" References: <792DE28E91F6EA42B4663AE761C41C2A02CEB944@cliff.bai.org> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 02 Sep 2004 17:08:07 -0500 In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB944@cliff.bai.org> (Ryan Malayter's message of "Thu, 2 Sep 2004 15:01:42 -0500") 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: (DEPLOY) In Support of Sender ID 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.6 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 <792DE28E91F6EA42B4663AE761C41C2A02CEB944@cliff.bai.org> "Ryan Malayter" writes: > [Kevin Peuhkurinen] >>To my mind, there are ZERO hinderences to Microsoft >>adopting SPF, but there are plenty of hinderences >>for most everyone else to adopt the encumbered >>Sender-ID. > > SPFv1 does not address email header forging at all. So SPFv1 does very > little to prevent forging of the "from" addresses seen by the user in > 99% of MUAs. SPFv1 therefore does very little to prevent phishing scams. > This is why Microsoft came up with CallerID for email, Yeah, but SenderID doesn't protect the From: header in any critical situation. It protects the nearly invisible Resent-Sender: header. > and why Meng and > MS decided to merge the best parts of SPF and Caller ID into SenderID > approaches. I have had lots of conversations with Meng and his usual reason for supporting the merger was because he felt that MS would promote deployment. He is now very actively promoting Unified-SPF. > So yes, there are very big hinderances to MS and everyone else adopting > SPF classic - it doesn't solve a big part of the email forging problem. SPF-classic goes a long way of solving the forging of the 2821.MAILFROM identity. SenderID does not do much of anything to solve the problem of forging the 2822.From: identity. > Even "Unified SPF" still defines the PRA algorithm for use in verifying > mail headers, and therefor is also incumbered by the Microsoft IP. And the PRA part of Unified-SPF is optional. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 18:30:36 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 SAA18652 for ; Thu, 2 Sep 2004 18:30:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82M9L9K034619; Thu, 2 Sep 2004 15:09:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82M9L0R034618; Thu, 2 Sep 2004 15:09:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82M9LFY034610 for ; Thu, 2 Sep 2004 15:09:21 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: In support of SenderID Date: Thu, 2 Sep 2004 17:09:27 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEB99F@cliff.bai.org> Thread-Topic: In support of SenderID thread-index: AcSRMQ+1rINhqSPgQB6dy7hTZtYXTAABzV2A From: "Ryan Malayter" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82M9LFY034613 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I also support SenderID. I do not believe the IP issues regarding the PRA algorithm are unsolvable; either the MS license can be changed to facilitate OSS deployment, or a nonincumbered algorithm with similar effectiveness to PRA can be found and substitiuted. RFC-2822 authentication is my organization's primary need (and that of our customers: banks). Sender ID solves this problem more neatly than other solutions I have seen proposed in MARID. SPFv1 does not address RFC-2822 authentication at all, and is therefore only marginally useful to my organization. Ryan Malayter Bank Administration Institute Chicago, Illinois, USA From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 18:30: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 SAA18672 for ; Thu, 2 Sep 2004 18:30: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 i82M6kup034455; Thu, 2 Sep 2004 15:06: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 i82M6kLu034454; Thu, 2 Sep 2004 15:06:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82M6jfZ034448 for ; Thu, 2 Sep 2004 15:06:45 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i82M6nRR008970 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Sep 2004 15:06:49 -0700 Date: Thu, 2 Sep 2004 15:06:49 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: "Michael R. Brumm" cc: IETF MARID WG , Ryan Malayter Subject: RE: (DEPLOY) In Support of Sender ID In-Reply-To: Message-ID: References: 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, 2 Sep 2004, Michael R. Brumm wrote: > While SPF doesn't prevent forging of 2822 addresses seen by 99% of MUAs, the > same could be said of SenderID. I don't know of any MUAs which display the > PRA as described by SenderID. As I said before, there is a large majority of mail that goes from large commercial sites (or consumer ISPs) merely one hop to another large commercial ISP, so the From: header will be successfully authenticated. Due to the fact that there will be a small number of messages that *will* take multiple forwarding or other hops, IP-based authentication of headers won't work for those with existing mail clients, and all IP auth solutions have the potential of causing false positives if the interim forwarding hops aren't upgraded. For this reason, it may end up being the case that Sender ID can not reliably prevent spoofing for messages that take complex paths; but there is some solace in that these complex paths are usually managed by the *receiver*. SPF, while authenticating something that does not give you a positive value for the first case I stated, also has the potential to change a very fundamental part of the mail channel in trying to work around the problem of the second case. (And yes Dave Crocker, I am simplifying the "one hop" idea in my first paragraph, but from what I've seen so far it looks like that idea holds for large Enterprise-to-ISP or ISP-to-ISP communication in a majority of cases :) -Rand From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 18:33: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 SAA19094 for ; Thu, 2 Sep 2004 18:33:32 -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 i82MCrZF034926; Thu, 2 Sep 2004 15:12: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 i82MCrwB034925; Thu, 2 Sep 2004 15:12:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82MCqFJ034915 for ; Thu, 2 Sep 2004 15:12:52 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: The SSL license offer. Date: Thu, 2 Sep 2004 17:12:59 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEB9A1@cliff.bai.org> Thread-Topic: The SSL license offer. thread-index: AcSRORm0ozJllD8LR6yRGOCX+5h3GwAAIaOA From: "Ryan Malayter" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i82MCqFJ034920 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [wayne] >Since I believe that there are unencumbered alternatives >to the PRA algorithm that are *better*, the cost of the >license would have to be negative. Please share them... I haven't read all of the non-sender-ID MARID drafts, and a lot of the list posts. The volume is just too high. What algorithm out there would be more effective than PRA at validating the true sender of an email from the headers? And is not covered by the MS IP? Thanks, Ryan From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 19:09:24 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 TAA21347 for ; Thu, 2 Sep 2004 19:09: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 i82MivmH037612; Thu, 2 Sep 2004 15:44: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 i82Miv8S037611; Thu, 2 Sep 2004 15:44:57 -0700 (PDT) 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 i82MiuCW037600 for ; Thu, 2 Sep 2004 15:44:56 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Thu, 02 Sep 2004 18:44:58 -0400 id 0000000000157772.000000004137A26A.000050DB X-IMAP-Sender: mrsam@courier-mta.com References: <008801c49118$8321a780$6401a8c0@JTHSony> <413770FB.3080206@moongroup.com> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik Cc: ietf-mxcomp@imc.org X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: (DEPLOY) In Support of Sender ID Date: Thu, 02 Sep 2004 18:44:58 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-11331-1094165098-0005"; 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-11331-1094165098-0005 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Chuck Mead writes: > I am given to understand by communications from many sources that a > great deal of work is going on quietly, behind the scenes, trying to > work out this issue and I commend Microsoft for their willingness to > discuss them... that said we aren't there yet and I do not see how you > can believe that Sender-ID will be *widely adopted* given the current > license situation. I don't know how actually willing is Microsoft, but I do know that many respected F/OSS community members have been trying to lobby behind the scenes, for which I commend them. However, I am 100% certain that Microsoft will never accept F/OSS-compatible licensing terms, and the lobbying efforts will not succeed. I believe their only purpose is so that everyone can truthfully say that they tried their best. Repeated calls on this mailing list for Microsoft to adopt F/OSS-compatible licensing terms will not do anything. This is not going to happen. --=_mimegpg-commodore.email-scan.com-11331-1094165098-0005 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBN6Jqx9p3GYHlUOIRAkezAJ9ihTwO3kJLR4o/p2UKG62DhE7W2wCfUdb+ zo8ct7cGx1iNsc5u2Pm4Bmw= =PCLR -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-11331-1094165098-0005-- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 19:09: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 TAA21365 for ; Thu, 2 Sep 2004 19:09:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82Mob5G038107; Thu, 2 Sep 2004 15:50:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82Moba4038106; Thu, 2 Sep 2004 15:50:37 -0700 (PDT) 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 i82MobgJ038100 for ; Thu, 2 Sep 2004 15:50:37 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Thu, 02 Sep 2004 18:50:41 -0400 id 000000000015766C.000000004137A3C1.000050F5 X-IMAP-Sender: mrsam@courier-mta.com References: <2AB71632-FD0A-11D8-BA2B-000A95AC5778@isipp.com> <030d01c49123$c0cdc450$3201a8c0@rasta> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: IETF MARID WG X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: Motion to abandon Sender ID Date: Thu, 02 Sep 2004 18:50:41 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-11331-1094165441-0006"; 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-11331-1094165441-0006 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 Harold A'Hole writes: > While I don't doubt the actual law as you are suggesting, the key question > is what would MSFT really do. Again, since the "license" costs nothing an= d > is given to all parties without bias, the loss of having a license wouldn'= t > impact MSFT at all. Ummm, MSFT can certainly sue for an injunction prohibiting the F/OSS developer from using patented IP without a license. Since, as you've acknowledged, the F/OSS developer is not likely to have the= financial resources for a protracted fight, and challenging the patent, Microsoft's legal expenses will be rather minimal. Do you think that there would be any value for Microsoft in blocking a competing F/OSS implementation of Sender-ID? Hhhhhhhmmmmmmm? > enough to prove the the user of the software even knew about it. And the > remedy would be a simple fax. Why would MSFT spend legal dollars after th= ey > have said they want it to be a freely deployed standard? Lol! Like Microsoft never spent money on anti-F/OSS legal actions, directly and indirectly, before=E2=80=A6 --=_mimegpg-commodore.email-scan.com-11331-1094165441-0006 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBN6PBx9p3GYHlUOIRAvwlAJ9gsPD/OvZvi82NB5413NsVh3x8DQCePYma j254LOvQ0hLm/N/dsfJ9ZC0= =zcAj -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-11331-1094165441-0006-- From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 19:13: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 TAA21532 for ; Thu, 2 Sep 2004 19:13: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 i82Mse8Y038560; Thu, 2 Sep 2004 15:54:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82MseBJ038559; Thu, 2 Sep 2004 15:54:40 -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 i82MsdSV038552 for ; Thu, 2 Sep 2004 15:54:39 -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 i82N4Fdi023209; Thu, 2 Sep 2004 16:04:15 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i82N4Fl7023206; Thu, 2 Sep 2004 16:04:15 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 2 Sep 2004 16:04:15 -0700 (PDT) From: "william(at)elan.net" To: Ryan Malayter cc: IETF MARID WG Subject: RE: The SSL license offer. In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB9A1@cliff.bai.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alternatives are in fact available, but those who know about it can not share it right now since WG chairs have requested that until last call is completed that people on this list evaluate current drafts that are based on Sender-ID proposal. And I believe we should respecct WG chairs and IETF process if we want to produce solution that IETF will be able to adopt as standard, though what has been going on here for last week, really does not look anything close to "last call" and that is not good for this WG. But be assured that SenderID algorithm and PRA is not the only DNS based client ip authorization system that can be used to authenticate email origin as listed in RFC2822 headers. However please do respect the hard work that has been done by all members of this WG (no matter what company they work for) for last several months and evaluate the proposed drafts based on technical elements and not merely on the IPR issues. Besides, your technical evaluation may also proove quite usefull for any other future WG proposal as well. On Thu, 2 Sep 2004, Ryan Malayter wrote: > > [wayne] > >Since I believe that there are unencumbered alternatives > >to the PRA algorithm that are *better*, the cost of the > >license would have to be negative. > > Please share them... I haven't read all of the non-sender-ID MARID > drafts, and a lot of the list posts. The volume is just too high. > > What algorithm out there would be more effective than PRA at validating > the true sender of an email from the headers? And is not covered by the > MS IP? > > Thanks, > Ryan --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 19:25:55 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 TAA22189 for ; Thu, 2 Sep 2004 19:25: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 i82N51wW039723; Thu, 2 Sep 2004 16:05: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 i82N51dp039722; Thu, 2 Sep 2004 16:05:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82N50Be039712 for ; Thu, 2 Sep 2004 16:05:00 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so393092rnl for ; Thu, 02 Sep 2004 16:05:00 -0700 (PDT) Received: by 10.38.70.76 with SMTP id s76mr1322941rna; Thu, 02 Sep 2004 16:05:00 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Thu, 2 Sep 2004 16:05:00 -0700 (PDT) Message-ID: <94df60cf04090216057a06d0cc@mail.gmail.com> Date: Thu, 2 Sep 2004 19:05:00 -0400 From: Reply-To: To: Rand Wacker Subject: Re: (DEPLOY) In Support of Sender ID Cc: Kevin Peuhkurinen , ietf-mxcomp@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376D09.1000400@hepcoe.com> <94df60cf04090213282ae5c57b@mail.gmail.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2 Sep 2004 14:20:14 -0700 (PDT), Rand Wacker wrote: > On Thu, 2 Sep 2004 mazieres@gmail.com wrote: > > I've talked to numerous large banks and consumer-oriented companies -- big > ones, the kind that run ads on TV -- and they've done the analysis on > their customer email address lists that a large majority (more than 50%) > go only one hop to large ISPs that don't allow forwarding, and to large > enterprises that discourage such. So, for these sites, a majority of > their customers will be very well served by accurately authenticating the > From: address which is shown in their MUA *today*. This is something that > SPF-classic can not provide today. Wait a sec... surely you don't claim that Sender ID can authenticate anything with MUAs today. I agree that in single-hop scenarios, mail won't be rejected by Sender ID. However, nothing stops forgery of the From: header by viruses or spammers. If I add a "Resent-Sender: virus@com" header, today's MTAs are still going to display the unauthentic "From: whatever@mybank.com" header. Anyway, are MUAs really within scope here, in a working group about MTA authentication? My challenge remains... describe a concrete scenario that requires Sender ID, and that could not achieve the same effective result with SPF-classic. Vague references to banks don't convince me any more, because I've thought through concrete scenarios, and in every case, if you specify what needs to be sent to whom, and what the attacker is trying to do, you'll see that SPF-classic is basically as powerful as Sender ID. Once you throw end users into the fray, you'll find that in either case you need to make small modifications to the MUA, but neither modification is particularly hard to do. David From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 19:39:22 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 TAA23122 for ; Thu, 2 Sep 2004 19:39:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82NCjL3040226; Thu, 2 Sep 2004 16:12: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 i82NCj5v040225; Thu, 2 Sep 2004 16:12:45 -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 i82NCjgX040219 for ; Thu, 2 Sep 2004 16:12:45 -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 i82NCoMT015441 for ; Thu, 2 Sep 2004 16:12:50 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 16:12:50 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: The SSL license offer. Date: Thu, 2 Sep 2004 16:12:44 -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: > In <792DE28E91F6EA42B4663AE761C41C2A02CEB896@cliff.bai.org> > "Ryan Malayter" writes: > > > [Hallam-Baker, Phillip] > >>The patent is held by Netscape (AOL) and covers transport layer > >>security. The terms are considerably more vague than in the SenderID > >>case. Netscape does not promise to offer a sublicensable patent or > >>even to offer reasonable or non discriminatory terms. > > The terms "reasonable" and "non descriminatory" of RAND are almost > meaningless. I bet that I could define terms that you would intersubjectively agree to be unreasonable and discriminatory. > The problem isn't the patents, the problem is the license. It is the > terms of the licenses that make the SenderID patent license > incompatible with the GPL and causes folks like sourceforge need a > license in order to redistribute the senderid-milter. > > The OpenSSL TLS patent and license dates 1996 or 1997. It is hard to > even dig up information to refresh my memory about this issue. But the terms were never even published. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 20:03:54 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 UAA24616 for ; Thu, 2 Sep 2004 20:03:54 -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 i82Ngd5R042327; Thu, 2 Sep 2004 16:42: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 i82NgdBw042326; Thu, 2 Sep 2004 16:42:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82Ngc7R042319 for ; Thu, 2 Sep 2004 16:42:39 -0700 (PDT) (envelope-from roy+dated+1096760556.994496@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i82Nh6gi038147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Sep 2004 23:43:12 GMT (envelope-from roy+dated+1096760556.994496@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i82Ngb3K042740 for ; Fri, 3 Sep 2004 00:42:37 +0100 (BST) (envelope-from roy+dated+1096760556.994496@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i82Nga96042739 for ietf-mxcomp@imc.org; Fri, 3 Sep 2004 00:42:36 +0100 (BST) (envelope-from roy+dated+1096760556.994496@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 03 Sep 2004 00:42:36 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.45036.160556.552577@giles.gnomon.org.uk> Date: Fri, 3 Sep 2004 00:42:36 +0100 To: ietf-mxcomp@imc.org Subject: TECH-ERROR: Name of SUBMITTER parameter X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Not really technical, but more technical than editorial... Just to reiterate a point I made prior to last call (which got no feedback, positive or negative). The SUBMITTER parameter was fine as a working name (as was FRED, DAVE, and all the rest of the names) but now that we're all in agreement that the name of the identity in question is the PRA, the obvious name for the parameter to identify the PRA is "PRA". MAIL FROM: PRA= is far more natural than the SUBMITTER alternative. -roy From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 20:16: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 UAA25399 for ; Thu, 2 Sep 2004 20:16: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 i82Nrp0S043087; Thu, 2 Sep 2004 16:53: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 i82Nrp0J043086; Thu, 2 Sep 2004 16:53:51 -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 i82NrnEb043080 for ; Thu, 2 Sep 2004 16:53:50 -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 1C31Op-0005HE-2v for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 18:53:55 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Thu, 02 Sep 2004 18:53:51 -0500 In-Reply-To: (william elan net's message of "Thu, 2 Sep 2004 16:04:15 -0700 (PDT)") 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: The SSL license offer. 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.6 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 "william(at)elan.net" writes: > Alternatives are in fact available, but those who know about it can not > share it right now since WG chairs have requested that until last call is > completed that people on this list evaluate current drafts that are based > on Sender-ID proposal. I have given Ryan a short answer offlist, but this restriction on discussing alternatives kind of puts us in a catch-22. I can understand the reasons why the co-chairs don't want the extra destractions, but RFC3669 talks about comparing with alternatives. If I discuss alternatives, I will get in trouble with the co-chairs. If I don't discuss the alternatives, people who have come in late to the game will likely think that there is no choice but to accept SenderID. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 20:16: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 UAA25405 for ; Thu, 2 Sep 2004 20:16: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 i82Ns5nZ043111; Thu, 2 Sep 2004 16:54: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 i82Ns57P043110; Thu, 2 Sep 2004 16:54:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82Ns42r043104 for ; Thu, 2 Sep 2004 16:54:04 -0700 (PDT) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id E997FBC19E; Thu, 2 Sep 2004 19:54:09 -0400 (EDT) Subject: DEPLOY: Postfix MTA position To: ietf-mxcomp@imc.org Date: Thu, 2 Sep 2004 19:54:09 -0400 (EDT) X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20040902235409.E997FBC19E@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I would like to adopt Sender-ID support into the open source Postfix MTA. However, Postfix Sender-ID deployment is practical only if Postfix developers, (re)distributors and users are comfortable with the Sender-ID licensing agreement. In order to make Sender-ID adoption practical for Postfix, the licensing conditions would need to change so that no license application is required to modify, (re)distribute, or use the PRA algorithm for the purpose of email Sender-ID authentication, in source or binary form. It would be desirable, but not necessary, that I can implement and distribute Postfix source code with Sender-ID support, without having to apply for a PRA license. It is entirely acceptable if Microsoft wants to maintain control over other uses of their patent, should their application succeed. Having gone to similar pains when Postfix was released before IBM had developed an open source release process, I wish the people at Microsoft all the best in their efforts to get the license issues straightened out. Wietse Venema From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 20:18:48 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 UAA25541 for ; Thu, 2 Sep 2004 20:18:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82NwwAN043459; Thu, 2 Sep 2004 16:58: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 i82NwwMx043455; Thu, 2 Sep 2004 16:58:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82Nwt8Q043428 for ; Thu, 2 Sep 2004 16:58:56 -0700 (PDT) (envelope-from roy+dated+1096761534.2fa1cf@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i82NxO8m039230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Sep 2004 23:59:30 GMT (envelope-from roy+dated+1096761534.2fa1cf@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i82NwsGF042838 for ; Fri, 3 Sep 2004 00:58:54 +0100 (BST) (envelope-from roy+dated+1096761534.2fa1cf@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i82NwstS042837 for ietf-mxcomp@imc.org; Fri, 3 Sep 2004 00:58:54 +0100 (BST) (envelope-from roy+dated+1096761534.2fa1cf@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 03 Sep 2004 00:58:54 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.46014.291159.582789@giles.gnomon.org.uk> Date: Fri, 3 Sep 2004 00:58:54 +0100 To: ietf-mxcomp@imc.org Subject: DOC-BUG: use of 'header' instead of 'field' X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Apologies if this is a dupe... I always get this wrong when I'm not thinking, but a field is a single (logical) line in the header of a message; the header is the entire set of fields -- a message has only one header. In all the documents, there's a general need to do s/header/field/ However in some cases 'header field' may be necessary to give context. Also there's a need to spot the cases where 'headers' is used to mean the entire header of the message, where it should be replaced by 'header' rather than 'fields', eg in section 1 of -pra 'the headers of the message' should be 'the header of the message' -roy From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 20:19:40 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 UAA25614 for ; Thu, 2 Sep 2004 20:19:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82NwXuZ043405; Thu, 2 Sep 2004 16:58:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82NwXbp043404; Thu, 2 Sep 2004 16:58:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost4.mail.uk.easynet.net (smarthost4.mail.uk.easynet.net [212.135.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82NwXGp043396 for ; Thu, 2 Sep 2004 16:58:33 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost4.mail.uk.easynet.net with smtp (Exim 4.10) id 1C31TB-000LZD-00; Fri, 03 Sep 2004 00:58:21 +0100 Message-ID: <243301c49148$64951060$0200000a@ringo> From: "Chris Haynes" To: "Ryan Malayter" Cc: References: <792DE28E91F6EA42B4663AE761C41C2A02CEB99F@cliff.bai.org> Subject: Re: In support of SenderID Date: Fri, 3 Sep 2004 00:55:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "Ryan Malayter" confused my by declaring: > > > I also support SenderID. > > I do not believe the IP issues regarding the PRA algorithm are > unsolvable; either the MS license can be changed to facilitate OSS > deployment, or a nonincumbered algorithm with similar effectiveness > to PRA can be found and substitiuted. Er, Ryan, This is the 'final call' on the tabled Sender-ID drafts. The licence IS what Microsoft says it is, the algorithm IS the encumbered PRA. The chairs have another three days or so in which to judge the concensus. I can't work out if you for or against these specific drafts. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 20:23: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 UAA25791 for ; Thu, 2 Sep 2004 20:23:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83017iS043635; Thu, 2 Sep 2004 17:01:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83017W9043634; Thu, 2 Sep 2004 17:01:07 -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 i83016xT043623 for ; Thu, 2 Sep 2004 17:01:07 -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 1C31Vr-0005MQ-Q1 for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 19:01:12 -0500 To: "IETF MARID WG" References: <792DE28E91F6EA42B4663AE761C41C2A02CEB99F@cliff.bai.org> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 02 Sep 2004 19:01:07 -0500 In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB99F@cliff.bai.org> (Ryan Malayter's message of "Thu, 2 Sep 2004 17:09:27 -0500") 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: In support of SenderID 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.6 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 <792DE28E91F6EA42B4663AE761C41C2A02CEB99F@cliff.bai.org> "Ryan Malayter" writes: > I also support SenderID. > > I do not believe the IP issues regarding the PRA algorithm are > unsolvable; either the MS license can be changed to facilitate OSS > deployment, or [....] This makes no sense. There is *zero* reason to believe that if MS wins IETF approval of the current license that they will change later on. MS has been under a lot of preasure for months and they really have barely budged on the critical issues even when it is clear they risk getting approval. > [...] or a nonincumbered algorithm with similar effectiveness to > PRA can be found and substitiuted. What you are saying here is that we wouldn't be accepting SenderID! So, if you are willing to accept something other than SenderID, why don't you demand a better license *before* it gets approved? -wayne From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 20:37:57 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 UAA26571 for ; Thu, 2 Sep 2004 20:37: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 i830GYIr044880; Thu, 2 Sep 2004 17:16:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i830GYaR044879; Thu, 2 Sep 2004 17:16:34 -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 i830GYWn044857 for ; Thu, 2 Sep 2004 17:16:34 -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; Thu, 02 Sep 2004 20:16:36 -0400 id 0015FA75.4137B7E5.00003850 In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB9A1@cliff.bai.org> References: <792DE28E91F6EA42B4663AE761C41C2A02CEB9A1@cliff.bai.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <822ABE7A-FD3E-11D8-B6CF-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: "IETF MARID WG" From: Andrew Newton Subject: Re: The SSL license offer. Date: Thu, 2 Sep 2004 20:16:32 -0400 To: "Ryan Malayter" 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 Sep 2, 2004, at 6:12 PM, Ryan Malayter wrote: > Please share them... I haven't read all of the non-sender-ID MARID > drafts, and a lot of the list posts. The volume is just too high. > > What algorithm out there would be more effective than PRA at validating > the true sender of an email from the headers? And is not covered by the > MS IP? Wayne has been very politely obeying the wishes of the co-chairs not to wonder in that direction. Do not hold it against him. If you think the volume is high now, adding this to the mix will certainly not help. Besides, at this moment I doubt such a conversation would end in agreement. -andy From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 20:53:41 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 UAA27398 for ; Thu, 2 Sep 2004 20:53:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i830YKrC046736; Thu, 2 Sep 2004 17:34:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i830YK4Y046734; Thu, 2 Sep 2004 17:34:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i830YI3b046711 for ; Thu, 2 Sep 2004 17:34:19 -0700 (PDT) (envelope-from roy+dated+1096763657.6b3761@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i830Ymcd041985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Sep 2004 00:34:54 GMT (envelope-from roy+dated+1096763657.6b3761@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i830YHOV043228 for ; Fri, 3 Sep 2004 01:34:17 +0100 (BST) (envelope-from roy+dated+1096763657.6b3761@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i830YH5m043227 for ietf-mxcomp@imc.org; Fri, 3 Sep 2004 01:34:17 +0100 (BST) (envelope-from roy+dated+1096763657.6b3761@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 03 Sep 2004 01:34:17 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.48136.742801.125862@giles.gnomon.org.uk> Date: Fri, 3 Sep 2004 01:34:16 +0100 To: ietf-mxcomp@imc.org Subject: TECH-ERROR: versioning X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd like to support the various proposals for modifying the syntax of the version specified so that 'pra' isn't hardwired. However, I'd rather propose a more neutral term than 'ver-scope' or 'scope' as has been previously proposed. I'd prefer 'ver-token'; these tokens may be useful for things other than defining scopes (the SPF term for identities to verify). At this point we don't need to decide what we think the extension mechanism will be used for, we just have to provide an extenstion mechanism. I would propose that the BNF in -protocol 3.4.1 be replaced with something on the lines of: version = "spf2." ver-minor [ / ver-token-list ] ver-minor = 1*DIGIT ver-token-list = ver-token *("," ver-token) ver-token = *SOMECHAR ; don't really care, but obiously must exclude "," The following text then needs to become: Only records that begin with a proper version section are considered. The version section contains two parts that are for backward compatible future extensions: the ver-minor and ver-token-list fields. These fields of the version must be well-formed for a record to be considered. The vir-minor field is otherwise ignored, and the ver-token-list field is considered as described in the following paragraphs. If there is only one record with a proper version section, it is selected. If there are two such records, one TXT and one SPF2 RR, then the later MUST be selected. If two or more such records exist of the same RR type, then check_host() exits immediately with the error "PermError". If the optional ver-token-list field is present in the selected record, and one (or more) of the ver-tokens have the value "pra", then the selected record is used as described in this document. Otherwise check_host() exits immediately with the error "PermError". From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 21:06: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 VAA28032 for ; Thu, 2 Sep 2004 21:06:04 -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 i830glV2047264; Thu, 2 Sep 2004 17:42:47 -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 i830gljw047263; Thu, 2 Sep 2004 17:42:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i830gk3w047257 for ; Thu, 2 Sep 2004 17:42:46 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 2 Sep 2004 17:42:52 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Sep 2004 17:42:42 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Sep 2004 17:42:52 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 17:42:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Sendmail releases open source Sender ID milter for testing Date: Thu, 2 Sep 2004 17:42:51 -0700 Message-ID: Thread-Topic: Sendmail releases open source Sender ID milter for testing thread-index: AcSQbYDBBQ4COonJSg2uCA7PK+wT9gA4H/gQ From: "Harry Katz" To: , Cc: "Rand Wacker" X-OriginalArrivalTime: 03 Sep 2004 00:42:51.0833 (UTC) FILETIME=[F17F1290:01C4914E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i830gk3w047258 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, September 01, 2004 2:49 PM, mazieres@gmail.com [mailto:mazieres@gmail.com] wrote: > On Wed, 1 Sep 2004 09:55:52 -0700, Harry Katz > wrote: > > > Second as per the terms of the license itself, End Users who are > > recipients of a licensed implementation of Sender ID and distributors > > who are redistributing a branded licensed implementation do not need > > to separately sign this License Agreement. > > I understand your the point about End Users, but could you > clarify how the license exempts distributors? Specifically, > my concern is that while section 2.1 allows indirect > distribution of object code, section 2.2, which applies to > source code, does not. Section 2.2 references 2.1 in a way that makes it permissible to "indirectly" distribute the source code versions of the Licensed implementations too. In other words, if you're redistributing a licensed branded implementation - either source or binary - you don't need to execute the license agreement. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 21:12: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 VAA28319 for ; Thu, 2 Sep 2004 21:12: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 i830pAQA047748; Thu, 2 Sep 2004 17:51:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i830p9l2047744; Thu, 2 Sep 2004 17:51:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i830p8Yx047711 for ; Thu, 2 Sep 2004 17:51:08 -0700 (PDT) (envelope-from SRS0=IufEee0g=LY=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i830pDHJ026666 for ; Fri, 3 Sep 2004 02:51:13 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409030051.I830PCLU026656@asarian-host.net> Date: Fri, 03 Sep 2004 00:51:13 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: TECH-ERROR: Name of SUBMITTER parameter X-Trace: jPr6Oc7snVvip7RFRjXmMFCr//H3xzbEmC0vQgtcS+956F1zRqgmrXaGE/1yupz9OocEn3OH/tlESTWoKH7omg== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <16695.45036.160556.552577@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQTfAATFqW1BleBN9AQGvpwf/W5Z0Mu4SJj8DvDXZ2MYqNfXWYMcXoeMv vefFZMcBaOI1iSKKx1NiF5Js1jIeXgnd+pdQczXG0qTSvjuYJATzhsYBK7kOEBRu UmIdfxTNtQVo2IpcH7Kr/pZdOs+q6roPYBJC8AXPAjw9d2b38o8pE7zmJiCOS0Y8 uk5MJlv/9k/ZOfVHe7vhXoSwUa/D1l8+EROnxuiPs9sqBNa2/9YwlpJRamQwtxLq kM0EE1qu3khSqOvgo37iV0W8/GZQkZ19W1t/E0wM1QtgIEmuakIbBStjDUuMDrBm 4a0qOymee+wr/1pHVNTG0i8kJ+55AeGqY4IGbNQ14EqQbz4VnDR/XA== =ODaw Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy Badami wrote: > The SUBMITTER parameter was fine as a working name (as was FRED, DAVE, > and all the rest of the names) but now that we're all in agreement > that the name of the identity in question is the PRA, the obvious name > for the parameter to identify the PRA is "PRA". > > MAIL FROM: PRA= > > is far more natural than the SUBMITTER alternative. I was more than happy even using the existing ENVID for this purpose. ;) Something like: Mail from: ENVID= Then we could have all used it tomorrow. I know, that is not what RFC 1891, section 5.4, meant it for; but it would have been fine by me. :) - Mark From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 21:13: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 VAA28361 for ; Thu, 2 Sep 2004 21:13:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i830ntEP047628; Thu, 2 Sep 2004 17:49:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i830ntm6047627; Thu, 2 Sep 2004 17:49:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i830nr6K047621 for ; Thu, 2 Sep 2004 17:49:53 -0700 (PDT) (envelope-from roy+dated+1096764592.c2f9e3@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i830oNCq043292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Sep 2004 00:50:28 GMT (envelope-from roy+dated+1096764592.c2f9e3@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i830nqhl043328 for ; Fri, 3 Sep 2004 01:49:52 +0100 (BST) (envelope-from roy+dated+1096764592.c2f9e3@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i830nq5j043327 for ietf-mxcomp@imc.org; Fri, 3 Sep 2004 01:49:52 +0100 (BST) (envelope-from roy+dated+1096764592.c2f9e3@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 03 Sep 2004 01:49:52 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.49071.671776.708651@giles.gnomon.org.uk> Date: Fri, 3 Sep 2004 01:49:51 +0100 To: ietf-mxcomp@imc.org Subject: TECH-ERROR/DOC-BUG: empty fields in -pra X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm tending to the opinion that the words 'non-empty' should simply be deleted from section 2 of -pra. They seem to serve no purpose other that to add complexity, and for all the header fields in question, empty field bodies are illegal, and I don't believe they are prevelent in the wild. If they must remain, then the wording should be made more accurate, ie "Locate the first non-empty Resent-Sender header in the message." should become "Locate the first Resend-Sender field in the message that has a non-empty field body" and similarly for the other references. From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 21:37:51 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 VAA29451 for ; Thu, 2 Sep 2004 21:37: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 i8318CGC048976; Thu, 2 Sep 2004 18:08: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 i8318CNC048975; Thu, 2 Sep 2004 18:08:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8318BVE048969 for ; Thu, 2 Sep 2004 18:08:11 -0700 (PDT) (envelope-from roy+dated+1096765690.eebe45@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i8318fMA044985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Sep 2004 01:08:47 GMT (envelope-from roy+dated+1096765690.eebe45@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i8318A6W043518 for ; Fri, 3 Sep 2004 02:08:10 +0100 (BST) (envelope-from roy+dated+1096765690.eebe45@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i8318AKf043517 for ietf-mxcomp@imc.org; Fri, 3 Sep 2004 02:08:10 +0100 (BST) (envelope-from roy+dated+1096765690.eebe45@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 03 Sep 2004 02:08:10 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16695.50169.927924.205196@giles.gnomon.org.uk> Date: Fri, 3 Sep 2004 02:08:09 +0100 To: ietf-mxcomp@imc.org Subject: TECH-ERROR: versioning In-Reply-To: <16695.48136.742801.125862@giles.gnomon.org.uk> References: <16695.48136.742801.125862@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Of course, what I wrote allows spf2.0/pra,mailfrom ... and spf2.0/mailfrom,pra ... to be both recognized by -protocol. But it forbids having two records spf2.0/pra ... spf2.0/mailfrom ... Of rather, if both such records exists, then neither would be used by -protocol. It seems cleaner to define it as I propose, but I don't have strong feelings on disallowing multiple spf/2.x records as long as only one of them has the "pra" token. I can see that the alternative approach may have merit, too... -roy From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 21:38:55 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 VAA29585 for ; Thu, 2 Sep 2004 21:38:54 -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 i831DM0V049516; Thu, 2 Sep 2004 18:13:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i831DMmH049515; Thu, 2 Sep 2004 18:13:22 -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 i831DL4G049507 for ; Thu, 2 Sep 2004 18:13:21 -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 1C32di-0006C9-1r for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 20:13:27 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Thu, 02 Sep 2004 20:13:17 -0500 In-Reply-To: (wayne@midwestcs.com's message of "Mon, 12 Jul 2004 22:18:59 -0500") 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: Obstacles between us and the finish line 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.6 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: Back on July 1, I posted a message with the subject "Obstacles between us and the finish line". I posted an updated to it two weeks later. I decided to go back and post another updated. The first two messages message can be found here: http://www.imc.org/ietf-mxcomp/mail-archive/msg02476.html http://www.imc.org/ietf-mxcomp/mail-archive/msg02651.html > Deadlines for this working group are rapidly approaching. According > to Andy's recent post, we have about 2 weeks (until 07/18) to finish > things up. For those who don't remember, 7/18 was the first deadline for MS to fix the license. > In my (oh so very humble) opinion, I see the following obstacles in > the way: > > 1) Proposals must have solid I-Ds > > 2) Proposals must have working code > > 3) Proposals must have been tested on real world data > > 4) Proposals must have IP licensing terms that allow for use in both > commercial and GPLed MTAs. > > 5) Proposals must not have gratuitous incompatibilities with an > installed base. > > > I have said from very early on that I think we may well need more than > one RFC to handle the various identities. To be quite honest, I don't > care if we have a dozen overlapping proposals, I think the market can > easily decide which are useful. > > As such, I see the following proposals that may be considered: > SPF-classic, CSV, Sender-ID and Unified-SPF. > > It appears to DMP, FSV, and Caller-ID are no longer being pushed by > anyone. > > > I'm going to go over all the proposals in a sec, but I think I should > make a few comments on the requirements. > > 1) solid I-Ds: Proposals must have been gone over with many eyes, > especially with developer's eyes when they are trying to implement the > proposal. I think it is far too late to do anything with a proposal > other than use it to implement code and make adjustments based on that > experience. > > 2) working code, and 3) testing, I think are pretty obvious. > > 4) IP licensing: I'm not dogmatic about the GPL or commercial > licenses, but there are significant MTAs and mail filters that fall > under both kinds of licenses, and several others to boot. I think > that any proposal that has incompatible IP licensing needs to be > dropped. Sadly, in response to this post back in July, Ted Hardie (the IETF Area Director for this WG), told us to stop worry about IP licensing issues. I believe the mess we are in right now is a direct result of this. Instead of getting the IP licensing issue resolved *much* earlier on, we now have a crisis and a no-win situation. > 5) Incompatibilities: Proposals such as SPF have a significant install > base and doing things like moving the location of the TXT records, > dropping macros, or using a different RR, etc. make no sense to me and > will likely run into a buzz saw with SPF adopters. > > > > Ok, so how do the current proposals stack up? > > > **** SPF-classic **** > > 1) solid I-D: Yes > It was supposed to have been submitted as an experiemental RFC, but I > don't know the status. > > 2) working code: Yes > Lots of working code in fact. New announcements of commercial > products using SPF a couple of times a week. > > 3) Tested: Yes > It is being used to check millions of emails per day. > > 4) IP Licensing: No problems > > 5) gratuitous incompatibilities: None. > > > I think SPF-classic should certainly be *one* of the proposals put > forth by this working group. I think it is really too bad that SPF-classic was not *one* of the proposals. It would have made our live much easier right now. > **** CSV **** > > 1) solid I-D: pretty good > To the best of my knowledge, no one has tried to implement code based > on it, but it appears to have been well reviewed by a fair number of > people. I think there is time to get implementation experience if the > backers hurry. Better I-Ds have been put forward, but I know of no change on the implementation experience part. > > 2) working code: none > > 3) testing: none > > 4) IP Licensing: No problems > > 5) gratuitous incompatibilities: None. > > > I think that CSV could be one of the proposals, if its backers quickly > start creating working code and doing testing. I think it is kind of funny that CSV has made it on the WG TODO list, but neither SPF-classic nor Unified-SPF did. > **** Sender-ID **** > > 1) solid I-D: No > I have looked again at the draft-ietf-marid-core-01.txt I-D, and > frankly, it is not even close to being in a state worth commenting on. > It is hugely incomplete and incompatible with SPF, which it tries to > be compatbile with. I can't see it becoming solid in the next couple > of weeks. The SenderID I-Ds have been much improved since July, but I think there are still a lot of rough edges. > 2) working code: none > In particular, the PRA and SUBMITTER are both on paper only. There is now some working code for the PRA, but none for SUBMITTER. > 3) testing: none > I requested results of the PRA algorithm the first day that the > Caller-ID spec was proposed to this working group. I made a point of > raising the issue at the interim meeting. In the many months since > then, nothing has been forth coming. I am getting seriously worried > about this. Ok, a little small-scale testing has been done on the PRA now, but the results have only shown that it doesn't work very well. > 4) IP Licensing: problems > It appears that the Sender-ID's license is incompatible with the GPL. > This could, in theory, be fixed very quickly, but the issues of IP > disclosure and licensing problems has been known since before the > interim meeting and nothing has been done. Woah. Here we are two months later and *STILL* nothing has been done. > 5) gratuitous incompatibilities: None. > In theory, the only incompatiblity is that it tries to use existing > SPF records for 2822 checks. Since SPF records were published with > the idea that they would be used for 2821.FROM and 2821.HELO, there > could be problems. Ah, gratuitous incompatibilities have been introduced with the change of the version number. > In practice, there are many incompatiblities with the current > Sender-ID spec and the SPF spec. > > > While Sender-ID appears to be the RFC-apparent for this WG, I have > very serious doubts that it will be in any shape to be advanced before > the deadlines. I am beginning to think this proposal should be > dropped as the backers of key parts appear to be moving way too > slowly. Well, Sender-ID wasn't in shape to make the deadline of 7/18, so the deadline was moved. > **** Unified-SPF **** > > 1) solid I-D: fuzzy > As Dave Crocker pointed out in a message earlier today, there is no > Unified-SPF I-D. This needs to be fixed ASAP or this proposal must be > dropped. Fortunately, the differences between SPF-classic and > Unified-SPF are small enough that I think I-Ds could be written fairly > quickly and yet remain pretty solid. > > 2) working code: none > > 3) testing: none > > 4) IP Licensing: No problems > > 5) gratuitous incompatibilities: None. > The Unified-SPF proposal needs to make some changes to the SPF records > in order to support the various scopes that it tries to cover. This > can be solved several ways. > > > I think that Unified-SPF has a chance to be a solid proposal, but the > I-Ds need to be written and the changes to the SPF-classic code needs > to be tested. > > > > **** DMP **** > > Ok, I said DMP isn't being pushed by anyone, but I'll list it anyway > > 1) solid I-D: Yes > > 2) working code: Yes > > 3) testing: Yes > > 4) IP Licensing: No problems > > 5) gratuitous incompatibilities: None. > > > I think that DMP is in far better shape than most of the other > proposals that appear to be much more likely to advanced by this > working group. *boggle* > > > Right now, I would say that SPF-classic and DMP are the only proposals > that are ready for RFC consideration. For backers of other proposals: > you have two weeks to finish. I wish I could say we have come a long way, but I don't think we have. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 21:53:26 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 VAA00437 for ; Thu, 2 Sep 2004 21:53:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i831W4AV051010; Thu, 2 Sep 2004 18:32: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 i831W4sG051009; Thu, 2 Sep 2004 18:32:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i831W3V8050999 for ; Thu, 2 Sep 2004 18:32:04 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 01:32:04 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "Rand Wacker" Subject: RE: (DEPLOY) In Support of Sender ID Date: Thu, 2 Sep 2004 19:32:15 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 03 Sep 2004 01:32:04.0318 (UTC) FILETIME=[D15087E0:01C49155] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ryan Malayter wrote: > SPFv1 does not address email header forging at all. So SPFv1 does very > little to prevent forging of the "from" addresses seen by the user in > 99% of MUAs. SPFv1 therefore does very little to prevent phishing scams. > This is why Microsoft came up with CallerID for email, and why Meng and > MS decided to merge the best parts of SPF and Caller ID into SenderID > approaches. Michael R. Brumm wrote: > SPF protects envelope forging correctly. SenderID doesn't. > > While SPF doesn't prevent forging of 2822 addresses seen by 99% of MUAs, the > same could be said of SenderID. I don't know of any MUAs which display the > PRA as described by SenderID. Rand Wacker wrote: > As I said before, there is a large majority of mail that goes from large > commercial sites (or consumer ISPs) merely one hop to another large > commercial ISP, so the From: header will be successfully authenticated. The problem with SenderID I mentioned is that most of the other PRA fields (besides From:) are invisible in most MUAs, and therefore allow forgers to spoof the From field anyway. The solution to this problem is, of course, upgrading MUAs to display the PRA field. But according to Ryan, SenderID's improvement over SPF was that MUAs didn't need to be upgraded. I'm not sure how the number of hops or the business model used by the MTAs affects this. In any case, if we are talking about upgrading MUAs en-masse to combat 2822 header forging and phishing, then I think the only good solution is cryptography and signing. However, this is probably outside the scope of MARID. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 22:01: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 WAA00925 for ; Thu, 2 Sep 2004 22:01:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i831epdg051460; Thu, 2 Sep 2004 18:40: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 i831ep03051459; Thu, 2 Sep 2004 18:40:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i831eosb051450 for ; Thu, 2 Sep 2004 18:40:51 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 01:40:49 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: PRA Patent: License for Display in MUAs? Date: Thu, 2 Sep 2004 19:41:00 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 V6.00.2900.2180 Importance: Normal X-OriginalArrivalTime: 03 Sep 2004 01:40:49.0432 (UTC) FILETIME=[0A4E9180:01C49157] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm wondering, since there has been talk about displaying the SenderID PRA in MUAs, would Microsoft's patent claims and licensing apply to MUAs also? I imagine that the steps used by an MTA to extract the PRA for evaluation would be the same as the steps used by an MUA to extract the PRA for display... If licensing FOSS MTAs are problematic with SenderID, I'd imagine that FOSS MUAs would greatly compound the problem. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 22:14:17 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 WAA01624 for ; Thu, 2 Sep 2004 22:14:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i831p0m1052595; Thu, 2 Sep 2004 18:51:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i831p0VS052594; Thu, 2 Sep 2004 18:51:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i831oxBk052585 for ; Thu, 2 Sep 2004 18:51:00 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1C33EG-000KzA-00 for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 02:51:04 +0100 Message-ID: <245201c49158$23d9c380$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: DEPLOY: Sender-ID provides little or no defence against adaptive threats Date: Fri, 3 Sep 2004 02:48:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 One of the problems with this attempted 'fast tracking' of Sender-ID is that, AFAICT, there has been no systematic catalog made of the threats against which Sender-ID is supposed to defend, and no analysis of its ability to defend against those threats - particularly when the threat-designers adapt them to take Sender-ID into account. Here is a first, simplistic attempt at what such a catalog might contain, collected mostly from other people's postings. Because of time and space restrictions, I'm going to just present these as personal assertions. There are, of course, special cases and boundary conditions, but I've tried to be as fair as I can about the broad thrust of the strengths and weaknesses of Sender-ID. My purpose is to cause some readers, perhaps those who have recently joined this list and are offering the support of the large organisations they represent, cause to pause for a minute, and ask their expert colleagues if 'this unknown Brit' could possibly have a point. In the brief list below I am considering only: - Consumer users - Who are using current versions of MS Outlook Express (OE) - Who do not know how to access or interpret the message headers. I guess that this probably covers the majority (i.e > 50%) of consumer users in the world. I am also assuming that the 'bad guys' have read and understood Sender-ID and so will have made whatever simple adaptations are necessary to continue to unleash their mischief. I have also assumed that the 'good guys' will have done all they should - i.e. implemented Sender-ID records with '+' records on their outbound MTAs and '-all' (or equivalent) for all other sources. =================== * Sender-ID blocks Phishing eMails - WRONG A Phisher need only use the headers From: Big Bank Security Resent-Sender: phisher@badguy.com and have a legitimate domain: 'badguy.com" with SPF records. The PRA test will 'pass' badguy.com, but there is no way to tell that user that test has been done, let alone what address was actually tested. The user will see "From: Big Bank Security" on her OE display. See David's post of an hour or so ago for further detail. ===================== * Sender-ID lets genuine senders show they are not Phishers - WRONG The Big Bank can send a message with a header From: Big Bank Security The PRA test on 'bigbank.com' will pass and the user will see "From: Big Bank Security" on her OE display. This is exactly the same as she saw when the phisher wrote to her, and is also exactly the same as if the bank did not implement Sender-ID at all. ====================== *Sender-ID stops spam - WRONG All a spammer has to do is register a domain and set up SPF records. As far as any MTA using the Sender-ID test is concerned, all spam which can pass the Sender-ID test is allowed through. Sender-ID itself has no ability to distinguish spam from ham. Some people posting to the spf-discuss list believe they can detect spammers amongst the early, enthusiastic adopters of SPF! ======================== *Sender-ID stops viruses - WRONG Recall that I am assuming that the virus-writers will adapt to the presence of Sender-ID. A virus writer who gains access to a 'trojaned' PC will cause the outbound mails to be sent through the SMTP server of the machine's normal ISP (if the trojan horse can access the address list, it can, in many cases, also work out the address of the ISPs' SMTP server). Many ISPs will accept the mail as genuine with no further checks, so the virus-carrying mail will emerge from the ISP appearing exactly like a legitimate mail from the same end-host, and will pass any SPF tests the ISP has set up. The only inconvenience to the virus-writer is that the message rate may be lower than when he used to send mails directly to the victims. =================================== So why use Sender-ID? Well, Sender-ID, just like other header forgery detection system such as SPF-Classic, forces some of the bad guys to have to use their own domains, and to set up SPF records. This introduces an additional element of traceability, via the domain registration process, and perhaps an element of stability (they will have to use the same domain several times) giving reputation systems a better chance to spot them. So, used in conjunction with _today's_ Outlook Express MUAs Sender-ID's PRA test is just as good / bad as the (licence-free) SPF test. Oh, and Sender-ID has a security vulnerability (a weak defence against 'bounce-bombs' ) which SPF has a defense against. In the long-term it might be possible to evolve Sender-ID _and_ a new generation of MUAs to provide users with a display which they could be educated to use to detect Phishing attempts. You will have to use your own judgement of Microsoft's product cycle times to decide how long is will be until, say, 20% of the installed consumer base would have this feature before their eyes. I myself would be amazed if even this small level of penetration could be achieved before 2007. ----------------------------------- So - just what benefits are you selling to your organisations when you support this current, rushed version of Sender-ID on their behalf - and are you _sure_ that you can deliver on those benefits? Are they in your personal objectives for 2004? Do you feel lucky? ========================== Personal statement re: DEPLOYment At present my plans are to implement SPF in our special-purpose MTAs, which are designed and implemented within my own organisation. Since, in the short term the majority of my users will continue to use Outlook Express and similar Sender-ID-unaware MUAs, and since Sender-ID provides no technical benefit over SPF in this time frame, and since Sender-ID has a security vulnerability which is not present in SPF, and since Sender-ID is encumbered with a licence which appears to require me to notify Microsoft of my business intentions, and since that same licence may be withdrawn by Microsoft at any time, I have no business justification for implementing and deploying Sender-ID at this time. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 22:19:59 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 WAA01965 for ; Thu, 2 Sep 2004 22:19: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 i831xOmm053528; Thu, 2 Sep 2004 18:59: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 i831xOv2053527; Thu, 2 Sep 2004 18:59:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i831xNt5053514 for ; Thu, 2 Sep 2004 18:59:23 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so97071rnk for ; Thu, 02 Sep 2004 18:59:24 -0700 (PDT) Received: by 10.38.164.76 with SMTP id m76mr3185701rne; Thu, 02 Sep 2004 18:59:24 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Thu, 2 Sep 2004 18:59:24 -0700 (PDT) Message-ID: <94df60cf040902185938a7d947@mail.gmail.com> Date: Thu, 2 Sep 2004 21:59:24 -0400 From: Reply-To: To: Harry Katz Subject: Re: Sendmail releases open source Sender ID milter for testing Cc: ietf-mxcomp@imc.org, Rand Wacker In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2 Sep 2004 17:42:51 -0700, Harry Katz wrote: > On Wednesday, September 01, 2004 2:49 PM, mazieres@gmail.com > > > [mailto:mazieres@gmail.com] wrote: > > > On Wed, 1 Sep 2004 09:55:52 -0700, Harry Katz > > wrote: > > > > > Second as per the terms of the license itself, End Users who are > > > recipients of a licensed implementation of Sender ID and > distributors > > > who are redistributing a branded licensed implementation do not need > > > > to separately sign this License Agreement. > > > > I understand your the point about End Users, but could you > > clarify how the license exempts distributors? Specifically, > > my concern is that while section 2.1 allows indirect > > distribution of object code, section 2.2, which applies to > > source code, does not. > > Section 2.2 references 2.1 in a way that makes it permissible to > "indirectly" distribute the source code versions of the Licensed > implementations too. In other words, if you're redistributing a > licensed branded implementation - either source or binary - you don't > need to execute the license agreement. Sorry, can you explain in more detail? I'd like to belive this is the case, but I'm just not seeing that in the text of the agreement. 2.2 gives me a "license to distribute or otherwise disclose source code copies of such Licensed Implementation licensed in Section 2.1..." So it sounds like the source code has to correspond to a binary licensed in 2.1, but I don't see how the reference to 2.1 affects the distribution of source code. As I read that sentence, the only options for source code are to "distribute" or "otherwise disclose". Does having a third party like sourceforge distribute your source code count as "otherwise disclosing" the source code? Is it really the case that sourceforge wouldn't need their own license? Is one of the lawyers on the list willing to vouch for this interpretation? David David From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 22:53: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 WAA03554 for ; Thu, 2 Sep 2004 22:53:45 -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 i832S3U4056140; Thu, 2 Sep 2004 19:28:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i832S3J0056139; Thu, 2 Sep 2004 19:28:03 -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 i832S2BQ056132 for ; Thu, 2 Sep 2004 19:28:02 -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 i832bgDr018017; Thu, 2 Sep 2004 19:37:42 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i832bfsS018013; Thu, 2 Sep 2004 19:37:41 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 2 Sep 2004 19:37:41 -0700 (PDT) From: "william(at)elan.net" To: "Michael R. Brumm" cc: IETF MARID WG Subject: Re: PRA Patent: License for Display in MUAs? 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: Microsoft may have misled others that SenderID and PRA algorithm can be used by MUAs to verify email (because of their dominance in MUA market on Windows PCs, they need something for MUAs). That is not true. SenderID is designed to verify email for SMTP servers directly talking to each other, it is NOT a good idea to use the same methods after the completion of SMTP transmission! Although, if authentication did occur on the SMTP level, it is a good idea to be able to inform end-users about that and to inform them what address was verified. For more information on why MUAs should not be used, please see the following messages posted earlier: http://www.imc.org/ietf-mxcomp/mail-archive/msg03769.html http://www.imc.org/ietf-mxcomp/mail-archive/msg03961.html I also would remind that MARID WG is about authentication methods for MTAs, this group has not been chartered to produce specification to be used for MUA verification of emails. Topics of MUA verification of email are appropriate for S/MIME and OpenPGP workgroups. And please feel free to reread the charter if you disagree with this statement. See: http://www.ietf.org/html.charters/marid-charter.html On Thu, 2 Sep 2004, Michael R. Brumm wrote: > I'm wondering, since there has been talk about displaying the SenderID PRA > in MUAs, would Microsoft's patent claims and licensing apply to MUAs also? I > imagine that the steps used by an MTA to extract the PRA for evaluation > would be the same as the steps used by an MUA to extract the PRA for > display... > > If licensing FOSS MTAs are problematic with SenderID, I'd imagine that FOSS > MUAs would greatly compound the problem. > > Michael R. Brumm > -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 23:18: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 XAA04888 for ; Thu, 2 Sep 2004 23:18: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 i832oABB057650; Thu, 2 Sep 2004 19:50:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i832oA4K057649; Thu, 2 Sep 2004 19:50:10 -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 i832o9Fr057643 for ; Thu, 2 Sep 2004 19:50: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 67961414C7 for ; Thu, 2 Sep 2004 19:50:15 -0700 (PDT) Subject: Re: Obstacles between us and the finish line From: Douglas Otis To: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1094179813.19890.267.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 02 Sep 2004 19:50:13 -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-09-02 at 18:13, wayne wrote: > > > **** CSV **** > > > > 1) solid I-D: pretty good > > To the best of my knowledge, no one has tried to implement code based > > on it, but it appears to have been well reviewed by a fair number of > > people. I think there is time to get implementation experience if the > > backers hurry. > > Better I-Ds have been put forward, but I know of no change on the > implementation experience part. > > > > 2) working code: none > > > > 3) testing: none Not extensive, but more than none. > > 4) IP Licensing: No problems > > > > 5) gratuitous incompatibilities: None. > > > > > > I think that CSV could be one of the proposals, if its backers quickly > > start creating working code and doing testing. > > I think it is kind of funny that CSV has made it on the WG TODO list, > but neither SPF-classic nor Unified-SPF did. Looking to the next step, CSV offers an extremely simple extension to RFC2821 for authenticating the EHLO domain. I see this as highly important for reputation services, as identities obtained from either Sender-ID or SPF are not suitable for basing reputation assertions without running considerable risk when making assumptions of the integrity of the mail channel. Once CSV is in place, to implement something extremely similar to SPF or Sender-ID becomes just a trivial name list created using PTR records much like DNA. I was hoping to get some feedback before offering code. http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt I would not expect many to be satisfied with just an EHLO check. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 2 23:34: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 XAA05943 for ; Thu, 2 Sep 2004 23:34:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8337iIs058645; Thu, 2 Sep 2004 20:07: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 i8337iu9058644; Thu, 2 Sep 2004 20:07:44 -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 i8337h7g058636 for ; Thu, 2 Sep 2004 20:07:43 -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 1C34QS-0007TF-IP for ietf-mxcomp@imc.org; Thu, 02 Sep 2004 22:07:49 -0500 To: "IETF MARID WG" References: <94df60cf040902185938a7d947@mail.gmail.com> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 02 Sep 2004 22:07:44 -0500 In-Reply-To: <94df60cf040902185938a7d947@mail.gmail.com> (mazieres@gmail.com's message of "Thu, 2 Sep 2004 21:59:24 -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: Sendmail releases open source Sender ID milter for testing 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.6 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 <94df60cf040902185938a7d947@mail.gmail.com> writes: > On Thu, 2 Sep 2004 17:42:51 -0700, Harry Katz > wrote: > >> Section 2.2 references 2.1 in a way that makes it permissible to >> "indirectly" distribute the source code versions of the Licensed >> implementations too. In other words, if you're redistributing a >> licensed branded implementation - either source or binary - you don't >> need to execute the license agreement. Harry: Is this your opinion, or Microsoft's lawyer's opinion? > Sorry, can you explain in more detail? I would like more details also. > [...] I'm just not seeing that in the text of the agreement. > [explanation deleted] Your explanation complete agrees with what I understand the license to say. > Does having a third party like sourceforge distribute your source code > count as "otherwise disclosing" the source code? Is it really the > case that sourceforge wouldn't need their own license? Is one of the > lawyers on the list willing to vouch for this interpretation? Well, I asked a lawyer about this very subject and got an informal opinion that pretty much agrees with your understanding and conflicts with Harry's. Basically, the *only* source code distributions that are allowed under the SenderID license are those that corrispond with object code implementations. Source code in the form of a patch is not allowed because it won't compile. Any redistribution from a third party like sourceforge requires a license. Anyone who modifies even a single #define in the source code so that the resulting object code is different needs to get a license. Now, my paraphrasing of what the lawyer said may well have mangled a few things. I won't repost private email, so I would appreciate any lawyer posting answers to David's questions directly to the list. MS lawyers would be best. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 01:12: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 BAA11890 for ; Fri, 3 Sep 2004 01:12:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i834mabn065815; Thu, 2 Sep 2004 21:48:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i834ma2M065814; Thu, 2 Sep 2004 21:48:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i834mZTm065804 for ; Thu, 2 Sep 2004 21:48:35 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 04:48:33 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "william\(at\)elan.net" Subject: RE: PRA Patent: License for Display in MUAs? Date: Thu, 2 Sep 2004 22:48:45 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 03 Sep 2004 04:48:33.0481 (UTC) FILETIME=[44340B90:01C49171] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit William, I am not an idiot. Please re-read the post. I am not talking about *performing* SenderID in the MUA, I'm talking about *displaying* the SenderID PRA in the MUA. Viewing the results of an MTA's MARID evaluations (in the MUA or elsewhere) is pertinent to the MARID charter. Thanks, Michael R. Brumm -----Original Message----- From: william(at)elan.net [mailto:william@elan.net] Sent: Thursday, September 02, 2004 08:38 PM To: Michael R. Brumm Cc: IETF MARID WG Subject: Re: PRA Patent: License for Display in MUAs? Microsoft may have misled others that SenderID and PRA algorithm can be used by MUAs to verify email (because of their dominance in MUA market on Windows PCs, they need something for MUAs). That is not true. SenderID is designed to verify email for SMTP servers directly talking to each other, it is NOT a good idea to use the same methods after the completion of SMTP transmission! Although, if authentication did occur on the SMTP level, it is a good idea to be able to inform end-users about that and to inform them what address was verified. For more information on why MUAs should not be used, please see the following messages posted earlier: http://www.imc.org/ietf-mxcomp/mail-archive/msg03769.html http://www.imc.org/ietf-mxcomp/mail-archive/msg03961.html I also would remind that MARID WG is about authentication methods for MTAs, this group has not been chartered to produce specification to be used for MUA verification of emails. Topics of MUA verification of email are appropriate for S/MIME and OpenPGP workgroups. And please feel free to reread the charter if you disagree with this statement. See: http://www.ietf.org/html.charters/marid-charter.html On Thu, 2 Sep 2004, Michael R. Brumm wrote: > I'm wondering, since there has been talk about displaying the SenderID PRA > in MUAs, would Microsoft's patent claims and licensing apply to MUAs also? I > imagine that the steps used by an MTA to extract the PRA for evaluation > would be the same as the steps used by an MUA to extract the PRA for > display... > > If licensing FOSS MTAs are problematic with SenderID, I'd imagine that FOSS > MUAs would greatly compound the problem. > > Michael R. Brumm > -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 01:46: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 BAA13751 for ; Fri, 3 Sep 2004 01:46: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 i835PPuf077120; Thu, 2 Sep 2004 22:25: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 i835PPJp077119; Thu, 2 Sep 2004 22:25:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i835PNgC077015 for ; Thu, 2 Sep 2004 22:25:24 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i835PLQc020048 for ; Fri, 3 Sep 2004 06:25:21 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i835PLUP020047; Fri, 3 Sep 2004 06:25:21 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID References: From: Graham Murray Date: Fri, 03 Sep 2004 06:25:21 +0100 In-Reply-To: (Rand Wacker's message of "Thu, 2 Sep 2004 15:06:49 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Rand Wacker writes: > As I said before, there is a large majority of mail that goes from large > commercial sites (or consumer ISPs) merely one hop to another large > commercial ISP, so the From: header will be successfully authenticated. In the case of sending from a large ISP (and that includes commercial sites who outsource email) that is not true. Unless the ISP does additional checking then Sender-ID (and SPF) still allows a customer of the ISP to forge the mail as coming from any other customer of that ISP. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 02:19: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 CAA29244 for ; Fri, 3 Sep 2004 02:19:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i835ul8A094995; Thu, 2 Sep 2004 22:56:47 -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 i835ulFW094994; Thu, 2 Sep 2004 22:56:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i835ukh6094946 for ; Thu, 2 Sep 2004 22:56:47 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i835umDB020364 for ; Fri, 3 Sep 2004 06:56:48 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i835umFV020362; Fri, 3 Sep 2004 06:56:48 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Obstacles between us and the finish line References: <1094179813.19890.267.camel@ddev.mail-abuse.org> From: Graham Murray Date: Fri, 03 Sep 2004 06:56:48 +0100 In-Reply-To: <1094179813.19890.267.camel@ddev.mail-abuse.org> (Douglas Otis's message of "Thu, 02 Sep 2004 19:50:13 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis writes: > Once CSV is in place, to implement something extremely similar to SPF or > Sender-ID becomes just a trivial name list created using PTR records > much like DNA. Unfortunately this is not quite as trivial as it seems. I believe that PTR records are not the easiest records for the domain owner (especially the owner of small domains) to have control over. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 02:37: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 CAA01101 for ; Fri, 3 Sep 2004 02:37:32 -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 i836CRbj002000; Thu, 2 Sep 2004 23:12:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i836CRE8001996; Thu, 2 Sep 2004 23:12:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i836CPnU001949 for ; Thu, 2 Sep 2004 23:12:26 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C37HY-0005Tk-1N for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 02:10:44 -0400 Message-ID: <41380B49.9040603@solidmatrix.com> Date: Fri, 03 Sep 2004 02:12:25 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "IETF MXCOMP (E-mail)" Subject: DEPLOY: On the IPR debate Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just a few comments... First of all, the final call period is only a few days away. Lets get our hands cracking and see if we can get any remaining technical issues out of the woodwork and bring them to the attention of the group. Even if some of us are against it on IPR principles, we can still look at the technical aspects. The IPR issue is on the table, the chairs are very well aware of it, and everyone's opinion is on record. It may very well happen that the IPR issues may end up being resolved. Second, the IETF standards process is not a "all or nothing" decision. Approval by the WG is only the first step. There is still IESG approval with its own final call period, which may bring additional comments and requests for changes from the wider community. Code still remains to be written and tested, possibly adjusting the standard. The standard will only be in "Proposed" stage anyway for a while, and may very well change. And of course, we probably will be forced to make changes in order to close loopholes that spammers will manage to find. We got a long road ahead of us, full of coding, testing and making adjustments. Lets not lose sight of that. Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 02:39: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 CAA01213 for ; Fri, 3 Sep 2004 02:38: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 i836IvL6004406; Thu, 2 Sep 2004 23:18: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 i836Ivuf004405; Thu, 2 Sep 2004 23:18:57 -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 i836IvPo004386 for ; Thu, 2 Sep 2004 23:18:57 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i836Its0008423 for ; Thu, 2 Sep 2004 23:18:55 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <21AE96C1-FD71-11D8-BA2B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: DEPLOY: Sender-ID provides little or no defence against adaptive threats Date: Thu, 2 Sep 2004 23:18:54 -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 > I am also assuming that the 'bad guys' have read and understood > Sender-ID and > so will have made whatever simple adaptations are necessary to > continue to > unleash their mischief. cf. CipherTrust's study released this week in which >50% of the sources for all email surveyed which published SPF records were spammers. http://www.infoworld.com/article/04/08/31/HNspammerstudy_1.html Anne From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 02:57:40 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 CAA02450 for ; Fri, 3 Sep 2004 02:57:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i836YOX5009940; Thu, 2 Sep 2004 23:34: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 i836YObq009939; Thu, 2 Sep 2004 23:34:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i836YOj0009927 for ; Thu, 2 Sep 2004 23:34:24 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C37cf-0006Qb-9t for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 02:32:33 -0400 Message-ID: <41381066.8030902@solidmatrix.com> Date: Fri, 03 Sep 2004 02:34:14 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "IETF MXCOMP (E-mail)" Subject: DOC-BUG: SUBMITTER Spelling mistake Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Section 4.1 of the submitter draft states: " SMTP clients MUST set the SUMBITTER parameter value to the purported responsible address of the message as defined in [PRA]. This also applies to messages containing a null reverse-path. " The extension name is mis-spelled, it should be SUBMITTER. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 03:08: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 DAA03017 for ; Fri, 3 Sep 2004 03:08: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 i836gHRU013105; Thu, 2 Sep 2004 23:42:17 -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 i836gHHg013104; Thu, 2 Sep 2004 23:42:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from icicle.pobox.com (icicle.pobox.com [207.8.226.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i836gGH8013079 for ; Thu, 2 Sep 2004 23:42:16 -0700 (PDT) (envelope-from SRS0=7G+L=LY=dumbo.pobox.com=mengwong@bounce2.pobox.com) Received: from emerald.pobox.com (emerald.pobox.com [207.8.226.12]) by icicle.pobox.com (Postfix) with ESMTP id 2194B11ADFA for ; Fri, 3 Sep 2004 02:42:16 -0400 (EDT) Received: from dumbo.pobox.com (unknown [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id AEAFF1341FC for ; Fri, 3 Sep 2004 02:41:04 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id AC5075D6; Fri, 3 Sep 2004 02:42:13 -0400 (EDT) Date: Fri, 3 Sep 2004 02:42:13 -0400 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID Message-ID: <20040903064213.GA23667@dumbo.pobox.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 06:25:21AM +0100, Graham Murray wrote: | | Rand Wacker writes: | | > As I said before, there is a large majority of mail that goes from large | > commercial sites (or consumer ISPs) merely one hop to another large | > commercial ISP, so the From: header will be successfully authenticated. | | In the case of sending from a large ISP (and that includes commercial | sites who outsource email) that is not true. Unless the ISP does | additional checking then Sender-ID (and SPF) still allows a customer | of the ISP to forge the mail as coming from any other customer of that | ISP. My read of most ISPs is that they are willing to move in this direction if it proves necessary. Many ISPs are beginning to roll out (mandatory) SMTP AUTH. With that in place, halting cross-customer forgery becomes a much more likely proposition. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 03:55:24 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 DAA05386 for ; Fri, 3 Sep 2004 03:55:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i837OMYK031101; Fri, 3 Sep 2004 00:24:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i837OMDD031100; Fri, 3 Sep 2004 00:24:22 -0700 (PDT) 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 i837OLZI031067 for ; Fri, 3 Sep 2004 00:24:22 -0700 (PDT) (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 i837OGYh063071 for ; Fri, 3 Sep 2004 07:24:16 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 i837OGE5002493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Sep 2004 09:24:16 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i837OGVI002492 for ietf-mxcomp@imc.org; Fri, 3 Sep 2004 09:24:16 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Fri, 3 Sep 2004 09:24:16 +0200 From: gmc@metro.cx To: IETF MARID WG Subject: Re: (DEPLOY) In Support of Sender ID Message-ID: <20040903072416.GE2390@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 02, 2004 at 03:06:49PM -0700, Rand Wacker wrote: > > For this reason, it may end up being the case that Sender ID can not > reliably prevent spoofing for messages that take complex paths; but there > is some solace in that these complex paths are usually managed by the > *receiver*. But what prevents a malicious individual to either set up such complex path himself or pretend that the message is travelling through such a complex path? As I understand it, the 2822 headers are easy to make up yourself (in fact, the senderid documents endorse doing this), which makes it easy to fool the senderid check. Koen -- 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/ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 03:56: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 DAA05476 for ; Fri, 3 Sep 2004 03:56: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 i837Vbbb033724; Fri, 3 Sep 2004 00:31:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i837Vbou033723; Fri, 3 Sep 2004 00:31:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.old-mill.net (old-mill-adsl.demon.co.uk [80.176.87.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i837Va44033674 for ; Fri, 3 Sep 2004 00:31:37 -0700 (PDT) (envelope-from nick@old-mill.net) To: ietf-mxcomp@imc.org Subject: Correction to: Microsoft Claimed IP, License Terms, etc. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Nick Shelness Message-ID: Date: Fri, 3 Sep 2004 08:30:49 +0100 X-MIMETrack: Serialize by Router on MailGate/Home(Release 6.0|September 26, 2002) at 03/09/2004 08:30:09, Serialize complete at 03/09/2004 08:30:09 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In an earlier posting to this list, I stated: "Any individual or organization is free to write to the patent authorities in any and all jurisdictions claiming that IP that they believe has been submitted for patent protection is covered by "prior art" or is "obvious", both of which are grounds for rejection of a patent application." This was based on my experience of receiving an almost continuous stream of requests via Lotus/IBM patent attorneys to offer "prior art" or arguments of "obviousness" that would invalidate in-process patent applications. In response to a request from Hadmut Danisch , I have now investigated this situation further. Basically, I was wrong. There is no way of bringing un-patented "prior art" or an argument of "obviousness" to the attention of the US patent authorities prior to the "publication" of a patent application, or a request from a patent examiner for such information. It would appear that the latter was the source of "the stream of requests from Lotus/IBM patent attorneys to offer "prior art" or arguments of "obviousness" that would invalidate in-process patent applications" to which I referred earlier. With respect to "publication", the US patent approval process calls for a patent to be "published" some 18 months after its receipt, and prior to its acceptance or denial, but an applicant can request that an application not be "published", which effectively closes this window. Once, and if, an application has been "published", one may submit a "public document" that represents what one believes to constitute "prior art", but one may only submit the document, "unedited" (I'm not sure what this means), and referenced to its source. One may also submit a cover letter attached to the document, referencing the document as being relevant "prior art" to the "published" patent application in question. What one is unable to do is actually argue the case for this constituting "prior art". Thus, an applicant may argue, in a vacuum, that your document is not relevant, and in practice, I have been informed, "prior art" submitted in this way, almost never has an impact on the approval process. So, beyond the existence of patented "prior art" and the diligence of the patent examiner involved, there is no direct way for the community to bring "prior art" to bear on the patent approval process. There is an "examiner education program", under which the IESG or Internet Society may offer the opportunity of a "visit" as a means of educating examiners on the discovery of un-patented "prior art" in IETF archives, or how to solicit identification of un-patented "prior art" from IETF participants, but this is only an indirect means, and it may take many years, if ever, for the offer to be taken up. I apologize to the list for providing inaccurate information, and hope that the above clarifies the situation. Finally, I would comment that I have always viewed the issuance of a US patent as a license to "defend" a claim of IP ownership in the courts, and not as proof of ownership per se. Thus issuance is a necessary, but not sufficient, condition for establishing the ownership of IP. I have been confirmed in this view, by those experts I have asked for input on this matter. Nick Shelness Independent Technology Consultant From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 05:09: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 FAA09074 for ; Fri, 3 Sep 2004 05:08: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 i838e3T6059356; Fri, 3 Sep 2004 01:40:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i838e3Ei059355; Fri, 3 Sep 2004 01:40:03 -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 i838doVw059240 for ; Fri, 3 Sep 2004 01:40:03 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 632E526C070; Fri, 3 Sep 2004 10:39:46 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 540BE26C068; Fri, 3 Sep 2004 10:39:45 +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 i838djm7670372; Fri, 3 Sep 2004 10:39:45 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 05538FACE; Fri, 3 Sep 2004 10:39:44 +0200 (CEST) Date: Fri, 3 Sep 2004 10:39:45 +0200 From: Stephane Bortzmeyer To: Roy Badami Cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR: Name of SUBMITTER parameter Message-ID: <20040903083945.GA7584@nic.fr> References: <16695.45036.160556.552577@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16695.45036.160556.552577@giles.gnomon.org.uk> 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+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 12:42:36AM +0100, Roy Badami wrote a message of 17 lines which said: > The SUBMITTER parameter was fine as a working name (as was FRED, > DAVE, and all the rest of the names) but now that we're all in > agreement athat the name of the identity in question is the PRA, the > obvious name for the parameter to identify the PRA is "PRA". IMHO, we should do quite the opposite: get rid of every mention of -pra in the -submitter draft to be able to drop -pra (because of patent issues) while keeping -submitter (which is IMHO an useful addition to SPF-classic, which helps to solve the forwarding problem which cripples SPF-classic). From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 05:48:17 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 FAA11555 for ; Fri, 3 Sep 2004 05:48: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 i839OCYI076140; Fri, 3 Sep 2004 02:24: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 i839OCwS076139; Fri, 3 Sep 2004 02:24:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839OCBW076074 for ; Fri, 3 Sep 2004 02:24:12 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [192.168.253.26] (unknown[66.240.194.10]) by comcast.net (rwcrmhc11) with ESMTP id <2004090309240701300gookee> (Authid: dhlii); Fri, 3 Sep 2004 09:24:07 +0000 Message-ID: <4139B3B0.8000905@comcast.net> Date: Sat, 04 Sep 2004 05:23:12 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IETF-MXCOMP WG'" Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> In-Reply-To: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> 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 Anne P. Mitchell, Esq. wrote: > > But real people in the real world have to make decisions and they have to go forward. One of the problems I have with lawyers - and my wife is one, is that of course life comes with no guarantees. But in the end one must do something. A lawyer can tell you what the potential worst case scenario is, they can help you get out of the trouble that you are in, but it is extremely rare that you can get one to tell you what your best choice is - aside from do nothing, when there are no perfect choices. It does not matter whether it is Microsoft or HP, or a patent holding company. There is a claim without any support that the current draft includes IP that would require a license. The details of the license does not become relevant until you decide whether the claim has merit. The burden for testing the claim is very low. I do not think it is wise to try and become IP lawyers over this, but the burden is not non-existent. Because "we say so" is just not sufficient.. The fact that the claim is nebulous and unknown does not make it stronger. It makes it weaker. The unknown may be a scary place to be, but it is where we are. It is also not far from where we would be if Microsoft had not made a nebulous claim of IP rights. > > This brings up a point which has been rolling around in the back of my > head for a few days. > > We simply _don't_ know what is in the claim. In any other area where > adoption of some program is to be impacted or encumbered in some way > which could cause either a legal liability or an inability to actually > implement on the part of the adopter - particularly such a potentially > widely used program - it is inconceivable that people would be even > considering adopting, or recommending, the program. In fact, if one > had a professional license, and recommended adoption of such a program > without a clear understanding of the encumberance, one could be guilty > of malpractice. But I digress...what has been rolling around in the > back of my head is this: > > Can anyone say with 100% certainty that there is *zero* technology, > software, or process, which can be reasonably argued by Microsoft to > belong to them, with regards to *checking*? Bear in mind that I have > some experience in patenting this sort of technology (I have been > involved in the patent work on the Habeas "technology", among others, > and I put that word in quotes because if you look at the Habeas model > I'm guessing many of you would be shocked to realize just how much > *is* patentable as "technology"). > > Ok, I'm going to guess that some of you might say "yes" to the > above. So, let's put it another way now: > > Is the method for checking under Sender I.D. *identical* to the method > for checking for SPF? > > Imagine a world where some day you have to pay for a site license to > be able to perform a check. Where the only receiver who *doesn't* > have to pay to perform checks is Microsoft itself. > > Again, this is not Microsoft bashing - I personally believe that *any* > large receiver owning the ultimate rights to an authentication system > is a conflict of interest. > > And to be honest, for the life of me, I don't understand why SPF, > which already had a lot of support from other corners, isn't what's > being pushed now. Although, of course, for all we know (and I very > much suspect) SPF is probably now in some way encumbered by MS > anyways. It would be foolish of them to embrace and incorporate SPF > technology without first making sure that they darned well owned it. > Just like any other acquisition - you can either put the competitor > under, or acquire them. > > Anne > > From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 05:51: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 FAA11802 for ; Fri, 3 Sep 2004 05:51: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 i839V9bV078890; Fri, 3 Sep 2004 02:31: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 i839V9nt078889; Fri, 3 Sep 2004 02:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839UvdF078745 for ; Fri, 3 Sep 2004 02:31:06 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 09:30:52 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: RE: DEPLOY: Sender-ID provides little or no defence against adaptive threats Date: Fri, 3 Sep 2004 03:31:04 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <21AE96C1-FD71-11D8-BA2B-000A95AC5778@isipp.com> X-OriginalArrivalTime: 03 Sep 2004 09:30:52.0860 (UTC) FILETIME=[B4DC27C0:01C49198] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne P. Mitchell wrote: >cf. CipherTrust's study released this week in which >50% of the sources >for all email surveyed which published SPF records were spammers. > >http://www.infoworld.com/article/04/08/31/HNspammerstudy_1.html Just so there is no confusion... this is good news for SPF, not bad news. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 06:13: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 GAA14340 for ; Fri, 3 Sep 2004 06:13:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839pfVU086383; Fri, 3 Sep 2004 02:51: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 i839pfqi086382; Fri, 3 Sep 2004 02:51:41 -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 i839peCW086370 for ; Fri, 3 Sep 2004 02:51:40 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id D120826C08E; Fri, 3 Sep 2004 11:51:40 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 9C08A26C075; Fri, 3 Sep 2004 11:51:39 +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 i839pdm7688980; Fri, 3 Sep 2004 11:51:39 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 3634EFACE; Fri, 3 Sep 2004 11:51:39 +0200 (CEST) Date: Fri, 3 Sep 2004 11:51:39 +0200 From: Stephane Bortzmeyer To: mazieres@gmail.com Cc: MARID Subject: Re: DOC-BUG: permitted use of PRA/submitter address Message-ID: <20040903095139.GA15186@nic.fr> References: <94df60cf040829163469ba9429@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94df60cf040829163469ba9429@mail.gmail.com> 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+20040523i 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 Sun, Aug 29, 2004 at 07:34:22PM -0400, mazieres@gmail.com wrote a message of 59 lines which said: > * I am on vacation, and receive mail which lists my own address in > the To: or CC: fields, and does not have any indications such as > "Precedence: list/bulk/junk" that it is from a mailing list. I wish > for my filter to notify the sender that I will not be responding for > a week. Should I send the notification to the MAIL-FROM address, as > I currently do, or to the PRA? RFC 2822 and 3834 are quite clear, IMHO. 2822 : Resent fields are strictly informational. They MUST NOT be used in the normal processing of replies or other such automatic actions on messages. 2822 : When the "Reply-To:" field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply. 3834 : Similarly, the Sender field SHOULD NOT be used as the destination for automatic responses. This field is intended only to identify the person or entity that sent the message, and is not required to contain an address that is valid for replies. > * I receive offensive and/or threatening mail from someone, and wish > to complain to their administrator. Should I complain to > postmaster/abuse at the domain name in the PRA, as opposed to the > domain in the From or envelope sender address? I would say first to the postmaster/abuse at the domain name in the From then, if there is no reply, to the one in the PRA (like people do when they first mail the "offender" then his ISP). From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 06:14:14 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 GAA14453 for ; Fri, 3 Sep 2004 06:14:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839sWp3087413; Fri, 3 Sep 2004 02:54:32 -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 i839sWbl087412; Fri, 3 Sep 2004 02:54:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839sV3w087402 for ; Fri, 3 Sep 2004 02:54:32 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 55F6826C070; Fri, 3 Sep 2004 11:54:32 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 25D1726C075; Fri, 3 Sep 2004 11:54:31 +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 i839sUm7680900; Fri, 3 Sep 2004 11:54:31 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id C36D7FACE; Fri, 3 Sep 2004 11:54:30 +0200 (CEST) Date: Fri, 3 Sep 2004 11:54:30 +0200 From: Stephane Bortzmeyer To: "David H. Lynch Jr." Cc: "IETF-MXCOMP WG'" Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) Message-ID: <20040903095430.GB15186@nic.fr> References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> <4133EA12.2010300@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4133EA12.2010300@comcast.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+20040523i 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 Mon, Aug 30, 2004 at 11:01:38PM -0400, David H. Lynch Jr. wrote a message of 89 lines which said: > Regardless of whether software should be patentable (or > business methods, or ...) and regardless of the fact that trivial > "improvements" should not be patentable no matter what. We live in a > world where they are. "A world"? You mistake the United States of America for the World. In Europe, software patents are currently illegal. (And frivolous/trivial patents like the Microsoft patent we talk about are a good reason why it should stay that way.) See http://swpat.ffii.org/ for details. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 06:18: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 GAA14638 for ; Fri, 3 Sep 2004 06:18:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839k91G083961; Fri, 3 Sep 2004 02:46: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 i839k99a083960; Fri, 3 Sep 2004 02:46:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i839k817083918 for ; Fri, 3 Sep 2004 02:46:09 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [192.168.253.26] (unknown[66.240.194.10]) by comcast.net (sccrmhc13) with ESMTP id <2004090309460401600h8rfre> (Authid: dhlii); Fri, 3 Sep 2004 09:46:04 +0000 Message-ID: <4139B8D4.5040702@comcast.net> Date: Sat, 04 Sep 2004 05:45:08 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: The SSL license offer. References: <792DE28E91F6EA42B4663AE761C41C2A02CEB896@cliff.bai.org> <00ef01c49112$0ad16370$cec8d684@sraq.intra> In-Reply-To: <00ef01c49112$0ad16370$cec8d684@sraq.intra> 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 Guillaume Filion wrote: >"Ryan Malayter" wrote: > > >>Very interesting. If OpenSSL can be included in Linux distributions, why >>can't SenderID? >> >>The SSL license would seem to have tproblems with the GPL similar to >>those that the SenderID license does. >> >> The SSL license probably is incompatible with the GPL. But that does not make it incompatible with all FOSS licenses. Also every piece of software included in a Linux distribution does not meet the Free Software Foundations criteria, that does not prevent it from being included. Some distributions such as Debian distinguish between free and non-free - incompatible license terms. The OpenSSL license would probably qualify it as non-free but redistributable. The Microsoft License would prevent redistribution. The GPL is the most popular OpenSource License. However it is not the only one. Finally, we - not even the lawyers, do not get to decide whether the Microsoft license is incompatible with whatever License a particular developer is using That developer does, or the distributor. Basically the people who are taking the risk by developing and distributing software get to decide based hopefully on the advice they receive from THEIR lawyers, whether they have a problem. If Phillip Hazel, or the developers of Courier, ... believe they have a problem, you can try to persuade them otherwise but you can not just tell them that they are wrong. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 06:27: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 GAA15443 for ; Fri, 3 Sep 2004 06:27: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 i83A5dJQ092165; Fri, 3 Sep 2004 03:05: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 i83A5deI092164; Fri, 3 Sep 2004 03:05:39 -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 i83A5c2R092154 for ; Fri, 3 Sep 2004 03:05:39 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 492BB26C09C; Fri, 3 Sep 2004 12:05:39 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 2EC5426C092; Fri, 3 Sep 2004 12:05:38 +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 i83A5bm7691878; Fri, 3 Sep 2004 12:05:38 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id DF533FACE; Fri, 3 Sep 2004 12:05:37 +0200 (CEST) Date: Fri, 3 Sep 2004 12:05:37 +0200 From: Stephane Bortzmeyer To: Roy Badami Cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra Message-ID: <20040903100537.GC15186@nic.fr> References: <16695.49071.671776.708651@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16695.49071.671776.708651@giles.gnomon.org.uk> 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+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 01:49:51AM +0100, Roy Badami wrote a message of 18 lines which said: > I'm tending to the opinion that the words 'non-empty' should simply > be deleted from section 2 of -pra. They seem to serve no purpose > other that to add complexity, The added complexity is very small (using the length of the code as a metric). The real issue is the definition of "non-empty". The sendmail milter tests "strlen(hdr->hdr_val) > 0". Mark Kramer uses the Perl \s expression. I used Python's definition of "empty". They do not agree and I do not find an authoritative definition. > empty field bodies are illegal, and I don't believe they are > prevelent in the wild. Never assume anything about the Real World when it is the Internet :-) I thought that the provisions of -pra like: If that header is malformed (e.g. it appears to contain multiple mailboxes, or the single mailbox is hopelessly malformed, or the single mailbox does not contain a domain name), were unecessary until I ran the PRA algorithm against my spam mailbox and find very strange addresses. > "Locate the first Resend-Sender field in the message that has a > non-empty field body" Not complete: is a set of whitespaces empty? Is "(Sender not displayed)" empty or malformed? From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 06:38: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 GAA16556 for ; Fri, 3 Sep 2004 06:38:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83AG19a095830; Fri, 3 Sep 2004 03:16: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 i83AG16P095829; Fri, 3 Sep 2004 03:16:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i83AG0Zq095817 for ; Fri, 3 Sep 2004 03:16:00 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-12.tower-48.messagelabs.com!1094206559!4463968 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 16335 invoked from network); 3 Sep 2004 10:15:59 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-12.tower-48.messagelabs.com with SMTP; 3 Sep 2004 10:15:59 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Sep 2004 11:15:59 +0100 Received: (qmail 8473 invoked from network); 2 Sep 2004 10:11:23 -0000 Received: from unknown (HELO ?10.191.100.32?) (10.191.100.32) by matt?dev.int.star.co.uk with SMTP; 2 Sep 2004 10:11:23 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4042BB90-FD92-11D8-B236-000A95AC67AA@messagelabs.com> Content-Transfer-Encoding: 7bit Cc: Ryan Malayter , "Michael R. Brumm" , IETF MARID WG From: Matt Sergeant Subject: Re: (DEPLOY) In Support of Sender ID Date: Fri, 3 Sep 2004 11:15:59 +0100 To: Rand Wacker X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 03 Sep 2004 10:15:59.0173 (UTC) FILETIME=[01F2BF50:01C4919F] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 Sep 2004, at 23:06, Rand Wacker wrote: > As I said before, there is a large majority of mail that goes from > large > commercial sites (or consumer ISPs) merely one hop to another large > commercial ISP, so the From: header will be successfully authenticated. You're talking about the positive evaluation proposition of Sender-ID - that the From address is authenticated. Yet both Cyphertrust and SpamAssassin's stats show that the spammers are more on top of this than the legit mailers. This indicates to me that we need to be looking towards the negative evaluation proposition (i.e. the value in rejecting mail) that Sender-ID and/or SPF gives us, rather than hoping that a Sender-ID approved mail actually provides us with any benefits. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 06:38: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 GAA16565 for ; Fri, 3 Sep 2004 06:38: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 i83AIvFw096847; Fri, 3 Sep 2004 03:18: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 i83AIve1096846; Fri, 3 Sep 2004 03:18:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i83AIton096815 for ; Fri, 3 Sep 2004 03:18:56 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-3.tower-48.messagelabs.com!1094206732!3752473 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 9059 invoked from network); 3 Sep 2004 10:18:52 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-3.tower-48.messagelabs.com with SMTP; 3 Sep 2004 10:18:52 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Sep 2004 11:18:52 +0100 Received: (qmail 8481 invoked from network); 2 Sep 2004 10:14:16 -0000 Received: from unknown (HELO ?10.191.100.32?) (10.191.100.32) by matt?dev.int.star.co.uk with SMTP; 2 Sep 2004 10:14:16 -0000 In-Reply-To: <20040903083945.GA7584@nic.fr> References: <16695.45036.160556.552577@giles.gnomon.org.uk> <20040903083945.GA7584@nic.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org, Roy Badami From: Matt Sergeant Subject: Re: TECH-ERROR: Name of SUBMITTER parameter Date: Fri, 3 Sep 2004 11:18:52 +0100 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 03 Sep 2004 10:18:52.0269 (UTC) FILETIME=[691F19D0:01C4919F] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 Sep 2004, at 09:39, Stephane Bortzmeyer wrote: > On Fri, Sep 03, 2004 at 12:42:36AM +0100, > Roy Badami wrote > a message of 17 lines which said: > >> The SUBMITTER parameter was fine as a working name (as was FRED, >> DAVE, and all the rest of the names) but now that we're all in >> agreement athat the name of the identity in question is the PRA, the >> obvious name for the parameter to identify the PRA is "PRA". > > IMHO, we should do quite the opposite: get rid of every mention of > -pra in the -submitter draft to be able to drop -pra (because of > patent issues) while keeping -submitter (which is IMHO an useful > addition to SPF-classic, which helps to solve the forwarding problem > which cripples SPF-classic). You cannot possibly do SUBMITTER without -pra because otherwise forging SUBMITTER will be trivial and undetectable. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 06:45: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 GAA17377 for ; Fri, 3 Sep 2004 06:45: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 i83AOIYN098793; Fri, 3 Sep 2004 03:24: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 i83AOIIV098792; Fri, 3 Sep 2004 03:24:18 -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 i83AOHFe098781 for ; Fri, 3 Sep 2004 03:24:18 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id AA9CF26C08E; Fri, 3 Sep 2004 12:24:18 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 7F7A226C06D; Fri, 3 Sep 2004 12:24:17 +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 i83AOHm7697133; Fri, 3 Sep 2004 12:24:17 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 585D8FACE; Fri, 3 Sep 2004 12:24:17 +0200 (CEST) Date: Fri, 3 Sep 2004 12:24:17 +0200 From: Stephane Bortzmeyer To: Jim Lyon Cc: IETF MARID WG Subject: SPF testing can be done against other addresses (Was: DEPLOY: Legal liability for creating bounces from forged messages Message-ID: <20040903102417.GA17497@nic.fr> References: <81AC085044D04B429F5FB883D94FA1AF8FACB0@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FACB0@df-fido-msg.exchange.corp.microsoft.com> 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+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 26, 2004 at 01:19:37PM -0700, Jim Lyon wrote a message of 17 lines which said: > > Is it unrealistic to assume that, if the current Sender-ID becomes a > > RFC as it is, nevertheless, some people will use SPF records (as > > specified in -protocol) to perform checks on the 2821 MAIL FROM and > > not only on the official PRA? A sort of unofficial "Unified SPF"? > > Yes, it's realistic to assume that some software will do this. The > technical term for such a program is "broken". :-) I disagree. Sender-ID currently mandates a test against the PRA but, as the modular architecture of the Sender-ID documents demonstrate, you can test SPF records against many things. This will not be Sender-ID, but it does not mean it is broken. IMHO, this would be a sensible course of action to work around the patent problem. > The whole point of having a standard is so that senders know what > the expectations are for the mail they send, and that receivers know > what they should be looking for. At the present time, it is far from true. Bulk emailers typically complain that they never know in advance what sort of checks will be performed against their messages. ISPs typically implement and deploy hastily a lot of ill-advised tests (like testing that the client MTA has a PTR) without taking into account standards, best practices or even other opinions. Given the architecture of the Internet, it will probably never change. > The whole PRA stuff was invented I'm glad that you do not say who invented it :-) From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 06:51: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 GAA17883 for ; Fri, 3 Sep 2004 06:51: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 i83ATdQB000800; Fri, 3 Sep 2004 03:29: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 i83ATd6X000799; Fri, 3 Sep 2004 03:29:39 -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 i83ATcNx000786 for ; Fri, 3 Sep 2004 03:29:39 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id BCE1826C092; Fri, 3 Sep 2004 12:29:39 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id C423526C08E; Fri, 3 Sep 2004 12:29:38 +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 i83ATcm7697160; Fri, 3 Sep 2004 12:29:38 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 98B42FACE; Fri, 3 Sep 2004 12:29:38 +0200 (CEST) Date: Fri, 3 Sep 2004 12:29:38 +0200 From: Stephane Bortzmeyer To: Matt Sergeant Cc: Stephane Bortzmeyer , ietf-mxcomp@imc.org, Roy Badami Subject: Re: TECH-ERROR: Name of SUBMITTER parameter Message-ID: <20040903102938.GA18224@nic.fr> References: <16695.45036.160556.552577@giles.gnomon.org.uk> <20040903083945.GA7584@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 11:18:52AM +0100, Matt Sergeant wrote a message of 27 lines which said: > You cannot possibly do SUBMITTER without -pra because otherwise > forging SUBMITTER will be trivial and undetectable. Correction: You cannot possibly do SUBMITTER without consistency checking with the RFC 2822 headers because otherwise forging SUBMITTER will be trivial and undetectable. Alternative: You cannot possibly do SUBMITTER without recording and displaying the SUBMITTER because otherwise forging SUBMITTER will be trivial and undetectable. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 06:55: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 GAA18070 for ; Fri, 3 Sep 2004 06:55: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 i83AaFVu003526; Fri, 3 Sep 2004 03:36:15 -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 i83AaFDB003524; Fri, 3 Sep 2004 03:36:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83AaEHD003508 for ; Fri, 3 Sep 2004 03:36:14 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 3 Sep 2004 11:42:00 +0100 Message-ID: <41384918.7040502@isode.com> Date: Fri, 03 Sep 2004 11:36:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael R. Brumm" CC: IETF MARID WG Subject: Re: PRA Patent: License for Display in MUAs? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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 Michael R. Brumm wrote: >I'm wondering, since there has been talk about displaying the SenderID PRA >in MUAs, would Microsoft's patent claims and licensing apply to MUAs also? I >imagine that the steps used by an MTA to extract the PRA for evaluation >would be the same as the steps used by an MUA to extract the PRA for >display... > >If licensing FOSS MTAs are problematic with SenderID, I'd imagine that FOSS >MUAs would greatly compound the problem. > Exactly. And some MUAs were displaying PRA information for years. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 07:28: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 HAA20119 for ; Fri, 3 Sep 2004 07:28: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 i83B4F2N008695; Fri, 3 Sep 2004 04:04:15 -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 i83B4FAO008694; Fri, 3 Sep 2004 04:04:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i83B49o5008675 for ; Fri, 3 Sep 2004 04:04:14 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id 4FB791BDEA5; Fri, 3 Sep 2004 13:04:06 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by kalyani.oryx.com (Postfix) with SMTP id 2B1951BDE5A for ; Fri, 3 Sep 2004 13:04:02 +0200 (CEST) Message-Id: Date: Fri, 3 Sep 2004 13:05:06 +0200 From: Arnt Gulbrandsen To: IETF MARID WG Subject: Re: PRA Patent: License for Display in MUAs? References: <41384918.7040502@isode.com> In-Reply-To: <41384918.7040502@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alexey Melnikov writes: > Michael R. Brumm wrote: >> If licensing FOSS MTAs are problematic with SenderID, I'd imagine that FOSS >> MUAs would greatly compound the problem. > > Exactly. And some MUAs were displaying PRA information for years. Explain? And name some names? (Although now that you say it, the client I'm using right now seems to be doing something very much like that...) Arnt From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 09:06:48 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 JAA26657 for ; Fri, 3 Sep 2004 09:06:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ChC1G015849; Fri, 3 Sep 2004 05:43: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 i83ChClA015848; Fri, 3 Sep 2004 05:43:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i83ChA4x015840 for ; Fri, 3 Sep 2004 05:43:11 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 15470 invoked from network); 3 Sep 2004 12:43:09 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 3 Sep 2004 12:43:09 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "Meng Weng Wong" , Subject: RE: (DEPLOY) In Support of Sender ID Date: Fri, 3 Sep 2004 08:43:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040903064213.GA23667@dumbo.pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Meng Weng Wong > Sent: Friday, September 03, 2004 2:42 AM > To: ietf-mxcomp@imc.org > Subject: Re: (DEPLOY) In Support of Sender ID > > On Fri, Sep 03, 2004 at 06:25:21AM +0100, Graham Murray wrote: > | > | In the case of sending from a large ISP (and that includes commercial > | sites who outsource email) that is not true. Unless the ISP does > | additional checking then Sender-ID (and SPF) still allows a customer > | of the ISP to forge the mail as coming from any other customer of that > | ISP. > > My read of most ISPs is that they are willing to move in > this direction if it proves necessary. Many ISPs are > beginning to roll out (mandatory) SMTP AUTH. With that in > place, halting cross-customer forgery becomes a much more > likely proposition. > While SMTP AUTH will help ISPs manage access to their MTAs, it doesn't help them with the policy and procedural issues of managing lists of domains that different users may legitimately send from. I believe that these types of issues are ultimately a greater deterrent to large scale prevention of cross-customer forgery than the particular method of MTA access authentication. As I've said before, http://www.imc.org/ietf-mxcomp/mail-archive/msg04034.html I think the simplest way all around (assuming we go forward with Sender-ID in some form) is to have ISPs use Submitter. That way they don't have to manage lists of domains that customers have access to. Any messages coming from the ISP MTA are checked under Sender-ID against the ISP spf2 pra record. I don't think it changes in any significant way what they will already have to do to support Sender-ID anyway. For those of us without the resources to operate our own MTA, the potential for cross customer forgery is a huge issue. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 09:06:50 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 JAA26678 for ; Fri, 3 Sep 2004 09:06:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ChH2J015859; Fri, 3 Sep 2004 05:43:17 -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 i83ChHAX015858; Fri, 3 Sep 2004 05:43:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ChGva015852 for ; Fri, 3 Sep 2004 05:43:16 -0700 (PDT) (envelope-from dotzero@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so7545rnk for ; Fri, 03 Sep 2004 05:43:12 -0700 (PDT) Received: by 10.38.1.72 with SMTP id 72mr121208rna; Fri, 03 Sep 2004 05:43:12 -0700 (PDT) Received: by 10.38.8.12 with HTTP; Fri, 3 Sep 2004 05:43:11 -0700 (PDT) Message-ID: <7ae58c220409030543643f5769@mail.gmail.com> Date: Fri, 3 Sep 2004 08:43:11 -0400 From: Michael Hammer Reply-To: Michael Hammer To: ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID Cc: "J. Trevor Hughes" In-Reply-To: <008801c49118$8321a780$6401a8c0@JTHSony> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <008801c49118$8321a780$6401a8c0@JTHSony> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm reluctant to join the fray as I find myself feeling caught in the middle. Long time lurker, first time poster. I speak for myself but work for a well known website which generates a fair amount of outbound mail mainly from a web GUI interface which customers interact with. Phishing is an issue for my employer and we are clearly interested in solutions which work. We have changed our mode of operation so that we could publish SPF1 records (by not sending emails as if it was the user sending them). We also recognized that other solutions such as CallerID and DomainKeys were on the horizon. The merging of CallerID and SPF into SenderID presented an opportunity to provide a generally accepted solution to reduce forgeries for both RFC2821 and RFC2822 headers. The issue of licenses does not directly impact us with the most recent changes made by Microsoft as we would simply be an end-user. I recognize that there is significant controversy over the licensing issue with many posters to this list indicating that they will not implement SenderID given the current situation. Fragmented implementation of standards (specified or de facto) by recipient MTAs (I'm setting aside the issue of MUAs as it would take a longer time frame for implementation in any event) is perhaps worse than no implementation at all. The risk of lost communications or troubleshooting problems would at best be difficult. Differing and competing implementations, whether within a standards framework or outside of it, is likely to have a potentially large negative impact on a core service provided over the Internet. Given that last call is almost over and considering the lack of consensus with regard to SenderID, I would prefer to see the Working Group not put forward SenderID but I would not like to see it killed. If core and unified SPF could be moved forward or simply SPF classic, that would at least be a step in the right direction. There is potential in SenderID that should not be discarded lightly. Given more time and less "heat" it may be possible to resolve the current issues given some flexibility by all concerned. To illustrate why consensus is important to deployment I decided to do a little checking after reading the post from J . Trevor Hughes stating how strongly ESPC and it's members support SenderID. I decided to check the extent to which members of the Email Service Provider Coalition have published either SPF1, SPF2.0/PRA or both. The results are somewhat interesting and bear on the issue of deployment. This is clearly a group of companies which should have a strong interest in authenticated email solutions (As Mr. Hughes pointed out in his email). If there are issues with achieving deployment (of anything) by a group that should have the strongest motivation, what happens when various large recipient (mail service providers) impose inconsistent requirements on sending MTAs? My concern is that the larger universe of organizations and companies will simply ignore any standards and go with whatever meets their immediate need. The results are as follows: 52 companies listed 27 have no TXT record in DNS (more than half) 17 have SPF1 only 3 have SPF2.0/PRA only 4 have both SPF1 and SPF2.0/PRA The detailed list as follows: NO Adknowledge, Inc. SPF1 aQuantive SPF1,SPF2.0/PRA Constant Contact (Formerly Roving Software) NO Digital Impact SPF1 DoubleClick NO Experian NO Got Marketing SPF1 ProspectivDirect SPF2.0/PRA SKYLIST NO 24/7 Real Media NO @Once NO Acxiom SPF1 Advertising.com NO AFG Media SPF1 Bigfoot Interactive SPF1 BlueHornet Networks, Inc. NO BlueStreak SPF1 Britemoon SPF1,SPF2.0/PRA CheetahMail NO Datran Media NO Digital Connexxions NO eDialog NO EmailLabs SPF1 ExactTarget NO Exmplar, Inc. SPF1 IMN SPF1 Inter@ctivate, Inc. SPF1 Internet Marketing Center NO The Lift Network NO Mediaplex SPF1 NetCreations, inc. NO Performics SPF1,SPF2.0/PRA Pexicom, Inc. SPF1,SPF2.0/PRA Port25 Solutions, Inc. NO Postfuture SPF1 Quris NO RightNow Technologies SPF1 Responsys NO Return Path NO Savicom SPF1 Silverpop SPF2.0/PRA SmartSource NO SourceLink NO StrongMail Systems YES SubscriberMail, LLC SPF2.0/PRA TargitInteractive SPF1 Topica NO Traffix, Inc. NO TranSend, Inc. NO ValueClick SPF1 VerticalResponse NO Yesmail Michael Hammer dotzero@gmail.com From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 09:21: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 JAA27832 for ; Fri, 3 Sep 2004 09:21: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 i83D1BkG017692; Fri, 3 Sep 2004 06:01: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 i83D1BAc017691; Fri, 3 Sep 2004 06:01:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i83D1A6p017681 for ; Fri, 3 Sep 2004 06:01:10 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-13.tower-48.messagelabs.com!1094216468!4767576 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 18656 invoked from network); 3 Sep 2004 13:01:08 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-13.tower-48.messagelabs.com with SMTP; 3 Sep 2004 13:01:08 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Sep 2004 14:01:08 +0100 Received: (qmail 9042 invoked from network); 2 Sep 2004 12:56:31 -0000 Received: from unknown (HELO ?10.191.100.32?) (10.191.100.32) by matt?dev.int.star.co.uk with SMTP; 2 Sep 2004 12:56:31 -0000 In-Reply-To: <20040903102938.GA18224@nic.fr> References: <16695.45036.160556.552577@giles.gnomon.org.uk> <20040903083945.GA7584@nic.fr> <20040903102938.GA18224@nic.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <52B2DFD0-FDA9-11D8-B236-000A95AC67AA@messagelabs.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org, Roy Badami From: Matt Sergeant Subject: Re: TECH-ERROR: Name of SUBMITTER parameter Date: Fri, 3 Sep 2004 14:01:08 +0100 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 03 Sep 2004 13:01:08.0128 (UTC) FILETIME=[14254A00:01C491B6] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 Sep 2004, at 11:29, Stephane Bortzmeyer wrote: > Alternative: You cannot possibly do SUBMITTER without recording and > displaying the SUBMITTER because otherwise forging SUBMITTER will be > trivial and undetectable. Right. I think this is a better implementation option. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 10:01: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 KAA29880 for ; Fri, 3 Sep 2004 10:01: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 i83DdBGc021534; Fri, 3 Sep 2004 06:39: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 i83DdBa7021533; Fri, 3 Sep 2004 06:39:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verboten.net (entry.verboten.net [80.74.132.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83DdAaS021520 for ; Fri, 3 Sep 2004 06:39:10 -0700 (PDT) (envelope-from matthias@astrum.ch) Received: from localhost (localhost [127.0.0.1]) by mail.verboten.net (Postfix) with ESMTP id 90A732B04F for ; Fri, 3 Sep 2004 15:38:57 +0200 (CEST) Received: from astrum.ch (marvin.net.astrum.ch [213.144.132.250]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.verboten.net (Postfix) with ESMTP id 05E2E2AFBC for ; Fri, 3 Sep 2004 15:38:57 +0200 (CEST) Message-ID: <413873EF.4000405@astrum.ch> Date: Fri, 03 Sep 2004 15:38:55 +0200 From: Matthias Leisi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-ch, de-de, de, en-us, en, fr MIME-Version: 1.0 To: IETF MARID WG Subject: Re: PRA Patent: License for Display in MUAs? References: <41384918.7040502@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at verboten.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Arnt Gulbrandsen wrote: > > Alexey Melnikov writes: > >> Exactly. And some MUAs were displaying PRA information for years. > > > Explain? And name some names? The Notes 5 client shows the Sender: header as "Sent by", but not 821-From. -- Matthias -- Brain-Log http://matthias.leisi.net/ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 10:01: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 KAA29898 for ; Fri, 3 Sep 2004 10:01: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 i83Dc3ee021449; Fri, 3 Sep 2004 06:38:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83Dc3OH021448; Fri, 3 Sep 2004 06:38:03 -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 i83Dc2D0021441 for ; Fri, 3 Sep 2004 06:38:02 -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 1C3EGN-0003Rk-12 for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 08:38:04 -0500 To: "IETF MARID WG" References: <16695.45036.160556.552577@giles.gnomon.org.uk> From: wayne Reply-To: "IETF MARID WG" Date: Fri, 03 Sep 2004 08:37:58 -0500 In-Reply-To: <16695.45036.160556.552577@giles.gnomon.org.uk> (Roy Badami's message of "Fri, 3 Sep 2004 00:42:36 +0100") 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: TECH-ERROR: Name of SUBMITTER parameter 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.6 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 <16695.45036.160556.552577@giles.gnomon.org.uk> Roy Badami writes: > The SUBMITTER parameter was fine as a working name (as was FRED, DAVE, > and all the rest of the names) but now that we're all in agreement > that the name of the identity in question is the PRA, the obvious name > for the parameter to identify the PRA is "PRA". > > MAIL FROM: PRA= > > is far more natural than the SUBMITTER alternative. I agree with this and made the same suggested during the IETF-60 jabber session. (See http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html 11:19:05) Unlike your message to this list, both Meng and Marshall gave positive feedback. (I suspect your message was just overlooked due to the volume of IPR messages.) So, I think we can count at least four people who would like to see SUBMITTER= renamed to PRA=. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 10:31: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 KAA02478 for ; Fri, 3 Sep 2004 10:31:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83E9kvL023267; Fri, 3 Sep 2004 07:09: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 i83E9kpE023266; Fri, 3 Sep 2004 07:09:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83E9j9n023259 for ; Fri, 3 Sep 2004 07:09:45 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:41025) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C3Eku-0000xU-4t (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 15:09:32 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C3Ekt-0001UF-DM; Fri, 03 Sep 2004 15:09:31 +0100 Date: Fri, 3 Sep 2004 15:09:31 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Roy Badami cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra In-Reply-To: <16695.49071.671776.708651@giles.gnomon.org.uk> Message-ID: References: <16695.49071.671776.708651@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 3 Sep 2004, Roy Badami wrote: > > empty field bodies are illegal, and I don't believe they are prevelent > in the wild. I'm afraid they are common enough that strict syntax checking has a high false positive rate. Tony. -- f.a.n.finch http://dotat.at/ LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: WEST OR SOUTHWEST 2 TO 4. MAINLY FAIR, SMALL RISK FOG PATCHES. MODERATE WITH FOG PATCHES. SLIGHT TO MODERATE. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 11:32: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 LAA06402 for ; Fri, 3 Sep 2004 11:32: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 i83F1CNu028097; Fri, 3 Sep 2004 08:01: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 i83F1CV1028096; Fri, 3 Sep 2004 08:01:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ms-smtp-02.nyroc.rr.com (ms-smtp-02.nyroc.rr.com [24.24.2.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83F1BiT028081 for ; Fri, 3 Sep 2004 08:01:12 -0700 (PDT) (envelope-from jthughes@maine.rr.com) Received: from JTHSony (ptd-204-210-94-155.maine.rr.com [204.210.94.155]) by ms-smtp-02.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id i83F16Mv027863; Fri, 3 Sep 2004 11:01:08 -0400 (EDT) From: "J. Trevor Hughes" To: "'Michael Hammer'" , Subject: RE: (DEPLOY) In Support of Sender ID Date: Fri, 3 Sep 2004 11:01:11 -0400 Message-ID: <000c01c491c6$da021c20$6401a8c0@JTHSony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <7ae58c220409030543643f5769@mail.gmail.com> X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i83F1CiT028086 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I'm reluctant to join the fray as I find myself feeling caught in the middle. Long time lurker, first time poster. [...snip...] Michael, Thanks for a thoughtful and objective response. The ESPC is fully committed to email authentication and has been supportive of SPF1 and Sender ID since the beginning. We've had a significant role in helping to get to this point (including hosting a meeting at Harvard Law School in January where the idea of merging Caller ID with SPF was discussed with Meng and Microsoft). One thing that is worth noting about your analysis is that the majority of ESPs do not send their customer emails from their corporate domains. Many employ dedicated IP addresses and vanity domains for each client. While there is no reason not to implement authentication on their corporate domains, it is not unthinkable that their first implementation would focus on the client domains and not the ESP corporate domain (we encourage all members to publish SPF1 and Sender ID for all domains). We recently issue a press release (http://www.espcoalition.org/083104senderid.php) stating that all new ESPC members are required to implement SPF1 and that all existing members are in compliance or in the process of implementing. I expect that we will require Sender ID compliance in the near future. I don't think there is any lack of consensus among the ESPC members. Less than a month ago almost 100 of our members visited Microsoft for a day long summit on Sender ID and expressed our support. Many of our members have posted their own thoughts to this list and I expect you will see more postings over the next few days as last call approaches. Trevor From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 12:17: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 MAA08653 for ; Fri, 3 Sep 2004 12:17: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 i83FsqrL032202; Fri, 3 Sep 2004 08:54: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 i83Fsqbc032201; Fri, 3 Sep 2004 08:54:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Fsqwi032195 for ; Fri, 3 Sep 2004 08:54:52 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Sep 2004 08:54:55 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Sep 2004 08:54:55 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Sep 2004 08:54:55 -0700 Received: from df-dogbert-msg.exchange.corp.microsoft.com ([157.54.5.14]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 08:54:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V8.0.155.1 Content-class: urn:content-classes:message Subject: RE: PRA Patent: License for Display in MUAs? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Sep 2004 08:54:54 -0700 Message-ID: Thread-Topic: PRA Patent: License for Display in MUAs? thread-index: A8+RX1/E3R/cUCkpQy+KI4+zJ/+08AAbb9sg From: "Jim Lyon" To: "william\(at\)elan.net" , "Michael R. Brumm" Cc: "IETF MARID WG" X-OriginalArrivalTime: 03 Sep 2004 15:54:51.0971 (UTC) FILETIME=[593D8130:01C491CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i83Fsqwi032196 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, September 02, 2004 at 7:38 PM, William Leibzon wrote: > Microsoft may have misled others that SenderID and PRA algorithm can be > used by MUAs to verify email (because of their dominance in MUA market on > Windows PCs, they need something for MUAs). That is not true. In spite of William's repeated assertions that it can't be done, we have built prototypes internally that do exactly that. They work. Briefly, the algorithm is: 1. Grovel through the Received: headers to find the header describing the hop where the message entered the current organization. 2. Extract the PRA from the [Resent-] Sender and From headers as usual. 3. Apply the SenderID algorithm. [Actually, our prototypes used the earlier CallerID algorithm, but the point remains.] William also implies that Microsoft would intentionally mislead people to believe that SenderID can be used in MUAs when it cannot. In the first place, I resent the insinuation. In the second place, were such misleading to occur, it would hurt Microsoft more than anyone else, precisely because we provide more of the world's MUAs than anyone else. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 12:18:11 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 MAA08679 for ; Fri, 3 Sep 2004 12:18:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Fs8EH032134; Fri, 3 Sep 2004 08:54: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 i83Fs8tN032133; Fri, 3 Sep 2004 08:54:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Fs7PY032121 for ; Fri, 3 Sep 2004 08:54:07 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i83Fs7TC018337 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 08:54:09 -0700 Date: Fri, 3 Sep 2004 08:54:07 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Graham Murray cc: ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID In-Reply-To: Message-ID: References: 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, 3 Sep 2004, Graham Murray wrote: > Rand Wacker writes: > > > As I said before, there is a large majority of mail that goes from large > > commercial sites (or consumer ISPs) merely one hop to another large > > commercial ISP, so the From: header will be successfully authenticated. > > In the case of sending from a large ISP (and that includes commercial > sites who outsource email) that is not true. Unless the ISP does > additional checking then Sender-ID (and SPF) still allows a customer > of the ISP to forge the mail as coming from any other customer of that > ISP. Sorry, I should have said "the domain of the From: header" Such is the limitation of doing domain-based auth. The limitation of doing user-based auth is a high barrier to deployment. -Rand From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 12:37:23 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 MAA09765 for ; Fri, 3 Sep 2004 12:37:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83GF520033457; Fri, 3 Sep 2004 09:15: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 i83GF5on033456; Fri, 3 Sep 2004 09:15:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83GF4F8033450 for ; Fri, 3 Sep 2004 09:15:04 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i83GEhBD023295 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 09:14:44 -0700 Date: Fri, 3 Sep 2004 09:14:43 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: mazieres@gmail.com cc: Kevin Peuhkurinen , ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID In-Reply-To: <94df60cf04090216057a06d0cc@mail.gmail.com> Message-ID: References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376D09.1000400@hepcoe.com> <94df60cf04090213282ae5c57b@mail.gmail.com> <94df60cf04090216057a06d0cc@mail.gmail.com> 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, 2 Sep 2004 mazieres@gmail.com wrote: > My challenge remains... describe a concrete scenario that requires > Sender ID, and that could not achieve the same effective result with > SPF-classic. Vague references to banks don't convince me any more, The following is not a vague reference, but an actual planned deployment (I just can't tell you who is planning it for obvious reasons): Large Bank communicates with numerous customers addresses at Large ISP. Large ISP has indicated that they will verify inbound authentication credentials and has negotiated preferred delivery of authenticated mail from Large Bank's domain. Large ISP has given Large Bank the ability to add a limited number of bank-controlled domains to the Large ISP preferred whitelist. Large Bank has quite a bit of customer email delivered by a third party. This third party delivers mail with a bounce address (MAIL FROM) of outsource.com (so they can do the bounce processing), but a From: header of largebank.com. Large ISP will only whitelist largebank.com (because that is who the ISP/Bank customers want to hear from, they don't care about hearing from outsource.com). In this case, Sender ID would let Large ISP whitelist largebank.com and still allow outsource.com to deliver mail for the bank (as long as the bank's DNS records let it do so), /and/ continue to process bounces properly. SPF doesn't permit From: header whitelisting (at best) and breaks bounce handling (at worst). WRT to Resent-From spoofing and the PRA, its important to note that it is the PRA result which is whitelisted, so if a phisher uses Resent-From: phisher.com w/ From: largebank.com, the message will not get preferred treatment by the ISPs whitelist. -Rand From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 12:39:49 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 MAA10033 for ; Fri, 3 Sep 2004 12:39:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83GJTHx034372; Fri, 3 Sep 2004 09:19:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83GJTJ5034371; Fri, 3 Sep 2004 09:19:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.hbinc.com (mail.hbinc.com [63.149.249.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id i83GJSSG034348 for ; Fri, 3 Sep 2004 09:19:29 -0700 (PDT) (envelope-from Matthew.van.Eerde@hbinc.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: TECH-ERROR: Name of SUBMITTER parameter Date: Fri, 3 Sep 2004 09:19:31 -0700 Message-ID: <61192FA29C719B469A2B13E57DEDF75B0300F1F7@mail.hbinc.com> Thread-Topic: TECH-ERROR: Name of SUBMITTER parameter Thread-Index: AcSRvTxj+SMaj6ZLQOunBFaFmo+7zAAFEJ1g From: To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i83GJTSG034362 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit wayne wrote: > In <16695.45036.160556.552577@giles.gnomon.org.uk> Roy Badami > writes: >> MAIL FROM: PRA= >> >> is far more natural than the SUBMITTER alternative. > So, I think we can count at least four people who would like to see > SUBMITTER= renamed to PRA=. I respectfully disagree. Acronyms are harder to understand than fully-spelled-out names. A search on AcronymFinder for PRA returned 41 results: Paint Research Association (UK) Paperwork Reduction Act of 1995 Parabolic Reflector Antenna Parti pour le Renouveau Algerien Participatory Rural Appraisal How about spelling PRA out rather than using the acronym? Matthew.van.Eerde@hbinc.com 805.964.4554 x902 Hispanic Business Inc./HireDiversity.com Software Engineer perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 12:45:55 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 MAA10391 for ; Fri, 3 Sep 2004 12:45:54 -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 i83GLXrV034880; Fri, 3 Sep 2004 09:21:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83GLXth034879; Fri, 3 Sep 2004 09:21:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts20-srv.bellnexxia.net (tomts20.bellnexxia.net [209.226.175.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83GLWKH034872 for ; Fri, 3 Sep 2004 09:21:32 -0700 (PDT) (envelope-from johnw@metamail.com) Received: from INSYNCH003 ([64.231.215.245]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040903162129.OQKM19123.tomts20-srv.bellnexxia.net@INSYNCH003> for ; Fri, 3 Sep 2004 12:21:29 -0400 Reply-To: From: To: "IETF MARID Working Group" Subject: (DEPLOY) In Further Support of Sender ID Date: Fri, 3 Sep 2004 12:19:58 -0400 Organization: Metamail Corp. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSR0dsV4o9LsmGwStOmBNiKSEqPng== Message-Id: <20040903162129.OQKM19123.tomts20-srv.bellnexxia.net@INSYNCH003> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I write as the IT Director for Metamail Corporation, a leading provider of advanced customer registration and Email communications software. Both personally and as a representative of Metamail, I am expressing support for Sender ID. Metamail is committed to implementing Sender ID in our future developments and in ensuring that our solutions work seamlessly in parallel with Sender ID. We feel that the integrity of Email as a vehicle for business activities relies upon the quick emergence of authenticated email technologies and that any delay in the adoption of Sender ID will not meet anyone's best interests. John Wylie IT Director Metamail Corporation From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 12:54: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 MAA10743 for ; Fri, 3 Sep 2004 12:54: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 i83GXec9035482; Fri, 3 Sep 2004 09:33:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83GXeiY035481; Fri, 3 Sep 2004 09:33:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.cloudmark.com (mx1.cloudmark.com [67.109.59.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83GXc58035475 for ; Fri, 3 Sep 2004 09:33:38 -0700 (PDT) (envelope-from leon@cloudmark.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C491D3.C5AB6897" Subject: In support of Sender ID Date: Fri, 3 Sep 2004 09:33:40 -0700 Message-ID: Thread-Topic: In support of Sender ID Thread-Index: AcSR08UZRG785Ps9RDijweJzu7h/yg== From: "Leon Rishniw" To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C491D3.C5AB6897 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a supporter of both commercial and opensource software models, Cloudmark does not see any issue with the Sender ID IPR license with regard to implemention or redistribution of Sender ID in its commercial products. Cloudmark intends to implement and support all popular authentication schemes, including Sender ID, SPF and other variants. We are satisfied that Microsoft has extended coverage in the agreement to all Microsoft IPR that is relevant to the implementation of Sender ID. Additionally, the reciprocal license issue is limited to IPR related to Sender ID, which is sufficiently restricted for our needs. -leon =20 -- Leon Rishniw Cloudmark, Inc. 415-543-1220 leon@cloudmark.com =20 ------_=_NextPart_001_01C491D3.C5AB6897 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a supporter of both commercial and = opensource=20 software models, Cloudmark does not see any issue with the Sender = ID IPR=20 license with regard to implemention or redistribution of Sender ID = in its=20 commercial products.  Cloudmark intends to implement and support = all=20 popular authentication schemes, including Sender ID, SPF and other=20 variants.

We are=20 satisfied that Microsoft has extended coverage in the = agreement to=20 all Microsoft IPR that is relevant to the implementation of Sender ID.=20 Additionally, the reciprocal license issue is limited to IPR related to = Sender=20 ID, which is sufficiently restricted for our = needs.

-leon
 
--
Leon = Rishniw
Cloudmark,=20 Inc.
415-543-1220
leon@cloudmark.com
 
------_=_NextPart_001_01C491D3.C5AB6897-- From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 12:57:40 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 MAA10882 for ; Fri, 3 Sep 2004 12:57: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 i83GbncL035741; Fri, 3 Sep 2004 09:37: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 i83Gbndr035740; Fri, 3 Sep 2004 09:37:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83GbmhO035733 for ; Fri, 3 Sep 2004 09:37:48 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so17815rnk for ; Fri, 03 Sep 2004 09:37:51 -0700 (PDT) Received: by 10.38.78.70 with SMTP id a70mr79022rnb; Fri, 03 Sep 2004 09:37:51 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Fri, 3 Sep 2004 09:37:51 -0700 (PDT) Message-ID: <94df60cf040903093778623ae@mail.gmail.com> Date: Fri, 3 Sep 2004 12:37:51 -0400 From: Reply-To: To: Stephane Bortzmeyer Subject: Re: DOC-BUG: permitted use of PRA/submitter address Cc: MARID In-Reply-To: <20040903095139.GA15186@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <94df60cf040829163469ba9429@mail.gmail.com> <20040903095139.GA15186@nic.fr> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 3 Sep 2004 11:51:39 +0200, Stephane Bortzmeyer wrote: > > * I am on vacation, and receive mail which lists my own address in > > the To: or CC: fields, and does not have any indications such as > > "Precedence: list/bulk/junk" that it is from a mailing list. I wish > > for my filter to notify the sender that I will not be responding for > > a week. Should I send the notification to the MAIL-FROM address, as > > I currently do, or to the PRA? > > RFC 2822 and 3834 are quite clear, IMHO. > > 2822 : > > Resent fields are > strictly informational. They MUST NOT be used in the normal > processing of replies or other such automatic actions on messages. > > 2822 : > > When the "Reply-To:" field is present, it > indicates the mailbox(es) to which the author of the message suggests > that replies be sent. In the absence of the "Reply-To:" field, > replies SHOULD by default be sent to the mailbox(es) specified in the > "From:" field unless otherwise specified by the person composing the > reply. > > 3834 : > > Similarly, the Sender field SHOULD NOT be used as the destination for > automatic responses. This field is intended only to identify the > person or entity that sent the message, and is not required to > contain an address that is valid for replies. This is very useful information. If it could be included in a non-normative paragraph of the standard, I think it would avoid a lot of mis-use of addresses. (Incidentally, this is slightly off-topic, but is still fine to send mail to the Return-Path, even this address might be the same as Sender:?) David From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 12:59:41 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 MAA11020 for ; Fri, 3 Sep 2004 12:59:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Ge9jG035889; Fri, 3 Sep 2004 09:40: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 i83Ge9EE035888; Fri, 3 Sep 2004 09:40:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Ge88O035881 for ; Fri, 3 Sep 2004 09:40:08 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Sep 2004 09:40:11 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Sep 2004 09:40:08 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Sep 2004 09:40:11 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 09:40:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH-ERROR: Name of SUBMITTER parameter Date: Fri, 3 Sep 2004 09:40:10 -0700 Message-ID: Thread-Topic: TECH-ERROR: Name of SUBMITTER parameter thread-index: AcSRvTxj+SMaj6ZLQOunBFaFmo+7zAAFEJ1gAAC7OcA= From: "Harry Katz" To: , X-OriginalArrivalTime: 03 Sep 2004 16:40:09.0006 (UTC) FILETIME=[ACB824E0:01C491D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i83Ge98O035882 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Friday, September 03, 2004 9:20 AM, Matthew.van.Eerde@hbinc.com wrote: > wayne wrote: > > In <16695.45036.160556.552577@giles.gnomon.org.uk> Roy Badami > > writes: > >> MAIL FROM: PRA= > >> > >> is far more natural than the SUBMITTER alternative. > > So, I think we can count at least four people who would like to see > > SUBMITTER= renamed to PRA=. > > I respectfully disagree. Acronyms are harder to understand > than fully-spelled-out names. A search on AcronymFinder for > PRA returned 41 results: > Paint Research Association (UK) > Paperwork Reduction Act of 1995 > Parabolic Reflector Antenna > Parti pour le Renouveau Algerien > Participatory Rural Appraisal > > How about spelling PRA out rather than using the acronym? > > Matthew.van.Eerde@hbinc.com 805.964.4554 x902 > Hispanic Business Inc./HireDiversity.com Software Engineer > perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," > Actually, I prefer the name SUBMITTER and would like to stick with it. I believe that, from the sender's perspective, the name accurately conveys what the parameter means. It is only on the receiving side that the value becomes "purported." From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 13:09: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 NAA11437 for ; Fri, 3 Sep 2004 13:09:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83GlLDU036253; Fri, 3 Sep 2004 09:47:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83GlLeq036252; Fri, 3 Sep 2004 09:47:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83GlKHj036246 for ; Fri, 3 Sep 2004 09:47:21 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: Date: Fri, 3 Sep 2004 18:46:29 +0200 From: Arnt Gulbrandsen To: Jim Lyon Subject: Re: PRA Patent: License for Display in MUAs? Cc: "Michael R. Brumm" , "william(at)elan.net" , IETF MARID WG References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jim Lyon writes: > In spite of William's repeated assertions that it can't be done, we > have built prototypes internally that do exactly that. They work. What happens if a message is sent on Saturday, the sender publishes a new policy on Sunday, and the recipient's MUA attempts to verify the message on Monday? Arnt From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 13:36: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 NAA00291 for ; Fri, 3 Sep 2004 13:36:04 -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 i83HBdBe038802; Fri, 3 Sep 2004 10:11: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 i83HBd5A038801; Fri, 3 Sep 2004 10:11:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83HBa41038793 for ; Fri, 3 Sep 2004 10:11:39 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43755) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C3Hb4-0007qM-5W (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 18:11:34 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C3Hb4-0008C1-3s for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 18:11:34 +0100 Date: Fri, 3 Sep 2004 18:11:34 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: DOC_BUG: -submitter processing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Section 4.2: If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed." What if the SMTP server doesn't support ENHANCED-STATUS-CODES? What about error message i18n and l10n? The same comments apply to the next two paragraphs. There's also no reference to RFC 3463 in the draft. Verifying MTAs are strongly urged to validate the SUBMITTER parameter against the RFC 2822 headers; otherwise, an attacker can trivially defeat the algorithm. Is that a MUST or a SHOULD? Isn't it redundant with the previous paragraph but one? Tony. -- f.a.n.finch http://dotat.at/ FISHER GERMAN BIGHT: SOUTHERLY 3 OR 4. MAINLY FAIR. MODERATE OR GOOD. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 13:38: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 NAA00846 for ; Fri, 3 Sep 2004 13:38:32 -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 i83HGo2F039528; Fri, 3 Sep 2004 10:16:50 -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 i83HGoRD039527; Fri, 3 Sep 2004 10:16:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83HGnuo039512 for ; Fri, 3 Sep 2004 10:16:49 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: In support of Sender ID Date: Fri, 3 Sep 2004 12:16:44 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEBAD6@cliff.bai.org> Thread-Topic: In support of Sender ID thread-index: AcSR12hOyqZQbDPLSkC20CpYQjiuBgAAR+oA From: "Ryan Malayter" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i83HGouo039522 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Mark C. Langston] > Could we perhaps dispense with the corporate (particularly executive) > endorsement posts for Sender-ID? I thought people in the IETF > represented themselves. The few times I've seen products > mentioned, it was by the /developers/ of said products. > We are all posting as individuals, except perhaps for "AccuSpam", which seems to be both a company and a person. If someone supports their organization's position on the Sender ID proposal, it is a somehow less valid endorsement? Even if they - horror of horrors - support SenderID as an individual BECAUSE their organization supports it? Obviously, you've got your knickers in a twist because these posters disagree with you. These posters are not violating any of the rules of this forum, as far as I can tell. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 13:41:04 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 NAA00984 for ; Fri, 3 Sep 2004 13:41: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 i83HFBbx039185; Fri, 3 Sep 2004 10:15: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 i83HFBBt039184; Fri, 3 Sep 2004 10:15:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83HFAjX039176 for ; Fri, 3 Sep 2004 10:15:11 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so21590rnl for ; Fri, 03 Sep 2004 10:15:13 -0700 (PDT) Received: by 10.38.82.8 with SMTP id f8mr99627rnb; Fri, 03 Sep 2004 10:15:13 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Fri, 3 Sep 2004 10:15:13 -0700 (PDT) Message-ID: <94df60cf040903101569c44ad@mail.gmail.com> Date: Fri, 3 Sep 2004 13:15:13 -0400 From: Reply-To: To: Rand Wacker Subject: Re: (DEPLOY) In Support of Sender ID Cc: Kevin Peuhkurinen , ietf-mxcomp@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376D09.1000400@hepcoe.com> <94df60cf04090213282ae5c57b@mail.gmail.com> <94df60cf04090216057a06d0cc@mail.gmail.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 3 Sep 2004 09:14:43 -0700 (PDT), Rand Wacker wrote: > On Thu, 2 Sep 2004 mazieres@gmail.com wrote: > > > My challenge remains... describe a concrete scenario that requires > > Sender ID, and that could not achieve the same effective result with > > SPF-classic. Vague references to banks don't convince me any more, > > The following is not a vague reference, but an actual planned deployment > (I just can't tell you who is planning it for obvious reasons): > > Large Bank communicates with numerous customers addresses at Large ISP. > Large ISP has indicated that they will verify inbound authentication > credentials and has negotiated preferred delivery of authenticated mail > from Large Bank's domain. Large ISP has given Large Bank the ability to > add a limited number of bank-controlled domains to the Large ISP preferred > whitelist. > > Large Bank has quite a bit of customer email delivered by a third party. > This third party delivers mail with a bounce address (MAIL FROM) of > outsource.com (so they can do the bounce processing), but a From: header > of largebank.com. Large ISP will only whitelist largebank.com (because > that is who the ISP/Bank customers want to hear from, they don't care > about hearing from outsource.com). > > In this case, Sender ID would let Large ISP whitelist largebank.com and > still allow outsource.com to deliver mail for the bank (as long as the > bank's DNS records let it do so), /and/ continue to process bounces > properly. SPF doesn't permit From: header whitelisting (at best) and > breaks bounce handling (at worst). Okay, now suppose SPF-classic were adopted as a standard. Large ISP would now whitelist MAIL-FROM addresses in *.largebank.com instead of whitelisting those addresses in the PRA. If the bank wants outsource.com to send the mail, it sets up either a CNAME, or else: $ORIGIN largebank.com. outsource MX 10 largebank-bounces.outsource.com. outsource TXT "v=spf1 include:spf.outsource.com -all" And outsource.com now sends mail using bounce address "outsource.largebank.com." (As a bonus, if for some reason outsource.com had to be fired quickly, largebank could redirect bounces quickly to their replacement.) Now, of course, just as phisher could always use a PRA of postmaster@phisher.com with a From: address of largebank.com, the phisher can also use a MAIL-FROM address of postmaster@phisher.com. But again, just as in your example, the mail would not be whitelisted, which is the desired result. The mechanisms are slighly different, but the achieved security policy is the same. I'm sure that largebank.com and outsource.com would be happy to use either approach depending on what got standardized. David From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 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 NAA01178 for ; Fri, 3 Sep 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 i83HPr5i040242; Fri, 3 Sep 2004 10:25: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 i83HPrLs040241; Fri, 3 Sep 2004 10:25:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83HPqu7040230 for ; Fri, 3 Sep 2004 10:25:52 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i83HPo3V029822; Fri, 3 Sep 2004 10:25:50 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id BC36E84F866; Fri, 3 Sep 2004 10:25:48 -0700 (PDT) Date: Fri, 3 Sep 2004 10:25:48 -0700 From: "Mark C. Langston" To: Ryan Malayter Cc: ietf-mxcomp@imc.org Subject: Re: In support of Sender ID Message-ID: <20040903172548.GD55407@bitshift.org> References: <792DE28E91F6EA42B4663AE761C41C2A02CEBAD6@cliff.bai.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEBAD6@cliff.bai.org> User-Agent: Mutt/1.4.1i X-Uptime: 10:16AM up 1 day, 16:13, 6 users, load averages: 0.04, 0.16, 0.16 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 12:16:44PM -0500, Ryan Malayter wrote: > > [Mark C. Langston] > > Could we perhaps dispense with the corporate (particularly executive) > > endorsement posts for Sender-ID? I thought people in the IETF > > represented themselves. The few times I've seen products > > mentioned, it was by the /developers/ of said products. > > > > We are all posting as individuals I quote from the most recent instance of this behavior, to which I responded: "As a supporter of both commercial and opensource software models, Cloudmark does not see any issue with the Sender ID IPR license with" US corporate law not withstanding, Cloudmark is not an individual. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:04: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 OAA02620 for ; Fri, 3 Sep 2004 14:04:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Hc6DQ041397; Fri, 3 Sep 2004 10:38: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 i83Hc63Q041396; Fri, 3 Sep 2004 10:38:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Hc5OT041379 for ; Fri, 3 Sep 2004 10:38:05 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i83HbxZl004070 for ; Fri, 3 Sep 2004 18:37:59 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i83Hbw0l004069; Fri, 3 Sep 2004 18:37:58 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: (DEPLOY) In Support of Sender ID References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376D09.1000400@hepcoe.com> <94df60cf04090213282ae5c57b@mail.gmail.com> <94df60cf04090216057a06d0cc@mail.gmail.com> From: Graham Murray Date: Fri, 03 Sep 2004 18:37:58 +0100 In-Reply-To: (Rand Wacker's message of "Fri, 3 Sep 2004 09:14:43 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Rand Wacker writes: > Large Bank has quite a bit of customer email delivered by a third party. > This third party delivers mail with a bounce address (MAIL FROM) of > outsource.com (so they can do the bounce processing), but a From: header > of largebank.com. Large ISP will only whitelist largebank.com (because > that is who the ISP/Bank customers want to hear from, they don't care > about hearing from outsource.com). And prior to Sender-ID being published, a recipient looking at the headers will see that the mail was not sent from largebank.com and at least some of them might discard the email as not genuine - especially as phishing is so rife at the moment. If instead of this they were to create a sub-domain 'outsource.largebank.com' for outsource.com to use and set up the DNS for that sub-domain to point to outsource.com's servers then both SPF1 would work *and* customers examining the headers would see that it comes from a host within largebank.com and would therefore put more trust in the authenticity of the emails. As I have said before, organisations like largebank.com who use third party domains in their emails are making life easier for phishers. If customers see genuine emails sent from third party domains, they are less likely to suspect the forged emails sent by phishers. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:12:54 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 OAA03440 for ; Fri, 3 Sep 2004 14:12: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 i83HpxOW042491; Fri, 3 Sep 2004 10: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 i83HpxGm042490; Fri, 3 Sep 2004 10:51:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Hpwmf042483 for ; Fri, 3 Sep 2004 10:51:58 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [192.168.253.26] (unknown[66.240.194.10]) by comcast.net (rwcrmhc11) with ESMTP id <2004090317515401300h48u9e> (Authid: dhlii); Fri, 3 Sep 2004 17:51:54 +0000 Message-ID: <413A2AB4.1030300@comcast.net> Date: Sat, 04 Sep 2004 13:51:00 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: IETF MARID WG Subject: Re: Motion to abandon Sender ID References: <2AB71632-FD0A-11D8-BA2B-000A95AC5778@isipp.com> <030d01c49123$c0cdc450$3201a8c0@rasta> In-Reply-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 Sam Varshavchik wrote: > > Ummm, MSFT can certainly sue for an injunction prohibiting the F/OSS > developer from using patented IP without a license. You can not get a broad "nobody can infringe on my patent anywhere" injucntion. M$ would have to institute proceedings against each individial infringer. I beleive preliminary injunctions are granted based on the likelyhood of M$ to prevail, the patent will be presumed valid, But if there are substantial questions regarding whether there is actual infringement an injuction will not likely be granted. They are also granted based on the potential harm to the patent holder. Since all Microsoft is asking for a license is registration, the damages that an injunction would prevent probably are not significant enough to warant one. > > Since, as you've acknowledged, the F/OSS developer is not likely to > have the financial resources for a protracted fight, and challenging > the patent, Microsoft's legal expenses will be rather minimal. > > Do you think that there would be any value for Microsoft in blocking a > competing F/OSS implementation of Sender-ID? M$ can not afford a fight either. They may have plenty of money, but they are significantly short on good will. The DOJ may have wimped out for the moment, but they are still watching things. Ashcroft is not a Freind of Bill, the Democrats if elected are even less so. The EU is still proceeding, and world markets are enormously Microsoft unfriendly. M$ will benefit enormously by playing a key role in this standard. Everyone will suffer if they do not. Conversly, they will suffer if they are perceived as an impediment to the solution to this problem. M$ has an enormous PR problem. I can not think of a major company that is perceived of so poorly. The resources available in an F/OSS vs. Microsoft engagement might prove much more significant than you perceive. The SCO vs. IBM case might be more of a model. In the event they beleive it is in their own self interests - and weakening Microsoft may be in most of the rest of the industries self interest. A significant amount of Linux's current success, can be attributed to industry efforts to prick Microsoft. I would also not underestimate the desire of other major corporate sponsors to take a possition that makes them look like the good guy. Further ignoring the resources from Linux corporate sponsors. F/OSS has gottent large enough and cohesive enough to fend for itself. While there might be some F/OSS legal resources available, the research resources would be enormous. Again witness the SCO vs. IBM dispute. Research is the bane of any IP claim. Prior art is somewhat difficult and often expensive for a small business to prove, But the F/OSS community can probably provide Published prior art for just about any software concept. I understand there ar 2,000,000 F/OSS developers. Most are deeply steeped in this industry. Again using the SCO vs. IBM conflict as a model. I would note that Microsoft clearly wants SCO to triumph, but to the same extent has been unwilling to take a high profile stance. Microsft can not afford to be on the wrong side of SPAMmers vs. the rest of us, or Micorosoft vs. F/OSS. If you wish to attribute evil intentions to Microsoft here, the only scenario I see where they win is one where they get to claim to have contributed to a standard, while F/OSS developers self regulate and refuse to impliment it because of Microsoft's License. IP rights and patent law are just tools. The real battleground is one of perception. Microsoft is not below sabotaging F/OSS, but is unlikely to want a direct public confrontation. Microsoft is pretty bad at PR, but they are pretty good at finding the weaknesses of their competition and trying to exploit them. F/OSS developers and distributors are not going to support a standard that requires sending a signed license to Microsoft. Getting that scenario is a WIN for Microsoft. Microsoft gets to claim a standards compliant solution and all the F/OSS players leave the feild to commercial developers. If some F/OSS developer does move forward without licensing Sender-ID from Microsoft, M$ starts a PR campaign about the lack of respect F/OSS has for IP and how they are all just a bunch of untrustworthy hackers anyway. The losing scenario for Microsoft is the perception that M$ splintered MARID. Leaving us all with either weaker or not broadly implimented solutions to this problem. Regardless, our responsibility has little to do with Microsoft. It is to get the best standard with the broadest possible implimentation. If we reject Sender-ID we may loose Microsoft which would be bad. If we do not we lose F/OSS which would be worse. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:13: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 OAA03522 for ; Fri, 3 Sep 2004 14:13: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 i83Hs7nT042728; Fri, 3 Sep 2004 10:54: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 i83Hs7kg042727; Fri, 3 Sep 2004 10:54:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Hs6Ro042718 for ; Fri, 3 Sep 2004 10:54:06 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3IEU-0003Gt-OT; Fri, 03 Sep 2004 13:52:19 -0400 Message-ID: <4138AFB7.3080708@solidmatrix.com> Date: Fri, 03 Sep 2004 13:53:59 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Ryan Malayter CC: ietf-mxcomp@imc.org Subject: Re: In support of Sender ID References: <792DE28E91F6EA42B4663AE761C41C2A02CEBAD6@cliff.bai.org> In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEBAD6@cliff.bai.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ryan Malayter wrote: > [Mark C. Langston] > >>Could we perhaps dispense with the corporate (particularly executive) >>endorsement posts for Sender-ID? I thought people in the IETF >>represented themselves. The few times I've seen products >>mentioned, it was by the /developers/ of said products. >> > > We are all posting as individuals, except perhaps for "AccuSpam", which > seems to be both a company and a person. If someone supports their > organization's position on the Sender ID proposal, it is a somehow less > valid endorsement? Even if they - horror of horrors - support SenderID > as an individual BECAUSE their organization supports it? > > Obviously, you've got your knickers in a twist because these posters > disagree with you. These posters are not violating any of the rules of > this forum, as far as I can tell. > They are providing information on potential deployment. I find that information valuable. Also, lets not lose sight of the fact that all these various people and companies are actually agreeing to deploy Sender-ID. That is a big accomplishment for something that isn't even a standard yet. Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:16: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 OAA03819 for ; Fri, 3 Sep 2004 14:16: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 i83HuC4u042902; Fri, 3 Sep 2004 10:56: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 i83HuC1R042901; Fri, 3 Sep 2004 10:56:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83HuBk4042886 for ; Fri, 3 Sep 2004 10:56:11 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: In support of SenderID Date: Fri, 3 Sep 2004 12:56:10 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEBAE4@cliff.bai.org> Thread-Topic: In support of SenderID thread-index: AcSRSaeKzoUMGMSvQMS2bIcSjxw/+wAk0RCA From: "Ryan Malayter" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i83HuBk4042896 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [wayne] >This makes no sense. > >There is *zero* reason to believe that if MS wins IETF approval of the >current license that they will change later on. MS has been under a >lot of preasure for months and they really have barely budged on the >critical issues even when it is clear they risk getting approval. > >>...or a nonincumbered algorithm with similar >>effectiveness to >>PRA can be found and substitiuted. > >What you are saying here is that we wouldn't be accepting SenderID! > >So, if you are willing to accept something other than SenderID, why >don't you demand a better license *before* it gets approved? My apologies... my post *was* rather unclear. My position is that the MS license is "free and open enough" for my purposes, and those of many others. My position also assumes that there *can* be changes to these drafts before final ratification, including finding an alternative to the PRA document if it is ultimately deemed necessary. If that is not the case, please let me know; I thought nothing was "final" until ratification. My position is that SenderID will be useful in its current form for a lot of people, including me, my organization, and my clients. Basically, I do not want to see SenderID and all the work that has been done discarded. I also don't want to lose the MS partnership in this process, and therefore lose all the mailboxes and MTAs to which MS can easily deploy an authentication standard. Personally, I'd rather go forward with the IP issues than see SenderID killed now. -- Ryan From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:27: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 OAA04451 for ; Fri, 3 Sep 2004 14:27: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 i83I892m043754; Fri, 3 Sep 2004 11:08: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 i83I89PN043753; Fri, 3 Sep 2004 11:08:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83I88ic043740 for ; Fri, 3 Sep 2004 11:08:09 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: In support of Sender ID Date: Fri, 3 Sep 2004 13:08:07 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEBAF0@cliff.bai.org> Thread-Topic: In support of Sender ID thread-index: AcSR2w9o5mffIlkCQlaozIdNiFy6CgABONnQ From: "Ryan Malayter" To: "Mark C. Langston" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i83I89ic043747 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Mark C. Langston] >US corporate law not withstanding, Cloudmark is not an individual. I submit that the From address of the message in question was "Leon Rishniw". As you say, we are supposed to assume we all represent ourselves as individuals here. So to me, that message says "Leon Rishniw supports SenderID because Cloudmark organizationally supports it." That's his opinion, and I think he's just as entitled to express it as you are entitled to express yours. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:27:57 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 OAA04469 for ; Fri, 3 Sep 2004 14:27: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 i83I92RE043844; Fri, 3 Sep 2004 11:09: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 i83I924M043843; Fri, 3 Sep 2004 11:09:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83I9154043836 for ; Fri, 3 Sep 2004 11:09:01 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3ISy-00042a-LR; Fri, 03 Sep 2004 14:07:17 -0400 Message-ID: <4138B339.3070901@solidmatrix.com> Date: Fri, 03 Sep 2004 14:08:57 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Tony Finch CC: ietf-mxcomp@imc.org Subject: Re: DOC_BUG: -submitter processing References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony Finch wrote: > > Section 4.2: > > If these tests indicate that the connecting SMTP client is not > authorized to transmit e-mail messages on behalf of the SUBMITTER > domain, the receiving SMTP server SHOULD reject the message and when > rejecting MUST use "550 5.7.1 Submitter not allowed." > > What if the SMTP server doesn't support ENHANCED-STATUS-CODES? What about > error message i18n and l10n? The same comments apply to the next two > paragraphs. There's also no reference to RFC 3463 in the draft. I don't remember that SMTP error messages support i18n. I think only ASCII is allowed. Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:29: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 OAA04594 for ; Fri, 3 Sep 2004 14:29: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 i83IBEdZ044059; Fri, 3 Sep 2004 11:11: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 i83IBECD044058; Fri, 3 Sep 2004 11:11:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83IBEVI044038 for ; Fri, 3 Sep 2004 11:11:14 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i83IBB3V009476; Fri, 3 Sep 2004 11:11:12 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id ACB6F84F865; Fri, 3 Sep 2004 11:11:12 -0700 (PDT) Date: Fri, 3 Sep 2004 11:11:12 -0700 From: "Mark C. Langston" To: Ryan Malayter Cc: ietf-mxcomp@imc.org Subject: Re: In support of Sender ID Message-ID: <20040903181112.GE55407@bitshift.org> References: <792DE28E91F6EA42B4663AE761C41C2A02CEBAF0@cliff.bai.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEBAF0@cliff.bai.org> User-Agent: Mutt/1.4.1i X-Uptime: 11:09AM up 1 day, 17:06, 6 users, load averages: 0.12, 0.14, 0.09 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 01:08:07PM -0500, Ryan Malayter wrote: > > [Mark C. Langston] > >US corporate law not withstanding, Cloudmark is not an individual. > > I submit that the From address of the message in question was "Leon > Rishniw". As you say, we are supposed to assume we all represent > ourselves as individuals here. > > So to me, that message says "Leon Rishniw supports SenderID because > Cloudmark organizationally supports it." That's his opinion, and I think > he's just as entitled to express it as you are entitled to express > yours. So you'll be okay with all those people speaking up for their organizations, stating that their organizations won't be implementing it? Fair enough. The SETI Institute won't be implementing Sender-ID. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:42: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 OAA05429 for ; Fri, 3 Sep 2004 14:42:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83IKI3O044804; Fri, 3 Sep 2004 11:20: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 i83IKIm5044803; Fri, 3 Sep 2004 11:20:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83IKHJ1044794 for ; Fri, 3 Sep 2004 11:20:18 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: In support of Sender ID Date: Fri, 3 Sep 2004 13:20:16 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEBAF7@cliff.bai.org> Thread-Topic: In support of Sender ID thread-index: AcSR4WWvPg4+C6mqRQ+Hdv0CUBxWRQAAFwxQ From: "Ryan Malayter" To: "Mark C. Langston" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i83IKIJ1044798 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Mark C. Langston] >So you'll be okay with all those people speaking up for their >organizations, stating that their organizations won't be implementing >it? Of course. I think it's valuable for people to say here, "I don't support SenderID because my org feels they cannot implement it". Isn't that what this voting process all about? Approval or disapproval should still be taken as your personal opinion, but one of your motivations is the applicability of the standard to your organization. >Fair enough. The SETI Institute won't be implementing Sender-ID. Noted. -- Ryan From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:42:40 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 OAA05447 for ; Fri, 3 Sep 2004 14:42:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83IMMKP044993; Fri, 3 Sep 2004 11:22:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83IMMgY044992; Fri, 3 Sep 2004 11:22:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.cloudmark.com (mx1.cloudmark.com [67.109.59.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83IMIUq044978 for ; Fri, 3 Sep 2004 11:22:20 -0700 (PDT) (envelope-from leon@cloudmark.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: In support of Sender ID Date: Fri, 3 Sep 2004 11:22:16 -0700 Message-ID: Thread-Topic: In support of Sender ID Thread-Index: AcSR28q7cTzASa9mSzmn1y27BMPTLgAA7y3Q From: "Leon Rishniw" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i83IMMUq044986 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I quote from the most recent instance of this behavior, to which I > responded: > > "As a supporter of both commercial and opensource software > models, Cloudmark does not see any issue with the Sender ID > IPR license with" > > US corporate law not withstanding, Cloudmark is not an individual. My posting is specifically a response to corporate IPR issues and there are substantially different issues the applicability of the Sender ID licensing terms for companies, individuals and the opensource community, I consider it important that all entities are represented to a managed extent in this discussion. -leon From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 14:49: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 OAA05734 for ; Fri, 3 Sep 2004 14:49:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83IRxS3045350; Fri, 3 Sep 2004 11:27: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 i83IRx4x045349; Fri, 3 Sep 2004 11:27:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83IRxeF045340 for ; Fri, 3 Sep 2004 11:27:59 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i83IRw3V012951 for ; Fri, 3 Sep 2004 11:27:58 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 8569184F865; Fri, 3 Sep 2004 11:27:58 -0700 (PDT) Date: Fri, 3 Sep 2004 11:27:58 -0700 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: In support of Sender ID Message-ID: <20040903182758.GF55407@bitshift.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 11:24AM up 1 day, 17:20, 6 users, load averages: 0.01, 0.06, 0.07 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 11:22:16AM -0700, Leon Rishniw wrote: > > > I quote from the most recent instance of this behavior, to which I > > responded: > > > > "As a supporter of both commercial and opensource software > > models, Cloudmark does not see any issue with the Sender ID > > IPR license with" > > > > US corporate law not withstanding, Cloudmark is not an individual. > > My posting is specifically a response to corporate IPR issues and there > are substantially different issues the applicability of the Sender ID > licensing terms for companies, individuals and the opensource community, > I consider it important that all entities are represented to a managed > extent in this discussion. So you aren't posting as an individual? -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 15:25: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 PAA09448 for ; Fri, 3 Sep 2004 15:25:45 -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 i83J47ZQ047788; Fri, 3 Sep 2004 12:04: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 i83J475m047787; Fri, 3 Sep 2004 12:04:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83J46rb047781 for ; Fri, 3 Sep 2004 12:04:06 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3JKJ-00075m-O3; Fri, 03 Sep 2004 15:02:24 -0400 Message-ID: <4138C023.2000507@solidmatrix.com> Date: Fri, 03 Sep 2004 15:04:03 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Mark C. Langston" CC: ietf-mxcomp@imc.org Subject: Re: In support of Sender ID References: <20040903182758.GF55407@bitshift.org> In-Reply-To: <20040903182758.GF55407@bitshift.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark C. Langston wrote: > On Fri, Sep 03, 2004 at 11:22:16AM -0700, Leon Rishniw wrote: > >>>I quote from the most recent instance of this behavior, to which I >>>responded: >>> >>>"As a supporter of both commercial and opensource software >>>models, Cloudmark does not see any issue with the Sender ID >>>IPR license with" >>> >>>US corporate law not withstanding, Cloudmark is not an individual. >> >>My posting is specifically a response to corporate IPR issues and there >>are substantially different issues the applicability of the Sender ID >>licensing terms for companies, individuals and the opensource community, >>I consider it important that all entities are represented to a managed >>extent in this discussion. > > > > So you aren't posting as an individual? > Its not worth arguing over on the list. People and companies are free to express their opinions. Remember that Apache's opinion is coming on behalf of the organization. Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 15:26: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 PAA09526 for ; Fri, 3 Sep 2004 15:26:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83J3jdM047769; Fri, 3 Sep 2004 12:03: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 i83J3j71047768; Fri, 3 Sep 2004 12:03:45 -0700 (PDT) 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 i83J3ic4047760 for ; Fri, 3 Sep 2004 12:03:44 -0700 (PDT) (envelope-from ThomasGal@LumenVox.com) Received: from PROGTHOMAS ([10.0.0.162]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Sep 2004 11:56:15 -0700 Reply-To: From: "Thomas Gal" To: "'Mark C. Langston'" , Subject: RE: In support of Sender ID Date: Fri, 3 Sep 2004 12:03:42 -0700 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 In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB02340F8F@svr-exc.domain.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSR2MSQhsZJrhGIRg2JkUQCADTDDwADPKQA Message-ID: X-OriginalArrivalTime: 03 Sep 2004 18:56:15.0031 (UTC) FILETIME=[B00CAC70:01C491E7] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Couple concise thoughts if I may: I think I'd rather have someone say what their intent is, rather than hammering away and not disclosing their rationale/motivation. That being said Of course I DON'T want to see those posts either, you just haven't considered the parallel to it....... If you're going to take this tack then people shouldn't mention their open source licenses and how microsoft's IPR is incompatible, because that is just the analogue. Of course in this arena championing open source is much more "Politically Correct" if you will, and this bias slips into a LOT of peoples posts. I've seen QUITE a few posts saying "we can't do this because MS IPR etc etc etc". Personally I don't think anything but technical issues should be discussed. IF IPR ends up being an issue than this will NEVER become an official standard as wide depolyment is requisite for that. If it doesn't GREAT! Probably the best reason I can think of to limit this to technical discussion is that listening to lawyers is a waste of our time (no offense legal folk... Err....) , when this IS in fact a technical discussion. If lawyers actually agreed on things then we'd not have judges or a legal system. We should relish the fact that we operate in an area in which objective points can be raised, evaluated and implemented. So in summary: -No "This is good for our business" -No "this doesn't fit into our licensing scheme" -No "Microsoft is the devil" -No "Open source is the wave of the future" Let's talk about the issue we are here for, and stop treating this like it's 5th grade elections as we try to champion our personal cause. WHAT is going to solve the issue. HOW and WHY or WHY NOT. Just my PERSONAL opinion on what we should be discussing. I hope I didn't reveal any inclinations in supporting any of the periperhal issues, and if I did it was unintentional. Let's get down to business! -Tom -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Mark C. Langston Sent: Friday, September 03, 2004 9:56 AM To: ietf-mxcomp@imc.org Subject: Re: In support of Sender ID Could we perhaps dispense with the corporate (particularly executive) endorsement posts for Sender-ID? I thought people in the IETF represented themselves. The few times I've seen products mentioned, it was by the /developers/ of said products. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 15:37: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 PAA10042 for ; Fri, 3 Sep 2004 15:37: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 i83JGxki048562; Fri, 3 Sep 2004 12:16: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 i83JGxD3048561; Fri, 3 Sep 2004 12:16:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83JGwpP048555 for ; Fri, 3 Sep 2004 12:16:58 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i83JGu8F028575 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 12:17:01 -0700 Date: Fri, 3 Sep 2004 12:16:56 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Matt Sergeant cc: Ryan Malayter , "Michael R. Brumm" , IETF MARID WG Subject: Re: (DEPLOY) In Support of Sender ID In-Reply-To: <4042BB90-FD92-11D8-B236-000A95AC67AA@messagelabs.com> Message-ID: References: <4042BB90-FD92-11D8-B236-000A95AC67AA@messagelabs.com> 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, 3 Sep 2004, Matt Sergeant wrote: > On 2 Sep 2004, at 23:06, Rand Wacker wrote: > > > As I said before, there is a large majority of mail that goes from > > large commercial sites (or consumer ISPs) merely one hop to another > > large commercial ISP, so the From: header will be successfully > > authenticated. > > You're talking about the positive evaluation proposition of Sender-ID - > that the From address is authenticated. Yet both Cyphertrust and > SpamAssassin's stats show that the spammers are more on top of this > than the legit mailers. *NO*. I am talking about using authentication status as the basis for a new set of checks such as whitelisting. I have been saying since the beginning that spammers would authenticate their outbound mail in hipes that someone would make the brain-dead assumption that "authenticated" == "wanted". > This indicates to me that we need to be looking towards the negative > evaluation proposition (i.e. the value in rejecting mail) that Sender-ID > and/or SPF gives us, rather than hoping that a Sender-ID approved mail > actually provides us with any benefits. Sender ID approved mail provides you with the benefit in that it is authenticating a well-comprehended user address, the From: header. This is something that's easy for users and admins to comprehend and whitelist. Whitelisting of the envelope is more complex and won't be understood by a large portion of users out there. Everyone on this list has also admitted that *no* IP-based scheme can authenticate more than one hop prior to when you receive a message, and we all seem to agree that the right long term approach is a crypto-based solution. Sender ID gives you a nearer-term benefit for large business-to-ISP or large ISP-to-ISP mail delivery, where you /can/ authenticate the from header (stuff that goes through forwarding hops be damned seems to be the consensus of anyone pushing *any* IP-based solution). Sender ID also has a more graceful workaround for the forwarding hops that want to become compliant. SRS has some severe technical failings, so much so that source routing was completely abandoned 15 to 20 years ago as unworkable. Everyone knows that there are limitations to what Sender ID can do, but it brings a good enough benefit to a large enough percentage of mail that it is worth moving forward with (as long as the licensing issues can be worked out). SPF solves a different problem and brings a whole host of other technical issues to the table. -Rand From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 15:51:09 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 PAA10609 for ; Fri, 3 Sep 2004 15:51: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 i83JUZsi049855; Fri, 3 Sep 2004 12:30: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 i83JUZwV049854; Fri, 3 Sep 2004 12:30:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83JUZaW049848 for ; Fri, 3 Sep 2004 12:30:35 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i83JUW1i006862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Sep 2004 12:30:32 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i83JUT1I000755; Fri, 3 Sep 2004 12:30:30 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Fri, 3 Sep 2004 12:30:28 -0700 To: "IETF MARID WG" From: Ted Hardie Subject: Re: Obstacles between us and the finish line Cc: wayne Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:13 PM -0500 9/2/04, wayne wrote: > > > 4) IP licensing: I'm not dogmatic about the GPL or commercial >> licenses, but there are significant MTAs and mail filters that fall >> under both kinds of licenses, and several others to boot. I think >> that any proposal that has incompatible IP licensing needs to be >> dropped. > >Sadly, in response to this post back in July, Ted Hardie (the IETF >Area Director for this WG), told us to stop worry about IP licensing >issues. I believe the mess we are in right now is a direct result of >this. Instead of getting the IP licensing issue resolved *much* >earlier on, we now have a crisis and a no-win situation. There's no reference to which post of mine is meant, but I assume http://www.imc.org/ietf-mxcomp/mail-archive/msg02748.html is the one to which this refers. That post did not say "stop worrying about the licensing issues", it said "Discuss licensing in terms of the engineering decisions" or more fully: >Comments based solely on the licensing terms without regard to the engineering >choices they affect *do not speak to the question working groups need to >decide*. The sudden appearance of new working group participants >after postings inviting them to comment is welcome *if they contribute to >the engineering discussion*. But if you are here to comment on licensing >outside of the engineering context, you are wasting your electrons. Several posters since that point have made very clear posts describing the engineering choices and deployment mechanisms which would have to change in the context of their reading of this license. I again point to Eric's post as one example; there are others. Saying "I don't like this" means nothing. Saying "I won't implement this" or "I will deploy this" means something. Saying "To do this I would have to implement an external filter mechanism in my MTA and distribute the Sender-ID filter separately under this license. The cost of that external filter mechanism development plus the filter development isn't worth the spam reduction costs in my environment. If someone contributed the code for the external filter mechanism, however, I would be willing to work on code efficiency and provide a pointer to an external filter" gives a lot more for the group to work with. Ted Hardie From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 16:25: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 QAA11935 for ; Fri, 3 Sep 2004 16:25: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 i83K06N4052569; Fri, 3 Sep 2004 13:00: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 i83K06pb052568; Fri, 3 Sep 2004 13:00:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i83K05A0052554 for ; Fri, 3 Sep 2004 13:00:05 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 22004 invoked from network); 3 Sep 2004 20:00:06 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 3 Sep 2004 20:00:06 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "Jim Lyon" , "Arnt Gulbrandsen" Cc: "Michael R. Brumm" , "william\(at\)elan.net" , "IETF MARID WG" Subject: TECH-OMMISSION: Time Phasing Rules For Records Not Included In Core and Protocol (was RE: PRA Patent: License for Display in MUAs?) Date: Fri, 3 Sep 2004 16:00:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Jim Lyon > Sent: Friday, September 03, 2004 12:57 PM > To: Arnt Gulbrandsen > Cc: Michael R. Brumm; william(at)elan.net; IETF MARID WG > Subject: RE: PRA Patent: License for Display in MUAs? > > > > On Friday, September 03, 2004 at 9:46 AM, Arnt Gulbrandsen wrote: > > What happens if a message is sent on Saturday, the sender publishes a > > new policy on Sunday, and the recipient's MUA attempts to verify the > > message on Monday? > > If I recall correctly, in the original CallerID spec: > > 1. If you're retiring use of an MTA, your record should continue > to reference it for at least 28 days after it last sent outgoing > mail. and > > 2. An MUA must not attempt to validate messages received by their > org more than 28 days ago. > > > -- Jim Lyon > Then we need to add those rules to the Sender-ID RFCs or prohibit MUA level Sender-ID validation. Recommend we add to core, page 8, paragraph 7.5: If an MUA is going to accomplish Sender-ID validation, the MUA MUST NOT attempt to validate messages received by their organization more than 28 days ago. Recommend we add to protocol, page 24, a new paragraph 6.3: 6.3 Record Maintenance Time Requirements When sender policies change, it is important that old mechanisms not be remove prematurely. Temporary errors between MTAs can legitimately delay mail delivery for several days. Sender-ID validation by receiving MUAs may occur as much as 28 days after the message has been successfully received, see [CORE]. Obsolete mechanisms SHOULD NOT be removed from permitted sender records until at least 32 days after the last legitimate use of the mail sender defined by that mechanism. Earlier removal incurs the risk that legitimate mail will fail Sender-ID checks. I say should not rather than may not because there are no doubt reasons that senders might want to take the risk that mail would be lost rather than leave the obsolete mechanism in the record. Compromise of an MTA is one reason that comes to mind. 32 is my uneducated guess, I welcome corrections. I think it should be 28 days plus however long should be allowed for delayed delivery due to transient errors. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 16:25: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 QAA11953 for ; Fri, 3 Sep 2004 16:25: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 i83JpVl7051217; Fri, 3 Sep 2004 12:51:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83JpVZX051216; Fri, 3 Sep 2004 12:51:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83JpUnS051200 for ; Fri, 3 Sep 2004 12:51:30 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i83JpT3V000306; Fri, 3 Sep 2004 12:51:29 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 32D7D84F865; Fri, 3 Sep 2004 12:51:29 -0700 (PDT) Date: Fri, 3 Sep 2004 12:51:29 -0700 From: "Mark C. Langston" To: Yakov Shafranovich Cc: Ryan Malayter , ietf-mxcomp@imc.org Subject: Re: In support of Sender ID Message-ID: <20040903195129.GC91563@bitshift.org> References: <792DE28E91F6EA42B4663AE761C41C2A02CEBAD6@cliff.bai.org> <4138AFB7.3080708@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4138AFB7.3080708@solidmatrix.com> User-Agent: Mutt/1.4.1i X-Uptime: 12:43PM up 1 day, 18:40, 6 users, load averages: 0.00, 0.02, 0.05 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 01:53:59PM -0400, Yakov Shafranovich wrote: > > They are providing information on potential deployment. I find that > information valuable. > > Also, lets not lose sight of the fact that all these various people and > companies are actually agreeing to deploy Sender-ID. That is a big > accomplishment for something that isn't even a standard yet. > I've thought about what you said above, and I agree with it. I'm afraid the recent discussions have gotten to me, and without clear focus from the chairs, it seems to have become an "anything goes" topic. It is that to which I was reacting...and reacting poorly. For that, I apologize. However, there's another issue underlying my reaction that I think still holds water: I wouldn't want to see the issue clouded by perceived weight of name, or money, or implied size-of-support, which is what I think the original IETF dictum regarding individuals was meant to forestall: Bob Everyperson saying, "I support/do not support foo" is viewed -- often subconsciously and erroneously -- as having less weight in the discussion when Well Known Multinational, Inc. comes in and says the same thing, even though Mr. Everyperson's argument may be more technically substantive, or when WKM, Inc. statement is simply one of support or rejection, no more. I have every confidence in the chairs that they will not allow such things to unduly sway their decision with respect to consensus , but such things nonetheless tend to colour the discussion, often negatively. I've said my piece, and won't bring the issue up again. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 16:25: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 QAA11974 for ; Fri, 3 Sep 2004 16:25: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 i83JmagF050999; Fri, 3 Sep 2004 12:48:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83Jma8i050998; Fri, 3 Sep 2004 12:48:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83JmZsP050992 for ; Fri, 3 Sep 2004 12:48:35 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3K1J-0001hK-1J; Fri, 03 Sep 2004 15:46:49 -0400 Message-ID: <4138CA8C.5070004@solidmatrix.com> Date: Fri, 03 Sep 2004 15:48:28 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Rand Wacker CC: Matt Sergeant , Ryan Malayter , "Michael R. Brumm" , IETF MARID WG Subject: Re: (DEPLOY) In Support of Sender ID References: <4042BB90-FD92-11D8-B236-000A95AC67AA@messagelabs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Rand Wacker wrote: > On Fri, 3 Sep 2004, Matt Sergeant wrote: > > >>On 2 Sep 2004, at 23:06, Rand Wacker wrote: >> >> >>>As I said before, there is a large majority of mail that goes from >>>large commercial sites (or consumer ISPs) merely one hop to another >>>large commercial ISP, so the From: header will be successfully >>>authenticated. >> >>You're talking about the positive evaluation proposition of Sender-ID - >>that the From address is authenticated. Yet both Cyphertrust and >>SpamAssassin's stats show that the spammers are more on top of this >>than the legit mailers. > > > *NO*. I am talking about using authentication status as the basis for a > new set of checks such as whitelisting. I have been saying since the > beginning that spammers would authenticate their outbound mail in hipes > that someone would make the brain-dead assumption that "authenticated" == > "wanted". > It can also serve as a basis for reputation and accreditation systems. Remember that spam is multipronged, and this is another tool in the toolbox. No one is talking about this as the final solution for spam. Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 16:25:14 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 QAA11992 for ; Fri, 3 Sep 2004 16:25:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Jt3oi051585; Fri, 3 Sep 2004 12:55:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83Jt3np051584; Fri, 3 Sep 2004 12:55:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Jt2iD051578 for ; Fri, 3 Sep 2004 12:55:02 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i83Jt6R1003061 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 3 Sep 2004 12:55:06 -0700 Date: Fri, 3 Sep 2004 12:55:06 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: IETF MARID WG Subject: DEPLOY: Rejection of Sender ID does not result in standardization of SPF Classic 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: Over the past two weeks I've seen two kinds of posts to this mailing list: 1) "Here are some technical/legal issues I have with the last call specs, can we ammend the spec or come up with a well-known workaround?" 2) "I refuse to accept Sender ID for reason X, I vote we dump it and standardize SPF." If people saying the latter would state their reason and then be done I wouldn't be getting so frustrated, but the "standardize SPF" comments are what really make this process difficult. There is no either-or in this discussion. As the chairs have indicated, we are to be discussing Sender ID on its technical/legal/real-world merits. If the group decides to /not/ move forward and submit the Sender ID drafts to the IESG for whatever reason, fine, that's the choice of the group. No-one here should be under the impression that scuttling Sender ID at this time will give SPF Classic any fast track through the standards process. Sender ID and SPF are not equivalent standards and can not be considered as alternatives to each other. I look forward to debating SPF Classic, CSV, MPR, BATV, etc etc etc AT WHATEVER POINT THE CHAIRS DEEM APPROPRIATE, but this is not that time. Saying that you want to scuttle Sender ID simply because you prefer SPF is non-constructive to this group. In fact, the longer these debates get drawn out the longer we are prevented from constructively discussing other approaches which you may prefer! -Rand From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 16:25:44 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 QAA12019 for ; Fri, 3 Sep 2004 16:25:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83K3C3x053057; Fri, 3 Sep 2004 13:03: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 i83K3CNB053056; Fri, 3 Sep 2004 13:03:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83K3C37053043 for ; Fri, 3 Sep 2004 13:03:12 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i83K3B3V003382 for ; Fri, 3 Sep 2004 13:03:11 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 1617984F865; Fri, 3 Sep 2004 13:03:11 -0700 (PDT) Date: Fri, 3 Sep 2004 13:03:11 -0700 From: "Mark C. Langston" To: IETF MARID WG Subject: Re: (DEPLOY) In Support of Sender ID Message-ID: <20040903200311.GD91563@bitshift.org> References: <4042BB90-FD92-11D8-B236-000A95AC67AA@messagelabs.com> <4138CA8C.5070004@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4138CA8C.5070004@solidmatrix.com> User-Agent: Mutt/1.4.1i X-Uptime: 12:56PM up 1 day, 18:53, 6 users, load averages: 0.07, 0.06, 0.03 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 03:48:28PM -0400, Yakov Shafranovich wrote: > > It can also serve as a basis for reputation and accreditation systems. > > Remember that spam is multipronged, and this is another tool in the > toolbox. No one is talking about this as the final solution for spam. It's important to realize that there is no one single "solution for spam". Much like the security arena, any successful anti-spam strategy will need to take a "layered onion" approach: multiple, diverse tools and techniques, none sufficient on their own, that provide a comprehensive solution when deployed together. This means that a robust anti-spam solution will encompass authentication, reputation, acceditation, whitelisting, blacklisting, filtering, and other techniques, at various points in an organization's infrastructure. There is no anti-spam magic bullet, nor a simple, all-in-one appliance with a single management interface that'll solve all your spam problems. A single firewall does not a security strategy make; a single anti-spam tool does not an anti-spam strategy make. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 16:27:22 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 QAA12121 for ; Fri, 3 Sep 2004 16:27: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 i83K5o2a053318; Fri, 3 Sep 2004 13:05:50 -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 i83K5o4c053317; Fri, 3 Sep 2004 13:05:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.ironport.com (a50.ironport.com [63.251.108.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83K5oe9053308 for ; Fri, 3 Sep 2004 13:05:50 -0700 (PDT) (envelope-from ctaylor@ironport.com) Received: from anakin.ironport.com (HELO anakin.ironportsystems.com) (10.1.1.166) by smtp.ironport.com with ESMTP; 03 Sep 2004 13:05:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C491F1.68275D1B" Subject: X-header for forwarding MTAs Date: Fri, 3 Sep 2004 13:05:49 -0700 Message-ID: <65D2600546E11444960D957CFF5B644FC0D011@anakin.ironportsystems.com> Thread-Topic: X-header for forwarding MTAs Thread-Index: AcSR8RuofHb1T2sETZOFbnL/q3Xfhw== From: "Craig Taylor" To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C491F1.68275D1B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Both Yakov , Thomas and others have made calls to focus on technical issues, so here's a strictly technical issue. One of the weakness of SenderID is its exclusive focus on the last hop. If I receive my email via an alumni forwarding MTA, the alumni MTA might or might not run the SenderID check but regardless the MTA probably still accepts and passes the message through because it is a forwarder. When the message arrives at my MTA I can run the SenderID check but again I'll accept the message because it is coming from my alumni forwarder. What I'd like to know is if the connection to my forwarder failed the SenderID test. Having as part of the standard some sort of x-header that well-behaving forwarders used would allow me to look beyond the last hop. For example, "x-senderid-result receiver=3Dforwarder.com = connecting-ip=3Dx.x.x.x pra-result=3Dfail". While such a record can be forged there is no = reason to forge failures (what would be the point). Knowing that somewhere in the chain authentication has broken down would allow me to take further action based on failed authentication. In addition, the same header could potentially be used to communicate between the MTA and the MUA but that is another discussion probably best left to asrg. Craig Taylor VP, Technology Ironport System ------_=_NextPart_001_01C491F1.68275D1B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Both Yakov=20 , Thomas and others have made calls to focus on technical issues, = so here's=20 a strictly technical issue.

One of the=20 weakness of SenderID is its exclusive focus on the last hop.  = If I=20 receive my email via an alumni forwarding MTA, the alumni MTA might or = might not=20 run the SenderID check but regardless the MTA probably still accepts and = passes=20 the message through because it is a forwarder.  When the message = arrives at=20 my MTA I can run the SenderID check but again I'll accept the message = because it=20 is coming from my alumni forwarder.  What I'd like to know is if = the=20 connection to my forwarder failed the SenderID = test.

Having as part=20 of the standard some sort of x-header that well-behaving forwarders used = would=20 allow me to look beyond the last hop.  For=20 example, "x-senderid-result receiver=3Dforwarder.com connecting-ip=3Dx.x.x.x = pra-result=3Dfail". =20 While such a record can be forged there is no reason to = forge failures (what would be the point). Knowing that = somewhere in=20 the chain authentication has broken down would allow me to take further action based on=20 failed authentication.  In = addition,=20 the same header could potentially be used to=20 communicate between the MTA and the MUA but that is = another discussion probably best left to=20 asrg.

Craig=20 Taylor
VP,=20 Technology
Ironport=20 System
------_=_NextPart_001_01C491F1.68275D1B-- From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 16:45: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 QAA13178 for ; Fri, 3 Sep 2004 16:45:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83KN0Hb054469; Fri, 3 Sep 2004 13:23:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83KN0pK054468; Fri, 3 Sep 2004 13:23:00 -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 i83KMxxb054456 for ; Fri, 3 Sep 2004 13:22:59 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 599C4409F for ; Fri, 3 Sep 2004 13:22:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <09A765B5-FDE7-11D8-BB96-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: TECH-OMMISSION: Time Phasing Rules For Records Not Included In Core and Protocol (was RE: PRA Patent: License for Display in MUAs?) Date: Fri, 3 Sep 2004 13:22:54 -0700 To: IETF MARID WG 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 Sep 3, 2004, at 1:00 PM, Scott Kitterman wrote: > Recommend we add to protocol, page 24, a new paragraph 6.3: > > 6.3 Record Maintenance Time Requirements > ... I would recommend against such inclusions. I agree that the information given is sound advice for system administrators. But, the technical scheme is hardly dependent on following such advice, nor will ignoring such advice lead to any major break down. Such language belongs in a How-To document, not the draft. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:02:48 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 RAA13890 for ; Fri, 3 Sep 2004 17:02:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83KgQbu055438; Fri, 3 Sep 2004 13:42:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83KgQiX055437; Fri, 3 Sep 2004 13:42:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83KgPqM055424 for ; Fri, 3 Sep 2004 13:42:26 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 20:42:25 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "Rand Wacker" Subject: RE: (DEPLOY) In Support of Sender ID Date: Fri, 3 Sep 2004 14:42:37 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 03 Sep 2004 20:42:25.0067 (UTC) FILETIME=[84E307B0:01C491F6] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Rand Wacker wrote: > Sender ID also has a more graceful workaround for the forwarding hops that > want to become compliant. Yes, and the "graceful workaround" is also an open backdoor for injecting forged DSNs. That is a technical failing. Rand Wacker wrote: > SRS has some severe technical failings, so much so that source routing > was completely abandoned 15 to 20 years ago as unworkable. SRS has no technical failings AFAIK, and it is being used successfully by quite a few people on several MTA platforms. It isn't aesthetically pleasing, but that isn't a technical fault. And your reference to source routing makes me doubt you even understand what SRS is... How is source routing relevant to SRS? Rand Wacker wrote: > Everyone knows that there are limitations to what Sender ID can do, but it > brings a good enough benefit to a large enough percentage of mail that it > is worth moving forward with (as long as the licensing issues can be > worked out). The MARID charter is "authenticate mail transfer". The MARID charter isn't "make the largest percentage of existing mail transfer appear to be authenticated". There is a big difference between these two. The former means that an MTA implementing MARID will be able to authenticate all mail from a domain publishing MARID, now and in the future. SenderID currently falls in the latter. An MTA implementing SenderID will receive some types of mail which appear authenticated, but are not. In my experience, partial protection is no protection at all. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:02:55 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 RAA13908 for ; Fri, 3 Sep 2004 17:02:54 -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 i83KfhB0055376; Fri, 3 Sep 2004 13: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 i83KfhU4055375; Fri, 3 Sep 2004 13:41:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Kfgtx055369 for ; Fri, 3 Sep 2004 13:41:42 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C3KsS-0006vz-00; Fri, 03 Sep 2004 13:41:44 -0700 To: Rand Wacker Cc: IETF MARID WG Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardization of SPF Classic References: From: Daniel Quinlan Date: 03 Sep 2004 13:41:44 -0700 In-Reply-To: Rand Wacker's message of "Fri, 3 Sep 2004 12:55:06 -0700 (PDT)" Message-ID: Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Rand Wacker writes: > Over the past two weeks I've seen two kinds of posts to this mailing list: This message is itself out of order. It's neither an indication that you will or will not implement Sender-ID (and I believe Sendmail has already made their position clear). I see nothing procedurally wrong or confusing about someone saying "I cannot implement Sender-ID" and including an aside that someone could implement SPF as it was last proposed. You are right that the aside has no bearing on whether or not the chairs believe there is consensus, only the statements about Sender-ID. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:05: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 RAA14066 for ; Fri, 3 Sep 2004 17:05: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 i83Kk2Tb055683; Fri, 3 Sep 2004 13:46: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 i83Kk2iY055682; Fri, 3 Sep 2004 13:46:02 -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 i83Kk1bS055676 for ; Fri, 3 Sep 2004 13:46:01 -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 i83KtjvO031773; Fri, 3 Sep 2004 13:55:45 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i83Ktj5Q031770; Fri, 3 Sep 2004 13:55:45 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 3 Sep 2004 13:55:45 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: IETF MARID WG Subject: RE: PRA Patent: License for Display in MUAs? 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, 3 Sep 2004, Jim Lyon wrote: > On Thursday, September 02, 2004 at 7:38 PM, William Leibzon wrote: > > > Microsoft may have misled others that SenderID and PRA algorithm can > be > > used by MUAs to verify email (because of their dominance in MUA market > on > > Windows PCs, they need something for MUAs). That is not true. > > In spite of William's repeated assertions that it can't be done, we have > built prototypes internally that do exactly that. They work. I assert that it works because you know exactly which mail server your MUA is connecting to and for general case MUAs would not work. > Briefly, the algorithm is: > 1. Grovel through the Received: headers to find the header > describing the hop where the message entered the current > organization. Received headers have no standartization - there is not RFC requirement to add ip address of the client or its EHLO name into the header. How this information is entered in received header varies from MTA to MTA (closest semi-standard is sendmail way of adding data into received). Same system may add multiple received headers (qmail and postfix do in some cases) and there maybe several systems on receiving ISP end before email came to MDA, trying to determine which received header to check so that it is the one entered by MTA that received mail from external source is very hard and will lead to errors and may even cause to choose header that was forged by spammer. > 2. Extract the PRA from the [Resent-] Sender and From headers > as usual. In some cases PRA may have changed after received header (for example on receiving ISP end, mail was received by gateway, forwarded to intermediate system and then forwarded to MDA; forwarding server may have added its own resent-from header resulting in MUA system checking its own ISP instead of external system). > 3. Apply the SenderID algorithm. [Actually, our prototypes > used the earlier CallerID algorithm, but the point remains.] > > William also implies that Microsoft would intentionally mislead people > to believe that SenderID can be used in MUAs when it cannot. > In the first place, I resent the insinuation. I apologize if you understood my remarks as meaning that you -intentionally<- misled anybody (nor did I ever use those words). I meant that because of Microsoft MUA share you want algorithm that would work om MUAs and expect SenderID to work there (but not that you knew it would not work there and eventhough still said that it would). > In the second place, were such misleading to occur, it would hurt > Microsoft more than anyone else, precisely because we provide more of > the world's MUAs than anyone else. Yes. That is why you should be carefull about trying to apply SenderID algorithm in MUAs and understand that there would be great number of errors with such approach that might be blamed on MUA programmers. We should focus MARID efforts on MTA authorization as WG charter said and in my view doing authorization several email hops after is bad idea. And while displaying PRA by itself in MUA would not lead to anything bad and should probably be done, trying to assert if it was verified or not should only be done when you have data indicating that MTA in fact done such authorization. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:09:24 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 RAA14287 for ; Fri, 3 Sep 2004 17:09: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 i83KpEUM056307; Fri, 3 Sep 2004 13:51: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 i83KpE7U056306; Fri, 3 Sep 2004 13:51:14 -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 i83KpDaW056300 for ; Fri, 3 Sep 2004 13:51:13 -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 i83L0xZx032139; Fri, 3 Sep 2004 14:00:59 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i83L0xEM032136; Fri, 3 Sep 2004 14:00:59 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 3 Sep 2004 14:00:59 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: IETF MARID WG Subject: RE: PRA Patent: License for Display in MUAs? 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, 3 Sep 2004, Jim Lyon wrote: > On Friday, September 03, 2004 at 9:46 AM, Arnt Gulbrandsen wrote: > > What happens if a message is sent on Saturday, the sender publishes a > > new policy on Sunday, and the recipient's MUA attempts to verify the > > message on Monday? > > If I recall correctly, in the original CallerID spec: > > 1. If you're retiring use of an MTA, your record should continue > to reference it for at least 28 days after it last sent outgoing > mail. and > > 2. An MUA must not attempt to validate messages received by their > org more than 28 days ago. That is a bad idea. First of all trying to track email and do the changes some time after is not an easy thing, some ISPs may not be able to accomodate. Second there are number of references as part of SPF records to other dns records, such as to "A" record of hosts, to MX records, to PTR, etc. All these may have to change lot faster and not be possible to wait 28 days. Speaking as an ISP operator, I'm opposed to any language in the text that will specify time in which we have to change dns records when ips have already been changed or any constraints on provisioning and renunbering. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:09: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 RAA14315 for ; Fri, 3 Sep 2004 17:09: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 i83Ko4dw056247; Fri, 3 Sep 2004 13:50: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 i83Ko4wH056246; Fri, 3 Sep 2004 13:50:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Ko2dw056236 for ; Fri, 3 Sep 2004 13:50:03 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i83Ko5XW014007 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 13:50:05 -0700 Date: Fri, 3 Sep 2004 13:50:05 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: "Michael R. Brumm" cc: IETF MARID WG Subject: RE: (DEPLOY) In Support of Sender ID In-Reply-To: Message-ID: References: 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: I agree with some of the things you say Michael: > The MARID charter is "authenticate mail transfer". Interesting, I went back to read the charter and notice that MARID has no binding to do IP-based authentication (although it could be read that way). Maybe we *should* just go straight to a crypto-based solution. That would seem to get around a lot of the disagreement currently on the list. -Rand From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:09: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 RAA14307 for ; Fri, 3 Sep 2004 17:09:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Kme1b056191; Fri, 3 Sep 2004 13:48:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83KmeHF056190; Fri, 3 Sep 2004 13:48:40 -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 i83KmdLQ056179 for ; Fri, 3 Sep 2004 13:48:39 -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.8/8.12.8) with ESMTP id i83KmT1U014203 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 16:48:32 -0400 Message-Id: <6.1.2.0.2.20040903105731.07089d78@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 03 Sep 2004 11:02:07 -0400 To: Meng Weng Wong , ietf-mxcomp@imc.org From: Daniel Senie Subject: Re: (DEPLOY) In Support of Sender ID In-Reply-To: <20040903064213.GA23667@dumbo.pobox.com> References: <20040903064213.GA23667@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 02:42 AM 9/3/2004, Meng Weng Wong wrote: >On Fri, Sep 03, 2004 at 06:25:21AM +0100, Graham Murray wrote: >| >| Rand Wacker writes: >| >| > As I said before, there is a large majority of mail that goes from large >| > commercial sites (or consumer ISPs) merely one hop to another large >| > commercial ISP, so the From: header will be successfully authenticated. >| >| In the case of sending from a large ISP (and that includes commercial >| sites who outsource email) that is not true. Unless the ISP does >| additional checking then Sender-ID (and SPF) still allows a customer >| of the ISP to forge the mail as coming from any other customer of that >| ISP. > >My read of most ISPs is that they are willing to move in >this direction if it proves necessary. Many ISPs are >beginning to roll out (mandatory) SMTP AUTH. With that in >place, halting cross-customer forgery becomes a much more >likely proposition. To be a little more accurate, SMTP AUTH does not prevent customers of an ISP or hosting company spoofing one another, but it does provide an audit trail, so the person doing the spoofing can easily be identified from log entries. The real point (which I think Meng was trying to make) is that if we use whatever this WG produces (assuming something useful is produced) a mechanism that gets us back to the originating ISP, abuse at that level can and should be handled by that ISP. It may be beyond the scope of this WG to solve the internal abuse issues within an ISP. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:15: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 RAA14925 for ; Fri, 3 Sep 2004 17:15: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 i83KsgR8056831; Fri, 3 Sep 2004 13:54:42 -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 i83Ksg2N056830; Fri, 3 Sep 2004 13:54:42 -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 i83KsgCM056824 for ; Fri, 3 Sep 2004 13:54:42 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i83KskwQ018375 for ; Fri, 3 Sep 2004 13:54:47 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <7CE29E37-FDEB-11D8-BA2B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: RE: DEPLOY: Sender-ID provides little or no defence against adaptive threats Date: Fri, 3 Sep 2004 13:54:46 -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 > Anne P. Mitchell wrote: > >cf. CipherTrust's study released this week in which >50% of the > sources > >for all email surveyed which published SPF records were spammers. > > > >http://www.infoworld.com/article/04/08/31/HNspammerstudy_1.html > > Just so there is no confusion... this is good news for SPF, not bad > news. > Absolutely, completely agreed! I should have elaborated. As I have said in various public posts (elsewhere), if spammers want to tie themselves to their sites by authentication, that's a *good* thing. My points are that a) spammers will adopt whatever is out there, and in this instance b) spammers are stupid - by adopting what they *think* is an anti-spam protocol to help get their spam through, they are actually raising their hands and saying "here I am!" Anne From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:17: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 RAA15146 for ; Fri, 3 Sep 2004 17:17:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Ku9On056972; Fri, 3 Sep 2004 13:56: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 i83Ku9Y6056971; Fri, 3 Sep 2004 13:56:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i83Ku8uk056964 for ; Fri, 3 Sep 2004 13:56:09 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 52089 invoked from network); 3 Sep 2004 20:56:11 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 3 Sep 2004 20:56:11 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "IETF MARID WG" Subject: RE: TECH-OMMISSION: Time Phasing Rules For Records Not Included In Core and Protocol (was RE: PRA Patent: License for Display in MUAs?) Date: Fri, 3 Sep 2004 16:56:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <09A765B5-FDE7-11D8-BB96-000393A56BB6@glyphic.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Mark Lentczner > Sent: Friday, September 03, 2004 4:23 PM > To: IETF MARID WG > Subject: Re: TECH-OMMISSION: Time Phasing Rules For Records Not Included > In Core and Protocol (was RE: PRA Patent: License for Display in MUAs?) > On Sep 3, 2004, at 1:00 PM, Scott Kitterman wrote: > > Recommend we add to protocol, page 24, a new paragraph 6.3: > > > > 6.3 Record Maintenance Time Requirements > > ... > > I would recommend against such inclusions. I agree that the > information given is sound advice for system administrators. But, the > technical scheme is hardly dependent on following such advice, nor will > ignoring such advice lead to any major break down. Such language > belongs in a How-To document, not the draft. > I sort of agree, but the fundamental problem is that MUA level Sender-ID validation is currently neither permitted not forbidden. I think the time limits need to be written into the RFC somewhere if MUA validation isn't prohibited. If their not, we will end up with disagreements about long obsolete data should be maintained and whether or not someone's e-mail was appropriately rejected. I would expect that Jim's 28 days from the Caller ID spec was a surprise to a fair number of people. It certainly was for me. The time frame for which the record has to be valid is an important point. However we want to bound the time domain, we need to do it. I don't propose we go back to the idea of adding valid times to the records, that's complicated. I do think we need to define limits however. The best solution, I think, would be to have the MTA add headers that the MUA can process at leisure and prohibit direct Sender-ID validation by MUAs. Then the time bound is limited to the times associated with SMTP processing. Those are generally well understood. I would have suggested that originally, but was trying to avoid controversy. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:36:34 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 ; Fri, 3 Sep 2004 17:36:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LDNUi058267; Fri, 3 Sep 2004 14:13:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83LDN1J058266; Fri, 3 Sep 2004 14:13:23 -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 i83LDNmT058260 for ; Fri, 3 Sep 2004 14:13:23 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i83LDSqA001602 for ; Fri, 3 Sep 2004 14:13:28 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <1941B892-FDEE-11D8-BA2B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: If not Sender I.D., then what? (Was Re: In support of Sender ID) Date: Fri, 3 Sep 2004 14:13:27 -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 > > I submit that the From address of the message in question was "Leon > > Rishniw". As you say, we are supposed to assume we all represent > > ourselves as individuals here. > > > > So to me, that message says "Leon Rishniw supports SenderID because > > Cloudmark organizationally supports it." That's his opinion, and I > think > > he's just as entitled to express it as you are entitled to express > > yours. > > So you'll be okay with all those people speaking up for their > organizations, stating that their organizations won't be implementing > it? > > Fair enough. The SETI Institute won't be implementing Sender-ID. I have a question. I was given to believe that generally in the the call for support/rejection, the question is, and only is, "should we recommend this?", and nothing else. BUT, given the uniqueness of the situation, and that there *are* alternatives, would it be useful (or forbidden?) for people to say not only "We won't deploy Sender-I.D." but also "we *will* deploy SPF" or "we also won't deploy SPF" or "we will deploy this other alternative"? I ask because there is great pressure, both external and internal, to implement something - *anything* it seems. And a fair bit of "if you toss Sender I.D. because of unclear IP concerns, there will be nothing, and the devil you know is better than no devil at all" (to mix metaphors). So I wonder whether this would be useful data. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:36:41 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 RAA16469 for ; Fri, 3 Sep 2004 17:36:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LDOPG058275; Fri, 3 Sep 2004 14:13: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 i83LDO5T058274; Fri, 3 Sep 2004 14:13:24 -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 i83LDMSZ058259 for ; Fri, 3 Sep 2004 14:13:24 -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 i83LN8bS004141; Fri, 3 Sep 2004 14:23:08 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i83LN8n7004138; Fri, 3 Sep 2004 14:23:08 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 3 Sep 2004 14:23:08 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: IETF MARID WG Subject: RE: PRA Patent: License for Display in MUAs? 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, 3 Sep 2004, Jim Lyon wrote: > On Thursday, September 02, 2004 at 7:38 PM, William Leibzon wrote: > > > Microsoft may have misled others that SenderID and PRA algorithm can be > > used by MUAs to verify email (because of their dominance in MUA market on > > Windows PCs, they need something for MUAs). That is not true. > William also implies that Microsoft would intentionally mislead people > to believe that SenderID can be used in MUAs when it cannot. In the > first place, I resent the insinuation. I'm going to apologize again, I never meant to make a statement that somebody intentionally is doing anything bad as far as SenderID algorithm or its implementation in MUA or anywhere else. I note my original statement said "Microsoft may have misled others" and its part of the phrase for which I dropped one important word, this should have been "Microsoft may have unintentionally misled others" and this is not a very strong statement at all if they did or not. Again I aplogize to Microsoft and others. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:39: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 RAA16731 for ; Fri, 3 Sep 2004 17:39: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 i83LKKgW058779; Fri, 3 Sep 2004 14:20:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83LKK4m058778; Fri, 3 Sep 2004 14:20:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.omniti.com (longsword.omniti.com [66.80.117.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LKJFL058771 for ; Fri, 3 Sep 2004 14:20:19 -0700 (PDT) (envelope-from george@omniti.com) Received: from ([66.80.117.2:53242]) by mail.omniti.com (ecelerity 1.2.1-dev) with SMTP id 3F/10-22145-810E8314; Fri, 03 Sep 2004 17:20:28 -0400 In-Reply-To: <6.1.2.0.2.20040903105731.07089d78@mail.amaranth.net> References: <20040903064213.GA23667@dumbo.pobox.com> <6.1.2.0.2.20040903105731.07089d78@mail.amaranth.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: George Schlossnagle , Meng Weng Wong , ietf-mxcomp@imc.org From: George Schlossnagle Subject: Re: (DEPLOY) In Support of Sender ID Date: Fri, 3 Sep 2004 17:19:42 -0400 To: Daniel Senie 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 Sep 3, 2004, at 11:02 AM, Daniel Senie wrote: > > At 02:42 AM 9/3/2004, Meng Weng Wong wrote: > >> On Fri, Sep 03, 2004 at 06:25:21AM +0100, Graham Murray wrote: >> >> My read of most ISPs is that they are willing to move in >> this direction if it proves necessary. Many ISPs are >> beginning to roll out (mandatory) SMTP AUTH. With that in >> place, halting cross-customer forgery becomes a much more >> likely proposition. > > To be a little more accurate, SMTP AUTH does not prevent customers of > an ISP or hosting company spoofing one another, but it does provide an > audit trail, so the person doing the spoofing can easily be identified > from log entries. It can. There are MTAs which support only using a set envelope sender after SMTP AUTH. George From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:39:40 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 RAA16749 for ; Fri, 3 Sep 2004 17:39: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 i83LIcvX058697; Fri, 3 Sep 2004 14:18: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 i83LIcDj058696; Fri, 3 Sep 2004 14:18:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LIbK4058684 for ; Fri, 3 Sep 2004 14:18:37 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 21:18:38 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "Rand Wacker" Subject: RE: (DEPLOY) In Support of Sender ID Date: Fri, 3 Sep 2004 15:18:50 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 03 Sep 2004 21:18:38.0460 (UTC) FILETIME=[94547BC0:01C491FB] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Rand Wacker wrote: >I agree with some of the things you say Michael: > >> The MARID charter is "authenticate mail transfer". > >Interesting, I went back to read the charter and notice that MARID has no >binding to do IP-based authentication (although it could be read that >way). Maybe we *should* just go straight to a crypto-based solution. >That would seem to get around a lot of the disagreement currently on the >list. Well, I think the IETF should tackle crypto-based solutions after we have the IP-based authentication standard well on its way. MARID's charter might allow this. IP-based authentication on MTAs has been seen as the first step because it has a smaller deployment and a smaller performance cost than the crypto-based solutions. And, surprisingly robust authentication can be done with IP-based authentication, if the 2821 HELO and/or MAIL FROM are used. Crypto-based solutions can be applied later (after the IP-based authentication), because it has a larger deployment (modification to message re-writers like mailing lists, and normally also modifications to MUAs) and a much larger performance cost. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:41: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 RAA16790 for ; Fri, 3 Sep 2004 17:41: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 i83LKBoZ058766; Fri, 3 Sep 2004 14:20: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 i83LKBkJ058765; Fri, 3 Sep 2004 14:20:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LKADX058759 for ; Fri, 3 Sep 2004 14:20:10 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3LRy-00075o-O2; Fri, 03 Sep 2004 17:18:27 -0400 Message-ID: <4138E006.1080201@solidmatrix.com> Date: Fri, 03 Sep 2004 17:20:06 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Mark Lentczner CC: IETF MARID WG Subject: Re: TECH-OMMISSION: Time Phasing Rules For Records Not Included In Core and Protocol (was RE: PRA Patent: License for Display in MUAs?) References: <09A765B5-FDE7-11D8-BB96-000393A56BB6@glyphic.com> In-Reply-To: <09A765B5-FDE7-11D8-BB96-000393A56BB6@glyphic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > > > On Sep 3, 2004, at 1:00 PM, Scott Kitterman wrote: > >> Recommend we add to protocol, page 24, a new paragraph 6.3: >> >> 6.3 Record Maintenance Time Requirements >> ... > > > I would recommend against such inclusions. I agree that the information > given is sound advice for system administrators. But, the technical > scheme is hardly dependent on following such advice, nor will ignoring > such advice lead to any major break down. Such language belongs in a > How-To document, not the draft. > I am hesistant about not mentioning it at all since it is something that might come up often. Perhaps a separate BCP document can be referenced as part of the main draft. And while we are on that, is there a BCP document or is that planned for the future? Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:50: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 RAA17254 for ; Fri, 3 Sep 2004 17:50:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LTcQA059631; Fri, 3 Sep 2004 14:29: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 i83LTcHe059630; Fri, 3 Sep 2004 14:29:38 -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 i83LTcgX059620 for ; Fri, 3 Sep 2004 14:29:38 -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; Fri, 03 Sep 2004 17:29:40 -0400 id 0016BD8B.4138E245.0000378D Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <5B6D5450-FDF0-11D8-B6CF-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: Extension of Sender ID working group last call Date: Fri, 3 Sep 2004 17:29:37 -0400 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 All, As you know, the working group last call for the Sender ID document set has seen an enormous amount of response and this volume of emails has overwhelmed many participants. The co-chairs feel that the discussion around the IPR issue has derailed discussion of some of the technical issues that have been raised. Therefore we are extending the working group last call period until Friday, September 10 so that these technical issues may be discussed. The co-chairs will be sending out separate messages requesting feedback on these issues so that consensus can better be judged. We ask that all participants respond to these messages without regard to the IPR issue now before the working group. -your co-chairs From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17: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 RAA17408 for ; Fri, 3 Sep 2004 17:53: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 i83LY30f059980; Fri, 3 Sep 2004 14:34:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83LY30b059979; Fri, 3 Sep 2004 14:34:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LY2Rh059965 for ; Fri, 3 Sep 2004 14:34:03 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so52742rnl for ; Fri, 03 Sep 2004 14:33:56 -0700 (PDT) Received: by 10.38.82.8 with SMTP id f8mr228781rnb; Fri, 03 Sep 2004 14:33:56 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Fri, 3 Sep 2004 14:33:56 -0700 (PDT) Message-ID: <94df60cf0409031433199367c2@mail.gmail.com> Date: Fri, 3 Sep 2004 17:33:56 -0400 From: Reply-To: To: "william(at)elan.net" Subject: Re: PRA Patent: License for Display in MUAs? Cc: Jim Lyon , IETF MARID WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 3 Sep 2004 14:00:59 -0700 (PDT), william(at)elan.net wrote: > > That is a bad idea. First of all trying to track email and do the changes > some time after is not an easy thing, some ISPs may not be able to accomodate. > Second there are number of references as part of SPF records to other dns > records, such as to "A" record of hosts, to MX records, to PTR, etc. All > these may have to change lot faster and not be possible to wait 28 days. > > Speaking as an ISP operator, I'm opposed to any language in the text that > will specify time in which we have to change dns records when ips have > already been changed or any constraints on provisioning and renunbering. Correct me if I'm wrong, but I don't see anything in the current drafts to suggest you could perform Sender ID checks after the fact. I understand that *Caller ID* may have had such a stipulation. Thus, as I read the drafts currently being considered, it is not possible to implement Sender ID in an MUA. Does this mean we need a change? I think changing the document to support Sender ID checks after the fact would be fairly controversial, however, both with ISPs, and with small domain owners. If you want to do this, perhaps we need a macro for the number days since 1970 when the message was received. (%{t} is currently no good because it's only for explanations, it is in seconds, and it is the current time, not the time at which the message was received.) David From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:53: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 RAA17426 for ; Fri, 3 Sep 2004 17:53:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LWi3D059810; Fri, 3 Sep 2004 14:32: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 i83LWiKn059809; Fri, 3 Sep 2004 14:32:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from express.email-advantage.com ([216.116.197.217]) by above.proper.com (8.12.11/8.12.9) with SMTP id i83LWgn4059801 for ; Fri, 3 Sep 2004 14:32:43 -0700 (PDT) (envelope-from steve@prospectivdirect.com) Received: (qmail 11510 invoked from network); 3 Sep 2004 21:30:55 -0000 Received: from unknown (HELO ?216.116.197.209?) (216.116.197.209) by 0 with SMTP; 3 Sep 2004 21:30:55 -0000 Date: Fri, 3 Sep 2004 16:51:45 -0400 (EDT) From: Steven Carbone X-Sender: steve@firewall.eversave.com To: ietf-mxcomp@imc.org Subject: (Deploy) In support of 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: I am the CTO of Eversave.com and Prospectiv Direct, Inc. My company is a founding member of the Email Service Provider Coalition, and the responsible party for outgoing email for companies like ADVO/ShopWise.com, which operates the "America's Looking for Its Missing Children (R)" program. We are very interested in advancing authentication solutions - we need first to identify the senders, so we can move on to the deeper issues associated with email. I support and will be implementing Sender-ID. -Steven Carbone From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:53:11 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 RAA17458 for ; Fri, 3 Sep 2004 17:53:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83H0Zr2037470; Fri, 3 Sep 2004 10:00: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 i83H0Z3Q037469; Fri, 3 Sep 2004 10:00:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83H0Y3R037462 for ; Fri, 3 Sep 2004 10:00:35 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42169) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1C3HQP-0000wC-KZ (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 18:00:33 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C3HQP-0006gs-JY for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 18:00:33 +0100 Date: Fri, 3 Sep 2004 18:00:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: TECH-OMISSION: -pra security considerations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There should be a paragraph along the following lines in the Security Considerations of the -pra draft: > A message's PRA will often be extracted from a header field that is not > normally displayed by existing mail user agent software. If the PRA is > used as part of a mechanism to authenticate the message's origin, the > message SHOULD NOT be displayed with an indication of its authenticity > (positive or negative) without the PRA header field also being > displayed. Tony. -- f.a.n.finch http://dotat.at/ THE MULL OF GALLOWAY TO MULL OF KINTYRE INCLUDING THE FIRTH OF CLYDE AND THE NORTH CHANNEL: SOUTH OR SOUTHEAST 5 OR 6 VEERING SOUTHWEST 4 LATER. RAIN AND DRIZZLE AT TIMES. MODERATE OR GOOD, OCCASIONALLY POOR. SLIGHT TO MODERATE, BUT ROUGH AT TIMES THROUGH THE NORTH CHANNEL. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:53: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 RAA17488 for ; Fri, 3 Sep 2004 17:53: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 i83GtotG037053; Fri, 3 Sep 2004 09:55:50 -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 i83GtoPb037052; Fri, 3 Sep 2004 09:55:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Gtnl0037045 for ; Fri, 3 Sep 2004 09:55:49 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so20333rnk for ; Fri, 03 Sep 2004 09:55:47 -0700 (PDT) Received: by 10.38.78.70 with SMTP id a70mr89250rnb; Fri, 03 Sep 2004 09:55:47 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Fri, 3 Sep 2004 09:55:47 -0700 (PDT) Message-ID: <94df60cf040903095535c5e845@mail.gmail.com> Date: Fri, 3 Sep 2004 12:55:47 -0400 From: Reply-To: To: Jim Lyon Subject: Re: PRA Patent: License for Display in MUAs? Cc: "william(at)elan.net" , "Michael R. Brumm" , IETF MARID WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 3 Sep 2004 08:54:54 -0700, Jim Lyon wrote: > > On Thursday, September 02, 2004 at 7:38 PM, William Leibzon wrote: > > > Microsoft may have misled others that SenderID and PRA algorithm can > be > > used by MUAs to verify email (because of their dominance in MUA market > on > > Windows PCs, they need something for MUAs). That is not true. > > In spite of William's repeated assertions that it can't be done, we have > built prototypes internally that do exactly that. They work. > > Briefly, the algorithm is: > 1. Grovel through the Received: headers to find the header > describing the hop where the message entered the current > organization. > 2. Extract the PRA from the [Resent-] Sender and From headers > as usual. > 3. Apply the SenderID algorithm. [Actually, our prototypes > used the earlier CallerID algorithm, but the point remains.] Note that in fact this algorithm does not properly implement Sender ID in the MUA. The problem is that people might not read email until days or even a week after you send it. For dynamically assigned IP addresses, the IP address in the header will no longer be valid. For examply, suppose my computer is called mybox.dyndns.org. I always make sure that the DNS name points to my IP address. Thus, I publish "+a -all" as my SPF2 record. If my ISP switches my IP address every day at midnight, and you read my mail the following day, you will extract an old IP address from the Received header and therefore deem my mail a forgery. One of the objections people have raised to both SPF and to Sender ID is that they are bad for individual domain-name owners, and only work for large organizations. Until now, I thought there were no grounds for such an objection--just people who didn't understand what was really going on. If, in fact, Microsoft is thinking of implementing something in Outlook that would essentially freeze out people with dynamic IP addresses, I actually find that quite alarming. If people knew this, I think you would find a lot more technical objections to Sender ID. David From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:53: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 RAA17510 for ; Fri, 3 Sep 2004 17:53: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 i83LXnVa059957; Fri, 3 Sep 2004 14:33: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 i83LXnV5059956; Fri, 3 Sep 2004 14:33:49 -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 i83LXnJE059950 for ; Fri, 3 Sep 2004 14:33:49 -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; Fri, 03 Sep 2004 17:33:52 -0400 id 0016BD5F.4138E340.0000383F Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: consensus call on MUST/SHOULD language for TXT records Date: Fri, 3 Sep 2004 17:33:48 -0400 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 The debate over the MUST/SHOULD/MAY language with regard to compliance and publication of TXT and SPF2 record types does not seem to be getting the attention of the full working group. Despite lack of agreement on the outcome, there is agreement on the stated positions. In the words of Olafur: 1) Specify everyone to be compliant at all times. 2) Specify clearly full complaint state and tolerate non-compliant state during phase-in. Position 1 is predicated on the notion that a future RFC will deprecate the (use of the) TXT record in favor of the SPF2 record. Position 2 demands that the TXT record be discouraged from use in the current -protocol document. Rather than wordsmithing the actual MUST/SHOULD/MAY language directly (and endlessly), we ask the participants state their preference on these positions. -your co-chairs From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 17:59:11 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 RAA17648 for ; Fri, 3 Sep 2004 17:59: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 i83LchVq060528; Fri, 3 Sep 2004 14:38: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 i83LchVa060527; Fri, 3 Sep 2004 14:38: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 i83Lch6o060520 for ; Fri, 3 Sep 2004 14:38: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 82813414C5; Fri, 3 Sep 2004 14:38:46 -0700 (PDT) Subject: Re: Obstacles between us and the finish line From: Douglas Otis To: Graham Murray Cc: MARID In-Reply-To: References: <1094179813.19890.267.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1094247524.20922.7.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 14:38:45 -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-09-02 at 22:56, Graham Murray wrote: > Douglas Otis writes: > > > Once CSV is in place, to implement something extremely similar to SPF or > > Sender-ID becomes just a trivial name list created using PTR records > > much like DNA. > > Unfortunately this is not quite as trivial as it seems. I believe that > PTR records are not the easiest records for the domain owner > (especially the owner of small domains) to have control over. Review the MPR draft at: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt This was not referring to a reverse DNS lookup. This record type is being used in much the same manner as with the DNA draft but using the _mp._smtp.xxxx.xxx sub-domain. This would be a forward lookup and something easily within the control of the domain owner. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:03: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 SAA17879 for ; Fri, 3 Sep 2004 18:03: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 i83LfJB6061168; Fri, 3 Sep 2004 14:41:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83LfJbj061167; Fri, 3 Sep 2004 14:41:19 -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 i83LfJkg061161 for ; Fri, 3 Sep 2004 14:41:19 -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; Fri, 03 Sep 2004 17:41:23 -0400 id 0016BD5F.4138E503.000038BF In-Reply-To: <1941B892-FDEE-11D8-BA2B-000A95AC5778@isipp.com> References: <1941B892-FDEE-11D8-BA2B-000A95AC5778@isipp.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: IETF MARID WG From: Andrew Newton Subject: Re: If not Sender I.D., then what? (Was Re: In support of Sender ID) Date: Fri, 3 Sep 2004 17:41:18 -0400 To: "Anne P. Mitchell, Esq." 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 Sep 3, 2004, at 5:13 PM, Anne P. Mitchell, Esq. wrote: > So I wonder whether this would be useful data. At this point, what is most useful is the reason inhibiting deployment. And many people have been quite clear about that. -andy From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:07: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 SAA18342 for ; Fri, 3 Sep 2004 18:07: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 i83LkHAV061510; Fri, 3 Sep 2004 14:46:17 -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 i83LkHfS061509; Fri, 3 Sep 2004 14:46:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LkHxw061503 for ; Fri, 3 Sep 2004 14:46:17 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [10.0.0.120] ([10.0.0.120]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for ietf-mxcomp@imc.org; Fri, 3 Sep 2004 14:46:21 -0700 Subject: Re: X-header for forwarding MTAs From: Max Kanat-Alexander To: ietf-mxcomp@imc.org In-Reply-To: <65D2600546E11444960D957CFF5B644FC0D011@anakin.ironportsystems.com> References: <65D2600546E11444960D957CFF5B644FC0D011@anakin.ironportsystems.com> Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094247981.5557.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 03 Sep 2004 14:46:21 -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-09-03 at 13:05, Craig Taylor wrote: > Having as part of the standard some sort of x-header that > well-behaving forwarders used [snip] My understanding was that this is the purpose of the Resent-* headers. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:07:26 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 SAA18394 for ; Fri, 3 Sep 2004 18:07:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Llsd3061626; Fri, 3 Sep 2004 14:47:54 -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 i83LlsH1061625; Fri, 3 Sep 2004 14:47:54 -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 i83LlrLu061619 for ; Fri, 3 Sep 2004 14:47:54 -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.8/8.12.8) with ESMTP id i83Lln1e020400 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 3 Sep 2004 17:47:57 -0400 Message-Id: <6.1.2.0.2.20040903173253.0752eec0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 03 Sep 2004 17:42:13 -0400 To: ietf-mxcomp@imc.org From: Daniel Senie Subject: Re: In support of Sender ID In-Reply-To: <20040903172548.GD55407@bitshift.org> References: <792DE28E91F6EA42B4663AE761C41C2A02CEBAD6@cliff.bai.org> <20040903172548.GD55407@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 01:25 PM 9/3/2004, Mark C. Langston wrote: >On Fri, Sep 03, 2004 at 12:16:44PM -0500, Ryan Malayter wrote: > > > > [Mark C. Langston] > > > Could we perhaps dispense with the corporate (particularly executive) > > > endorsement posts for Sender-ID? I thought people in the IETF > > > represented themselves. The few times I've seen products > > > mentioned, it was by the /developers/ of said products. > > > > > > > We are all posting as individuals > >I quote from the most recent instance of this behavior, to which I >responded: > >"As a supporter of both commercial and opensource software models, >Cloudmark does not see any issue with the Sender ID IPR license with" > >US corporate law not withstanding, Cloudmark is not an individual. Should Cloudmark wish to have its representatives/employees active in the IETF explain why they feel Sender ID is the best solution on technical merit, that MIGHT be appropriate. The statement posted, however, is NOT useful input to the IETF process. Folks, we ALL want to find a solution to this mess, but there is a REAL need to find a solution that can be deployed by all types of organizations worldwide. That really implies it needs to be unencumbered to the greatest extent possible. Anyone or any company truly committed to the goal of dealing with spam should put that goal ahead of profit or legal protection. I do understand defensive patents. They are used acceptably without problematic license terms by many. I will not deploy Sender ID based on the legal issue. Since I happen to run a hosting company, it follows that my company also will not deploy the technology. As an individual participant in the IETF process, my reasons for deploying or not deploying a technology are based on technical merit first, and sadly of late on licensing terms for use of the IPR behind that technology. On technology grounds, we are planning to remove all SPF records from domains we host, due to significant issues seen with that technology. We do not use SPF on incoming mail ourselves to validate anything yet. We have had troubles with email delivery that resulted from the presence of SPF records, and after analysis are unsure SPF or Sender ID will have a net positive impact on the Internet. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:08:26 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 SAA18529 for ; Fri, 3 Sep 2004 18:08:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LiuW4061406; Fri, 3 Sep 2004 14:44: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 i83LiuMP061405; Fri, 3 Sep 2004 14:44:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LitGZ061399 for ; Fri, 3 Sep 2004 14:44:55 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3Lpv-0000ES-7q; Fri, 03 Sep 2004 17:43:11 -0400 Message-ID: <4138E5D3.6000401@solidmatrix.com> Date: Fri, 03 Sep 2004 17:44:51 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Craig Taylor CC: ietf-mxcomp@imc.org Subject: Re: X-header for forwarding MTAs References: <65D2600546E11444960D957CFF5B644FC0D011@anakin.ironportsystems.com> In-Reply-To: <65D2600546E11444960D957CFF5B644FC0D011@anakin.ironportsystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Craig Taylor wrote: > One of the weakness of SenderID is its exclusive focus on the last hop. > If I receive my email via an alumni forwarding MTA, the alumni MTA might > or might not run the SenderID check but regardless the MTA probably > still accepts and passes the message through because it is a forwarder. > When the message arrives at my MTA I can run the SenderID check but > again I'll accept the message because it is coming from my alumni > forwarder. What I'd like to know is if the connection to my forwarder > failed the SenderID test. > Can you give a reason of why you would be interested in that? Can you rely on your forwarder to do the checking? > Having as part of the standard some sort of x-header that well-behaving > forwarders used would allow me to look beyond the last hop. For > example, "x-senderid-result receiver=forwarder.com > connecting-ip=x.x.x.x pra-result=fail". While such a record can be > forged there is no reason to forge failures (what would be the point). > Knowing that somewhere in the chain authentication has broken down > would allow me to take further action based on failed authentication. > In addition, the same header could potentially be used to communicate > between the MTA and the MUA but that is another discussion probably > best left to asrg. > There was a "Received-SPF" header in the SPF draft. The problem with relying on headers is that they can be faked. This is one of the main issues we ran up against in the ASRG when discussing a common standard for MTA/MUA communications (for example, see http://216.239.39.104/search?q=cache:millenix.zemos.net/asrg-filtering/draft-irtf-asrg-filtering-header.html). One of the easy ways in dealing with it, is simply stripping all previous headers which I believe what SpamAssassin does. This would be problem when multiple forwarding hops are involved but it might be sufficient for a case like the one you are talking about. One of the beautiful things about Sender-ID and its related proposals is that they are based on one piece of data from the SMTP transaction that cannot be easily faked - the IP address of the incoming SMTP client (yes, I know about BGP attacks). The basic issue here is that Sender-ID is designed for MTA authorization which by definition is single-hop. Extending it past a single hop might better done with solutions like DomainKeys. But, on the other hand it might be possible to use the information in the headers including the "Received" and "Resent-*" headers to backtrack and verify each step. Of course, as William Leibzon pointed out in a different thread, that is not reliable. Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:08:54 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 SAA18616 for ; Fri, 3 Sep 2004 18:08: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 i83LoIT7061989; Fri, 3 Sep 2004 14:50: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 i83LoI7R061988; Fri, 3 Sep 2004 14:50:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LoH8J061971 for ; Fri, 3 Sep 2004 14:50:17 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so57438rnk for ; Fri, 03 Sep 2004 14:50:12 -0700 (PDT) Received: by 10.38.78.70 with SMTP id a70mr235840rnb; Fri, 03 Sep 2004 14:50:12 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Fri, 3 Sep 2004 14:50:12 -0700 (PDT) Message-ID: <94df60cf040903145029d7d68a@mail.gmail.com> Date: Fri, 3 Sep 2004 17:50:12 -0400 From: Reply-To: To: Scott Kitterman Subject: Re: TECH-OMMISSION: Time Phasing Rules For Records Not Included In Core and Protocol (was RE: PRA Patent: License for Display in MUAs?) Cc: Jim Lyon , Arnt Gulbrandsen , "Michael R. Brumm" , "william(at)elan.net" , IETF MARID WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 3 Sep 2004 16:00:06 -0400, Scott Kitterman wrote: > > Then we need to add those rules to the Sender-ID RFCs or prohibit MUA level > Sender-ID validation. I prohibiting MUA-level validation is fine, so long as the MUA is allowed to extract the validatoin result from some header. I think that after the fact Sender-ID validation is very problematic, and I would not like to see the changes you suggest. However, if you do include those changes, I would very strongly also encourage you to make the following change to the protocol draft: In section 7.1, between the macro explanations for p and v, include: u = The year, month, day, hour, and minute in UTC at which the message was accepted by the receiving MTA, separated by periods. The month, day, hour, and minute fields are always two decimal digits. In the example section (7.2), state that the received time is August 31, 2004, 12:30AM UTC, and include the examples: %{u} 2004.08.31.00.30 %{u3r} 31.08.2004 David From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:09: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 SAA18776 for ; Fri, 3 Sep 2004 18:09: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 i83LmID3061686; Fri, 3 Sep 2004 14:48: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 i83LmIef061685; Fri, 3 Sep 2004 14:48:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LmH19061678 for ; Fri, 3 Sep 2004 14:48:17 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3LtE-0000Pg-TN; Fri, 03 Sep 2004 17:46:37 -0400 Message-ID: <4138E6A0.3050204@solidmatrix.com> Date: Fri, 03 Sep 2004 17:48:16 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Michael R. Brumm" CC: IETF MARID WG , Rand Wacker Subject: Re: (DEPLOY) In Support of Sender ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Michael R. Brumm wrote: > Rand Wacker wrote: > >>I agree with some of the things you say Michael: >> >> >>>The MARID charter is "authenticate mail transfer". >> >>Interesting, I went back to read the charter and notice that MARID has no >>binding to do IP-based authentication (although it could be read that >>way). Maybe we *should* just go straight to a crypto-based solution. >>That would seem to get around a lot of the disagreement currently on the >>list. > > > Well, I think the IETF should tackle crypto-based solutions after we have > the IP-based authentication standard well on its way. MARID's charter might > allow this. > > IP-based authentication on MTAs has been seen as the first step because it > has a smaller deployment and a smaller performance cost than the > crypto-based solutions. And, surprisingly robust authentication can be done > with IP-based authentication, if the 2821 HELO and/or MAIL FROM are used. > > Crypto-based solutions can be applied later (after the IP-based > authentication), because it has a larger deployment (modification to message > re-writers like mailing lists, and normally also modifications to MUAs) and > a much larger performance cost. See: http://www.imc.org/ietf-mailsig/index.html From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:18:54 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 SAA20198 for ; Fri, 3 Sep 2004 18:18: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 i83LtP3Z062456; Fri, 3 Sep 2004 14:55: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 i83LtPZ3062455; Fri, 3 Sep 2004 14:55:25 -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 i83LtPpm062449 for ; Fri, 3 Sep 2004 14:55:25 -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 80AD1414C5; Fri, 3 Sep 2004 14:55:30 -0700 (PDT) Subject: Re: (DEPLOY) In Support of Sender ID From: Douglas Otis To: Daniel Senie Cc: Meng Weng Wong , MARID In-Reply-To: <6.1.2.0.2.20040903105731.07089d78@mail.amaranth.net> References: <20040903064213.GA23667@dumbo.pobox.com> <6.1.2.0.2.20040903105731.07089d78@mail.amaranth.net> Content-Type: text/plain Message-Id: <1094248528.20922.15.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 14:55:29 -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-09-03 at 08:02, Daniel Senie wrote: > At 02:42 AM 9/3/2004, Meng Weng Wong wrote: > > >On Fri, Sep 03, 2004 at 06:25:21AM +0100, Graham Murray wrote: > >| > >| Rand Wacker writes: > >| > >| > As I said before, there is a large majority of mail that goes from large > >| > commercial sites (or consumer ISPs) merely one hop to another large > >| > commercial ISP, so the From: header will be successfully authenticated. > >| > >| In the case of sending from a large ISP (and that includes commercial > >| sites who outsource email) that is not true. Unless the ISP does > >| additional checking then Sender-ID (and SPF) still allows a customer > >| of the ISP to forge the mail as coming from any other customer of that > >| ISP. > > > >My read of most ISPs is that they are willing to move in > >this direction if it proves necessary. Many ISPs are > >beginning to roll out (mandatory) SMTP AUTH. With that in > >place, halting cross-customer forgery becomes a much more > >likely proposition. > > To be a little more accurate, SMTP AUTH does not prevent customers of an > ISP or hosting company spoofing one another, but it does provide an audit > trail, so the person doing the spoofing can easily be identified from log > entries. > > The real point (which I think Meng was trying to make) is that if we use > whatever this WG produces (assuming something useful is produced) a > mechanism that gets us back to the originating ISP, abuse at that level can > and should be handled by that ISP. It may be beyond the scope of this WG to > solve the internal abuse issues within an ISP. Any process which authenticates the MTA, including CSV, would allow such a method of tracing. With Sender-ID or SPF, those administering the policy for the MTA remain anonymous. Unlike CSV, the Sender-ID or SPF name is not safely used for doing reputation assertions. After a name for an MTA is established, prescribing an association of the mailbox domain to a set of MTAs can be done using a simple list of names. With a name list, no subsequent lookups are required. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:25:40 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 SAA20602 for ; Fri, 3 Sep 2004 18:25: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 i83M36pX063135; Fri, 3 Sep 2004 15:03: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 i83M367M063134; Fri, 3 Sep 2004 15:03:06 -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 i83M36Q2063128 for ; Fri, 3 Sep 2004 15:03:06 -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 1EAE0414C5; Fri, 3 Sep 2004 15:03:11 -0700 (PDT) Subject: Re: (DEPLOY) In Support of Sender ID From: Douglas Otis To: Rand Wacker Cc: mazieres@gmail.com, Kevin Peuhkurinen , MARID In-Reply-To: References: <008801c49118$8321a780$6401a8c0@JTHSony> <41376D09.1000400@hepcoe.com> <94df60cf04090213282ae5c57b@mail.gmail.com> <94df60cf04090216057a06d0cc@mail.gmail.com> Content-Type: text/plain Message-Id: <1094248989.20922.22.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 15:03:09 -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-09-03 at 09:14, Rand Wacker wrote: > On Thu, 2 Sep 2004 mazieres@gmail.com wrote: > > > My challenge remains... describe a concrete scenario that requires > > Sender ID, and that could not achieve the same effective result with > > SPF-classic. Vague references to banks don't convince me any more, > > The following is not a vague reference, but an actual planned deployment > (I just can't tell you who is planning it for obvious reasons): > > Large Bank communicates with numerous customers addresses at Large ISP. > Large ISP has indicated that they will verify inbound authentication > credentials and has negotiated preferred delivery of authenticated mail > from Large Bank's domain. Large ISP has given Large Bank the ability to > add a limited number of bank-controlled domains to the Large ISP preferred > whitelist. > > Large Bank has quite a bit of customer email delivered by a third party. > This third party delivers mail with a bounce address (MAIL FROM) of > outsource.com (so they can do the bounce processing), but a From: header > of largebank.com. Large ISP will only whitelist largebank.com (because > that is who the ISP/Bank customers want to hear from, they don't care > about hearing from outsource.com). > > In this case, Sender ID would let Large ISP whitelist largebank.com and > still allow outsource.com to deliver mail for the bank (as long as the > bank's DNS records let it do so), /and/ continue to process bounces > properly. SPF doesn't permit From: header whitelisting (at best) and > breaks bounce handling (at worst). > > WRT to Resent-From spoofing and the PRA, its important to note that it is > the PRA result which is whitelisted, so if a phisher uses Resent-From: > phisher.com w/ From: largebank.com, the message will not get preferred > treatment by the ISPs whitelist. In the case of the MPR draft, the From header can receive specific restrictions. Whether a field is restricted or not does not impact reputation services or MTA authentications. This allows such restrictions to be applied as needed without the risk of a list treated as representing the nominal sources of mail, rather than the exclusive source of mail, serving as a spam exploit because of the double role of also associating the MTA to the mailbox domain. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:33: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 SAA21200 for ; Fri, 3 Sep 2004 18:33:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83M9Lth063694; Fri, 3 Sep 2004 15:09:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83M9LGW063693; Fri, 3 Sep 2004 15:09:21 -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 i83M9JnS063678 for ; Fri, 3 Sep 2004 15:09:20 -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 i83M8LG6014992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Sep 2004 18:08:24 -0400 Subject: Re: (DEPLOY) In Support of Sender ID From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: References: <20040903064213.GA23667@dumbo.pobox.com> <6.1.2.0.2.20040903105731.07089d78@mail.amaranth.net> Content-Type: text/plain Message-Id: <1094249240.6576.7.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 03 Sep 2004 18:07:20 -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 Fri, 2004-09-03 at 17:19, George Schlossnagle wrote: [snip] > > > > To be a little more accurate, SMTP AUTH does not prevent customers of > > an ISP or hosting company spoofing one another, but it does provide an > > audit trail, so the person doing the spoofing can easily be identified > > from log entries. > > It can. There are MTAs which support only using a set envelope sender > after SMTP AUTH. I'm actually doing this with some simple rulesets in sendmail on my personal domains. I even do 2822.from header checking to prevent forging the 2822.from address beyond issued aliases for a given username (my usernames are username@example.com). I currently don't support Resent-* headers (From: header is always checked) and don't know that I ever will. Point being that although SMTP AUTH doesn't require limiting users to specific 2821.from and/or 2822.from addresses, it certainly makes it possible, and in fact is trivial to add in at least some MTAs/MSAs. -- -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 Fri Sep 3 18:34:14 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 SAA21310 for ; Fri, 3 Sep 2004 18:34: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 i83MECCT064041; Fri, 3 Sep 2004 15:14: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 i83MECVM064040; Fri, 3 Sep 2004 15:14:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83MEBRZ064023 for ; Fri, 3 Sep 2004 15:14:11 -0700 (PDT) (envelope-from SRS0=IufEee0g=LY=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i83ME9jw068407 for ; Sat, 4 Sep 2004 00:14:09 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409032214.I83ME8W8068397@asarian-host.net> Date: Fri, 03 Sep 2004 22:14:09 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: (DEPLOY) In Support of Sender ID X-Trace: nMSru3e4aYFtNVIm9SpGqkQKr1ihowP20tMkUMm9sjeQKOXdRlbImwUW+/SHTYH/TciCq/19cH7vyKZC3Nfn5g== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <4042BB90-FD92-11D8-B236-000A95AC67AA@messagelabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQTjssTFqW1BleBN9AQGbPgf/ev89thns2jxAGMG7xa94wVvnEtJBXnLo 1bvBFj86dpTCuu5GD8892I7LfFzKK1E4F2WW+SCTAlZKACxhhNMNv5NTmaVEbDnG GyOsgBNNJs0iD9m373qpBiqYPX9Wiu9hJezQ6+ynxmzuVSRuFVyEP8Rt3asdxYsF +tP/UfLRTMXZfNdWBn0GQrjAvRkOhN/RUowYAecykn+ssLSGFL/py/5B3GA/BfiO p92ljDroxY62XBAtSQbp0lie0qaz30oTNLiD8uYzdNVqRGY33x591GhFfPh+f7jh 68IHN4r4OldCcHwXZEm6/14VTksXeywBQtwqLuUFHDRQqa97pzziRQ== =W3O1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Rand Wacker wrote: > Sender ID also has a more graceful workaround for the forwarding hops > that want to become compliant. SRS has some severe technical > failings, so much so that source routing was completely abandoned 15 > to 20 years ago as unworkable. There are, as far as I know, no outstanding issues with SRS. I have been using it almost since day one, on my own server (and implemented SRS functionality in spf-milter, for instance). It has no technical failings; let alone "severe" ones. In the very early days of SRS, addresses could become too long. Ever since SRS1, that problem has long since been solved, and people have upgraded both their SRS implementations and their knowledge of SRS. - Mark From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:39:04 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 SAA21668 for ; Fri, 3 Sep 2004 18:39: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 i83MJOJZ064438; Fri, 3 Sep 2004 15:19: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 i83MJOTH064437; Fri, 3 Sep 2004 15:19:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83MJNTn064429 for ; Fri, 3 Sep 2004 15:19:23 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3MNI-0002iK-TB; Fri, 03 Sep 2004 18:17:41 -0400 Message-ID: <4138EDE8.3020802@solidmatrix.com> Date: Fri, 03 Sep 2004 18:19:20 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Andrew Newton CC: IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > The debate over the MUST/SHOULD/MAY language with regard to compliance > and publication of TXT and SPF2 record types does not seem to be getting > the attention of the full working group. > > Despite lack of agreement on the outcome, there is agreement on the > stated positions. In the words of Olafur: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant state > during phase-in. > > Position 1 is predicated on the notion that a future RFC will deprecate > the (use of the) TXT record in favor of the SPF2 record. Position 2 > demands that the TXT record be discouraged from use in the current > -protocol document. > > Rather than wordsmithing the actual MUST/SHOULD/MAY language directly > (and endlessly), we ask the participants state their preference on these > positions. > I am not sure how #1 differs from #2? Are you suggesting that if we adopt position #1, someone not having SPF RR records would be ignored? Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:41: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 RAA17443 for ; Fri, 3 Sep 2004 17:53: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 i83LWMhS059795; Fri, 3 Sep 2004 14:32:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83LWMci059794; Fri, 3 Sep 2004 14:32:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83LWMZg059787 for ; Fri, 3 Sep 2004 14:32:22 -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; Fri, 03 Sep 2004 17:32:26 -0400 id 0016BD5F.4138E2EA.0000380B Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: consensus call of RR prefix Date: Fri, 3 Sep 2004 17:32:22 -0400 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 From the discussion on prefixes for the DNS record, there seems to have been no discernible outcome regarding the use of prefixes for the purposes of avoiding collisions with other DNS records (thus avoiding fallback to DNS over TCP). Naturally, this issue wraps itself into both the versioning/scoping issue and the wildcard issue. Based on the comments received so far, it is the opinion of the co-chairs that there is no consensus on how to handle wildcards and that most participants seem to agree that wildcards present a problem no matter the solution. Based on the comments received so far, it is the opinion of the co-chairs that there is consensus on placing the "scope" in the RDATA of the record and no consensus on the scope being in the prefix. Therefore, that leaves one under-discussed question: should a prefix be used to avoid collision with other records as one measure of preventing the requirement of DNS over TCP? Incidentally, the co-chairs note that many examples of the prefix have used "-marid". We would note that "MARID" is the name of this working group and likely not meaningful beyond the context of discussions and process of this working group. Therefore we recommend a more meaningful label such as "_rmx": the deduction of its meaning is easier and it references the genesis of the MARID idea. -your co-chairs From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:41: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 SAA21814 for ; Fri, 3 Sep 2004 18:41: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 i83MNQEW064780; Fri, 3 Sep 2004 15:23:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83MNQSL064779; Fri, 3 Sep 2004 15:23:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83MNPLc064771 for ; Fri, 3 Sep 2004 15:23:25 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C3MSt-0002op-00; Fri, 03 Sep 2004 15:23:27 -0700 To: Andrew Newton Cc: IETF MARID WG Subject: Re: consensus call of RR prefix References: From: Daniel Quinlan Date: 03 Sep 2004 15:23:27 -0700 In-Reply-To: Andrew Newton's message of "Fri, 3 Sep 2004 17:32:22 -0400" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > Therefore, that leaves one under-discussed question: should a prefix be > used to avoid collision with other records as one measure of preventing > the requirement of DNS over TCP? No. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:41: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 SAA21832 for ; Fri, 3 Sep 2004 18:41:32 -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 i83ML7uI064575; Fri, 3 Sep 2004 15:21: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 i83ML7wG064574; Fri, 3 Sep 2004 15:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83ML7dB064567 for ; Fri, 3 Sep 2004 15:21:07 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C3MQh-0002h3-00; Fri, 03 Sep 2004 15:21:11 -0700 To: Andrew Newton Cc: IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records References: From: Daniel Quinlan Date: 03 Sep 2004 15:21:11 -0700 In-Reply-To: Andrew Newton's message of "Fri, 3 Sep 2004 17:33:48 -0400" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > Despite lack of agreement on the outcome, there is agreement on the > stated positions. In the words of Olafur: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant > state during phase-in. > > Position 1 is predicated on the notion that a future RFC will deprecate > the (use of the) TXT record in favor of the SPF2 record. Position 2 > demands that the TXT record be discouraged from use in the current > -protocol document. I think Position 3 needs to be mentioned: 3) Remove SPF2 record and specify the use of TXT going forward. and Position 4: 4) Schedule the deprecation of TXT now, not later. Option 3 is so much superior to 1 and 2 from my perspective (MTA and spam filter software) that will be doing many DNS queries, that it's barely worth prioritizing 1 vs. 2. That being said, in order of preference: 3 >> 4 >> 2 >> 1 Put another way: - Doubling query volume is bad; inability to schedule in advance the end of querying both records is bad. - TXT is easier to deploy than SPF2 and no significant technical argument favors SPF2 over TXT aside from puritanism. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 18:49:40 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 SAA22092 for ; Fri, 3 Sep 2004 18:49:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83MT8Ga065459; Fri, 3 Sep 2004 15:29: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 i83MT8PU065458; Fri, 3 Sep 2004 15:29:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83MT7Fb065448 for ; Fri, 3 Sep 2004 15:29:07 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so60426rnk for ; Fri, 03 Sep 2004 15:28:57 -0700 (PDT) Received: by 10.38.74.61 with SMTP id w61mr253346rna; Fri, 03 Sep 2004 15:28:57 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Fri, 3 Sep 2004 15:28:57 -0700 (PDT) Message-ID: <94df60cf04090315281062428e@mail.gmail.com> Date: Fri, 3 Sep 2004 18:28:57 -0400 From: Reply-To: To: Andrew Newton Subject: Re: consensus call on MUST/SHOULD language for TXT records Cc: IETF MARID WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 3 Sep 2004 17:33:48 -0400, Andrew Newton wrote: > > Despite lack of agreement on the outcome, there is agreement on the > stated positions. In the words of Olafur: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant > state during phase-in. I would favor position 2. I think the recommended document should describe where we want to be in the long run, whether or not we can get there quickly. While I strongly suspect Sender ID will undergo future revisions anyway, why intentionally adopt a standard that will have to be superseded? David From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:09: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 TAA22968 for ; Fri, 3 Sep 2004 19:09:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83MnSJB067521; Fri, 3 Sep 2004 15:49: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 i83MnSrp067520; Fri, 3 Sep 2004 15:49:28 -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 i83MnR86067514 for ; Fri, 3 Sep 2004 15:49:27 -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 i83MxDjv012407; Fri, 3 Sep 2004 15:59:13 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i83MxDJh012404; Fri, 3 Sep 2004 15:59:13 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 3 Sep 2004 15:59:13 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records 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, 3 Sep 2004, Andrew Newton wrote: > The debate over the MUST/SHOULD/MAY language with regard to compliance > and publication of TXT and SPF2 record types does not seem to be > getting the attention of the full working group. > > Despite lack of agreement on the outcome, there is agreement on the > stated positions. In the words of Olafur: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant > state during phase-in. > > Position 1 is predicated on the notion that a future RFC will deprecate > the (use of the) TXT record in favor of the SPF2 record. Position 2 > demands that the TXT record be discouraged from use in the current > -protocol document. > > Rather than wordsmithing the actual MUST/SHOULD/MAY language directly > (and endlessly), we ask the participants state their preference on > these positions. I take middle position: 1.5) Specify everyone to be compliant at all times and tolerate non-compliance as a matter of fact (current reality) for a given period of time (next 4 years say). P.S. Did I hear right that next version of Windows is coming early 2006? I assume Microsoft people present here are going to work on making sure that it will support "unknown" and yet undefined dns data types as well as preferably support new SPF data type directly... -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:09: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 TAA22969 for ; Fri, 3 Sep 2004 19:09:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83MllB0067012; Fri, 3 Sep 2004 15:47:47 -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 i83MllkA067011; Fri, 3 Sep 2004 15:47:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Mll71067004 for ; Fri, 3 Sep 2004 15:47:47 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3Mon-000410-IK for ietf-mxcomp@imc.org; Fri, 03 Sep 2004 18:46:05 -0400 Message-ID: <4138F491.1040102@solidmatrix.com> Date: Fri, 03 Sep 2004 18:47:45 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "IETF MXCOMP (E-mail)" Subject: DOC-BUG: Security considerations for parsing records Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I haven't seen this mentioned in the drafts, but I remember someone Bellovin bringing this up in a different forum in regards to SPF a few months ago. Among the two RR formats for Sender-ID, is the TXT format. As Steve pointed out, parsing any kind of free form data can potentially lead to security issues if the parsers are not written properly (such as buffer overruns). Therefore, it might be useful to add a section or just a few sentences to mention that issue. Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:26: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 SAA21663 for ; Fri, 3 Sep 2004 18:39: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 i83MKfhg064530; Fri, 3 Sep 2004 15:20: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 i83MKfsa064529; Fri, 3 Sep 2004 15:20: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 i83MKfSv064521 for ; Fri, 3 Sep 2004 15:20: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 i83MTGNs010874; Fri, 3 Sep 2004 15:29:16 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i83MTG88010871; Fri, 3 Sep 2004 15:29:16 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 3 Sep 2004 15:29:16 -0700 (PDT) From: "william(at)elan.net" To: mazieres@gmail.com cc: IETF MARID WG Subject: Re: PRA Patent: License for Display in MUAs? In-Reply-To: <94df60cf0409031433199367c2@mail.gmail.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, 3 Sep 2004 mazieres@gmail.com wrote: > Correct me if I'm wrong, but I don't see anything in the current > drafts to suggest you could perform Sender ID checks after the fact. > I understand that *Caller ID* may have had such a stipulation. Thus, > as I read the drafts currently being considered, it is not possible to > implement Sender ID in an MUA. Does this mean we need a change? The current drafts are inprecise and I've pointed out some of the conflicting statements in one of previous posts. The marid-core draft in introduction says that: "This document described mechanism such that receiving MTAs, MDAs and/or MUAs can recognize mail in the above category and take appropriate action. For example, an MTA might refuse to accept a message, an MDA might discard a message rather then placing it into a mailbox, and an MUA might render that message in some distinctive fashion". This statement can be understood to mean that MUAs would do SenderID check but can also be understood that MUAs will take certain actions (displaying verified email address, etc) based on secondary information from MTA but not directly do authentication. However majority of people reading above statement will probably understand it to mean that MUAs would do authorization directly, so I'd like to request that this statement be changed to: "This document described mechanism such that receiving MTAs and MDAs can recognize mail in the above category and take appropriate action. For example, an MTA might refuse to accept a message and MDA might discard a message rather then placing it into a mailbox." > I think changing the document to support Sender ID checks after the > fact would be fairly controversial, however, both with ISPs, and with > small domain owners. If you want to do this, perhaps we need a macro > for the number days since 1970 when the message was received. (%{t} > is currently no good because it's only for explanations, it is in > seconds, and it is the current time, not the time at which the message > was received.) It gets complicated, messy and leads to errors when you try to do ip authorization after the smtp transaction and especially when you know that serious amount of time passed from when it happened (serious is anything more then 1 hour and even that is too much). It is also very difficult to standartize this behavior and its outside scope of this working group which is developing standard ONLY for MTA authorization using DNS records. The only program that has been successfull after the fact is Spamassin and the reason is that it does it right after message is received by SMTP server (within seconds usually) so there is no time interval and spamassasin is setup specific with MTA it works with so it knows exactly how that MTA will inform about which client just connected to it and it knows there were no other email hop in between. Nevertheless, as I understand it, spamassasin developers prefer to move system where spamassasin is called directly from MTA (andthus within scope of mail transaction) and not after the completion of transaction. That is why it is now often called from sendmail milter and patches are available for other MTAs. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:27: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 TAA23893 for ; Fri, 3 Sep 2004 19:27:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83N9UCT070142; Fri, 3 Sep 2004 16:09: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 i83N9UMw070141; Fri, 3 Sep 2004 16:09:30 -0700 (PDT) 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 i83N9Tad070135 for ; Fri, 3 Sep 2004 16:09:29 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Fri, 03 Sep 2004 19:09:34 -0400 id 0000000000157937.000000004138F9AE.00006575 X-IMAP-Sender: mrsam@courier-mta.com References: Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: IETF MARID WG X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: Obstacles between us and the finish line Date: Fri, 03 Sep 2004 19:09:34 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-17893-1094252974-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-17893-1094252974-0007 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Ted Hardie writes: > > At 8:13 PM -0500 9/2/04, wayne wrote: > That post did not say "stop worrying about the licensing issues", > it said "Discuss licensing in terms of the engineering decisions" > or more fully: > >>Comments based solely on the licensing terms without regard to the engineering >>choices they affect *do not speak to the question working groups need to >>decide*. The sudden appearance of new working group participants >>after postings inviting them to comment is welcome *if they contribute to >>the engineering discussion*. But if you are here to comment on licensing >>outside of the engineering context, you are wasting your electrons. > > Several posters since that point have made very clear posts describing > the engineering choices and deployment mechanisms which would have to > change in the context of their reading of this license. I again point > to Eric's post as one example; there are others. > > Saying "I don't like this" means nothing. Saying "I won't implement this" > or "I will deploy this" means something. Right. I'm afraid that this licensing issue has a major engineering impact. Engineering as in: well, this licensing issue will prevent any engineering from occuring in the first place. --=_mimegpg-commodore.email-scan.com-17893-1094252974-0007 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBOPmux9p3GYHlUOIRAhrgAJ4/FU6YqhCFb0xmo3ky74rQNQYXJACfQzHp lH1UWFnwAx/gvTfm+H/xHJY= =Une1 -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-17893-1094252974-0007-- From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:27:40 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 TAA23911 for ; Fri, 3 Sep 2004 19:27:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83N7lQK070017; Fri, 3 Sep 2004 16:07:47 -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 i83N7lvd070016; Fri, 3 Sep 2004 16:07:47 -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 i83N7kYq070009 for ; Fri, 3 Sep 2004 16:07:46 -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 i83NHYbk013749; Fri, 3 Sep 2004 16:17:34 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i83NHYZT013746; Fri, 3 Sep 2004 16:17:34 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 3 Sep 2004 16:17:34 -0700 (PDT) From: "william(at)elan.net" To: Yakov Shafranovich cc: "IETF MXCOMP (E-mail)" Subject: Re: DOC-BUG: Security considerations for parsing records In-Reply-To: <4138F491.1040102@solidmatrix.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, 3 Sep 2004, Yakov Shafranovich wrote: > > I haven't seen this mentioned in the drafts, but I remember someone > Bellovin bringing this up in a different forum in regards to SPF a few http://www.interesting-people.org/archives/interesting-people/200401/msg00037.html Steve Bellovin is security area advisor at IETF and part of IESG. While we're at it please look through his message and compare if we solved other issues mentioned there too. > months ago. Among the two RR formats for Sender-ID, is the TXT format. > As Steve pointed out, parsing any kind of free form data can potentially > lead to security issues if the parsers are not written properly (such as > buffer overruns). Therefore, it might be useful to add a section or just > a few sentences to mention that issue. I agree. This should be in protocol draft. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:27: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 TAA23929 for ; Fri, 3 Sep 2004 19:27: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 i83N5N3H069828; Fri, 3 Sep 2004 16:05:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83N5NQP069827; Fri, 3 Sep 2004 16:05:23 -0700 (PDT) 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 i83N5Mwo069815 for ; Fri, 3 Sep 2004 16:05:22 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Fri, 03 Sep 2004 19:05:24 -0400 id 0000000000157937.000000004138F8B4.00006570 X-IMAP-Sender: mrsam@courier-mta.com References: <2AB71632-FD0A-11D8-BA2B-000A95AC5778@isipp.com> <030d01c49123$c0cdc450$3201a8c0@rasta> <413A2AB4.1030300@comcast.net> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: IETF MARID WG X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: Motion to abandon Sender ID Date: Fri, 03 Sep 2004 19:05:24 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-17893-1094252724-0006"; 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-17893-1094252724-0006 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit David H. Lynch Jr. writes: > > Sam Varshavchik wrote: > >> >> Ummm, MSFT can certainly sue for an injunction prohibiting the F/OSS >> developer from using patented IP without a license. > > You can not get a broad "nobody can infringe on my patent anywhere" > injucntion. That's why I used the word "the", above. > M$ would have to institute proceedings against each > individial infringer. There are not that many F/OSS MTA developers. An individual injunction for each one of them is quite feasible. Game over. > I beleive preliminary injunctions are granted based on the > likelyhood of M$ to prevail, the patent will be presumed valid, But if > there are substantial questions regarding > whether there is actual infringement an injuction will not likely be > granted. If the F/OSS developer implements Sender-ID without registering with Microsoft, and without giving Microsoft a reciprocal patent license (as I believe Microsoft's current licensing terms mandate) proving an infringement won't be that difficult. > They are also granted based on the potential harm to the patent > holder. Since all Microsoft is asking for > a license is registration, the damages that an injunction would prevent > probably are not significant enough to warant one. You are thinking about monetary damages. The purpose of getting this injunction is not to win some cash. If Sender-ID becomes widespread, and becomes a necessary component of a secure, well-executed E-mail infrastructure, there will be a clear benefit to legally barring F/OSS from competing with Microsoft's commercial offerings. >> Since, as you've acknowledged, the F/OSS developer is not likely to >> have the financial resources for a protracted fight, and challenging >> the patent, Microsoft's legal expenses will be rather minimal. >> >> Do you think that there would be any value for Microsoft in blocking a >> competing F/OSS implementation of Sender-ID? > > > M$ can not afford a fight either. They may have plenty of money, but > they are significantly short on good will. The DOJ may have wimped out > for the moment, but they are still watching things. Ashcroft is not > a Freind of Bill, the Democrats if elected are even less so. The EU is > still proceeding, and world markets are enormously Microsoft unfriendly. http://www.linspire.com/lindows_michaelsminutes_archives.php?id=131 The real figure may not be $200 million; but I don't think that's the major point. I don't see the DOJ, or the EU, doing anything about it. > M$ will benefit enormously by playing a key role in this standard. Yes. Locking out F/OSS carries quite a bit of benefit. > Everyone will suffer if they do not. I don't think so. With a little work even today you can achieve an acceptable junk mail filtering ratio. The world will not come to an end if Sender-ID does not get promoted. > Conversly, they will suffer if they are perceived as an impediment > to the solution to this problem. M$ has an enormous PR problem. I can > not think of a major company that is perceived of so poorly. Completely irrelevant. Microsoft's reputation was not a factor in reaching my decision. > Linux corporate sponsors. F/OSS has gottent large enough and > cohesive enough to fend for itself. Right, and that's why we don't need to hop aboard a patent-encumbered train. > While there might be some F/OSS > legal resources available, the research resources would be enormous. > Again witness the SCO vs. IBM dispute. Research is the bane of any > IP claim. Prior art is somewhat difficult and often expensive for a > small business to prove, But the F/OSS community can probably provide > Published prior art > for just about any software concept. Probably true, but why should I even want to deal with this, when it is much easier to avoid the whole mess in the first place? > If you wish to attribute evil intentions to Microsoft here, the only > scenario I see where they win is one where they get to claim to have > contributed to a standard, while F/OSS developers self regulate and > refuse to I assure you that I haven't spent even a single second musing whether Microsoft's intentions are "evil", or not. It is certainly in their best interests to stamp out competition; this is true of any business. Here, their competition is F/OSS, as they clearly spell out in their 10Q: http://news.com.com/2100-7344_3-5347325.html This is purely business sense, not some metaphysical manifestation of "evil". > impliment it because of Microsoft's License. IP rights and patent > law are just tools. The real battleground is one of perception. Earlier you've claimed that their rep is poor. Looking at their balance sheet, I doubt that their perception has any impact on the bottom line. > Microsoft is not below sabotaging F/OSS, but is unlikely to want a > direct public confrontation. > Microsoft is pretty bad at PR, but they are pretty good at finding > the weaknesses of their competition and trying to exploit them. Right, and the IP situation in the US is an acknowledged weakness for F/OSS. > > F/OSS developers and distributors are not going to support a > standard that requires sending a signed license to Microsoft. Getting > that scenario is a WIN for Microsoft. Microsoft gets to claim a > standards compliant solution and all the F/OSS players leave the feild > to commercial developers. That's OK. There's not a lot of Netcraft-style breakdown for E-mail server software; but from the data that I've seen commercial E-mail server software's share is not that great. Microsoft's dominance in E-mail client field is not going to help in the context of Sender-ID, which requires server support. > If some F/OSS developer does move forward > without licensing Sender-ID from Microsoft, M$ starts a PR campaign > about the lack of respect F/OSS has for IP and how they are all just a > bunch of untrustworthy hackers anyway. I am confident that this scenario will not happen, no matter what the IETF decides. Surveying the list archive, I see no evidence suggesting that any F/OSS developer has such plans. > The losing scenario for Microsoft is the perception that M$ > splintered MARID. Leaving us all with either weaker or not broadly > implimented solutions to this problem. I do not agree. > Regardless, our responsibility has little to do with Microsoft. It > is to get the best standard with the broadest possible implimentation. This really depends on what definition of "best standard" one chooses. There is no standard definition for that. My definition pretty much excludes patent-encumbered technologies (with few exceptions). > If we reject Sender-ID we may loose Microsoft which would be bad. If we > do not > we lose F/OSS which would be worse. I'm not sure what "lose F/OSS" means. Certainly F/OSS will not go along with Sender-ID; this, I think, does not need to be debated any further. It's a foregone conclusion. F/OSS will simply use an alternative. It looks like the consensus is that F/OSS will proceed with SPF classic. Do you know what that means? It means that most organizations will choose to publish only SPF records. Some may choose to also publish Sender-ID records; I don't think that there's going to be anyone who'll publish only Sender-ID records. This is because publishing SPF records is the only way to guarantee the most widespread coverage. Everyone will support checking SPF records, and if you want to use MARID to prevent your mail domain from being forged, you want as much coverage as you can possibly get. --=_mimegpg-commodore.email-scan.com-17893-1094252724-0006 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBOPi0x9p3GYHlUOIRAorLAJ41yLmdA+oMUzdJojcSXnc7gBh69gCfV8jI u56nP6aCnDpyvlGlnEHfyfw= =Puct -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-17893-1094252724-0006-- From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:28:59 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 TAA24004 for ; Fri, 3 Sep 2004 19:28: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 i83NAJuU070224; Fri, 3 Sep 2004 16:10:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83NAJRF070223; Fri, 3 Sep 2004 16:10:19 -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 i83NAI1S070196 for ; Fri, 3 Sep 2004 16:10:18 -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.8/8.12.8) with ESMTP id i83NAF1W027069 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 19:10:18 -0400 Message-Id: <6.1.2.0.2.20040903190612.07955ec0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 03 Sep 2004 19:09:39 -0400 To: "Craig Taylor" , From: Daniel Senie Subject: Re: X-header for forwarding MTAs In-Reply-To: <65D2600546E11444960D957CFF5B644FC0D011@anakin.ironportsyst ems.com> References: <65D2600546E11444960D957CFF5B644FC0D011@anakin.ironportsystems.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_433204575==.ALT" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=====================_433204575==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:05 PM 9/3/2004, Craig Taylor wrote: >Both Yakov , Thomas and others have made calls to focus on technical >issues, so here's a strictly technical issue. > >One of the weakness of SenderID is its exclusive focus on the last >hop. If I receive my email via an alumni forwarding MTA, the alumni MTA >might or might not run the SenderID check but regardless the MTA probably >still accepts and passes the message through because it is a >forwarder. When the message arrives at my MTA I can run the SenderID >check but again I'll accept the message because it is coming from my >alumni forwarder. What I'd like to know is if the connection to my >forwarder failed the SenderID test. > >Having as part of the standard some sort of x-header that well-behaving >forwarders used would allow me to look beyond the last hop. First, if it's important enough to implement in a uniform way around the world, then it should not be an X-something. Second, this implies all those servers that haven't been touched, need to be touched. While adding in a new header might be less work than implementing Sender ID (if a site is even willing to consider implementing Sender ID), this means a lot of things will still break. Seems like a non-starter to me. > For example, "x-senderid-result receiver=forwarder.com > connecting-ip=x.x.x.x pra-result=fail". While such a record can be > forged there is no reason to forge failures (what would be the point). There may be a point to forging a failure if this results in significant headaches in the form of a denial of service. >Knowing that somewhere in the chain authentication has broken down would >allow me to take further action based on failed authentication. In >addition, the same header could potentially be used to communicate between >the MTA and the MUA but that is another discussion probably best left to asrg. >Craig Taylor >VP, Technology >Ironport System --=====================_433204575==.ALT Content-Type: text/html; charset="us-ascii" At 04:05 PM 9/3/2004, Craig Taylor wrote:

Both Yakov , Thomas and others have made calls to focus on technical issues, so here's a strictly technical issue.

One of the weakness of SenderID is its exclusive focus on the last hop.  If I receive my email via an alumni forwarding MTA, the alumni MTA might or might not run the SenderID check but regardless the MTA probably still accepts and passes the message through because it is a forwarder.  When the message arrives at my MTA I can run the SenderID check but again I'll accept the message because it is coming from my alumni forwarder.  What I'd like to know is if the connection to my forwarder failed the SenderID test.

Having as part of the standard some sort of x-header that well-behaving forwarders used would allow me to look beyond the last hop.

First, if it's important enough to implement in a uniform way around the world, then it should not be an X-something.

Second, this implies all those servers that haven't been touched, need to be touched. While adding in a new header might be less work than implementing Sender ID (if a site is even willing to consider implementing Sender ID), this means a lot of things will still break.

Seems like a non-starter to me.

  For example, "x-senderid-result receiver=forwarder.com connecting-ip=x.x.x.x pra-result=fail".  While such a record can be forged there is no reason to forge failures (what would be the point).

There may be a point to forging a failure if this results in significant headaches in the form of a denial of service.

Knowing that somewhere in the chain authentication has broken down would allow me to take further action based on failed authentication.  In addition, the same header could potentially be used to communicate between the MTA and the MUA but that is another discussion probably best left to asrg.
Craig Taylor
VP, Technology
Ironport System
--=====================_433204575==.ALT-- From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:32:44 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 TAA24219 for ; Fri, 3 Sep 2004 19:32:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NCRnN070803; Fri, 3 Sep 2004 16:12:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83NCRAm070802; Fri, 3 Sep 2004 16:12:27 -0700 (PDT) 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 i83NCQdm070795 for ; Fri, 3 Sep 2004 16:12:26 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Fri, 03 Sep 2004 19:12:31 -0400 id 0000000000157937.000000004138FA5F.0000657A X-IMAP-Sender: mrsam@courier-mta.com References: Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: IETF MARID WG X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardization of SPF Classic Date: Fri, 03 Sep 2004 19:12:30 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-17893-1094253150-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-17893-1094253150-0008 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Rand Wacker writes: > fine, that's the choice of the group. No-one here should be under the > impression that scuttling Sender ID at this time will give SPF Classic any > fast track through the standards process. That's fine. You might want to study the evolution of NNTP. There, lack of the official IETF stamp of approval did not inhibit NNTP from evolving. If you try to implement NNTP based only on IETF's standards-track documentation, you won't get very far. This may have changed recently, but this has been the case for a long time. --=_mimegpg-commodore.email-scan.com-17893-1094253150-0008 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBOPpex9p3GYHlUOIRAtnUAJwIyrYOFklLU5f9qmVi4Z6DR6o/NgCfUlsN P/QwSoh/87b3xU5baoG6rPk= =cqRY -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-17893-1094253150-0008-- From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:34: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 TAA24305 for ; Fri, 3 Sep 2004 19:34: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 i83NEQmN071100; Fri, 3 Sep 2004 16:14:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83NEQOi071099; Fri, 3 Sep 2004 16:14:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NEPIe071093 for ; Fri, 3 Sep 2004 16:14:25 -0700 (PDT) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id E578EBC19E; Fri, 3 Sep 2004 19:14:29 -0400 (EDT) Subject: Re: consensus call on MUST/SHOULD language for TXT records In-Reply-To: <94df60cf04090315281062428e@mail.gmail.com> "from mazieres@gmail.com at Sep 3, 2004 06:28:57 pm" To: IETF MARID WG Date: Fri, 3 Sep 2004 19:14:29 -0400 (EDT) Reply-To: ietf-mxcomp@imc.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20040903231429.E578EBC19E@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit mazieres@gmail.com: > > On Fri, 3 Sep 2004 17:33:48 -0400, Andrew Newton wrote: > > > > Despite lack of agreement on the outcome, there is agreement on the > > stated positions. In the words of Olafur: > > 1) Specify everyone to be compliant at all times. > > 2) Specify clearly full complaint state and tolerate non-compliant > > state during phase-in. > > I would favor position 2. I think the recommended document should > describe where we want to be in the long run, whether or not we can > get there quickly. While I strongly suspect Sender ID will undergo > future revisions anyway, why intentionally adopt a standard that will > have to be superseded? I second this. The document should bless the usage of TXT records during the initial deployment phase. It does not need to define the time schedule for the txt -> spf transition. Wietse From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:34: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 TAA24334 for ; Fri, 3 Sep 2004 19:34:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NEBMh071061; Fri, 3 Sep 2004 16:14: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 i83NEBda071060; Fri, 3 Sep 2004 16:14:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NEAU4071044 for ; Fri, 3 Sep 2004 16:14:11 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i83NEAWx010088 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 16:14:10 -0700 Date: Fri, 3 Sep 2004 16:14:09 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call of RR prefix In-Reply-To: Message-ID: References: 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, 3 Sep 2004, Andrew Newton wrote: > Therefore, that leaves one under-discussed question: should a prefix be > used to avoid collision with other records as one measure of preventing > the requirement of DNS over TCP? The include workaround proposed to the list seem to work for the major cases I outlined, and leaving the TXT records in the domain.tld dataspace, while ugly, seems like a good bit of parallelism for the SPF records that will be published in the same place. I would suggest that the document be ammended to remind people that *all* TXT records published for domain.tld should fit in 480 bytes (mentioning spfv1 and spfv2), and perhaps also suggest the include workaround for sites that will need to publish really large records. -Rand From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:48: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 TAA24876 for ; Fri, 3 Sep 2004 19:48: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 i83NPTMK072106; Fri, 3 Sep 2004 16:25:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83NPTW2072105; Fri, 3 Sep 2004 16:25:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NPScW072099 for ; Fri, 3 Sep 2004 16:25:29 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3NPI-0005v7-1J; Fri, 03 Sep 2004 19:23:48 -0400 Message-ID: <4138FD68.2050408@solidmatrix.com> Date: Fri, 03 Sep 2004 19:25:28 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "william(at)elan.net" CC: Andrew Newton , IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit william(at)elan.net wrote: > On Fri, 3 Sep 2004, Andrew Newton wrote: > > >>The debate over the MUST/SHOULD/MAY language with regard to compliance >>and publication of TXT and SPF2 record types does not seem to be >>getting the attention of the full working group. >> >>Despite lack of agreement on the outcome, there is agreement on the >>stated positions. In the words of Olafur: >>1) Specify everyone to be compliant at all times. >>2) Specify clearly full complaint state and tolerate non-compliant >>state during phase-in. >> >>Position 1 is predicated on the notion that a future RFC will deprecate >>the (use of the) TXT record in favor of the SPF2 record. Position 2 >>demands that the TXT record be discouraged from use in the current >>-protocol document. >> >>Rather than wordsmithing the actual MUST/SHOULD/MAY language directly >>(and endlessly), we ask the participants state their preference on >>these positions. > > > I take middle position: > > 1.5) Specify everyone to be compliant at all times and tolerate > non-compliance as a matter of fact (current reality) for a given > period of time (next 4 years say). > "be conservative in what you do, be liberal in what you accept from others" (John Postel, RFC 793) Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 19:48: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 TAA24889 for ; Fri, 3 Sep 2004 19:48:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NSBEU072271; Fri, 3 Sep 2004 16:28: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 i83NSBfn072270; Fri, 3 Sep 2004 16:28: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 i83NSBIP072264 for ; Fri, 3 Sep 2004 16:28:11 -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 1A487414C8; Fri, 3 Sep 2004 16:28:17 -0700 (PDT) Subject: Re: (DEPLOY) In Support of Sender ID From: Douglas Otis To: Yakov Shafranovich Cc: Rand Wacker , Matt Sergeant , Ryan Malayter , "Michael R. Brumm" , IETF MARID WG In-Reply-To: <4138CA8C.5070004@solidmatrix.com> References: <4042BB90-FD92-11D8-B236-000A95AC67AA@messagelabs.com> <4138CA8C.5070004@solidmatrix.com> Content-Type: text/plain Message-Id: <1094254095.20922.72.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 16:28:15 -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-09-03 at 12:48, Yakov Shafranovich wrote: > Rand Wacker wrote: > > On Fri, 3 Sep 2004, Matt Sergeant wrote: > >> On 2 Sep 2004, at 23:06, Rand Wacker wrote: > >> > >>> As I said before, there is a large majority of mail that goes from > >>> large commercial sites (or consumer ISPs) merely one hop to another > >>> large commercial ISP, so the From: header will be successfully > >>> authenticated. > >> > >> You're talking about the positive evaluation proposition of Sender-ID - > >> that the From address is authenticated. Yet both Cyphertrust and > >> SpamAssassin's stats show that the spammers are more on top of this > >> than the legit mailers. > > > > > > *NO*. I am talking about using authentication status as the basis for a > > new set of checks such as whitelisting. I have been saying since the > > beginning that spammers would authenticate their outbound mail in hipes > > that someone would make the brain-dead assumption that "authenticated" == > > "wanted". > > It can also serve as a basis for reputation and accreditation systems. For an identification to useful for reputation assessment, there needs to be certainty this identity has not been spoofed. This is not achievable with Sender-ID. There are many scenarios where Sender-ID can be spoofed, as the mail channel is not secure. It is possible to establish an authenticated name for the MTA however, and then assert a mailbox domain relationship with MTA names. The MTA name, as the stronger identification, and not the mailbox domain, could be used for reputation assessment. The use of the mailbox/MTA relationship would be helpful in lowering odds of being tagged by a filter. This type of arrangement overcomes the high DNS overhead problem plaguing Sender-ID. This arrangement is no worse than endemic use of Resent-From headers for administrators to understand, and it has far less overhead to implement than Sender-ID. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 20:01: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 UAA25365 for ; Fri, 3 Sep 2004 20:01:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NgTxS073372; Fri, 3 Sep 2004 16:42:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83NgThE073371; Fri, 3 Sep 2004 16:42:29 -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 i83NgSoP073365 for ; Fri, 3 Sep 2004 16:42: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.8/8.12.8) with ESMTP id i83NgS1U029325 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 19:42:29 -0400 Message-Id: <6.1.2.0.2.20040903193938.07594c30@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 03 Sep 2004 19:41:17 -0400 To: "william(at)elan.net" , Andrew Newton From: Daniel Senie Subject: Re: consensus call on MUST/SHOULD language for TXT records Cc: IETF MARID WG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 06:59 PM 9/3/2004, william(at)elan.net wrote: >On Fri, 3 Sep 2004, Andrew Newton wrote: > > > The debate over the MUST/SHOULD/MAY language with regard to compliance > > and publication of TXT and SPF2 record types does not seem to be > > getting the attention of the full working group. > > > > Despite lack of agreement on the outcome, there is agreement on the > > stated positions. In the words of Olafur: > > 1) Specify everyone to be compliant at all times. > > 2) Specify clearly full complaint state and tolerate non-compliant > > state during phase-in. > > > > Position 1 is predicated on the notion that a future RFC will deprecate > > the (use of the) TXT record in favor of the SPF2 record. Position 2 > > demands that the TXT record be discouraged from use in the current > > -protocol document. > > > > Rather than wordsmithing the actual MUST/SHOULD/MAY language directly > > (and endlessly), we ask the participants state their preference on > > these positions. > >I take middle position: > > 1.5) Specify everyone to be compliant at all times and tolerate > non-compliance as a matter of fact (current reality) for a given > period of time (next 4 years say). Please be sure ALL such timeout dates are listed in drafts as a period of time from when the draft is published as an RFC. Dates should NEVER be set in a draft as pointing to a specific date on the calendar, nor from the date a draft appears in the drafts repository. We've run into issues before where "deadlines" were set and then acted upon before drafts were approved. Please let's not ever do that again. From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 20:02: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 UAA25406 for ; Fri, 3 Sep 2004 20:02:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NXi0n072620; Fri, 3 Sep 2004 16:33: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 i83NXiwV072619; Fri, 3 Sep 2004 16:33:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NXid4072609 for ; Fri, 3 Sep 2004 16:33:44 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i83NXi3V018091 for ; Fri, 3 Sep 2004 16:33:44 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 4593484F865; Fri, 3 Sep 2004 16:33:44 -0700 (PDT) Date: Fri, 3 Sep 2004 16:33:44 -0700 From: "Mark C. Langston" To: IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records Message-ID: <20040903233344.GA99172@bitshift.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 4:30PM up 1 day, 22:27, 6 users, load averages: 0.16, 0.09, 0.02 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 05:33:48PM -0400, Andrew Newton wrote: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant > state during phase-in. > I'm more comfortable with option 2, as it provides time for transition and experimentation. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 20:02: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 UAA25424 for ; Fri, 3 Sep 2004 20:02: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 i83Ngkll073390; Fri, 3 Sep 2004 16:42: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 i83NgkuI073389; Fri, 3 Sep 2004 16:42:46 -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 i83NgjKe073380 for ; Fri, 3 Sep 2004 16:42:45 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i83NgkfG002833; Fri, 3 Sep 2004 16:42:46 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Sep 2004 16:42:46 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Anne P. Mitchell, Esq.'" , IETF MARID WG Subject: RE: DEPLOY: Sender-ID provides little or no defence against adapt ive threats Date: Fri, 3 Sep 2004 16:42:41 -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: Even if we end up with spammers using disposable domains it will mean a major switching cost for every message variant. In effect the use of hash busters will be completely negated. Saying that Sender ID will not work because of the throaway domain problem is like saying that it is pointless putting locks on your doors because a burglar can break a window. In the real world breaking windows creates noise and leads to burglars being caught. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Anne P. Mitchell, > Esq. > Sent: Friday, September 03, 2004 4:55 PM > To: IETF MARID WG > Subject: RE: DEPLOY: Sender-ID provides little or no defence against > adaptive threats > > > > > > Anne P. Mitchell wrote: > > >cf. CipherTrust's study released this week in which >50% of the > > sources > > >for all email surveyed which published SPF records were spammers. > > > > > >http://www.infoworld.com/article/04/08/31/HNspammerstudy_1.html > > > > Just so there is no confusion... this is good news for SPF, not bad > > news. > > > > Absolutely, completely agreed! I should have elaborated. As I have > said in various public posts (elsewhere), if spammers want to tie > themselves to their sites by authentication, that's a *good* > thing. My > points are that a) spammers will adopt whatever is out there, and in > this instance b) spammers are stupid - by adopting what they > *think* is > an anti-spam protocol to help get their spam through, they > are actually > raising their hands and saying "here I am!" > > Anne > From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 20:17: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 UAA25897 for ; Fri, 3 Sep 2004 20:17:45 -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 i83NpwPL073959; Fri, 3 Sep 2004 16:51: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 i83NpwDP073958; Fri, 3 Sep 2004 16:51:58 -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 i83NpvFY073952 for ; Fri, 3 Sep 2004 16:51:57 -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 i8401je0017094 for ; Fri, 3 Sep 2004 17:01:45 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8401j47017091 for ; Fri, 3 Sep 2004 17:01:45 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 3 Sep 2004 17:01:45 -0700 (PDT) From: "william(at)elan.net" To: "IETF MXCOMP (E-mail)" Subject: Issues raised in comments by Steve Belovin from January 2004 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: > Steve Bellovin is security area advisor at IETF and part of IESG. While > we're at it please look through his message and compare if we solved other > issues mentioned there too. Actually, I'm just going to reforward his message (its important as we're on last call) and go through the issues mentioned. Again original is at http://www.interesting-people.org/archives/interesting-people/200401/msg00037.html My comments are listed in (--- ... ---). ------------------------------------------------------------------------ Delivered-To: dfarber+@ux13.sp.cs.cmu.edu Date: Sun, 04 Jan 2004 18:23:55 -0500 From: "Steven M. Bellovin" Subject: Re: [IP] MTA packagers please consider SPF To: dave@farber.net >From: mengwong@dumbo.pobox.com (Meng Weng Wong) >Subject: MTA packagers please consider SPF >To: chip@perlsupport.com >Cc: dave@farber.net > >SUMMARY > > This message goes to some of the maintainers of MTA packages for major > Linux distributions. I ask that they consider adding SPF support to > their packages in helping to solve spam. I founded pobox.com, which > produced the MySQL extensions for Postfix. I authored the SPF > standard and am now trying to get it widely adopted. Dave, I hope that people don't jump too rapidly on the SPF "standard". From my persepctive, it's very far from ready for prime time. (Note that although I'm a member of the IESG, I'm speaking as an individual. I'm not even saying how I'd vote if this document were to come before the IESG today -- IESG evaluations are a deliberative process, and I could very easily be talked out of some or all of my points.) There are several major problems with the document as written, including its semantic model, the uptake model, and the "specsmanship". The latter is easiest to fix, but it will render current implementations useless if the eventual spec is different. Running code is a great way to test a concept; too much deployment of bad running code is a tremendous obstacle to a decent standard. I'm not even talking of the perfect being the enemy of the good. To make it easier to read, I've indented the major sections of this note: Specsmanship: The version number definition is problematic -- it only has major version numbers. I suspect that we need minor version numbers as well, for operational debugging. (---- This is solved with new protocol SPF2 records that have minor version. I'm not certain how important this is though... (it could be introduced to spf1 as neutral "comment" modifier to be ignored) ----) The most glaring problem with SPF is the use of TXT records. TXT records are supposed to be free-form text, with no semantics attached. The use of TXT for test purposes is understandable (though regrettable -- an experimental record type code would be better); the use of TXT records for textual error messages is not. The document itself notes the problem of ordering of multi-record messages. (---- Current drafts do not allow for "multi-record messages". I note that I'm personally for allowing it but we will need modifier specifying ordering then and it may get more complicated. ----) Beyond that, there are problems with internationalization: what language should the error message be in, and in what character set is it encoded? A simple URI would be a better solution; at the least, it should point to an SPFERR record. (---- I remember discussions about this at spf-discuss. I don't remember if there was any resolution... ----) (Record subtyping in the DNS causes problems; see RFC 3445 for some details on why.) The use of TXT-like records is problematic because it requires parsing an ASCII string in a DNS resolver. (Yes, I know that NAPTR records require the same sort of parse. I don't much like that, either.) The more complex the parse, the harder it is to get right, both for the author and the receiver of such records. (---- As Yakov pointed out this should be listed as an issue in security section. ----) A TLV-based structure permits parsing by the author's DNS server, and is easier to interpret on the receiving end. The Received-SPF header line is badly specified. It doesn't follow the the standards for other RFC 822/2822 headers (i.e., it requires exactly one space in certain places where an arbitrary amount of white space (including none) is permitted in other headers); it has some things as comments (receiving host) that should be parseable; and it doesn't mandate that Received-SPF lines from outside of the domain MUST be deleted. (The actual requirements here are more complex; I won't go into details in this note.) Yes, the line as specified is a bit easier to parse, but any spam filter is going to have to deal with many other headers, and hence will have to have a full-fledged 822/2822 parser. (---- Open issue. We need new draft on reporting results of spf verification in either special new header or as part of received header. ----) Too many cases can result in an "unknown" return value. That makes debugging hard. There needs to be a "none" value, for cases where there is no SPF record; there needs to be a type code for "unknown", to distinguish among the many error cases. Beyond that, the set of type codes needs to be enumerated -- as is, we'll see an operational nightmare. (---- I think this is now listed on page 16 of protocol draft. Mark, do you want to comment if this is now resolved? ----) Section 5 speaks of using Received: lines. Such lines have been forged by spammers for many years. While they can be used, great care must be taken. This document needs to define the necessary steps appropriately. (---- Open issue as has been seen in latest MUA related discussions. I'm in favor of specifying that they should not be used beyond the very top (last added one) in the email message. ----) 5.1 speaks of cidr-lengths, but 5.2 et seq. speak of dual-cidr-length. That looks like something where the editing hasn't caught up yet. But having a CIDR length on an MX record is a bad idea, since there may be multiple MX records with different appropriate lengths. The macro language scares me -- it's very complex. Note that DNS records are limited to 512 bytes unless EDNS0 is used; EDNS0 is not widely used today, and may incur other costs. But the real problem is that the functionality permitted may be far too rich -- arbitrary semantics are not a good idea, since they can lead to random breakage when some site implements a test that another site isn't prepared to meet. In Postel's language, a sender can't be conservative in what it emits if it doesn't know what the requirements are. (---- I'm not certain if these are resolved or not. Mark may want to comment on cidr-lenghts and macro. ----) 8.4 ruins much of the effectiveness of the scheme -- it provides ways to avoid processing. For example, a spam engine could send email with a local-seeming HELO, MAIL FROM, and From: entries, in which case (per Example 3) SPF isn't to be used. Spam from abuse@ or postmaster@ can also bypass checks. (---- I think this issue does not come up with SenderID/PRA drafts... Somebody please do comment if it still exist with Classic-SPF. ----) The suggestion that this scheme become default in April, 2004 (Section 9.4) is preposterous. Even if the IESG were to approve this document today -- and very few documents are passed on first try -- it would take far longer than four months to build, test, and deploy production-grade clients and servers. (---- The "April 2004" date is no longer of consequence... ----) The security considerations section mentions IP address spoofing, though the FAQ claims that they aren't real. I agree that classical spoofing, per Morris' 1984 memo, is probably not a major threat here. But spammers are using BGP to steal entire address blocks -- that's a bigger threat. (The FAQ also points to RFC 2761 when it should be 2671.) (---- As suggested by Jim Fenton, IP hijacking is now listed as a threat in the appropriate section of core draft. ----) Uptake Model: As Rick Adams has pointed out, there is no consensus yet that this is the right way to go. The major ISPs on the net -- AOL, Yahoo, MSN, etc. -- have not bought into this scheme. Unless and until they do, it doesn't help much, either for their customers (who make up a substantial proportion of the user population) or for everyone else (since their addresses could be forged). (---- AOL now published SPF records and commented on this list regarding SenderID and I suspect MSN supports this too as its part of Microsoft. ----) Semantic Model: In a strong sense, the part that requires the most debate is the semantic model. SPF strongly binds a sender to some DNS records. But that isn't always a good idea. People who use portable email addresses will now be constrained to use the domain owner's SMTP sender, which may not even exist. (A more interesting model would permit delegation of individual user names to particular sending machines. But that would probably require too much public key cryptography to be affordable.) (---- I believe how individual users can be permitted to do have separate email signatures is part of Jim Fenton's Identified Mail proposal. Similarly this is also supported by my MTA Signatures proposal as individual public keys could be used by users that could be signed by entity's main public key. Both of these proposals are to be discussed as part of http://www.imc.org/ietf-mailsig/index.html SPF protocol by means of macros also allows to have individual user dns records but it might not be very popular way to do it. ----) The net effect will be to bind users more strongly to their ISPs and/or their employers. While big ISPs may like that, it flies in the face of current (American) public policy -- witness local telephone number portability. Ironically, it will also discourage a current anti-spam strategy used by many: throw-away email addresses for particular purposes. It will also make life harder for people who regularly use multiple sending email addresses. For reasons of privacy, my children generally use email address that are not readily tied to their real names. But for certain very important kinds of communication -- sending email to teachers, for example -- they use a family-linked email address. It isn't always clear to people what SMTP server they're actually using. Over the last few years, I've noticed that one major hotel chain intercepts outbound SMTP connections. I don't know if they're trying to defend against check-in spammers or if they're trying to help travelers whose laptops are hard-wired to point to their company's or home ISP's SMTP servers. Granted, people should use VPNs or SMTP/SASL for such things; too may don't and perhaps can't -- if your ISP doesn't support it, for example, you can't use it, and switching ISPs carries a non-trivial cost, especially if you have only one choice of broadband ISP. I've underscored some of my points here by using a portable email address of my own, rather than my usual email address. (---- I think all these issues have been raised before and people decided that certain limitations are worth it for better email security. Possibly draft needs to talk about this more... ----) Conclusion: The basic concept may or may not be a good idea. The authors themselves admit that it's only part of a total anti-spam solution, and I'm not convinced that it's worth the deployment effort. Its strongest in dealing with "joe jobs" -- spammers (and worms) impersonating real email addresses -- but that's the part that most runs afoul of my semantic concerns. -------------------------------------------------------------------- --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 20:23: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 UAA26090 for ; Fri, 3 Sep 2004 20:23:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NxNJT074465; Fri, 3 Sep 2004 16:59:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83NxN8C074464; Fri, 3 Sep 2004 16:59:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NxNVI074456 for ; Fri, 3 Sep 2004 16:59:23 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [10.0.0.120] ([10.0.0.120]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Fri, 3 Sep 2004 16:59:26 -0700 Subject: Re: consensus call of RR prefix From: Max Kanat-Alexander To: Andrew Newton Cc: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094255966.5841.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 03 Sep 2004 16:59:26 -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-09-03 at 14:32, Andrew Newton wrote: > From the discussion on prefixes for the DNS record, there seems to have > been no discernible outcome regarding the use of prefixes for the > purposes of avoiding collisions with other DNS records (thus avoiding > fallback to DNS over TCP). I suspect that I missed some of the comments on this possibly earlier, as I only recently was able to get to this list. (I thought that perhaps my developers were on it, but it turns out that they aren't, I think.) Anyhow, here's my thoughts: Any requirement (or even expectation) of DNS over TCP will probably kill widespread adoption of Sender ID, as DNS over TCP does not work over a large number of networks. Either it's blocked at a firewall, or it's disabled on the DNS server. If we use a record in domain.tld, we have a higher chance of collision with some other record than if we use _senders (or some other prefix). Granted, wildcards are a problem, but they're not really significant, because obviously the admins who enable wildcards expect spurious DNS hits and are willing to accept that strange things might happen. Also, whether I get a collision (or too large of a DNS reply) from querying *.domain.tld, or domain.tld, it makes no difference to me. The only thing about using a prefix is that I get to choose to avoid that collision. I don't think it's a huge issue -- what are sysadmins currently using TXT records in domain.tld for, and how many of them also have wildcards enabled? I don't know of an extensive number of uses of those things combined. Personally, as a sysadmin, potential implementor, and the fellow who will have to deal with any angry customers, I'd probably prefer having a prefix, as I suspect that it will clear up more problems that it will create. -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 20:44:40 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 UAA26954 for ; Fri, 3 Sep 2004 20:44: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 i840C8ET075580; Fri, 3 Sep 2004 17:12: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 i840C8qv075579; Fri, 3 Sep 2004 17:12:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i840C8As075568 for ; Fri, 3 Sep 2004 17:12:08 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so67963rnk for ; Fri, 03 Sep 2004 17:12:08 -0700 (PDT) Received: by 10.38.75.73 with SMTP id x73mr290504rna; Fri, 03 Sep 2004 17:12:08 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Fri, 3 Sep 2004 17:12:08 -0700 (PDT) Message-ID: <94df60cf0409031712473b6a2e@mail.gmail.com> Date: Fri, 3 Sep 2004 20:12:08 -0400 From: Reply-To: To: Andrew Newton Subject: Re: consensus call of RR prefix Cc: IETF MARID WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 3 Sep 2004 17:32:22 -0400, Andrew Newton wrote: > > Therefore, that leaves one under-discussed question: should a prefix be > used to avoid collision with other records as one measure of preventing > the requirement of DNS over TCP? My understanding from discussing uses of the PRA is that the PRA doesn't need to be a functioning mailbox, and that its domain doesn't even need to have an MX or A record. So can't people just use a prefix anyway? Sites concerned about conflicts with other large TXT records can still use a prefix. They just need to add a header field like: Resent-Sender: sender@_rmx.mydomain.tld Presumably most Sender-ID compliant MTAs will have facilities for automatically adding such headers anyway. Thus, I support not mandating any prefix. David From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 20:51: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 UAA25364 for ; Fri, 3 Sep 2004 20:01:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Ndfni073176; Fri, 3 Sep 2004 16:39: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 i83NdfZc073175; Fri, 3 Sep 2004 16:39:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83NdfW4073168 for ; Fri, 3 Sep 2004 16:39:41 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [10.0.0.120] ([10.0.0.120]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Fri, 3 Sep 2004 16:39:43 -0700 Subject: Re: consensus call on MUST/SHOULD language for TXT records From: Max Kanat-Alexander To: Daniel Quinlan Cc: Andrew Newton , IETF MARID WG In-Reply-To: References: Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094254783.5841.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 03 Sep 2004 16:39:43 -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-09-03 at 15:21, Daniel Quinlan wrote: > I think Position 3 needs to be mentioned: > > 3) Remove SPF2 record and specify the use of TXT going forward. I agree. Barring that this solution (#3) is adopted, I believe that the specification should require full compliance from the start. There are (relatively) very few Sender ID implementations now, and there will be many in the future. Requiring compliance now means a hope for 99% interoperation, where as making compliance optional means a fight that we're putting in the future when we *do* desire compliance. "MUST" means something very significant to developers and managers, whereas making compliance optional means "Let's make it work in some hacked way, even in our brand-new implementation, because we're under time pressure to implement this feature that our customers want." -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 21:01:17 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 VAA27692 for ; Fri, 3 Sep 2004 21:01:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i840aMAd077535; Fri, 3 Sep 2004 17:36:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i840aMnM077534; Fri, 3 Sep 2004 17:36:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i840aMQ9077528 for ; Fri, 3 Sep 2004 17:36:22 -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; Fri, 03 Sep 2004 20:36:25 -0400 id 0016BD64.41390E09.00004AC6 In-Reply-To: <4138EDE8.3020802@solidmatrix.com> References: <4138EDE8.3020802@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71A9B6DF-FE0A-11D8-9A6B-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: consensus call on MUST/SHOULD language for TXT records Date: Fri, 3 Sep 2004 20:36:21 -0400 To: Yakov Shafranovich 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 Sep 3, 2004, at 6:19 PM, Yakov Shafranovich wrote: > I am not sure how #1 differs from #2? Are you suggesting that if we > adopt position #1, someone not having SPF RR records would be ignored? My interpretation of the thread is "might be ignored". -andy From owner-ietf-mxcomp@mail.imc.org Fri Sep 3 22:55: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 WAA03785 for ; Fri, 3 Sep 2004 22:55: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 i842PU4h085549; Fri, 3 Sep 2004 19:25: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 i842PUZS085548; Fri, 3 Sep 2004 19:25:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i842PTZ9085539 for ; Fri, 3 Sep 2004 19:25:29 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 68182 invoked from network); 4 Sep 2004 02:25:33 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 4 Sep 2004 02:25:33 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "Daniel Senie" , "Meng Weng Wong" , Subject: RE: (DEPLOY) In Support of Sender ID Date: Fri, 3 Sep 2004 22:25:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <6.1.2.0.2.20040903105731.07089d78@mail.amaranth.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Daniel Senie > Sent: Friday, September 03, 2004 11:02 AM > To: Meng Weng Wong; ietf-mxcomp@imc.org > Subject: Re: (DEPLOY) In Support of Sender ID > At 02:42 AM 9/3/2004, Meng Weng Wong wrote: > > >On Fri, Sep 03, 2004 at 06:25:21AM +0100, Graham Murray wrote: > >| > >| Rand Wacker writes: > >| > >| > As I said before, there is a large majority of mail that > goes from large > >| > commercial sites (or consumer ISPs) merely one hop to another large > >| > commercial ISP, so the From: header will be successfully > authenticated. > >| > >| In the case of sending from a large ISP (and that includes commercial > >| sites who outsource email) that is not true. Unless the ISP does > >| additional checking then Sender-ID (and SPF) still allows a customer > >| of the ISP to forge the mail as coming from any other customer of that > >| ISP. > > > >My read of most ISPs is that they are willing to move in > >this direction if it proves necessary. Many ISPs are > >beginning to roll out (mandatory) SMTP AUTH. With that in > >place, halting cross-customer forgery becomes a much more > >likely proposition. > > To be a little more accurate, SMTP AUTH does not prevent customers of an > ISP or hosting company spoofing one another, but it does provide an audit > trail, so the person doing the spoofing can easily be identified from log > entries. > > The real point (which I think Meng was trying to make) is that if we use > whatever this WG produces (assuming something useful is produced) a > mechanism that gets us back to the originating ISP, abuse at that > level can > and should be handled by that ISP. It may be beyond the scope of > this WG to > solve the internal abuse issues within an ISP. > Currently Sender-ID only gets us back to the ISP if the PRA is an address in the ISP's domain. In the case of a single hop, non-forwarded message from the ISP, if from: is a different domain than the ISP's, PRA will resolve to the from: domain and not the ISP: domain. While the from: domain could report any complaints to the ISP, by the time the matter was resolved, the from: domain might already be blacklisted (assuming domain name based blacklists again become popular). I think it would be much better to insist that in this case the ISP domain be the PRA by adding an appropriate 2822 header as I suggested earlier: http://www.imc.org/ietf-mxcomp/mail-archive/msg04034.html This gets us directly back to the originating ISP and also place the risk of blacklisting where it belongs. Since it would be the ISP's reputation that would be at stake, they would also be more likely to be motivated to limit cross-customer forgery in the first place. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 00:10:24 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 AAA07488 for ; Sat, 4 Sep 2004 00:10: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 i843jCFI093383; Fri, 3 Sep 2004 20:45: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 i843jCDS093382; Fri, 3 Sep 2004 20:45:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i843jBoE093374 for ; Fri, 3 Sep 2004 20:45:12 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i843sn5U019364; Fri, 3 Sep 2004 23:54:49 -0400 From: To: "'Andrew Newton'" , "'IETF MARID WG'" Subject: RE: consensus call on MUST/SHOULD language for TXT records Date: Fri, 3 Sep 2004 23:43:22 -0400 Message-ID: <000b01c49231$54562100$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I vote for position 1, future RFC should deprecate TXT record AFTER a SPF RR is approved and implemented in DNS servers. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Andrew Newton > Sent: Friday, September 03, 2004 5:34 PM > To: IETF MARID WG > Subject: consensus call on MUST/SHOULD language for TXT records > > > > The debate over the MUST/SHOULD/MAY language with regard to > compliance > and publication of TXT and SPF2 record types does not seem to be > getting the attention of the full working group. > > Despite lack of agreement on the outcome, there is agreement on the > stated positions. In the words of Olafur: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant > state during phase-in. > > Position 1 is predicated on the notion that a future RFC will > deprecate > the (use of the) TXT record in favor of the SPF2 record. Position 2 > demands that the TXT record be discouraged from use in the current > -protocol document. > > Rather than wordsmithing the actual MUST/SHOULD/MAY language directly > (and endlessly), we ask the participants state their preference on > these positions. > > -your co-chairs > From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 00:32: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 AAA08621 for ; Sat, 4 Sep 2004 00:32: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 i84487VW094705; Fri, 3 Sep 2004 21:08: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 i84487oe094704; Fri, 3 Sep 2004 21:08:07 -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 i84486O6094697 for ; Fri, 3 Sep 2004 21:08:06 -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 i8448DxR014964 for ; Fri, 3 Sep 2004 21:08:13 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Sep 2004 21:08:13 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MARID WG Subject: RE: DEPLOY: Rejection of Sender ID does not result in standardiza tion of SPF Classic Date: Fri, 3 Sep 2004 21:08:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Rand Wacker writes: > > > fine, that's the choice of the group. No-one here should > be under the > > impression that scuttling Sender ID at this time will give > SPF Classic any > > fast track through the standards process. > > That's fine. You might want to study the evolution of NNTP. > There, lack of > the official IETF stamp of approval did not inhibit NNTP from > evolving. If > you try to implement NNTP based only on IETF's standards-track > documentation, you won't get very far. Are you saying that NNTP is a good example of protocol design? Or a good example of creating a widely supported feature set? I don't think either really holds. NNTP was in any case established and the RFC published before the date of the first IETF meeting and long before there was a defined IETF process. NNTP chews up about four orders of bandwidth more bandwidth than it needs to. The protcol set is poorly standardized and the application has failed to meet the problems of spam, trolls and other social issues. There is a reason why NNTP has been replaced by the blogosphere. From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 00:44: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 AAA09232 for ; Sat, 4 Sep 2004 00:43: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 i844O688096456; Fri, 3 Sep 2004 21:24: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 i844O6wQ096455; Fri, 3 Sep 2004 21:24:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i844O5m3096448 for ; Fri, 3 Sep 2004 21:24:06 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 5242 invoked from network); 4 Sep 2004 04:24:12 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 4 Sep 2004 04:24:12 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "IETF MARID WG" Subject: RE: consensus call of RR prefix Date: Sat, 4 Sep 2004 00:24:12 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Andrew Newton > Sent: Friday, September 03, 2004 5:32 PM > To: IETF MARID WG > Subject: consensus call of RR prefix > > > > From the discussion on prefixes for the DNS record, there seems to have > been no discernible outcome regarding the use of prefixes for the > purposes of avoiding collisions with other DNS records (thus avoiding > fallback to DNS over TCP). > > Naturally, this issue wraps itself into both the versioning/scoping > issue and the wildcard issue. Based on the comments received so far, > it is the opinion of the co-chairs that there is no consensus on how to > handle wildcards and that most participants seem to agree that > wildcards present a problem no matter the solution. Based on the > comments received so far, it is the opinion of the co-chairs that there > is consensus on placing the "scope" in the RDATA of the record and no > consensus on the scope being in the prefix. > > Therefore, that leaves one under-discussed question: should a prefix be > used to avoid collision with other records as one measure of preventing > the requirement of DNS over TCP? > > Incidentally, the co-chairs note that many examples of the prefix have > used "-marid". We would note that "MARID" is the name of this working > group and likely not meaningful beyond the context of discussions and > process of this working group. Therefore we recommend a more > meaningful label such as "_rmx": the deduction of its meaning is easier > and it references the genesis of the MARID idea. > > -your co-chairs > One possibly small point with respect to deployment in this area... At least some (and I understand it to be many) DNS providers do not currently allow underscore characters. Even if other issues that might prevent my deployment of Sender-ID records are resolved, I would currently be unable to publish records if they are prefixed with an underscore due to such limitations. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 01:15:11 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 BAA10674 for ; Sat, 4 Sep 2004 01:15:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i844r684098645; Fri, 3 Sep 2004 21:53: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 i844r6JQ098644; Fri, 3 Sep 2004 21:53:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i844r5JI098627 for ; Fri, 3 Sep 2004 21:53:06 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i844r2MS011361 for ; Sat, 4 Sep 2004 05:53:02 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i844r2um011360; Sat, 4 Sep 2004 05:53:02 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: consensus call on MUST/SHOULD language for TXT records References: From: Graham Murray Date: Sat, 04 Sep 2004 05:53:02 +0100 In-Reply-To: (Andrew Newton's message of "Fri, 3 Sep 2004 17:33:48 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > Rather than wordsmithing the actual MUST/SHOULD/MAY language directly > (and endlessly), we ask the participants state their preference on > these positions. I think we should require full compliance from the start. Having taken that stance, I would question the need for having 2 RR types. It is acknowledged (in the current documents) that the use of TXT is a transitional, but if we require everyone to publish SPF2 (or whatver name is used) RR then I do not think we need to publish or check TXT records. I would also support the alternative given by Daniel Quinlan's response of dropping SFP RR and using TXT as this would lead to less deployment problems than using a new RR - though I understand and appreciate the arguments for having a new RR. From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 03:41: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 DAA00588 for ; Sat, 4 Sep 2004 03:41:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i847HEgO053973; Sat, 4 Sep 2004 00:17: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 i847HElv053972; Sat, 4 Sep 2004 00:17:14 -0700 (PDT) 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 i847HDes053959 for ; Sat, 4 Sep 2004 00:17:13 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 54C761A6C3; Sat, 4 Sep 2004 09:17:20 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id DA8EB1A6BA for ; Sat, 4 Sep 2004 09:17:17 +0200 (CEST) Message-Id: Date: Sat, 4 Sep 2004 09:17:17 +0200 From: Arnt Gulbrandsen To: IETF MARID WG Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardiza tion of SPF Classic References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip writes: > Are you saying that NNTP is a good example of protocol design? Or a > good example of creating a widely supported feature set? It's an example of a protocol that's evolved outside anyone's control. In my impression, it's evolved without accompanying documentation. Very inconvenient for implementers. Arnt From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 03:41: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 DAA00594 for ; Sat, 4 Sep 2004 03:41: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 i847LJWr055159; Sat, 4 Sep 2004 00:21:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i847LJcM055157; Sat, 4 Sep 2004 00:21:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i847LIhn055118 for ; Sat, 4 Sep 2004 00:21:19 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1C3UrJ-0009J1-00; Sat, 04 Sep 2004 08:21:13 +0100 Message-ID: <002b01c4924f$70a4b290$0200000a@ringo> From: "Chris Haynes" To: "Hallam-Baker, Phillip" Cc: "'Anne P. Mitchell, Esq.'" , "IETF MARID WG" References: Subject: Re: DEPLOY: Sender-ID provides little or no defence against adaptive threats Date: Sat, 4 Sep 2004 08:18:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "Hallam-Baker, Phillip" commented: > > Even if we end up with spammers using disposable domains it will > mean a major switching cost for every message variant. In effect > the use of hash busters will be completely negated. > > Saying that Sender ID will not work because of the throaway domain > problem is like saying that it is pointless putting locks on your > doors because a burglar can break a window. I don't think anyone is listing this as a weakness of Sender-ID - certainly no-one on this thread. All anti-forgery schemes which force the bad guys to have to make themselves visible are ultimately helpful. We seem to have a violent agreement for once! >In the real world breaking > windows creates noise and leads to burglars being caught. > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Anne P. Mitchell, > > Esq. > > Sent: Friday, September 03, 2004 4:55 PM > > To: IETF MARID WG > > Subject: RE: DEPLOY: Sender-ID provides little or no defence against > > adaptive threats > > > > > > > > > > > Anne P. Mitchell wrote: > > > >cf. CipherTrust's study released this week in which >50% of the > > > sources > > > >for all email surveyed which published SPF records were spammers. > > > > > > > >http://www.infoworld.com/article/04/08/31/HNspammerstudy_1.html > > > > > > Just so there is no confusion... this is good news for SPF, not bad > > > news. > > > > > > > Absolutely, completely agreed! I should have elaborated. As I have > > said in various public posts (elsewhere), if spammers want to tie > > themselves to their sites by authentication, that's a *good* > > thing. My > > points are that a) spammers will adopt whatever is out there, and in > > this instance b) spammers are stupid - by adopting what they > > *think* is > > an anti-spam protocol to help get their spam through, they > > are actually > > raising their hands and saying "here I am!" > > > > Anne > > > Chris From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 03:50: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 DAA00855 for ; Sat, 4 Sep 2004 03:50:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i847VJI1059384; Sat, 4 Sep 2004 00:31:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i847VJSg059383; Sat, 4 Sep 2004 00:31:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i847VILG059361 for ; Sat, 4 Sep 2004 00:31:18 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1C3V19-0008Ng-00; Sat, 04 Sep 2004 08:31:23 +0100 Message-ID: <003101c49250$dbd2f0d0$0200000a@ringo> From: "Chris Haynes" To: "william\(at\)elan.net" , "IETF MXCOMP \(E-mail\)" References: Subject: Re: Issues raised in comments by Steve Belovin from January 2004 Date: Sat, 4 Sep 2004 08:28:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "william(at)elan.net" was quoting Steven Bellovin: > > Beyond that, there are problems with internationalization: > what language should the error message be in, and in what > character set is it encoded? A simple URI would be a better > solution; at the least, it should point to an SPFERR record. > (---- > I remember discussions about this at spf-discuss. I don't remember > if there was any resolution... > ----) > I started the 'internationalisation' thread, both here and on spf-discuss. The conclusions I came to myself were: 1) The barrier to internationalisation support is that the text supplied in SMTP rejections is only (implicitly-) defined as being in US-ASCII. One would have to change RFC 8211 to introduce some form of encoding, and it could break existing systems. 2) The best compromise seemed to be to put a URL into the SPF string (as implied by one of the examples), and hope that users realize that they should click on it to see the fully-internationalised error message. Anything else appeared to need substantial re-engineering outside the scope of MARID. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 04:37: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 EAA02818 for ; Sat, 4 Sep 2004 04:37: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 i848CWV9072698; Sat, 4 Sep 2004 01:12:32 -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 i848CW0E072697; Sat, 4 Sep 2004 01:12:32 -0700 (PDT) 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 i848CVsm072635 for ; Sat, 4 Sep 2004 01:12:32 -0700 (PDT) (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 i848CSL9025722; Sat, 4 Sep 2004 08:12:28 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 i848CSE5010709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Sep 2004 10:12:28 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i848CRe0010708; Sat, 4 Sep 2004 10:12:27 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Sat, 4 Sep 2004 10:12:27 +0200 From: Koen Martens To: "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardiza tion of SPF Classic Message-ID: <20040904081227.GA10690@metro.cx> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 09:08:13PM -0700, Hallam-Baker, Phillip wrote: > There is a reason why NNTP has been replaced by the blogosphere. And that reason is spam. Not bad protocol design. -- 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/ From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 05:02:23 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 FAA03868 for ; Sat, 4 Sep 2004 05:02:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i848d5tr081393; Sat, 4 Sep 2004 01:39: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 i848d5bA081392; Sat, 4 Sep 2004 01:39:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i848d5H8081372 for ; Sat, 4 Sep 2004 01:39:05 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i848d6QA030365 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 4 Sep 2004 04:39:06 -0400 Date: Sat, 4 Sep 2004 04:39:06 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: "'Yakov Shafranovich'" , Hadmut Danisch , Jonathan Gardner , IETF MARID WG Subject: RE: Motion to abandon Sender ID 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 Thu, 2 Sep 2004, Hallam-Baker, Phillip wrote: > This is not a technical issue, it is the type of issue the IESG should > be involved with instead of making technical comments on the WG > output. The selection of technology is a technical issue. Patent encumbrances are a factor in that decision. > The problem here is that a bad precedent was set with the RSA patent. > There are two types of patent at issue, casual patents and > fundamental ones. The RSA patent did not set any precedents, other than its subject matter. In that sense, every patent is precedent setting. There are only truly novel patents and patents that aren't truly novel. But there is always another way to do something. It may be inconvenient. It may be so inconvenient that you don't want to do it, or so inconvenient that licensing is the grudgingly unhappy but obvious choice. Or, out of principle, you may just choose not to do it at all. But sometimes the search for another way to do something turns up a better solution: compare LZW and bzip. The scary thing about truly novel patents is that they may be so revolutionary that it will take a long time to find another alternative, and so impactful that non-licensees can't survive economically with the alternatives. Another scary thing is that one ordinarilly learns about them 18 months after the filing. In those 18 months, one may have deployed quite a few copies of the technology which they will have to pay for, or one may have committed significant investment in the technology. You only learn about this patent expense up to 18 months after its been incurred. --Dean From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 05:11: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 FAA04448 for ; Sat, 4 Sep 2004 05:11:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i848p5pn085477; Sat, 4 Sep 2004 01:51: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 i848p5rw085476; Sat, 4 Sep 2004 01:51:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i848p4c8085466 for ; Sat, 4 Sep 2004 01:51:04 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i848pCBD030641 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 4 Sep 2004 04:51:12 -0400 Date: Sat, 4 Sep 2004 04:51:12 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: "'Anne P. Mitchell, Esq.'" , IETF MARID WG Subject: RE: DEPLOY: Sender-ID provides little or no defence against adapt ive threats 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, 3 Sep 2004, Hallam-Baker, Phillip wrote: > > Even if we end up with spammers using disposable domains it will > mean a major switching cost for every message variant. In effect > the use of hash busters will be completely negated. > > Saying that Sender ID will not work because of the throaway domain > problem is like saying that it is pointless putting locks on your > doors because a burglar can break a window. In the real world breaking > windows creates noise and leads to burglars being caught. There is no point in putting a lock on a free-standing doorframe when the burglar can simply walk around the door. And that is the situation we face. Spammers can still forge email, even without disposable domains. They can forge email from the domain (any domain) serviced by their ISP. There are infinitely many user addresses to the left of the @ sign. Since there no walls, there is no point in having doors with locks. If the abuser just doesn't want to give an email address they use, they can forge an address at their ISPs domain. Or they can use a disposable address. One still has to contact the ISP with the IP address and time of use of the abuser. Same as one would without sender-id/SPF/RMX. If the abuser is interested in harrassing a particular email address (a joe job), they can just forge email to their ISP's relay. That relay will then bounce the message to the target. The target then has to contact each ISP to report the abuse. But they had to do that before sender-id/SPF/RMX. The problem is the same. At great expense, you've accomplished nothing. --Dean From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 05:51: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 FAA06095 for ; Sat, 4 Sep 2004 05:51: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 i849Q6Ur098062; Sat, 4 Sep 2004 02:26: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 i849Q6dE098061; Sat, 4 Sep 2004 02:26:06 -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 i849Q6pq098053 for ; Sat, 4 Sep 2004 02:26:06 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i849QE3R000405 for ; Sat, 4 Sep 2004 02:26:14 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <72C17075-FE54-11D8-B4F9-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardiza tion of SPF Classic Date: Sat, 4 Sep 2004 02:26:06 -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 > > There is a reason why NNTP has been replaced by the blogosphere. > > And that reason is spam. Not bad protocol design. And the the relative lack of a proficiency barrier to entry. Anne From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 09:32: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 JAA16364 for ; Sat, 4 Sep 2004 09:32: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 i84D6sFe036671; Sat, 4 Sep 2004 06:06:54 -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 i84D6sks036670; Sat, 4 Sep 2004 06:06:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84D6q40036662 for ; Sat, 4 Sep 2004 06:06:53 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i84DGGuO030709; Sat, 4 Sep 2004 09:16:17 -0400 From: To: "'Dean Anderson'" , "'Hallam-Baker, Phillip'" Cc: "'Anne P. Mitchell, Esq.'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Sender-ID provides little or no defense against adaptive threats Date: Sat, 4 Sep 2004 09:04:48 -0400 Message-ID: <002c01c4927f$c2727780$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Not "accomplished nothing" but we would have accomplished the need for the next step: SMTP AUTH that incorporates spoofing prevention. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Dean Anderson > Sent: Saturday, September 04, 2004 4:51 AM > To: Hallam-Baker, Phillip > Cc: 'Anne P. Mitchell, Esq.'; IETF MARID WG > Subject: RE: DEPLOY: Sender-ID provides little or no defence against > adaptive threats > > > > On Fri, 3 Sep 2004, Hallam-Baker, Phillip wrote: > > > > > Even if we end up with spammers using disposable domains it will > > mean a major switching cost for every message variant. In effect > > the use of hash busters will be completely negated. > > > > Saying that Sender ID will not work because of the throaway domain > > problem is like saying that it is pointless putting locks on your > > doors because a burglar can break a window. In the real > world breaking > > windows creates noise and leads to burglars being caught. > > There is no point in putting a lock on a free-standing > doorframe when the > burglar can simply walk around the door. And that is the situation we > face. Spammers can still forge email, even without > disposable domains. > They can forge email from the domain (any domain) serviced by > their ISP. > There are infinitely many user addresses to the left of the @ > sign. Since > there no walls, there is no point in having doors with locks. > > If the abuser just doesn't want to give an email address they > use, they > can forge an address at their ISPs domain. Or they can use a > disposable > address. One still has to contact the ISP with the IP > address and time of > use of the abuser. Same as one would without sender-id/SPF/RMX. > > If the abuser is interested in harrassing a particular email > address (a > joe job), they can just forge email to their ISP's relay. > That relay will > then bounce the message to the target. The target then has to contact > each ISP to report the abuse. But they had to do that before > sender-id/SPF/RMX. The problem is the same. > > At great expense, you've accomplished nothing. > > --Dean > From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 09:37:49 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 JAA16602 for ; Sat, 4 Sep 2004 09:37:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84DCeRK036972; Sat, 4 Sep 2004 06:12:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i84DCeG0036971; Sat, 4 Sep 2004 06:12:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84DCcaS036964 for ; Sat, 4 Sep 2004 06:12:39 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i84DMJuO030762; Sat, 4 Sep 2004 09:22:20 -0400 From: To: "'Andrew Newton'" , "'IETF MARID WG'" Subject: RE: consensus call on MUST/SHOULD language for TXT records Date: Sat, 4 Sep 2004 09:10:51 -0400 Message-ID: <002d01c49280$9aae4d40$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <000b01c49231$54562100$2766f30a@development.greatgulfhomes.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit After reading this: > On Sep 3, 2004, at 6:19 PM, Yakov Shafranovich wrote: > > I am not sure how #1 differs from #2? Are you suggesting that if we > > adopt position #1, someone not having SPF RR records would be ignored? > > My interpretation of the thread is "might be ignored". I did not infer that implication myself. And after careful consideration I am going to have to change my vote to (2), I cannot accept condoning of ignoring published SPF records (regardless of RR type). Sorry for any confusion. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of > terry@ashtonwoodshomes.com > Sent: Friday, September 03, 2004 11:43 PM > To: 'Andrew Newton'; 'IETF MARID WG' > Subject: RE: consensus call on MUST/SHOULD language for TXT records > > > > I vote for position 1, future RFC should deprecate TXT record > AFTER a SPF RR is approved and > implemented in DNS servers. > > Terry Fielder > Manager Software Development and Deployment > Great Gulf Homes / Ashton Woods Homes > terry@greatgulfhomes.com > Fax: (416) 441-9085 > > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Andrew Newton > > Sent: Friday, September 03, 2004 5:34 PM > > To: IETF MARID WG > > Subject: consensus call on MUST/SHOULD language for TXT records > > > > > > > > The debate over the MUST/SHOULD/MAY language with regard to > > compliance > > and publication of TXT and SPF2 record types does not seem to be > > getting the attention of the full working group. > > > > Despite lack of agreement on the outcome, there is agreement on the > > stated positions. In the words of Olafur: > > 1) Specify everyone to be compliant at all times. > > 2) Specify clearly full complaint state and tolerate non-compliant > > state during phase-in. > > > > Position 1 is predicated on the notion that a future RFC will > > deprecate > > the (use of the) TXT record in favor of the SPF2 record. Position 2 > > demands that the TXT record be discouraged from use in the current > > -protocol document. > > > > Rather than wordsmithing the actual MUST/SHOULD/MAY > language directly > > (and endlessly), we ask the participants state their preference on > > these positions. > > > > -your co-chairs > > > From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 09: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 JAA16756 for ; Sat, 4 Sep 2004 09:40:45 -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 i84DJFOB037382; Sat, 4 Sep 2004 06:19:15 -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 i84DJF1g037381; Sat, 4 Sep 2004 06:19:15 -0700 (PDT) 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 i84DJE9V037328 for ; Sat, 4 Sep 2004 06:19:14 -0700 (PDT) (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 i84DJGCS035326; Sat, 4 Sep 2004 13:19:16 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 i84DJFE5011240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Sep 2004 15:19:15 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i84DJDwx011239; Sat, 4 Sep 2004 15:19:13 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Sat, 4 Sep 2004 15:19:13 +0200 From: gmc@metro.cx To: Andrew Newton Cc: IETF MARID WG Subject: Re: consensus call of RR prefix Message-ID: <20040904131913.GE10690@metro.cx> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 05:32:22PM -0400, Andrew Newton wrote: > Therefore, that leaves one under-discussed question: should a prefix be > used to avoid collision with other records as one measure of preventing > the requirement of DNS over TCP? As there is almost no other use for TXT records as we speak (perhaps someone could be so kind to repost the survey carried out on a large list of domains, which stated how many domains with non-spf1 txt records were found) and added to that the problems with wildcards, my opinion is that prefixes are not preferable. However, problems might start to exist in the future, when several competing versions of spf-derived protocols will be in effect. However, this might also be a pro, as it limits the proliferation of possible spf-derived protocols and therefore will force the community to converge on a standard sooner. Koen Martnes -- 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/ From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 09:43:50 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 JAA16929 for ; Sat, 4 Sep 2004 09:43:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84DMEtK037515; Sat, 4 Sep 2004 06:22: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 i84DMEUU037514; Sat, 4 Sep 2004 06:22:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84DMCBD037508 for ; Sat, 4 Sep 2004 06:22:13 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i84DVsuO030921; Sat, 4 Sep 2004 09:31:54 -0400 From: To: "'Andrew Newton'" , "'IETF MARID WG'" Subject: RE: consensus call of RR prefix Date: Sat, 4 Sep 2004 09:20:18 -0400 Message-ID: <002e01c49281$f106aec0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit No, don't make prefixes required (this is an oversimplication but I believe to cover the reasons for common deployment): -not all dns servers support "_" -domains with potential collision issues can explicitly use a small redirect to move the spf query result elsewhere -many dns providers do not allow subdomains (or not easily via an interface, and we need to keep publishing easy or it won't get done)(yes I know many ISPs don't support TXT RR either, but that *is* changing and it *is* an RFC compliant DNS standard, even if SPF abuses it) Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Andrew Newton > Sent: Friday, September 03, 2004 5:32 PM > To: IETF MARID WG > Subject: consensus call of RR prefix > > > > From the discussion on prefixes for the DNS record, there > seems to have > been no discernible outcome regarding the use of prefixes for the > purposes of avoiding collisions with other DNS records (thus avoiding > fallback to DNS over TCP). > > Naturally, this issue wraps itself into both the versioning/scoping > issue and the wildcard issue. Based on the comments received so far, > it is the opinion of the co-chairs that there is no consensus > on how to > handle wildcards and that most participants seem to agree that > wildcards present a problem no matter the solution. Based on the > comments received so far, it is the opinion of the co-chairs > that there > is consensus on placing the "scope" in the RDATA of the record and no > consensus on the scope being in the prefix. > > Therefore, that leaves one under-discussed question: should a > prefix be > used to avoid collision with other records as one measure of > preventing > the requirement of DNS over TCP? > > Incidentally, the co-chairs note that many examples of the > prefix have > used "-marid". We would note that "MARID" is the name of > this working > group and likely not meaningful beyond the context of discussions and > process of this working group. Therefore we recommend a more > meaningful label such as "_rmx": the deduction of its meaning > is easier > and it references the genesis of the MARID idea. > > -your co-chairs > From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 10:10: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 KAA18466 for ; Sat, 4 Sep 2004 10:10: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 i84DoiBj038847; Sat, 4 Sep 2004 06:50: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 i84DoirA038846; Sat, 4 Sep 2004 06:50:44 -0700 (PDT) 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 i84Doh2d038838 for ; Sat, 4 Sep 2004 06:50:43 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Sat, 04 Sep 2004 09:50:51 -0400 id 000000000015766C.000000004139C83B.00000A08 X-IMAP-Sender: mrsam@courier-mta.com References: Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: IETF MARID WG X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardiza tion of SPF Classic Date: Sat, 04 Sep 2004 09:50:50 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-25006-1094305850-0002"; 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-25006-1094305850-0002 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip writes: > >> That's fine. You might want to study the evolution of NNTP. >> There, lack of >> the official IETF stamp of approval did not inhibit NNTP from >> evolving. If >> you try to implement NNTP based only on IETF's standards-track >> documentation, you won't get very far. > > Are you saying that NNTP is a good example of protocol design? > Or a good example of creating a widely supported feature set? NNTP works. It has survived the onslaught of spam far better than SMTP. I may be see one or two spam message a week across all the newsgroups I'm subscribed to. And NNTP's evolution was outside of the IETF process. > I don't think either really holds. NNTP was in any case established > and the RFC published before the date of the first IETF meeting > and long before there was a defined IETF process. The early versions of NNTP, perhaps. The NNTP of today has evolved far beyond those early days. > NNTP chews up about four orders of bandwidth more bandwidth than it > needs to. I don't think so. > The protcol set is poorly standardized and the application > has failed to meet the problems of spam, trolls and other social > issues. That's not what I'm seeing. I see hundreds of thousands of independent nodes; excellent propagation, certainly no worse than SMTP. --=_mimegpg-commodore.email-scan.com-25006-1094305850-0002 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBOcg6x9p3GYHlUOIRAp+PAJ9gldm+jeeq3S/Ew65r5vP2+kM3yQCcCfEQ 4ROu773T62MxQgfass8iW+E= =/SJN -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-25006-1094305850-0002-- From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 11:06: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 LAA20634 for ; Sat, 4 Sep 2004 11:06: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 i84Ei2uV041894; Sat, 4 Sep 2004 07:44: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 i84Ei2eN041893; Sat, 4 Sep 2004 07:44:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winger.mail.pas.earthlink.net (winger.mail.pas.earthlink.net [207.217.120.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84Ei26j041886 for ; Sat, 4 Sep 2004 07:44:02 -0700 (PDT) (envelope-from tripp@corp.earthlink.net) Received: from [68.243.38.55] (helo=[68.243.38.55]) by winger.mail.pas.earthlink.net with asmtp (Exim 3.36 #1) id 1C3bly-0005QC-00; Sat, 04 Sep 2004 07:44:12 -0700 Mime-Version: 1.0 X-Mailer: SnapperMail 1.9.2.01 by Snapperfish, www.snappermail.com To: ietf-mxcomp@imc.org Subject: [Deploy] Insufficient Microsoft IPR disclosure From: Tripp Cox Date: Sat, 04 Sep 2004 9:43 -0500 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Message-Id: X-ELNK-Trace: 50622dd748c31efb0eea5ec98aae1f9f7cb464f1c45e15a462525a58e35e5c4c407b3430dbcccf4901edfae561465979715ed6d3cd8c1f1f715ed6d3cd8c1f1f Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit First, let me say that I think the proposed Sender-ID framework is a great first step in creating a low-overhead, global sender authentication framework. I would like nothing more than to deploy Sender-ID at EarthLink, however a lack of information in the Microsoft IPR claims and associated license at present will prevent me from doing so, base on the following advise from EarthLink counsel. The IETF's position on the provision of IP rights in connection with a particular patent holder that is proposing a standard require that "working groups and participants have as much information about any IPR constraints on a technical proposal as possible." What we have received, to date, from Microsoft is a short description of what Microsoft intends to include within its license. A link to this licensing position can be found at: http://www.microsoft.com/mscorp/ip/standards. Among the areas of concern for EarthLink include: Timing of the disclosure: The IPR for the IETF requires timely disclosure of all relevant licensing terms. As stated in Section 6.2 of Intellectual Property Rights in IETF Technology: "Timely IPR disclosure is important because working group need to have as much information as they can while they are evaluating alternative solutions." Substance of Grant and Lack of Disclosure Microsoft's proposed license does not meet the requirements of the IPR. While Microsoft states that it is willing to license all of its potential IPR to implement the standard on a royalty-free basis, Microsoft must also disclose any other terms and conditions in connection with this license. The disclosure by Microsoft fails to indicate these terms and conditions. As a result, we are not able to determine whether the license granted by Microsoft will fully enable the full use of Sender ID within a proposed standard and if there are any other impacts to integrally related areas that may not explicitly be included in the standard but may be necessary to fully exploit the standard. Without having access to the terms and conditions of the Microsoft license, this situation cannot fully be evaluated. In addition, it is not clear if all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to the proposed standard a) under a royalty-free and otherwise reasonable and non-discriminatory license, or b) under a license that contains reasonable and non-discriminatory terms and conditions, including a reasonable royalty or other payment, or c) without the need to obtain a license from the IPR holder. The answer to these questions is not clear and, as we understand it, Microsoft has been unwilling to address these issues. If Microsoft would be willing to address these issues in a satisfactory manner, then EarthLink would be willing and able to lend its support to the proposed standard. From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 11:32:34 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 LAA22334 for ; Sat, 4 Sep 2004 11:32:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84FCIX8042991; Sat, 4 Sep 2004 08:12: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 i84FCHZR042990; Sat, 4 Sep 2004 08:12:17 -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 i84FCFeA042972 for ; Sat, 4 Sep 2004 08:12:16 -0700 (PDT) (envelope-from sb0-0665f0eeab-johnl@iecc.com) Received: (qmail 26632 invoked by uid 100); 4 Sep 2004 15:12:25 -0000 Date: 4 Sep 2004 15:12:25 -0000 Message-ID: <20040904151225.26631.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: RR prefix is not useful In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: andy@hxr.us Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Therefore, that leaves one under-discussed question: should a prefix be >used to avoid collision with other records as one measure of preventing >the requirement of DNS over TCP? No, for two reasons. The first is that it is not a very effective way to keep multiple TXT records out of the same DNS node. Based on what I've read, there aren't a whole lot of other TXT records at the same nodes where MARID records need to live. The bloat problem occurs when you use wildcards. Since no DNS server I know supports wildcards of the form _marid.*.phoo.com, you have to put all of your wildcards at *.phoo.com and that's where you get overlap and bloat. If specific nodes do get overloaded, SPF and Sender-ID both let you use a short record pointing to a longer record somewhere else as a band-aid. The other is to keep in mind that using TXT records is a botch. DNS was designed to have a separate record type for each separate application. Type numbers are 16 bits so number assignments are not particularly precious, and queries by type number are the right way to get the records you want and not the records you don't want in a small DNS response. It's a historical accident, and arguably a historical mistake, that there haven't been hundreds of types assigned in the past two decades. I realize that short-sighted implementation decisions by some DNS software authors and vendors make it difficult to deploy new record types in the near term. The right response to that is to permit TXT records as a transition measure (no doubt for a very long transition), but to keep in mind that it's a transition and in the longer term, we should deploy new record types as needed to support new services and applications. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 11:38:24 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 LAA22560 for ; Sat, 4 Sep 2004 11:38:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84FGwGC043421; Sat, 4 Sep 2004 08:16: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 i84FGwuv043420; Sat, 4 Sep 2004 08:16:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sorrow.cyrius.com (sorrow.cyrius.com [65.19.161.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84FGwtw043411 for ; Sat, 4 Sep 2004 08:16:58 -0700 (PDT) (envelope-from tbm@cyrius.com) Received: by sorrow.cyrius.com (Postfix, from userid 10) id 625EC64D44; Sat, 4 Sep 2004 15:17:03 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 60889FEB8; Sat, 4 Sep 2004 17:16:31 +0200 (CEST) Date: Sat, 4 Sep 2004 17:16:31 +0200 From: Martin Michlmayr - Debian Project Leader To: ietf-mxcomp@imc.org Subject: DEPLOY: Debian project unable to deploy Sender ID Message-ID: <20040904151631.GA20928@deprecation.cyrius.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This message summarises the position of the Debian project, producer of the universal operating system: Debian GNU/Linux. The Debian project abides by a social contract to our users that specifies all software included in the operating system will be Free Software, meaning that it can be freely redistributed, modified, used, etc. as defined under the Debian Free Software Guidelines (DFSG). The current Microsoft Royalty-Free Sender ID Patent License Agreement terms are a barrier to any Debian package which wants to implement Sender ID or include Sender ID support. We believe the current license and resulting encumbrances are incompatible with the DFSG, unlike other Internet standards that Debian is able to support. Therefore, we cannot implement or deploy Sender ID under the current license terms. Indeed, we would be forced to remove SenderID support =66rom software we ship that does support Sender ID upstream according to the terms of our social contract. For the most part, our legal concerns mirror those of the Apache Software Foundation, the Free Software Foundation, as well as the Postfix, Exim, and Courier maintainers. We are also concerned that no company should be permitted intellectual property rights (IPR) over core Internet infrastructure. We believe the IETF needs to revamp its IPR policies to ensure that the core Internet infrastructure remain unencumbered. With thanks to the Apache Software Foundation for their statement, which we used as a starting point, though we have arrived at our determination independently. Martin Michlmayr Debian Project Leader Additional information Debian Social Contract http://www.debian.org/social_contract Debian Free Software Guidelines http://www.debian.org/social_contract#guidelines Apache Statement on Sender ID http://www.apache.org/foundation/docs/sender-id-position.html --=20 Martin Michlmayr leader@debian.org --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBOdxPKb5dImj9VJ8RAu9WAJ47u4gTRJAtDs2bNFJRXlfWDV+AUwCdEMGO AEVr6wfS1+ko5Fjje+vYmAQ= =CqAV -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 12:53:24 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 MAA25713 for ; Sat, 4 Sep 2004 12:53:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84GSBV4047745; Sat, 4 Sep 2004 09:28: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 i84GSBfO047744; Sat, 4 Sep 2004 09:28:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84GSATK047735 for ; Sat, 4 Sep 2004 09:28:10 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from righton.sendmail.com (ns.sendmail.com [209.246.26.10]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i84GSFn7003111 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 4 Sep 2004 09:28:15 -0700 Received: from [192.168.1.102] (soggy22.drizzle.com [216.162.199.22]) (authenticated bits=0) by righton.sendmail.com (8.13.1.Beta1/8.13.1.Beta1) with ESMTP id i84GSCsL090479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Sep 2004 09:28:14 -0700 (PDT) Message-ID: <4139ED1C.7050704@sendmail.com> Date: Sat, 04 Sep 2004 09:28:12 -0700 From: Rand Wacker User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Levine CC: ietf-mxcomp@imc.org Subject: Re: RR prefix is not useful References: <20040904151225.26631.qmail@xuxa.iecc.com> In-Reply-To: <20040904151225.26631.qmail@xuxa.iecc.com> Content-Type: text/plain; charset=us-ascii; 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 John Levine wrote: > Based on what I've read, there > aren't a whole lot of other TXT records at the same nodes where MARID > records need to live. spfv1 records live here right now. > The bloat problem occurs when you use > wildcards. Since no DNS server I know supports wildcards of the form > _marid.*.phoo.com, you have to put all of your wildcards at *.phoo.com > and that's where you get overlap and bloat. This means that domainkeys records are going to get caught by these wildcards as well. Wildcards just aren't going to work when we're publishing TXT records, period. > If specific nodes do get > overloaded, SPF and Sender-ID both let you use a short record pointing > to a longer record somewhere else as a band-aid. That's a fine workaround, but even *those* records will get caught by wildcards. Wildcards won't work. -Rand From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 12:58:55 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 MAA25967 for ; Sat, 4 Sep 2004 12:58: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 i84GalnX048255; Sat, 4 Sep 2004 09:36:47 -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 i84GalPx048254; Sat, 4 Sep 2004 09:36:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84GaktF048247 for ; Sat, 4 Sep 2004 09:36:46 -0700 (PDT) (envelope-from sb0-0665f0eeab-johnl@iecc.com) Received: (qmail 4935 invoked from network); 4 Sep 2004 16:36:56 -0000 Received: (ofmipd 127.0.0.1); 4 Sep 2004 16:36:34 -0000 Date: 4 Sep 2004 12:36:56 -0400 Message-ID: From: "John R Levine" To: "Rand Wacker" Cc: "ietf-mxcomp@imc.org" Subject: Re: RR prefix is not useful In-Reply-To: <4139ED1C.7050704@sendmail.com> References: <20040904151225.26631.qmail@xuxa.iecc.com> <4139ED1C.7050704@sendmail.com> Cleverness: None detected 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: > > The bloat problem occurs when you use > > wildcards. Since no DNS server I know supports wildcards of the form > > _marid.*.phoo.com, you have to put all of your wildcards at *.phoo.com > > and that's where you get overlap and bloat. > > This means that domainkeys records are going to get caught by these > wildcards as well. Wildcards just aren't going to work when we're > publishing TXT records, period. At this point it appears that the most likely format for DK records is some version of SPF records, so the band-aid works for them, too. > > If specific nodes do get > > overloaded, SPF and Sender-ID both let you use a short record pointing > > to a longer record somewhere else as a band-aid. > > That's a fine workaround, but even *those* records will get caught by > wildcards. Wildcards won't work. I don't see how repeating this claim makes it any more persuasive. All the records I know about can use the short pointer band-aid, and it looks easy enough to have five or six band-aid records and still fit in a UDP packet. What am I missing? I realize that a hundred TXT records won't fit, but I don't see more than about four TXT record applications showing up any time soon. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 13:36: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 NAA27466 for ; Sat, 4 Sep 2004 13:36: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 i84HAgrY050157; Sat, 4 Sep 2004 10:10:42 -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 i84HAgfY050156; Sat, 4 Sep 2004 10:10:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HAfIf050149 for ; Sat, 4 Sep 2004 10:10:41 -0700 (PDT) (envelope-from roy+dated+1096909843.c8767d@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HBfY0088165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 17:11:47 GMT (envelope-from roy+dated+1096909843.c8767d@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HAhJh058755 for ; Sat, 4 Sep 2004 18:10:43 +0100 (BST) (envelope-from roy+dated+1096909843.c8767d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84HAh1j058754 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 18:10:43 +0100 (BST) (envelope-from roy+dated+1096909843.c8767d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 18:10:40 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16697.63248.419833.754283@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 18:10:40 +0100 To: "Harry Katz" Cc: , Subject: RE: TECH-ERROR: Name of SUBMITTER parameter In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Harry> Actually, I prefer the name SUBMITTER and would like to Harry> stick with it. I believe that, from the sender's Harry> perspective, the name accurately conveys what the parameter Harry> means. It is only on the receiving side that the value Harry> becomes "purported." Yeah. I guess with hindsight including 'purported' in the name of the identity was a mistake, since whether 'purported' is appropriate depends on context. We could always repurpose PRA to stand for Primary Responsible Address; I'll make a separete post proposing that. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 13:41:36 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 NAA27661 for ; Sat, 4 Sep 2004 13:41:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HLekY050675; Sat, 4 Sep 2004 10:21:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i84HLeAO050674; Sat, 4 Sep 2004 10:21:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HLdeT050668 for ; Sat, 4 Sep 2004 10:21:40 -0700 (PDT) (envelope-from roy+dated+1096910504.b682f5@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HMgS2088986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 17:22:48 GMT (envelope-from roy+dated+1096910504.b682f5@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HLiR0058826 for ; Sat, 4 Sep 2004 18:21:44 +0100 (BST) (envelope-from roy+dated+1096910504.b682f5@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84HLind058825 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 18:21:44 +0100 (BST) (envelope-from roy+dated+1096910504.b682f5@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 18:21:43 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16697.63911.166056.276878@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 18:21:43 +0100 To: Rand Wacker Cc: Andrew Newton , IETF MARID WG Subject: Re: consensus call of RR prefix In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Rand" == Rand Wacker writes: Rand> I would suggest that the document be ammended to remind Rand> people that *all* TXT records published for domain.tld Rand> should fit in 480 bytes The current drafts mandate support for EDNS0 so the 480 byte limit goes away. I really think we shouldn't get to caught up in this 480 byte limit. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 13:41:41 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 NAA27680 for ; Sat, 4 Sep 2004 13:41:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HKWos050545; Sat, 4 Sep 2004 10:20:32 -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 i84HKWwe050544; Sat, 4 Sep 2004 10:20:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HKVvj050538 for ; Sat, 4 Sep 2004 10:20:31 -0700 (PDT) (envelope-from roy+dated+1096910435.c6d235@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HLX6f088915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 17:21:39 GMT (envelope-from roy+dated+1096910435.c6d235@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HKZPX058794 for ; Sat, 4 Sep 2004 18:20:35 +0100 (BST) (envelope-from roy+dated+1096910435.c6d235@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84HKZUg058793 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 18:20:35 +0100 (BST) (envelope-from roy+dated+1096910435.c6d235@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 18:20:24 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16697.63831.938253.936526@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 18:20:23 +0100 To: Rand Wacker Cc: Andrew Newton , IETF MARID WG Subject: Re: consensus call of RR prefix In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Rand" == Rand Wacker writes: Rand> and leaving the TXT records in the domain.tld dataspace, Rand> while ugly, seems like a good bit of parallelism for the SPF Rand> records that will be published in the same place. I concur. Purely pragmatically, many people will want to check both SPF and IETF-compliant Sender ID. Being able to fetch both with a single query is therefore beneficial. (Of course it doesn't matter if I use separate pieces of software to check SPF and Sender ID, both of which make their own queries; my local caching nameserver will still ensure that only one query is made to the authoritative nameservers.) -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 13:55:23 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 NAA28071 for ; Sat, 4 Sep 2004 13:55:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HXqP2051630; Sat, 4 Sep 2004 10:33: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 i84HXquQ051628; Sat, 4 Sep 2004 10:33:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HXpZp051622 for ; Sat, 4 Sep 2004 10:33:52 -0700 (PDT) (envelope-from roy+dated+1096911235.b0c48a@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HYseN089924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 17:35:00 GMT (envelope-from roy+dated+1096911235.b0c48a@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HXujJ058986 for ; Sat, 4 Sep 2004 18:33:56 +0100 (BST) (envelope-from roy+dated+1096911235.b0c48a@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84HXukF058985 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 18:33:56 +0100 (BST) (envelope-from roy+dated+1096911235.b0c48a@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 18:33:55 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16697.64643.37620.763822@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 18:33:55 +0100 To: Andrew Newton Cc: IETF MARID WG Subject: consensus call on MUST/SHOULD language for TXT records In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Andrew" == Andrew Newton writes: Andrew> 1) Specify everyone to be compliant at all times. Andrew> 2) Specify clearly full complaint state and tolerate Andrew> non-compliant state during phase-in. As long as support for SPF2 records is mandatory for compliance on both the publishing and checking side, I'm neutral as to what the documents should say about use of TXT records as an altertive. The discussion of the TXT record could even be relegated to an informative annexe. People will make a pragmatic decision to publish and check for TXT records as long as the pragmatic need to do so remains. I see no pressing need to mandate that pragmatism (though I see ow harm in doing so if people want to). -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 14:03: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 OAA28535 for ; Sat, 4 Sep 2004 14:03: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 i84HfQef052648; Sat, 4 Sep 2004 10:41:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i84HfQp3052647; Sat, 4 Sep 2004 10:41:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HfPQx052640 for ; Sat, 4 Sep 2004 10:41:25 -0700 (PDT) (envelope-from roy+dated+1096911690.a1275e@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HgS36090546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 17:42:34 GMT (envelope-from roy+dated+1096911690.a1275e@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HfUOe059072 for ; Sat, 4 Sep 2004 18:41:30 +0100 (BST) (envelope-from roy+dated+1096911690.a1275e@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84HfUBc059071 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 18:41:30 +0100 (BST) (envelope-from roy+dated+1096911690.a1275e@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 18:41:28 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16697.65095.832137.342452@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 18:41:27 +0100 To: Roy Badami Cc: Rand Wacker , Andrew Newton , IETF MARID WG Subject: Re: consensus call of RR prefix In-Reply-To: <16697.63831.938253.936526@giles.gnomon.org.uk> References: <16697.63831.938253.936526@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I wrote: Roy> I concur. Purely pragmatically, many people will want to Roy> check both SPF and IETF-compliant Sender ID. Being able to Roy> fetch both with a single query is therefore beneficial. I replied without thinking it through; compliant implementations will check SPF2 first, so the gain I was envisaging does not exist. In fact, there's a loss in that you potentially fetch the Sender ID data twice, once in the SPF2 lookup, and once in the TXT lookup needed for SPF checks. However, I'm against using a prefix with SPF2 records. It would be pointless as an attempt to avoid a clash with other uses of SPF2 records, and as others have said, wildcards are unlikely to be useful in either case... I'm neutral as to whether TXT records should have a prefix, but it's probably simpler to put SPF2 records and TXT records at the same place. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 14:05: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 OAA28632 for ; Sat, 4 Sep 2004 14:05:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HkJGp052810; Sat, 4 Sep 2004 10:46:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i84HkJ9J052809; Sat, 4 Sep 2004 10:46:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HkIiT052802 for ; Sat, 4 Sep 2004 10:46:18 -0700 (PDT) (envelope-from roy+dated+1096911983.9423ea@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HlLJx090864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 17:47:27 GMT (envelope-from roy+dated+1096911983.9423ea@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HkNnX059131 for ; Sat, 4 Sep 2004 18:46:23 +0100 (BST) (envelope-from roy+dated+1096911983.9423ea@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84HkNhc059130 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 18:46:23 +0100 (BST) (envelope-from roy+dated+1096911983.9423ea@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 18:46:23 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16697.65390.802720.119471@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 18:46:22 +0100 To: ietf-mxcomp@imc.org Subject: TECH-ERROR: Name of SPF2 record X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm against including the major version number of the protocol in the name of the RR type. The '2' should not be there. _If_ the designers of a future standard decide they need a new typecode, they are free to do so. But I think versioning a protocol in the typecode is probably a bad idea, and doing so from the outset doubly so. I propose that the record simply be called SPF. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 14:17: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 OAA29051 for ; Sat, 4 Sep 2004 14:17:04 -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 i84HtJTW053563; Sat, 4 Sep 2004 10:55:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i84HtJUm053562; Sat, 4 Sep 2004 10:55:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84HtICt053556 for ; Sat, 4 Sep 2004 10:55:18 -0700 (PDT) (envelope-from roy+dated+1096912523.d10bec@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HuLxA091539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 17:56:27 GMT (envelope-from roy+dated+1096912523.d10bec@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84HtNAC059196 for ; Sat, 4 Sep 2004 18:55:23 +0100 (BST) (envelope-from roy+dated+1096912523.d10bec@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84HtNOw059195 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 18:55:23 +0100 (BST) (envelope-from roy+dated+1096912523.d10bec@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 18:55:23 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16698.394.983773.516925@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 18:55:22 +0100 To: ietf-mxcomp@imc.org Subject: DOC-BUG: Terminology: Purported Responsible Address X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit As a result of a recent post by Harry Katz, I've come to the conclusion that the term 'Purported Responsible Address' may be a mistake, and perhaps should be modified. In the case of a Sender ID checker, the term makes sense. The identity is only purported; we don't know yet if the message is forged. But we need a name for this concept that is applicable in other contexts, too, including those where the implications of the word 'purported' are inappropriate, since the senders identity is known by other means. (eg SASL) Harry's objection to using PRA= instead of SUBMITTER= in the MAIL FROM command is, as I understand it, that at this point the address isn't purported, it's known. I therefore suggest that the term Primary Responsible Address would be more appropriate. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 14:31: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 OAA29520 for ; Sat, 4 Sep 2004 14:31:45 -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 i84IBrkF055142; Sat, 4 Sep 2004 11:11: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 i84IBrVa055141; Sat, 4 Sep 2004 11:11:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84IBqis055135 for ; Sat, 4 Sep 2004 11:11:53 -0700 (PDT) (envelope-from roy+dated+1096913517.5e2475@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84ICu2J092762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 18:13:02 GMT (envelope-from roy+dated+1096913517.5e2475@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84IBv5q059379 for ; Sat, 4 Sep 2004 19:11:57 +0100 (BST) (envelope-from roy+dated+1096913517.5e2475@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84IBvaE059372 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 19:11:57 +0100 (BST) (envelope-from roy+dated+1096913517.5e2475@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 19:11:56 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16698.1388.231292.755112@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 19:11:56 +0100 To: Tony Finch Cc: Roy Badami , ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra In-Reply-To: References: <16695.49071.671776.708651@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tony" == Tony Finch writes: Tony> I'm afraid they are common enough that strict syntax Tony> checking has a high false positive rate. OK, if the empty header check turns out to be useful, then I'm all for keeping it. I suggest that an empty field body is defined to be one that is of zero lenght, or consists entirely of linear whitespace. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 14:53:55 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 OAA00707 for ; Sat, 4 Sep 2004 14:53:54 -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 i84IXI3M056717; Sat, 4 Sep 2004 11:33: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 i84IXInJ056716; Sat, 4 Sep 2004 11:33:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84IXFt3056708 for ; Sat, 4 Sep 2004 11:33:17 -0700 (PDT) (envelope-from roy+dated+1096914800.9083a5@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84IYJtw094327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 18:34:24 GMT (envelope-from roy+dated+1096914800.9083a5@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84IXKMg059515 for ; Sat, 4 Sep 2004 19:33:20 +0100 (BST) (envelope-from roy+dated+1096914800.9083a5@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84IXKKo059514 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 19:33:20 +0100 (BST) (envelope-from roy+dated+1096914800.9083a5@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 19:33:20 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16698.2671.522881.368707@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 19:33:19 +0100 To: ietf-mxcomp@imc.org Subject: DOC-BUG: Clarify implications of malformed messages X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The PRA algorithm (deliberately) specifies its behaviour for messages that are not conformant with RFC822 or RFC2822. I think it would be desirable to clarify why this is (ie to ensure a deterministic result in the presence of liberal parsers) and what the implications are (specifically that we are not in any way requiring implementations to accept messages that they would otherwise have rejected as malformed). I suggest adding the following note to the end of section 2 of -pra. Although the algorithm specifies how messages that are not in conformance with the provisions of RFC822 or RFC2822 should be treated for the purposes of determining the purported responsible address, this should not be taken as requiring or recommending that any systems accept such messages when they would not otherwise have done so. However, if a liberal implementation that chooses to accept messages not in conformance with RFC822 or RFC2822, then it MUST use this algorithm to determine the purported responsible address of such messages. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 15:01:41 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 PAA01125 for ; Sat, 4 Sep 2004 15:01:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84IgXmc057289; Sat, 4 Sep 2004 11:42:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i84IgWsL057288; Sat, 4 Sep 2004 11:42:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84IgWeN057280 for ; Sat, 4 Sep 2004 11:42:32 -0700 (PDT) (envelope-from roy+dated+1096915356.2ff28d@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84IhZVm094982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 18:43:41 GMT (envelope-from roy+dated+1096915356.2ff28d@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84IgaCV059673 for ; Sat, 4 Sep 2004 19:42:36 +0100 (BST) (envelope-from roy+dated+1096915356.2ff28d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84Iga1j059672 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 19:42:36 +0100 (BST) (envelope-from roy+dated+1096915356.2ff28d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 19:42:36 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16698.3227.709844.613165@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 19:42:35 +0100 To: ietf-mxcomp@imc.org Subject: DOC-BUG: Add note on RFC822 compatibility to -pra X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A note should be added to -pra noting that the algorithm might have unexpected results in rare cases where messages are formed according to RFC822 rather than RFC2822: Where messages conform to RFC822 rather than RFC2822, it is possible for the algorithm to give unexpected results. An RFC822 message should not normally contain more than one set of resent headers; however the placement of those headers is not specified, nor are they required to be contiguous. It is hence possible that the Resent-From header will be selected even though a Resent-Sender header is present. Such cases are expected to be rare or non-existent in practice. Implementations MUST use the algorithm as specified in this document, even where the message is know to conform to RFC822. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 15:19: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 PAA02826 for ; Sat, 4 Sep 2004 15:19: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 i84Iw2gZ058198; Sat, 4 Sep 2004 11:58: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 i84Iw2JF058197; Sat, 4 Sep 2004 11:58:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84Iw18G058191 for ; Sat, 4 Sep 2004 11:58:01 -0700 (PDT) (envelope-from roy+dated+1096916286.1d7177@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84Ix5Ys095998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 18:59:11 GMT (envelope-from roy+dated+1096916286.1d7177@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84Iw6BQ059772 for ; Sat, 4 Sep 2004 19:58:06 +0100 (BST) (envelope-from roy+dated+1096916286.1d7177@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84Iw6ZR059771 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 19:58:06 +0100 (BST) (envelope-from roy+dated+1096916286.1d7177@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 19:58:06 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16698.4157.543727.884195@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 19:58:05 +0100 To: ietf-mxcomp@imc.org Subject: DOC-BUG: -pra intro X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -pra currently says This document describes an algorithm that allows one to determine who appears to have most recently caused an e-mail message to be delivered. It does this by inspecting the headers in the message. [RFC2822] contains a detailed specification of all of the relevant headers. I think this is the wrong approach, particularly now we have split out PRA from Sender ID, and it might be used for other things, too. We should be defining an identity. Then we can comment on what it's useful for. I propose this should be replaced with: This document defines a new identity associated with a message, called the purported responsible address, which is determined by inspecting the header of the message. [RFC2822] contains a detailed specification of all of the relevant header fields. The purported responsible address is designed to correspond to the entity that (according to the header) most recently caused an e-mail message to be delivered. The algorithm for determining the purported responsible address from the header of a message is given in section 2. Also: For this reason, the result of the algorithm is called the "Purported Responsible Address" -- "purported" because it tells you what a message claims about where it came from, but not necessarily where it actually came from. I believe this paragraph should be deleted as it relates to one specific use of the PRA algorithm. The PRA algorithm may be of use in circumstances where the headers are known to be authentic. Indeed, [SUBMITTER] requires that the PRA algorithm be run by the sender as well as the recipient. (See also my separate post suggesting that we rename the purported responsible address so as to remove the word "purported") -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 15:26: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 PAA03150 for ; Sat, 4 Sep 2004 15:26: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 i84J6Q3r058627; Sat, 4 Sep 2004 12:06:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i84J6QHk058626; Sat, 4 Sep 2004 12:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84J6PJg058620 for ; Sat, 4 Sep 2004 12:06:26 -0700 (PDT) (envelope-from roy+dated+1096916791.e5e2c3@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84J7Uwv096739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 19:07:36 GMT (envelope-from roy+dated+1096916791.e5e2c3@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84J6V7C059897 for ; Sat, 4 Sep 2004 20:06:31 +0100 (BST) (envelope-from roy+dated+1096916791.e5e2c3@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84J6V8V059896 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 20:06:31 +0100 (BST) (envelope-from roy+dated+1096916791.e5e2c3@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 20:06:30 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16698.4661.986792.418657@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 20:06:29 +0100 To: Andrew Newton Cc: IETF MARID WG Subject: Re: Extension of Sender ID working group last call In-Reply-To: <5B6D5450-FDF0-11D8-B6CF-000A95B3BA44@hxr.us> References: <5B6D5450-FDF0-11D8-B6CF-000A95B3BA44@hxr.us> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It might also be helpful if you are in a position to identify any significant items on which the co-chairs believe there is a rough concensus for a change, lest silence be mistaken for agreement (rather than simply a sign of e-mail overload). -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 15:26: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 PAA03184 for ; Sat, 4 Sep 2004 15:26: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 i84J1mXd058401; Sat, 4 Sep 2004 12: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 i84J1mDl058400; Sat, 4 Sep 2004 12:01:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84J1l3L058394 for ; Sat, 4 Sep 2004 12:01:47 -0700 (PDT) (envelope-from roy+dated+1096916512.e160ae@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84J2qbr096424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 19:02:57 GMT (envelope-from roy+dated+1096916512.e160ae@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84J1qZ8059813 for ; Sat, 4 Sep 2004 20:01:52 +0100 (BST) (envelope-from roy+dated+1096916512.e160ae@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84J1qb0059806 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 20:01:52 +0100 (BST) (envelope-from roy+dated+1096916512.e160ae@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 20:01:52 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16698.4383.741239.971772@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 20:01:51 +0100 To: Roy Badami Cc: ietf-mxcomp@imc.org Subject: DOC-BUG: -pra intro In-Reply-To: <16698.4157.543727.884195@giles.gnomon.org.uk> References: <16698.4157.543727.884195@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Also: This document does not prescribe any particular uses for the Purported Responsible Address. However, [SenderID] describes a method of determining whether a particular MTA is authorized to send mail on behalf of the domain contained in the PRA. This paragraph should also reference [SUBMITTER] -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 15:57: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 PAA04446 for ; Sat, 4 Sep 2004 15:57: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 i84JYgXE059972; Sat, 4 Sep 2004 12:34:42 -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 i84JYgHM059971; Sat, 4 Sep 2004 12:34:42 -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 i84JYfDx059959 for ; Sat, 4 Sep 2004 12:34:41 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id CCF9940E0 for ; Sat, 4 Sep 2004 12:34:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <16697.65390.802720.119471@giles.gnomon.org.uk> References: <16697.65390.802720.119471@giles.gnomon.org.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7AD310AB-FEA9-11D8-BB96-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: TECH-ERROR: Name of SPF2 record Date: Sat, 4 Sep 2004 12:34:47 -0700 To: IETF MARID WG 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 Sep 4, 2004, at 10:46 AM, Roy Badami wrote: > I propose that the record simply be called SPF. This has been proposed several times on this list before. Since I have seen only only dissent from the idea, assuming the chairs agree that there is general consensus on this, I'll make this change. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 15:58: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 PAA04465 for ; Sat, 4 Sep 2004 15:58:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84JYnMO059988; Sat, 4 Sep 2004 12:34: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 i84JYnSw059987; Sat, 4 Sep 2004 12:34:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84JYmPa059963 for ; Sat, 4 Sep 2004 12:34:49 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: (from hadmut@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) id i84JYnR6009465; Sat, 4 Sep 2004 21:34:49 +0200 From: Hadmut Danisch Date: Sat, 4 Sep 2004 21:34:49 +0200 To: Andrew Newton Cc: IETF MARID WG Subject: Re: consensus call of RR prefix Message-ID: <20040904193449.GA9176@danisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 03, 2004 at 05:32:22PM -0400, Andrew Newton wrote: > > Therefore, that leaves one under-discussed question: should a prefix be > used to avoid collision with other records as one measure of preventing > the requirement of DNS over TCP? There are still good reasons to have a prefix. A method like MARID (whatever it will be) is not limited to e-mail only. It can be used for other services (e.g. chat) as well to verify identity descriptors derived from domain names. If there ever will be another use of MARID, collision should be avoided (which could be resolved by omitting the prefix for e-mail and using a prefix for any other service, but this is not a good design). On the other hand, in about 10 years of handling DNS I can remember only a single case where someone actually used wildcards. DNS server also need to support the underscore for the SRV RR type. So I'd prefer a prefix. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 16:09:11 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 QAA04788 for ; Sat, 4 Sep 2004 16:09: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 i84JjnAh061191; Sat, 4 Sep 2004 12:45: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 i84JjnbP061190; Sat, 4 Sep 2004 12:45:49 -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 i84Jjl6x061182 for ; Sat, 4 Sep 2004 12:45:49 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 72C1340E0 for ; Sat, 4 Sep 2004 12:45:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <077532AD-FEAB-11D8-BB96-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: consensus call on MUST/SHOULD language for TXT records Date: Sat, 4 Sep 2004 12:45:52 -0700 To: IETF MARID WG 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 Sep 3, 2004, at 2:33 PM, Andrew Newton wrote: > Despite lack of agreement on the outcome, there is agreement on the > stated positions. In the words of Olafur: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant > state during phase-in. My preference is for position 2. I am also strongly against other options with explicit phase-in periods and sunset-dates. As has been eloquently argued by Doug Crocker, such language in RFCs has a bad track record of working out, and so is best dispensed with. Options which drop the new SPF2 RR type altogether are not likely to sit well with the rest of the IETF community, specifically the DNS-EXT folks. The will reasonably argue that DNS has a well designed extension mechanism in the allocation of RR types, and it should be used, rather than overloading the TXT type. Options which drop the TXT RR type are not practical as there are some significant barriers to using a new RR type in some software environments. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 16:17: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 QAA05219 for ; Sat, 4 Sep 2004 16:17: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 i84JsuSm061537; Sat, 4 Sep 2004 12:54: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 i84Jsu1k061536; Sat, 4 Sep 2004 12:54:56 -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 i84Jsuwu061529 for ; Sat, 4 Sep 2004 12:54:56 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 8734A40E0 for ; Sat, 4 Sep 2004 12:55:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4EBE4E62-FEAC-11D8-BB96-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: consensus call of RR prefix Date: Sat, 4 Sep 2004 12:55:01 -0700 To: IETF MARID WG 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 My position on the prefix issue is that, since the right way to do things is to publish SPF2 RR records at the domain itself, we should put the TXT records there as well. While it might make for less clutter to put the TXT records at some sub-domain such as _spf, it would be inconsistent with where the SPF2 RR goes. Further, using sub-domains appears to be a significant barrier to publishing for domains that use existing domain hosting services. Lastly, from previous technical discussion, it is clear that use of a sub-domain doesn't improve the wild-card situation at all, nor allow any information to be removed from the version string. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 17:01: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 RAA06948 for ; Sat, 4 Sep 2004 17:01: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 i84Ke7en063854; Sat, 4 Sep 2004 13:40: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 i84Ke72i063853; Sat, 4 Sep 2004 13:40:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84Ke6PW063847 for ; Sat, 4 Sep 2004 13:40:06 -0700 (PDT) (envelope-from roy+dated+1096922411.0304a0@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84KfC8W004072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 20:41:17 GMT (envelope-from roy+dated+1096922411.0304a0@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84KeB5U060440 for ; Sat, 4 Sep 2004 21:40:11 +0100 (BST) (envelope-from roy+dated+1096922411.0304a0@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84KeBT4060439 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 21:40:11 +0100 (BST) (envelope-from roy+dated+1096922411.0304a0@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 21:40:10 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16698.10282.16684.111611@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 21:40:10 +0100 To: Mark Lentczner Cc: IETF MARID WG Subject: Re: TECH-ERROR: Name of SPF2 record In-Reply-To: <7AD310AB-FEA9-11D8-BB96-000393A56BB6@glyphic.com> References: <16697.65390.802720.119471@giles.gnomon.org.uk> <7AD310AB-FEA9-11D8-BB96-000393A56BB6@glyphic.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Mark" == Mark Lentczner writes: Mark> Since I have seen only only dissent from the idea, assuming Mark> the chairs agree that there is general consensus on this, Mark> I'll make this change. I'm assume there must be a typo in the above :-) -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 17:24:51 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 RAA07589 for ; Sat, 4 Sep 2004 17:24: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 i84L1POF066940; Sat, 4 Sep 2004 14:01: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 i84L1PXM066939; Sat, 4 Sep 2004 14:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84L1OPB066933 for ; Sat, 4 Sep 2004 14:01:25 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so139097rnk for ; Sat, 04 Sep 2004 14:01:32 -0700 (PDT) Received: by 10.38.74.61 with SMTP id w61mr651296rna; Sat, 04 Sep 2004 14:01:32 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Sat, 4 Sep 2004 14:01:32 -0700 (PDT) Message-ID: <94df60cf04090414016e4ca085@mail.gmail.com> Date: Sat, 4 Sep 2004 17:01:32 -0400 From: Reply-To: To: Roy Badami Subject: Re: DOC-BUG: Terminology: Purported Responsible Address Cc: ietf-mxcomp@imc.org In-Reply-To: <16698.394.983773.516925@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16698.394.983773.516925@giles.gnomon.org.uk> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 4 Sep 2004 18:55:22 +0100, Roy Badami wrote: > > I therefore suggest that the term Primary Responsible Address would be > more appropriate. I think the term Primary would be unfortunate, because in a lot of settings, the PRA doesn't really equate to people's intuitive notion of primary address. Right now it just happens to be the only one you can verify with sender ID. It the long run, I hope future standards bring us a way to verify not just the preceding hop, but multiple hops going back to the original sender. For example, say user@mit.edu sends mail to me at xxx@acm.org, and this forwards to me@nyu.edu. The mail will probably arrive at NYU with a PRA of "forwarding-service@acm.org" or similar. However, in some sense, the primary responsible address for this email is really user@mit.edu. While Sender ID alone won't let me verify user@mit.edu, in the future I hope there will be some automatic way of saying, "I trust the ACM as a forwarder, tell me who is really primarily responsible for the mail." Can we choose a name name that implies going back one hop, but not necessarily to the "primary" address. How about "Preceding Responsible Address" or better "Previous Responsible Address." David From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 17:27: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 RAA07662 for ; Sat, 4 Sep 2004 17:27:32 -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 i84L7DpH067615; Sat, 4 Sep 2004 14:07:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i84L7DLd067614; Sat, 4 Sep 2004 14:07:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84L7CTY067608 for ; Sat, 4 Sep 2004 14:07:13 -0700 (PDT) (envelope-from roy+dated+1096924038.b2d8cf@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84L8Jcu006167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Sep 2004 21:08:24 GMT (envelope-from roy+dated+1096924038.b2d8cf@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i84L7IQW060872 for ; Sat, 4 Sep 2004 22:07:18 +0100 (BST) (envelope-from roy+dated+1096924038.b2d8cf@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i84L7INb060865 for ietf-mxcomp@imc.org; Sat, 4 Sep 2004 22:07:18 +0100 (BST) (envelope-from roy+dated+1096924038.b2d8cf@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 04 Sep 2004 22:07:17 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16698.11908.824283.856445@giles.gnomon.org.uk> Date: Sat, 4 Sep 2004 22:07:16 +0100 To: Cc: Roy Badami , ietf-mxcomp@imc.org Subject: Re: DOC-BUG: Terminology: Purported Responsible Address In-Reply-To: <94df60cf04090414016e4ca085@mail.gmail.com> References: <16698.394.983773.516925@giles.gnomon.org.uk> <94df60cf04090414016e4ca085@mail.gmail.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "mazieres" == writes: mazieres> I think the term Primary would be unfortunate, because mazieres> in a lot of settings, the PRA doesn't really equate to mazieres> people's intuitive notion of primary address. Agreed; it was just the best I could come up with that kept the acronym PRA (not that that's essential) mazieres> How about "Preceding Responsible Address" or better mazieres> "Previous Responsible Address." I like both of those. Ultimately it's just a name, and I don't _really_ care what it is. I can happily live with 'purported responsible address' as long as we accept that it is simply the name for this identity, and not just a term we use to refer to an (as yet unnamed) underlying concept when we're unsure of its accuracy. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 17:39: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 RAA08114 for ; Sat, 4 Sep 2004 17:39:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84LFvYo069131; Sat, 4 Sep 2004 14:15: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 i84LFvDD069130; Sat, 4 Sep 2004 14:15:57 -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 i84LFuTg069124 for ; Sat, 4 Sep 2004 14:15:56 -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 i84LPxJ7025273; Sat, 4 Sep 2004 14:25:59 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i84LPxtv025270; Sat, 4 Sep 2004 14:25:59 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 4 Sep 2004 14:25:59 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call of RR prefix 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, 3 Sep 2004, Andrew Newton wrote: > From the discussion on prefixes for the DNS record, there seems to have > been no discernible outcome regarding the use of prefixes for the > purposes of avoiding collisions with other DNS records (thus avoiding > fallback to DNS over TCP). > > Naturally, this issue wraps itself into both the versioning/scoping > issue and the wildcard issue. Based on the comments received so far, > it is the opinion of the co-chairs that there is no consensus on how to > handle wildcards and that most participants seem to agree that > wildcards present a problem no matter the solution. Based on the > comments received so far, it is the opinion of the co-chairs that there > is consensus on placing the "scope" in the RDATA of the record and no > consensus on the scope being in the prefix. > > Therefore, that leaves one under-discussed question: should a prefix be > used to avoid collision with other records as one measure of preventing > the requirement of DNS over TCP? I'm not very strongly in favor or against using dns prefixes for TXT record placement (my preference as indicated at the very end of message and it depends on other factors), but I'd like to summarize current arguments and points for and against using subdomain prefixes and explain how it all works so that others that are new to this can decide on their own. As a reminder, in these posts: http://www.imc.org/ietf-mxcomp/mail-archive/msg03726.html http://www.imc.org/ietf-mxcomp/mail-archive/msg03762.html I sucessfully argued that because of how wildcards work (or don't work :) scoping can not rely on prefixes alone and version and scope must be part of data portion (this chairs agree with as per their statemenet above). It can be noted that original thread discussion about using or not using prefixes started from problems that may exist when user does want to publish two types of SPF records (with presumably different version strings), like: (*1*) example.com. IN TXT "v=spf1 ..." example.com. IN TXT "spf2.0/pra ..." ------------------------------ Option1 ------------------------------ Since total size of RDATA space in udp dns packet is limited to approximately 480 bytes, each of the records from (*1*) would have to be smaller and be half that (up to say max 200 bytes to be safe), it has been said that is too small and hence using dns prefixes/subdomains was proposed, like: (*2*) _mfrom._rmx.example.com. IN TXT "v=spf1 ..." _pra._rmx.example.com. IN TXT "spf2.0/pra ..." However same wildcard problem I have pointed out applies here, names that in case of wildcards, no matter if there are prefixes or not, you would have to put wildcard records in the root of the domain and thus have this limitation with size of records: (*3*) *.example.com. IN TXT "v=spf1 ..." *.example.com. IN TXT "spf2.0/pra ..." But as has been pointed out to me by David Blacka, that prefixes dont work with specific case of wildcards, doesnt mean its bad for everyone else and use of wildcards is in general pretty rare, so we should not discard usefullness of scenario (*2*) just because of wildcards. I agreed with that in this message: http://www.imc.org/ietf-mxcomp/mail-archive/msg03963.html But have pointed out that there is another problem that we may have and that has to do with number of dns requests. In case like (*1*) when all SPF records are located in the root of zone, in order to see all the mail policies for different identities/scopes. a verification client program would only need to make one dns request for TXT record under that domain. But if we go with different prefixes for each scope as with (*2*), then client program would have to normally make two dns requests for each of those identities (i.e. for _pra._rmx and for _mfrom._rmx). It can be noted that if identities have the same SPF record (and Mark Lentczner has pointed out that for most situations SenderID/PRA and SPF-Classic/Mail-From records are likely to be the same) then we maybe able to deal with this by having records like: (*4*) _mfrom._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24 _pra._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24 In that case a program looking pra or mailfrom identity scoping record (which it does first does not matter if records are the same) would get the record indicating that the other identity is equivalent and would presumably not have to do an extra dns lookup. However this does lead to situation of having to enter and maintain two different but completely equivalent (as far as RDATA) TXT records. I'll note that to support programs checking SPFv1 records, additional record may have to be added (also equivalent), so we would have: (*5*) _mfrom._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24 _pra._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24 example.com. IN TXT "v=spf1 ip4:10.0.0.0/24 ~all" ------------------------------ Option2 ------------------------------ Another option maybe to place SPF TXT records in the same prefix no matter what identity/scope this is, which allows to avoid collision with other TXT records that may exist for the domain/host: (*6*) _rmx.example.com. IN TXT "spf2.0/mfrom ..." _rmx.example.com. IN TXT "spf2.0/pra ..." In that case it is not necessary to make an extra dns lookups for multiple identity records, nor is it necessary to have two separate records when they are the same, as the following will work just fine: _rmx.example.com. IN TXT "spf2.0/pra,mfrom ..." However, this does mean that in case the two records are seriously different size limitations would apply (since records share the same prefix) and records would have to be limited to half of what they could have been. Solution to this involves doing redirection, which would lead to 2nd dns lookup: (*7*) _rmx.example.com. IN TXT "spf2.0/pra redirect=_pra._rmx.example.com _rmx.example.com. IN TXT "spf2.0/mfrom redirect=_mfrom._rmx.example.com _pra._rmx.example.com. IN TXT "spf2.0/pra ...." _pra._mfrom.example.com. IN TXT "spf2.0/pra ...." Additionally I'll note that there exist another possible plus side that applies to how wildcards are entered. Because of how wildcards work normally you need to have two separate records when using wildcards - one for domain itself and one wildcard for all subdomains: (*8*) example.com. IN TXT "v=spf1 ..." example.com. IN TXT "spf2.0/pra ..." *.example.com. IN TXT "v=spf1 ..." *.example.com. IN TXT "spf2.0/pra ..." In above the first two records apply to example.com itself while the 2nd two apply to any subdomain under it (i.e. xxxx.example.com or even futher down the tree like a.b.c.example.com) and normally these two would be the same, but entering wildcard seems to lead to duplicate entries. But when using prefixes (and this applies to option 1 as well), we only need to have one record: (*9*) *.example.com. IN TXT "v=spf1 ..." *.example.com. IN TXT "spf2.0/pra ..." And this record would equially apply to both _rmx.example.com and to _rmx.xxx.example.com or to _rmx.a.b.c.example.com, etc. ------------------------------ Summary ------------------------------ So we have several options: Option1 is using prefixes with different one for each scope/identity Option2 is using prefixes but with same prefix no matter what spf scope Option3 is not using prefixes at all (SPF2 TXT record in zone root) Option4 is not using prefixes, nor even using new SPF2 version (in that case scoping is achieved by using scope modifier with v=SPF1 record) For Option1 the PROs are: 1. Avoids collision with other TXT records for domain 2. Avoids collision with different TXT records (except for wildcards) and thus avoids record size limit for different spf scope records 3. Allows to specify wildcard entry for subdomain & domain using one record The CONs are: 1. Requires multiple dns lookups if SPF records for different scopes are different (no matter what size these records are) 2. Requires multiple dns records if SPF records for different scopes are the same (no matter what size these records are) 3. Requires separate SPFv1 records and dns lookup to support existing SPVv1 resolvers and libraries For Option2 the PROs are: 1. Avoids collision with other TXT records for domain 2. Allows to specify wildcard entry for subdomain & domain using one record 3. Allows to specify multiple scopes together in one record when they are same 4. Does not require separate dns lookups for different scope records no matter if they are different or the same The CONs are: 1. Requires multuple dns lookups to avoid size limitations if multiple scope SPF records are different and are large 2. Requires separate SPFv1 records and dns lookup to support existing SPVv1 resolvers and libraries For Option3 the PROs are: 1. Allows to specify multiple scopes together in one record when they are same 2. Does not require separate dns lookups for different scope records no matter if they are different or the same 3. Does not require separate dns lookups for SPFv1 records (but normally you would not need to do it anyway) The CONs are: 1. Collision problems with other (non-SPF) TXT records for the domain 2. Requires multuple dns lookups to avoid size limitations if multiple scope SPF records are different and are large 3. Requires multiple records to specify wildcard for domain & subdomains 3. Requires separate SPFv1 records and dns lookup to support existing SPFv1 libraries and resolvers For Option4 the PROs are: 1. Allows to specify multiple scopes together in one record when they are same 2. Does not require separate dns lookups for different scope records no matter if they are different or the same 3. Does not require separate dns lookups for SPFv1 records and fully supports existing SPVv1 libraries and resolvers with one record The CONs are: 1. Collision problems with other (non-SPF) TXT records for the domain 2. Requires multuple dns lookups to avoid size limitations if multiple scope SPF records are different and are large (*) 3. Requires multiple records to specify wildcard for domain & subdomains (*) I note that when using scoping modifier, different scope records can have shared data parts all in one SPF record and this allows for smaller size of records and avoids size limitations and necessity to do 2nd dns lookup in majority of situations. For more info see: http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html http://www.imc.org/ietf-mxcomp/mail-archive/msg03716.html http://www.imc.org/ietf-mxcomp/mail-archive/msg03731.html ------------------------------ In my opinion a lot depends on if we consider supporting existing installed SPF v1 base important or not and consider that people using existing libraries and publishing spfv1 records can upgrade quickly to new spf2 records or not. If we do want to support SPFv1 base as much as possible and think that new scope for mailfrom will be deployed along with SPF1 records (and hence programs like spamassasin would do lookups for both for considerable time), then option4 is the best one and completely avoids these issues. On the other hand if we think that transition to SPF2 records would be quick and nobody would do SPF1 lookups in say one year time, then to me option2 (common prefix for all spf records) looks like the best one because compared to option3 (no prefixes) it has the following advantages: 1. Avoids collision with other TXT record for domain 2. Allows to specify wildcard entry for subdomain & domain using one record As far as everything else it is pretty much same as option3, with exception that possibly some bad dns gui programs do not allow to enter "_" records (but all dns servers support this just fine). And in my opinion option1 (separate prefixes for different scopes) is the worst one because it leads to either multiple dns records or multiple dns lookups and those exist no matter if record is large or small and so would effect absolutely everybody. > Incidentally, the co-chairs note that many examples of the prefix have > used "-marid". We would note that "MARID" is the name of this working > group and likely not meaningful beyond the context of discussions and > process of this working group. Therefore we recommend a more > meaningful label such as "_rmx": the deduction of its meaning is easier > and it references the genesis of the MARID idea. I have no strong preference as far as prefix name, but I would like to note that _rmx has meaning if we're talking about MAIL-FROM identity SPF scope records but in general SPF records might apply to different identities (for example PTR scope from unified SPF) and might not not be related to mail-from or RMX at all. So I think general prefix such as _spf might be better. But I have complied with chair's request and have used _rmx in all above examples. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 17:58:23 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 RAA08683 for ; Sat, 4 Sep 2004 17:58:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i84LaKjZ069835; Sat, 4 Sep 2004 14:36:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i84LaKXq069834; Sat, 4 Sep 2004 14:36:20 -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 i84LaJK9069825 for ; Sat, 4 Sep 2004 14:36:19 -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 i84LkP1H026526; Sat, 4 Sep 2004 14:46:25 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i84LkPGx026522; Sat, 4 Sep 2004 14:46:25 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 4 Sep 2004 14:46:25 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call of RR prefix 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: Also I would like to add that I support having common "mail policy" prefix for SPF RR type refords as well. As with arguments for option2, this helps with wildcards (no extra duplicate entries) and it allows to in the future extend use of SPF to be general policy language for other protocols but would avoid collision with existing mail policy base (except in case of wildcards, but there redirection can be used if records get too large all together). So in this case, we need to use protocol specific name as part of prefix, something like: _smtp.example.com. IN TXT "spf2.0/pra,mfrom ..." _smtp.example.com. IN SPF "spf2.0/pra,mfrom ..." Or possibly: _smtp._spf.example.com. IN TXT "spf2.0/pra,mfrom ..." _smtp.example.com. IN SPF "spf2.0/pra,mfrom ..." On Sat, 4 Sep 2004, william(at)elan.net wrote: > On Fri, 3 Sep 2004, Andrew Newton wrote: > > > From the discussion on prefixes for the DNS record, there seems to have > > been no discernible outcome regarding the use of prefixes for the > > purposes of avoiding collisions with other DNS records (thus avoiding > > fallback to DNS over TCP). > > > > Naturally, this issue wraps itself into both the versioning/scoping > > issue and the wildcard issue. Based on the comments received so far, > > it is the opinion of the co-chairs that there is no consensus on how to > > handle wildcards and that most participants seem to agree that > > wildcards present a problem no matter the solution. Based on the > > comments received so far, it is the opinion of the co-chairs that there > > is consensus on placing the "scope" in the RDATA of the record and no > > consensus on the scope being in the prefix. > > > > Therefore, that leaves one under-discussed question: should a prefix be > > used to avoid collision with other records as one measure of preventing > > the requirement of DNS over TCP? > > I'm not very strongly in favor or against using dns prefixes for TXT record > placement (my preference as indicated at the very end of message and it > depends on other factors), but I'd like to summarize current arguments > and points for and against using subdomain prefixes and explain how it > all works so that others that are new to this can decide on their own. > > As a reminder, in these posts: > http://www.imc.org/ietf-mxcomp/mail-archive/msg03726.html > http://www.imc.org/ietf-mxcomp/mail-archive/msg03762.html > I sucessfully argued that because of how wildcards work (or don't work :) > scoping can not rely on prefixes alone and version and scope must be part > of data portion (this chairs agree with as per their statemenet above). > > It can be noted that original thread discussion about using or not using > prefixes started from problems that may exist when user does want to publish > two types of SPF records (with presumably different version strings), like: > (*1*) example.com. IN TXT "v=spf1 ..." > example.com. IN TXT "spf2.0/pra ..." > > ------------------------------ > Option1 > ------------------------------ > > Since total size of RDATA space in udp dns packet is limited to approximately > 480 bytes, each of the records from (*1*) would have to be smaller and be > half that (up to say max 200 bytes to be safe), it has been said that is > too small and hence using dns prefixes/subdomains was proposed, like: > (*2*) _mfrom._rmx.example.com. IN TXT "v=spf1 ..." > _pra._rmx.example.com. IN TXT "spf2.0/pra ..." > > However same wildcard problem I have pointed out applies here, names that > in case of wildcards, no matter if there are prefixes or not, you would > have to put wildcard records in the root of the domain and thus have > this limitation with size of records: > (*3*) *.example.com. IN TXT "v=spf1 ..." > *.example.com. IN TXT "spf2.0/pra ..." > > But as has been pointed out to me by David Blacka, that prefixes dont work > with specific case of wildcards, doesnt mean its bad for everyone else > and use of wildcards is in general pretty rare, so we should not discard > usefullness of scenario (*2*) just because of wildcards. > > I agreed with that in this message: > http://www.imc.org/ietf-mxcomp/mail-archive/msg03963.html > But have pointed out that there is another problem that we may have and > that has to do with number of dns requests. In case like (*1*) when all > SPF records are located in the root of zone, in order to see all the > mail policies for different identities/scopes. a verification client > program would only need to make one dns request for TXT record under that > domain. But if we go with different prefixes for each scope as with (*2*), > then client program would have to normally make two dns requests for each > of those identities (i.e. for _pra._rmx and for _mfrom._rmx). > > It can be noted that if identities have the same SPF record (and Mark > Lentczner has pointed out that for most situations SenderID/PRA and > SPF-Classic/Mail-From records are likely to be the same) then we maybe > able to deal with this by having records like: > (*4*) _mfrom._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24 > _pra._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24 > > In that case a program looking pra or mailfrom identity scoping record > (which it does first does not matter if records are the same) would > get the record indicating that the other identity is equivalent and would > presumably not have to do an extra dns lookup. However this does lead to > situation of having to enter and maintain two different but completely > equivalent (as far as RDATA) TXT records. > > I'll note that to support programs checking SPFv1 records, additional record > may have to be added (also equivalent), so we would have: > (*5*) _mfrom._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24 > _pra._rmx.example.com. IN TXT "spf2.0/pra,mfrom ip4:10.0.0.0/24 > example.com. IN TXT "v=spf1 ip4:10.0.0.0/24 ~all" > > ------------------------------ > Option2 > ------------------------------ > > Another option maybe to place SPF TXT records in the same prefix no matter > what identity/scope this is, which allows to avoid collision with other > TXT records that may exist for the domain/host: > (*6*) _rmx.example.com. IN TXT "spf2.0/mfrom ..." > _rmx.example.com. IN TXT "spf2.0/pra ..." > > In that case it is not necessary to make an extra dns lookups for multiple > identity records, nor is it necessary to have two separate records when > they are the same, as the following will work just fine: > _rmx.example.com. IN TXT "spf2.0/pra,mfrom ..." > > However, this does mean that in case the two records are seriously different > size limitations would apply (since records share the same prefix) and records > would have to be limited to half of what they could have been. Solution > to this involves doing redirection, which would lead to 2nd dns lookup: > (*7*) _rmx.example.com. IN TXT "spf2.0/pra redirect=_pra._rmx.example.com > _rmx.example.com. IN TXT "spf2.0/mfrom redirect=_mfrom._rmx.example.com > _pra._rmx.example.com. IN TXT "spf2.0/pra ...." > _pra._mfrom.example.com. IN TXT "spf2.0/pra ...." > > Additionally I'll note that there exist another possible plus side that > applies to how wildcards are entered. Because of how wildcards work normally > you need to have two separate records when using wildcards - one for domain > itself and one wildcard for all subdomains: > (*8*) example.com. IN TXT "v=spf1 ..." > example.com. IN TXT "spf2.0/pra ..." > *.example.com. IN TXT "v=spf1 ..." > *.example.com. IN TXT "spf2.0/pra ..." > In above the first two records apply to example.com itself while the 2nd > two apply to any subdomain under it (i.e. xxxx.example.com or even futher > down the tree like a.b.c.example.com) and normally these two would be the > same, but entering wildcard seems to lead to duplicate entries. > > But when using prefixes (and this applies to option 1 as well), we only need > to have one record: > (*9*) *.example.com. IN TXT "v=spf1 ..." > *.example.com. IN TXT "spf2.0/pra ..." > > And this record would equially apply to both _rmx.example.com and to > _rmx.xxx.example.com or to _rmx.a.b.c.example.com, etc. > > ------------------------------ > Summary > ------------------------------ > > So we have several options: > Option1 is using prefixes with different one for each scope/identity > Option2 is using prefixes but with same prefix no matter what spf scope > Option3 is not using prefixes at all (SPF2 TXT record in zone root) > Option4 is not using prefixes, nor even using new SPF2 version (in that > case scoping is achieved by using scope modifier with v=SPF1 record) > > For Option1 the PROs are: > 1. Avoids collision with other TXT records for domain > 2. Avoids collision with different TXT records (except for wildcards) > and thus avoids record size limit for different spf scope records > 3. Allows to specify wildcard entry for subdomain & domain using one record > The CONs are: > 1. Requires multiple dns lookups if SPF records for different scopes > are different (no matter what size these records are) > 2. Requires multiple dns records if SPF records for different scopes > are the same (no matter what size these records are) > 3. Requires separate SPFv1 records and dns lookup to support existing > SPVv1 resolvers and libraries > > For Option2 the PROs are: > 1. Avoids collision with other TXT records for domain > 2. Allows to specify wildcard entry for subdomain & domain using one record > 3. Allows to specify multiple scopes together in one record when they are same > 4. Does not require separate dns lookups for different scope records no > matter if they are different or the same > The CONs are: > 1. Requires multuple dns lookups to avoid size limitations if multiple > scope SPF records are different and are large > 2. Requires separate SPFv1 records and dns lookup to support existing > SPVv1 resolvers and libraries > > For Option3 the PROs are: > 1. Allows to specify multiple scopes together in one record when they are same > 2. Does not require separate dns lookups for different scope records no > matter if they are different or the same > 3. Does not require separate dns lookups for SPFv1 records > (but normally you would not need to do it anyway) > The CONs are: > 1. Collision problems with other (non-SPF) TXT records for the domain > 2. Requires multuple dns lookups to avoid size limitations if multiple > scope SPF records are different and are large > 3. Requires multiple records to specify wildcard for domain & subdomains > 3. Requires separate SPFv1 records and dns lookup to support existing > SPFv1 libraries and resolvers > > For Option4 the PROs are: > 1. Allows to specify multiple scopes together in one record when they are same > 2. Does not require separate dns lookups for different scope records no > matter if they are different or the same > 3. Does not require separate dns lookups for SPFv1 records and fully > supports existing SPVv1 libraries and resolvers with one record > The CONs are: > 1. Collision problems with other (non-SPF) TXT records for the domain > 2. Requires multuple dns lookups to avoid size limitations if multiple > scope SPF records are different and are large (*) > 3. Requires multiple records to specify wildcard for domain & subdomains > > (*) I note that when using scoping modifier, different scope records can > have shared data parts all in one SPF record and this allows for smaller > size of records and avoids size limitations and necessity to do 2nd > dns lookup in majority of situations. For more info see: > http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html > http://www.imc.org/ietf-mxcomp/mail-archive/msg03716.html > http://www.imc.org/ietf-mxcomp/mail-archive/msg03731.html > > ------------------------------ > > In my opinion a lot depends on if we consider supporting existing installed > SPF v1 base important or not and consider that people using existing libraries > and publishing spfv1 records can upgrade quickly to new spf2 records or not. > > If we do want to support SPFv1 base as much as possible and think that new > scope for mailfrom will be deployed along with SPF1 records (and hence > programs like spamassasin would do lookups for both for considerable time), > then option4 is the best one and completely avoids these issues. > > On the other hand if we think that transition to SPF2 records would be quick > and nobody would do SPF1 lookups in say one year time, then to me option2 > (common prefix for all spf records) looks like the best one because compared > to option3 (no prefixes) it has the following advantages: > 1. Avoids collision with other TXT record for domain > 2. Allows to specify wildcard entry for subdomain & domain using one record > As far as everything else it is pretty much same as option3, with exception > that possibly some bad dns gui programs do not allow to enter "_" records > (but all dns servers support this just fine). > > And in my opinion option1 (separate prefixes for different scopes) is the > worst one because it leads to either multiple dns records or multiple > dns lookups and those exist no matter if record is large or small and so > would effect absolutely everybody. > > > Incidentally, the co-chairs note that many examples of the prefix have > > used "-marid". We would note that "MARID" is the name of this working > > group and likely not meaningful beyond the context of discussions and > > process of this working group. Therefore we recommend a more > > meaningful label such as "_rmx": the deduction of its meaning is easier > > and it references the genesis of the MARID idea. > > I have no strong preference as far as prefix name, but I would like to > note that _rmx has meaning if we're talking about MAIL-FROM identity > SPF scope records but in general SPF records might apply to different > identities (for example PTR scope from unified SPF) and might not not be > related to mail-from or RMX at all. So I think general prefix such > as _spf might be better. But I have complied with chair's request and > have used _rmx in all above examples. > > --- > William Leibzon, Elan Networks: > mailto: william@elan.net > Anti-Spam Research Worksite: > http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 22:06: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 WAA19731 for ; Sat, 4 Sep 2004 22:06: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 i851hsPS085683; Sat, 4 Sep 2004 18:43:54 -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 i851hs9L085682; Sat, 4 Sep 2004 18:43:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i851hr4F085676 for ; Sat, 4 Sep 2004 18:43:53 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3m2w-0000j9-VX; Sat, 04 Sep 2004 21:42:23 -0400 Message-ID: <413A6F5F.7070503@solidmatrix.com> Date: Sat, 04 Sep 2004 21:43:59 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: John R Levine CC: Rand Wacker , "ietf-mxcomp@imc.org" Subject: Re: RR prefix is not useful References: <20040904151225.26631.qmail@xuxa.iecc.com> <4139ED1C.7050704@sendmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John R Levine wrote: >>>If specific nodes do get >>>overloaded, SPF and Sender-ID both let you use a short record pointing >>>to a longer record somewhere else as a band-aid. >> >>That's a fine workaround, but even *those* records will get caught by >>wildcards. Wildcards won't work. > > > I don't see how repeating this claim makes it any more persuasive. All > the records I know about can use the short pointer band-aid, and it looks > easy enough to have five or six band-aid records and still fit in a UDP > packet. What am I missing? I realize that a hundred TXT records won't > fit, but I don't see more than about four TXT record applications showing > up any time soon. > If Sender-ID sucessfully uses a combination of TXT records and new RR type, then other new protocols may follow the same advice. That can quickly add up. Yakov From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 22:07: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 WAA19807 for ; Sat, 4 Sep 2004 22:07: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 i851lK8o085811; Sat, 4 Sep 2004 18:47:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i851lKAj085810; Sat, 4 Sep 2004 18:47:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i851lJlQ085804 for ; Sat, 4 Sep 2004 18:47:19 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3m6G-0000w0-U2; Sat, 04 Sep 2004 21:45:49 -0400 Message-ID: <413A702D.6070202@solidmatrix.com> Date: Sat, 04 Sep 2004 21:47:25 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Mark Lentczner CC: IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records References: <077532AD-FEAB-11D8-BB96-000393A56BB6@glyphic.com> In-Reply-To: <077532AD-FEAB-11D8-BB96-000393A56BB6@glyphic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > > > On Sep 3, 2004, at 2:33 PM, Andrew Newton wrote: > >> Despite lack of agreement on the outcome, there is agreement on the >> stated positions. In the words of Olafur: >> 1) Specify everyone to be compliant at all times. >> 2) Specify clearly full complaint state and tolerate non-compliant >> state during phase-in. > > > My preference is for position 2. > > I am also strongly against other options with explicit phase-in periods > and sunset-dates. As has been eloquently argued by Doug Crocker, such > language in RFCs has a bad track record of working out, and so is best > dispensed with. > > Options which drop the new SPF2 RR type altogether are not likely to sit > well with the rest of the IETF community, specifically the DNS-EXT > folks. The will reasonably argue that DNS has a well designed extension > mechanism in the allocation of RR types, and it should be used, rather > than overloading the TXT type. > > Options which drop the TXT RR type are not practical as there are some > significant barriers to using a new RR type in some software environments. > Even within option two, we can specify that the RR type be looked at first, and the TXT second, if the RR is not found. This would clearly show that the RR type is prefered over TXT, but TXT is tolerated. Yakov From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 22:08: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 WAA19876 for ; Sat, 4 Sep 2004 22:08: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 i851mCg4085847; Sat, 4 Sep 2004 18:48: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 i851mCLd085846; Sat, 4 Sep 2004 18:48:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i851mB2f085838 for ; Sat, 4 Sep 2004 18:48:11 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3m77-0000yQ-Q8; Sat, 04 Sep 2004 21:46:42 -0400 Message-ID: <413A7062.3040100@solidmatrix.com> Date: Sat, 04 Sep 2004 21:48:18 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Hadmut Danisch CC: Andrew Newton , IETF MARID WG Subject: Re: consensus call of RR prefix References: <20040904193449.GA9176@danisch.de> In-Reply-To: <20040904193449.GA9176@danisch.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hadmut Danisch wrote: > On Fri, Sep 03, 2004 at 05:32:22PM -0400, Andrew Newton wrote: > >>Therefore, that leaves one under-discussed question: should a prefix be >>used to avoid collision with other records as one measure of preventing >>the requirement of DNS over TCP? > > > There are still good reasons to have a prefix. > > A method like MARID (whatever it will be) is not limited to > e-mail only. It can be used for other services (e.g. chat) as > well to verify identity descriptors derived from domain names. > > If there ever will be another use of MARID, collision should be > avoided (which could be resolved by omitting the prefix for > e-mail and using a prefix for any other service, but this is not > a good design). > I would add to that that others in the IETF may use MARID as a precendent to argue for the use of TXT record. This may quickly increase the possible number of them. Therefore, I am for the prefix as well. Yakov From owner-ietf-mxcomp@mail.imc.org Sat Sep 4 22:56: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 WAA19748 for ; Sat, 4 Sep 2004 22:06:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i851do3v085513; Sat, 4 Sep 2004 18:39:50 -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 i851doCP085512; Sat, 4 Sep 2004 18:39:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i851dnCu085503 for ; Sat, 4 Sep 2004 18:39:49 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C3lz1-0000bx-JS; Sat, 04 Sep 2004 21:38:19 -0400 Message-ID: <413A6E69.2020106@solidmatrix.com> Date: Sat, 04 Sep 2004 21:39:53 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Andrew Newton CC: IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records References: <4138EDE8.3020802@solidmatrix.com> <71A9B6DF-FE0A-11D8-9A6B-000A95B3BA44@hxr.us> In-Reply-To: <71A9B6DF-FE0A-11D8-9A6B-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > On Sep 3, 2004, at 6:19 PM, Yakov Shafranovich wrote: > >> I am not sure how #1 differs from #2? Are you suggesting that if we >> adopt position #1, someone not having SPF RR records would be ignored? > > > My interpretation of the thread is "might be ignored". > > -andy > Then I support #2 simply because I don't see how position #1 will be practical. Yakov From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 00:51:54 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 AAA26273 for ; Sun, 5 Sep 2004 00:51:54 -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 i854PQK6097502; Sat, 4 Sep 2004 21:25:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i854PQg9097501; Sat, 4 Sep 2004 21:25:26 -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 i854PP4d097485 for ; Sat, 4 Sep 2004 21:25:25 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id B666040E0 for ; Sat, 4 Sep 2004 21:25:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <7AD310AB-FEA9-11D8-BB96-000393A56BB6@glyphic.com> References: <16697.65390.802720.119471@giles.gnomon.org.uk> <7AD310AB-FEA9-11D8-BB96-000393A56BB6@glyphic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: TECH-ERROR: Name of SPF2 record Date: Sat, 4 Sep 2004 21:25:32 -0700 To: IETF MARID WG 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 > This has been proposed several times on this list before. Since I > have seen only only dissent from the idea, assuming the chairs agree > that there is general consensus on this, I'll make this change. Ach! Since I have seen only ** one ** dissent... - Mark From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 01:42:04 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 BAA28032 for ; Sun, 5 Sep 2004 01:41: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 i855Gwrw009367; Sat, 4 Sep 2004 22:16: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 i855GwZ5009366; Sat, 4 Sep 2004 22:16:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i855GwLd009302 for ; Sat, 4 Sep 2004 22:16:58 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Sep 2004 05:17:02 +0000 From: "Michael R. Brumm" To: "Andrew Newton" Cc: "IETF MARID WG" Subject: RE: consensus call of RR prefix Date: Sat, 4 Sep 2004 23:17:17 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 05 Sep 2004 05:17:02.0401 (UTC) FILETIME=[93A00B10:01C49307] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > Therefore, that leaves one under-discussed question: should a prefix be > used to avoid collision with other records as one measure of preventing > the requirement of DNS over TCP? No. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 01:45: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 BAA28138 for ; Sun, 5 Sep 2004 01:44: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 i855OeHB012257; Sat, 4 Sep 2004 22:24:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i855Oebb012256; Sat, 4 Sep 2004 22:24:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i855OdPS012212 for ; Sat, 4 Sep 2004 22:24:39 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Sep 2004 05:24:50 +0000 From: "Michael R. Brumm" To: "Andrew Newton" Cc: "IETF MARID WG" Subject: RE: consensus call on MUST/SHOULD language for TXT records Date: Sat, 4 Sep 2004 23:25:04 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 05 Sep 2004 05:24:50.0168 (UTC) FILETIME=[AA6F9F80:01C49308] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > Despite lack of agreement on the outcome, there is agreement on the > stated positions. In the words of Olafur: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant > state during phase-in. I vote for #2. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 03:47: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 DAA16172 for ; Sun, 5 Sep 2004 03:47: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 i857PF5f068111; Sun, 5 Sep 2004 00:25:15 -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 i857PFZP068110; Sun, 5 Sep 2004 00:25:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i857PFZT068103 for ; Sun, 5 Sep 2004 00:25:15 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i857PLE07450; Sun, 5 Sep 2004 00:25:21 -0700 Date: Sun, 5 Sep 2004 15:24:48 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1382105314.20040905152448@brandenburg.com> To: Andrew Newton CC: IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew, AN> 1) Specify everyone to be compliant at all times. AN> 2) Specify clearly full complaint state and tolerate non-compliant AN> state during phase-in. The concept of "phase-in" for Internet services -- especially ones that modify mission-critical, established services -- is measure in 5-10 year increments. For the purposes of IETF standards specification and -- even more importantly -- for operations planning, this is the same as saying "forever". So, the accurate semantics of the choices are: 1) Specify everyone to be compliant at all times 2) Specify clearly full compliant state, but tolerate non-compliance forever The second choice does, of course, lead the a small question: why bother with the concept of compliance? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 03:50:51 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 DAA16247 for ; Sun, 5 Sep 2004 03:50: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 i857P0Dt067999; Sun, 5 Sep 2004 00:25:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i857P0Li067998; Sun, 5 Sep 2004 00:25:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i857Ouat067956 for ; Sun, 5 Sep 2004 00:24:59 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sodom (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i857P6Xr021999; Sun, 5 Sep 2004 09:25:06 +0200 Received: (from hadmut@localhost) by sodom.home.danisch.de (8.12.11/8.12.11/Debian-5) id i857K5Mk003222; Sun, 5 Sep 2004 09:20:05 +0200 From: Hadmut Danisch Date: Sun, 5 Sep 2004 09:20:05 +0200 To: Yakov Shafranovich Cc: Andrew Newton , IETF MARID WG Subject: Re: consensus call of RR prefix Message-ID: <20040905072005.GA3179@danisch.de> References: <20040904193449.GA9176@danisch.de> <413A7062.3040100@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413A7062.3040100@solidmatrix.com> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 04, 2004 at 09:48:18PM -0400, Yakov Shafranovich wrote: > > I would add to that that others in the IETF may use MARID as a > precendent to argue for the use of TXT record. This may quickly increase > the possible number of them. Therefore, I am for the prefix as well. Correct. The reason to use a prefix is basically the same as to use the _service._tcp prefix for SRV records (which are used for good reasons). regards Hadmut From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 05:03: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 FAA18697 for ; Sun, 5 Sep 2004 05:03: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 i858bJ8k095365; Sun, 5 Sep 2004 01:37:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i858bJ5V095364; Sun, 5 Sep 2004 01:37:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miranda.server-plant.co.uk (miranda.server-plant.co.uk [193.110.88.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i858bHxV095322 for ; Sun, 5 Sep 2004 01:37:19 -0700 (PDT) (envelope-from johnp@idimo.com) Received: from idimo2 ([62.87.76.161]) (authenticated) by miranda.server-plant.co.uk (8.11.6/8.11.2) with ESMTP id i858bOT09656 for ; Sun, 5 Sep 2004 09:37:25 +0100 Message-ID: <02dc01c49323$9148c3e0$334d573e@idimo2> From: "jpinkerton" To: References: Subject: DEPLOY Date: Sun, 5 Sep 2004 10:37:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have about 20 domains, most with multiple, active e-mail facilities, and with many more on many sub-domains. I will not be using Sender-ID because :- 1. There is no means by which Sender-ID identifies the originating server, IP or domain for e-mails in a multi-hop transmission, thereby allowing me to be confident that the mail is from who it claims to be from, and allowing me to check it against white/black lists, reputations, etc. 2. There is insufficient proof that the technology will be free of legal encumberances for me to implement, modify and pass on to other implementors. In fact there are three legal opinions that I have seen on this list stating the opposite. I am an active member a co-operative group owning 5 server boxes at different locations, we have something in the region of 1,000 domains between us. I will be recommending that Sender-ID is NOT implemented by the members of the co-operative. I will be recommending alternative solutions to add to our existing anti-spam efforts. Kind regards, John Pinkerton. johnp@idimo.com ICQ 313355492 From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 06:19: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 GAA21024 for ; Sun, 5 Sep 2004 06:19: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 i859s8rg025580; Sun, 5 Sep 2004 02:54: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 i859s8du025579; Sun, 5 Sep 2004 02:54:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i859s7lJ025535 for ; Sun, 5 Sep 2004 02:54:07 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 5 Sep 2004 09:54:18 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "Yakov Shafranovich" Subject: RE: consensus call of RR prefix Date: Sun, 5 Sep 2004 03:54:35 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <413A7062.3040100@solidmatrix.com> X-OriginalArrivalTime: 05 Sep 2004 09:54:18.0778 (UTC) FILETIME=[4FADB7A0:01C4932E] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yakov Shafranovich wrote: > I would add to that that others in the IETF may use MARID as a > precendent to argue for the use of TXT record. This may quickly increase > the possible number of them. Therefore, I am for the prefix as well. This is a good point, however: - MARID has an immediate (emergency-like) need for widespread deployment like few other standards, and thus the precedent is limited. Most (if not all) other standards can depend on RFC 3597 (unknown RR types) and/or underscored prefixes. - The IETF is capable of determining whether standards now and in the future have this special need or not. - Requiring an underscored prefix to prevent this (likely non-existent) future problem prevents and slows adoption of MARID by those whose DNS providers do not allow underscores. It would seem strange if MARID provided TXT publishing to improve deployment, but then placed it in an underscored prefix which impedes deployment. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 06:42:34 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 GAA22085 for ; Sun, 5 Sep 2004 06:42:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85AKW7s037418; Sun, 5 Sep 2004 03:20:32 -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 i85AKWeL037417; Sun, 5 Sep 2004 03:20:32 -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 i85AKV8C037406 for ; Sun, 5 Sep 2004 03:20:31 -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 i85AUlWT002651; Sun, 5 Sep 2004 03:30:47 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i85AUl7s002648; Sun, 5 Sep 2004 03:30:47 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 5 Sep 2004 03:30:47 -0700 (PDT) From: "william(at)elan.net" To: "Michael R. Brumm" cc: IETF MARID WG Subject: RE: consensus call of RR prefix 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 Sun, 5 Sep 2004, Michael R. Brumm wrote: > This is a good point, however: > > - MARID has an immediate (emergency-like) need for widespread deployment > like few other standards, and thus the precedent is limited. Most (if not > all) other standards can depend on RFC 3597 (unknown RR types) and/or > underscored prefixes. The "immediate need" or emergency is in the eye of the beholder. What may seem urgent for us may not seem so urgent for somebody else and similarly what may seem like not so important matter to us maybe very important and seemingly an emergency for somebody else. The precident will be there, that one is certainly right, so don't be surprised if somebody else wants to use it for their "emergency". As such we better show good understanding of such emergency situation and good example for that to follow in our technical solution. > - Requiring an underscored prefix to prevent this (likely non-existent) > future problem prevents and slows adoption of MARID by those whose DNS > providers do not allow underscores. It would seem strange if MARID > provided TXT publishing to improve deployment, but then placed it in an > underscored prefix which impedes deployment. I have a question for Michael here: Is "_" as part of the prefix name the only problem you see (or the primarily one) as far as what you see wrong about introduced idea of using prefixes for placement of SPF TXT records? Similarly if others here who have so far spoken against using prefix also see underscore as the main problem, please also speak up as I believe it is important issue for chairs to recongnize as far as arguments against it and how strong technically these arguments are. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 06:54: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 GAA22789 for ; Sun, 5 Sep 2004 06:54:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85ARMG6040573; Sun, 5 Sep 2004 03:27:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85ARMol040572; Sun, 5 Sep 2004 03:27:22 -0700 (PDT) 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 i85ARLCK040483 for ; Sun, 5 Sep 2004 03:27:22 -0700 (PDT) (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 i85ARR65078600 for ; Sun, 5 Sep 2004 10:27:27 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 i85ARQE5030709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Sep 2004 12:27:27 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i85ARQnb030708 for ietf-mxcomp@imc.org; Sun, 5 Sep 2004 12:27:26 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Sun, 5 Sep 2004 12:27:26 +0200 From: Koen Martens To: IETF MARID WG Subject: DEPLOY new RR type deployment Message-ID: <20040905102726.GC30572@metro.cx> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On the subject of a new RR type: What are microsoft's plans on this account? As I understand it, microsoft products are the biggest obstacle for using a new RR type for spf records. Are there any plans from microsoft to fix their products to support new RR types? Will there be free updates for those products to support new RR types, or will these cost money? I think it's important that if a new RR type is put forward, that this gets resolved soon, as this might prove to be another barrier microsoft=20 puts up to widespread adoption. Koen Martens --=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/ --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBOuoNktDgRrkFPpYRAtX+AJ9nftS1ZYgvmKxBt6uz9jrFz7v//ACdG/6p /GEsJv18WhHDeq8Z7W0ZFD4= =z5Uo -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 08:39: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 IAA27561 for ; Sun, 5 Sep 2004 08:39: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 i85CFNDh060399; Sun, 5 Sep 2004 05:15:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85CFNm5060398; Sun, 5 Sep 2004 05:15:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85CFMgZ060390 for ; Sun, 5 Sep 2004 05:15:22 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i85CPFc0006476; Sun, 5 Sep 2004 08:25:15 -0400 From: To: "'william(at)elan.net'" , "'Michael R. Brumm'" Cc: "'IETF MARID WG'" Subject: RE: consensus call of RR prefix Date: Sun, 5 Sep 2004 08:13:40 -0400 Message-ID: <00c801c49341$c85e5840$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I voted against a prefix. I did this not just because of the "_" character support issue, but also because: -implementing a prefix adds complexity (comprehension complexity if nothing else) -many dns providers do not support users adding subdomains (or not through the UI anyway) -prefix does not solve the wildcard issue -one can use redirect in a small record to a subdomain (simulating prefix) if one really wants prefix Anything that hinders deployment needs to be considered for benefit and lack of alternatives. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of > william(at)elan.net > Sent: Sunday, September 05, 2004 6:31 AM > To: Michael R. Brumm > Cc: IETF MARID WG > Subject: RE: consensus call of RR prefix > > > > On Sun, 5 Sep 2004, Michael R. Brumm wrote: > > > This is a good point, however: > > > > - MARID has an immediate (emergency-like) need for > widespread deployment > > like few other standards, and thus the precedent is > limited. Most (if not > > all) other standards can depend on RFC 3597 (unknown RR > types) and/or > > underscored prefixes. > > The "immediate need" or emergency is in the eye of the > beholder. What may > seem urgent for us may not seem so urgent for somebody else > and similarly > what may seem like not so important matter to us maybe very important > and seemingly an emergency for somebody else. > > The precident will be there, that one is certainly right, so don't be > surprised if somebody else wants to use it for their "emergency". > As such we better show good understanding of such emergency situation > and good example for that to follow in our technical solution. > > > - Requiring an underscored prefix to prevent this (likely > non-existent) > > future problem prevents and slows adoption of MARID by > those whose DNS > > providers do not allow underscores. It would seem strange if MARID > > provided TXT publishing to improve deployment, but then > placed it in an > > underscored prefix which impedes deployment. > > I have a question for Michael here: > Is "_" as part of the prefix name the only problem you see (or the > primarily one) as far as what you see wrong about introduced idea of > using prefixes for placement of SPF TXT records? > > Similarly if others here who have so far spoken against using > prefix also > see underscore as the main problem, please also speak up as I > believe it > is important issue for chairs to recongnize as far as > arguments against it > and how strong technically these arguments are. > > -- > William Leibzon > Elan Networks > william@elan.net > From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 09:41:34 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 JAA00074 for ; Sun, 5 Sep 2004 09:41:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85DGSHR068109; Sun, 5 Sep 2004 06:16: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 i85DGSCT068108; Sun, 5 Sep 2004 06:16:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from trillian.net.astrum.ch (trillian.net.astrum.ch [213.144.132.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85DGQL9068099 for ; Sun, 5 Sep 2004 06:16:27 -0700 (PDT) (envelope-from matthias@astrum.ch) Received: from localhost (localhost [127.0.0.1]) by trillian.net.astrum.ch (Postfix) with ESMTP id B202F4D617 for ; Sun, 5 Sep 2004 15:16:43 +0200 (CEST) Received: from astrum.ch (marvin.net.astrum.ch [213.144.132.250]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by trillian.net.astrum.ch (Postfix) with ESMTP id 8EE224DAE4 for ; Sun, 5 Sep 2004 15:16:42 +0200 (CEST) Message-ID: <413B11B9.6050101@astrum.ch> Date: Sun, 05 Sep 2004 15:16:41 +0200 From: Matthias Leisi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-ch, de-de, de, en-us, en, fr MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: [DEPLOY] personal testimony References: <20040902145233.GG659@bitshift.org> In-Reply-To: <20040902145233.GG659@bitshift.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at astrum.ch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My interest in this working group comes both from a personal and business perspective. Besides my work in several non-profit projects, I am involved with my employer's mail infrastructure. My employer is in the financial services business, has around 9'000 users in Europe and the US (plus a number of offices around the world); for those users, we process roughly 5 Mio incoming mails per month. The company has no retail business; the mail traffic is mostly with other companies from the financial services business. However, users are allowed to use mail for a limited amount of personal communication. From my experience, users are loosing trust in Internet mail, which also affects internal mail (since it can be hard for users to distinguish what is really an internal mail and what not). With all the junk and noise users receive, I would be very glad to be able to authenticate (the source, the sender, ... of) incoming mails. Further, we would like to be able to use white/blacklists on the domain level, which would be made somewhat easier and more effective by a "domain authentication" of whatever sort. From the sender side, both SPF and SenderId have roughly the same operational complexity (nearly zero, as we have only a very limited set of outsourced sending), so there is no reason to prefer one or the other (we could publish both, actually). On the receiving side, however, SenderId introduces a certain complexity, whereas SPF seems easier to maintain. Due to it's simplicity, SPF is easier to explain /within my organization/, which makes it more likely to be adopted. Given the unclear situation about IP claims surrounding SenderId, internal corporate legal would need to be consulted, making it less likely that SenderId could be deployed in a timely fashion. It is well understood that both SenderId and SPF are more medium- than long-term solutions with limited scope and usefulness. From a cost/benefit perspective, spending too much at this point in time seems not justified. For a long-term solution (eg based on some form of crypto/signing), we would re-evaluate the situation and be prepared to invest what will be required by then. -- Matthias -- Brain-Log http://matthias.leisi.net/ From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 09:43:24 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 JAA00192 for ; Sun, 5 Sep 2004 09:43:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85DN8uP069513; Sun, 5 Sep 2004 06:23: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 i85DN8c7069512; Sun, 5 Sep 2004 06:23: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 i85DN82P069502 for ; Sun, 5 Sep 2004 06:23:08 -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 i85DXQCY026553 for ; Sun, 5 Sep 2004 06:33:26 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i85DXQgG026550 for ; Sun, 5 Sep 2004 06:33:26 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 5 Sep 2004 06:33:26 -0700 (PDT) From: "william(at)elan.net" To: "'IETF MARID WG'" Subject: RE: consensus call of RR prefix In-Reply-To: <00c801c49341$c85e5840$2766f30a@development.greatgulfhomes.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 Sun, 5 Sep 2004 terry@ashtonwoodshomes.com wrote: > I voted against a prefix. > > I did this not just because of the "_" character support issue, but > also because: > -implementing a prefix adds complexity (comprehension complexity if > nothing else) You know, if a person went through SPF protocol draft and understood the syntax and how these records work, I would imagine same person could take 2 more seconds to understand about prefix placement of the record... > -many dns providers do not support users adding subdomains > (or not through the UI anyway) These are not truly subdomains, prefix is more like a host record for specific domain. And actually if you place records at the root of the domain, its more GUI that will not let you do it (or make it difficult to do it) as many programs will not let you add records with empty host record. > -prefix does not solve the wildcard issue Actually prefix helps wildcard issues and solves at least one of them. It allows to avoid necessity to enter separate records for both "example,com" and for "*.example.com" while with prefix one record for "*.example.com" would suffice and cover both _prefix.example.com and anything else like _prefix.subdonain.example.com. The rest of wildcard issues are the same no matter if prefix is used or not but. But having solved at least one wildcard issue does mean that use of prefix is preferable when considering wildcards. > -one can use redirect in a small record to a subdomain (simulating > prefix) if one really wants prefix Which dies not completely avoids collision with other records while requirying multiple dns lookups. > Anything that hinders deployment needs to be considered for benefit and > lack of alternatives. Ok, then I have the following objection: We should stop working on MARID and SPF completely because they use dns TXT records and entering TXT records is not supported by large number of GUI dns configuation tools and not supported by majority of registrars that offer dns service hosting directly to end-users. P.S. If you do a comparision, you may find that there are more GUI dns systems that don't support TXT then there are those that don't support "_" in the host name. At the same time you may actually find that majority of DNS GUI systems that have one of these problems have the other one too. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 10:10:54 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 KAA01949 for ; Sun, 5 Sep 2004 10:10:54 -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 i85Dkeor073406; Sun, 5 Sep 2004 06:46:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85Dkesf073405; Sun, 5 Sep 2004 06:46:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85DkZS2073367 for ; Sun, 5 Sep 2004 06:46:40 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from [192.168.1.13] ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Sun, 05 Sep 2004 09:46:45 -0400 id 003A1285.413B18C5.00006F53 In-Reply-To: <00c801c49341$c85e5840$2766f30a@development.greatgulfhomes.com> References: <00c801c49341$c85e5840$2766f30a@development.greatgulfhomes.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <067E3762-FF42-11D8-A776-000A95CC77E2@verisignlabs.com> Content-Transfer-Encoding: 7bit Cc: "'IETF MARID WG'" From: David Blacka Subject: Re: consensus call of RR prefix Date: Sun, 5 Sep 2004 09:46:44 -0400 To: terry@ashtonwoodshomes.com 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 Sep 5, 2004, at 8:13 AM, terry@ashtonwoodshomes.com wrote: > > I voted against a prefix. > > I did this not just because of the "_" character support issue, but > also because: > -implementing a prefix adds complexity (comprehension complexity if > nothing else) > -many dns providers do not support users adding subdomains (or not > through the UI anyway) I don't yet understand this. Are you saying that there are DNS providers who allow you to host your "example.com" domain, but then only allow you to add DNS records named "example.com"? They wouldn't allow you to add a record for, say, "www.example.com"? Are there DNS providers who do not allow this but would allow the addition of a TXT record? > -prefix does not solve the wildcard issue What, precisely, is "the wildcard issue"? -- David Blacka Sr. Engineer Verisign Applied Research From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 11:04:59 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 LAA04578 for ; Sun, 5 Sep 2004 11:04: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 i85EfEc3082788; Sun, 5 Sep 2004 07:41: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 i85EfE5x082787; Sun, 5 Sep 2004 07:41:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from trillian.net.astrum.ch (trillian.net.astrum.ch [213.144.132.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85EfCno082779 for ; Sun, 5 Sep 2004 07:41:13 -0700 (PDT) (envelope-from matthias@astrum.ch) Received: from localhost (localhost [127.0.0.1]) by trillian.net.astrum.ch (Postfix) with ESMTP id 9A0484DE31 for ; Sun, 5 Sep 2004 16:41:30 +0200 (CEST) Received: from astrum.ch (marvin.net.astrum.ch [213.144.132.250]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by trillian.net.astrum.ch (Postfix) with ESMTP id 86A4D4D617 for ; Sun, 5 Sep 2004 16:41:29 +0200 (CEST) Message-ID: <413B2598.8070606@astrum.ch> Date: Sun, 05 Sep 2004 16:41:28 +0200 From: Matthias Leisi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-ch, de-de, de, en-us, en, fr MIME-Version: 1.0 To: "'IETF MARID WG'" Subject: Re: consensus call of RR prefix References: <002e01c49281$f106aec0$2766f30a@development.greatgulfhomes.com> In-Reply-To: <002e01c49281$f106aec0$2766f30a@development.greatgulfhomes.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at astrum.ch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit terry@ashtonwoodshomes.com wrote: > -not all dns servers support "_" Just for clarification: Which DNS servers do /not/ support underscores? I know from testing that BIND 9 is happy with them; since Microsoft uses them for some AD stuff, I guess that at least newer implementations of their DNS services will not choke on them. Local DNS libraries seem to be able to handle it - at least I haven't heard of resolver-library incompatibility with products that use Apple's Rendezvous, which is based on kind-of-SRV records and also use SRV's _._ scheme. Of course, further testing would be fine, but technically most relevant pieces of DNS software around should not have issues underscores. > -many dns providers do not allow subdomains (or not easily via an interface, and we need to keep > publishing easy or it won't get done)(yes I know many ISPs don't support TXT RR either, but that > *is* changing and it *is* an RFC compliant DNS standard, even if SPF abuses it) Which DNS providers do (not) allow subdomains and/or TXT records? Adding something a record for "_spf" should not be any different from adding a "www" record to a domain. (Adding TXT records to the admin GUI of my non-profit ISP took me a couple of minutes.) IMO, there are no technical or admin issues for or against RR prefixes. Having said that, there are of course policy reasons to consider - eg if we go for a dedicated record type for "MARID", there is no need for a prefix (after all, we don't have a prefix for MX records). Still IMO, a prefix would only make sense if the TXT record workaround were a long-term solution. As this quite possibly is not the intention of this working group, using a prefix does not offer any benefits other than possibly keeping the DNS response size below the magical 418 bytes, a restriction which can be easily worked around using redirects by those few(?) that would need it. -- Matthias -- Brain-Log http://matthias.leisi.net/ From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 12: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 MAA07711 for ; Sun, 5 Sep 2004 12:21:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85Ftbmn095205; Sun, 5 Sep 2004 08:55:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85FtbAw095204; Sun, 5 Sep 2004 08:55:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85FtaIC095188 for ; Sun, 5 Sep 2004 08:55:36 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i85FtnY2008013 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 5 Sep 2004 11:55:52 -0400 Date: Sun, 5 Sep 2004 11:55:49 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Anne P. Mitchell, Esq." cc: IETF MARID WG Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardiza tion of SPF Classic In-Reply-To: <72C17075-FE54-11D8-B4F9-000A95AC5778@isipp.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 Sat, 4 Sep 2004, Anne P. Mitchell, Esq. wrote: > > > > There is a reason why NNTP has been replaced by the blogosphere. > > > > And that reason is spam. Not bad protocol design. NNTP isn't the only network protocol subject to abuse. IRC is also a favorite for abuse. Of the three, none have been effective at controlling abuse through technical means. Perhaps we should be asking for an example of where abuse _was_ successfully controlled by technical means (I think there are theoretical grounds that this is impossible, but a counter example would certainly make that less certain.) > And the the relative lack of a proficiency barrier to entry. This is a popular myth. Proficiency is not a problem. The abusers are quite proficient, and quite determined, and frequently quite resourceful. Occasionally they take advantage of people who aren't proficient, but as often as not they exploit very proficient operations. Every major vendor has had vulnerabilities, and I've little doubt that many competently run servers have been exploited. We don't find out about the security exploits until a server is exploited, and the exploit is discovered and reported. The myth is that somehow a proficient operator isn't vulnerable. Belief in this myth ironically is the first obvious sign of a lack proficiency. --Dean From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 12:22:09 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 MAA07790 for ; Sun, 5 Sep 2004 12:22: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 i85G0N86095796; Sun, 5 Sep 2004 09:00:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85G0N5i095795; Sun, 5 Sep 2004 09:00:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85G0MuJ095787 for ; Sun, 5 Sep 2004 09:00:22 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i85G0dSg008107 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 5 Sep 2004 12:00:39 -0400 Date: Sun, 5 Sep 2004 12:00:39 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: terry@ashtonwoodshomes.com cc: "'Hallam-Baker, Phillip'" , "'Anne P. Mitchell, Esq.'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Sender-ID provides little or no defense against adaptive threats In-Reply-To: <002c01c4927f$c2727780$2766f30a@development.greatgulfhomes.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 Sat, 4 Sep 2004 terry@ashtonwoodshomes.com wrote: > > Not "accomplished nothing" but we would have accomplished the need for the next step: SMTP AUTH > that incorporates spoofing prevention. Oh, SMTP AUTH needs to be changed now. And you still have SMTP AUTH passwords that can be stolen. And you still have disposable accounts. And you still have disposable domains. Etc, etc, etc. The user _still_ needs to do just what they did before. At even greater expense, you have _still_ accomplished nothing. --Dean From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 12:38: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 MAA08552 for ; Sun, 5 Sep 2004 12:38: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 i85GHAv6098236; Sun, 5 Sep 2004 09:17:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85GHANB098235; Sun, 5 Sep 2004 09:17:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85GH916098226 for ; Sun, 5 Sep 2004 09:17:09 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i85GHPFr008380 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 5 Sep 2004 12:17:26 -0400 Date: Sun, 5 Sep 2004 12:17:25 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Sam Varshavchik cc: IETF MARID WG Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardiza tion of SPF Classic 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 Sat, 4 Sep 2004, Sam Varshavchik wrote: > Hallam-Baker, Phillip writes: > > > > >> That's fine. You might want to study the evolution of NNTP. > >> There, lack of > >> the official IETF stamp of approval did not inhibit NNTP from > >> evolving. If > >> you try to implement NNTP based only on IETF's standards-track > >> documentation, you won't get very far. > > > > Are you saying that NNTP is a good example of protocol design? > > Or a good example of creating a widely supported feature set? > > NNTP works. It has survived the onslaught of spam far better than SMTP. I > may be see one or two spam message a week across all the newsgroups I'm > subscribed to. And NNTP's evolution was outside of the IETF process. We haven't carried Usenet news for years, now. I'll have to check somewhere see how spam-free Usenet is. And maybe its because many of the groups are now moderated. Or maybe its because NNTP is particularly efficient about spam and the cancel-bot** wars have stopped. All a spammer needs to do is post one message a week to a group to make sure that everyone in the group gets it once a week. Cross-posting the same message to many groups means that you see it only once for all of those groups. Moderated mailing lists have also had less problem that unmoderated lists, even though it is trivial to forge an on-list from address to post on a (subscriber-only) moderated list. I've always found it strange that abusers are so 'ethical' that they don't forge from addresses to get on moderated lists. --Dean [** The cancel-bot wars were when usenet news admins would cancel spam posts. The spammers would then repost the message. This process was automated on both sides, and the result was thousands of spam messages to a group. This made many groups unreadable. Spammers were blamed, but the fault was just as much on the people who were doing the canceling, since the groups were unmoderated and Usenet never had any kind of non-commercial nature.] From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 12:42: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 MAA08839 for ; Sun, 5 Sep 2004 12:42: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 i85GM5c4099193; Sun, 5 Sep 2004 09:22: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 i85GM5bA099192; Sun, 5 Sep 2004 09:22:05 -0700 (PDT) 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 i85GM42r099182 for ; Sun, 5 Sep 2004 09:22:04 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Sun, 05 Sep 2004 12:22:20 -0400 id 0000000000157937.00000000413B3D3C.0000461C X-IMAP-Sender: mrsam@courier-mta.com References: Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: IETF MARID WG X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardiza tion of SPF Classic Date: Sun, 05 Sep 2004 12:22:20 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-1774-1094401340-0001"; 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-1774-1094401340-0001 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Dean Anderson writes: > > On Sat, 4 Sep 2004, Anne P. Mitchell, Esq. wrote: > >> >> > > There is a reason why NNTP has been replaced by the blogosphere. >> > >> > And that reason is spam. Not bad protocol design. > > NNTP isn't the only network protocol subject to abuse. IRC is also a > favorite for abuse. Of the three, none have been effective at > controlling abuse through technical means. Really? I read several Usenet newsgroups. I see, maybe, one or two spams a week on a newsgroup that carries 400-500 messages a day. --=_mimegpg-commodore.email-scan.com-1774-1094401340-0001 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBOz08x9p3GYHlUOIRAuleAJ0V7LJ0i6Z3IH6n9cJiRYHRO0jCxQCeLUUM XpxmVoqRFBMEz512EBflegM= =trI6 -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-1774-1094401340-0001-- From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 12:49: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 MAA09256 for ; Sun, 5 Sep 2004 12:49:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85GRBOt099889; Sun, 5 Sep 2004 09:27: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 i85GRBfr099888; Sun, 5 Sep 2004 09:27:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85GRAdv099878 for ; Sun, 5 Sep 2004 09:27:10 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from righton.sendmail.com (ns.sendmail.com [209.246.26.10]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i85GRRme003194 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 5 Sep 2004 09:27:27 -0700 Received: from [192.168.1.104] (soggy22.drizzle.com [216.162.199.22]) (authenticated bits=0) by righton.sendmail.com (8.13.1.Beta1/8.13.1.Beta1) with ESMTP id i85GRPEZ016021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Sep 2004 09:27:26 -0700 (PDT) Message-ID: <413B3E6E.80401@sendmail.com> Date: Sun, 05 Sep 2004 09:27:26 -0700 From: Rand Wacker User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Kanat-Alexander CC: IETF MARID WG Subject: Re: consensus call of RR prefix References: <1094255966.5841.24.camel@localhost.localdomain> In-Reply-To: <1094255966.5841.24.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; 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 Max Kanat-Alexander wrote: > I don't think it's a huge issue -- what are sysadmins currently using > TXT records in domain.tld for, and how many of them also have wildcards > enabled? I don't know of an extensive number of uses of those things > combined. spfv1, supposedly tens of thousands of them are doing it, and they are making no indication that they will replace those records w/ Sender ID. -Rand From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 13:36:17 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 MAA09277 for ; Sun, 5 Sep 2004 12:49: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 i85GV9vd000516; Sun, 5 Sep 2004 09:31: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 i85GV9Ss000515; Sun, 5 Sep 2004 09:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85GV9wU000507 for ; Sun, 5 Sep 2004 09:31:09 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from righton.sendmail.com (ns.sendmail.com [209.246.26.10]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i85GVIvh004062 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 5 Sep 2004 09:31:18 -0700 Received: from [192.168.1.104] (soggy22.drizzle.com [216.162.199.22]) (authenticated bits=0) by righton.sendmail.com (8.13.1.Beta1/8.13.1.Beta1) with ESMTP id i85GVGQW016425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Sep 2004 09:31:17 -0700 (PDT) Message-ID: <413B3F55.9030102@sendmail.com> Date: Sun, 05 Sep 2004 09:31:17 -0700 From: Rand Wacker User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami CC: IETF MARID WG Subject: Re: consensus call of RR prefix References: <16697.63911.166056.276878@giles.gnomon.org.uk> In-Reply-To: <16697.63911.166056.276878@giles.gnomon.org.uk> Content-Type: text/plain; charset=us-ascii; 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 Roy Badami wrote: > The current drafts mandate support for EDNS0 so the 480 byte limit > goes away. > > I really think we shouldn't get to caught up in this 480 byte limit. The 480 byte limit is a limit of UDP. The potential to have to fall back to a TCP call-back connection is pretty scary to sites that receive billions of messages a day. Again though, I'm fine with the draft the way it is as long as we tell people to be wary of the aggregate limit on TXT records and the suggested include: workaround. -Rand From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 13:41: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 NAA12200 for ; Sun, 5 Sep 2004 13:41: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 i85Gp9uF002675; Sun, 5 Sep 2004 09:51: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 i85Gp9ZS002674; Sun, 5 Sep 2004 09:51:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85Gp8Pm002668 for ; Sun, 5 Sep 2004 09:51:08 -0700 (PDT) (envelope-from roy+dated+1096995080.cd09d5@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85GqYH1007941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Sep 2004 16:52:40 GMT (envelope-from roy+dated+1096995080.cd09d5@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85GpLhk065659 for ; Sun, 5 Sep 2004 17:51:21 +0100 (BST) (envelope-from roy+dated+1096995080.cd09d5@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i85GpLiq065652 for ietf-mxcomp@imc.org; Sun, 5 Sep 2004 17:51:21 +0100 (BST) (envelope-from roy+dated+1096995080.cd09d5@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 05 Sep 2004 17:51:20 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16699.17415.492224.734011@giles.gnomon.org.uk> Date: Sun, 5 Sep 2004 17:51:19 +0100 To: Rand Wacker Cc: Roy Badami , IETF MARID WG Subject: Re: consensus call of RR prefix In-Reply-To: <413B3F55.9030102@sendmail.com> References: <16697.63911.166056.276878@giles.gnomon.org.uk> <413B3F55.9030102@sendmail.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Rand" == Rand Wacker writes: Rand> The 480 byte limit is a limit of UDP. The potential to have Rand> to fall back to a TCP call-back connection is pretty scary Rand> to sites that receive billions of messages a day. It's not a limit of UDP, though it stems from the 512 byte limit that RFC1035 places on DNS over UDP. EDNS0 (RFC2535) provides a mechanism for sending larger DNS transactions over UDP. RFC3226 (which is also referenced by Sender ID) says that EDNS0 implementations MUST allow at least 1220 bytes, and SHOULD allow at least 4000 bytes. -roy From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 13:42: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 NAA12241 for ; Sun, 5 Sep 2004 13:42: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 i85GwwfX003705; Sun, 5 Sep 2004 09:58: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 i85GwwkU003704; Sun, 5 Sep 2004 09:58: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 i85GwmjC003672 for ; Sun, 5 Sep 2004 09:58:52 -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 22EFC16CD2 for ; Sun, 5 Sep 2004 13:07:58 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: OT: Forgery on moderated lists In-Reply-To: Your message of "Sun, 05 Sep 2004 12:17:25 EDT." Date: Sun, 05 Sep 2004 13:07:58 -0400 Message-Id: <20040905170758.22EFC16CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > Moderated mailing lists have also had less problem that unmoderated lists, > even though it is trivial to forge an on-list from address to post on a > (subscriber-only) moderated list. I've always found it strange that > abusers are so 'ethical' that they don't forge from addresses to get on > moderated lists. They do. Not often, but they do. I can't find the articles now, but I have seen them in the past few months. In addition, I'm regularly receiving spam "from" people I've exchanged messages with on public lists. It's clearly forged, but the spammers obviously believe that such forgery is useful. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 13:48:17 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 NAA12515 for ; Sun, 5 Sep 2004 13:48:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85HFxPU006488; Sun, 5 Sep 2004 10: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 i85HFxei006487; Sun, 5 Sep 2004 10:15:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i85HFwoU006476 for ; Sun, 5 Sep 2004 10:15:58 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 76293 invoked from network); 5 Sep 2004 17:16:15 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 5 Sep 2004 17:16:15 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "'IETF MARID WG'" Subject: RE: consensus call of RR prefix Date: Sun, 5 Sep 2004 13:16:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <413B2598.8070606@astrum.ch> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Matthias Leisi > Sent: Sunday, September 05, 2004 10:41 AM > To: 'IETF MARID WG' > Subject: Re: consensus call of RR prefix > > Just for clarification: Which DNS servers do /not/ support underscores? > > I know from testing that BIND 9 is happy with them; since Microsoft uses > them for some AD stuff, I guess that at least newer implementations of > their DNS services will not choke on them. > > Local DNS libraries seem to be able to handle it - at least I haven't > heard of resolver-library incompatibility with products that use Apple's > Rendezvous, which is based on kind-of-SRV records and also use SRV's > _._ scheme. > > Of course, further testing would be fine, but technically most relevant > pieces of DNS software around should not have issues underscores. > > Which DNS providers do (not) allow subdomains and/or TXT records? > > Adding something a record for "_spf" should not be any different from > adding a "www" record to a domain. > > (Adding TXT records to the admin GUI of my non-profit ISP took me a > couple of minutes.) For me, the issue isn't BIND, but the web front end that my DNS provider uses to enable me to enter data. For the record, www.pairnic.com currently does the following: TXT support: Yes. CNAME support (in my case www is always a CNAME for the base domain): Yes. Add sudomains: Yes. Underscore support: No. SRV support: No. Underscore and SRV support are both on their list of things to do, but are not currently available. If the IPR issue is satifactorily resolved, then I would like to publish records for both SPF and Sender-ID. If an underscored prefix is required, then I'll be unable to do so. The marginal benifit to me for publishing records for both SPF and Sender-ID (instead of just SPF as I currently do) is not sufficient for me to consider changing DNS providers. Speaking for myself, as a very small fish in this pond, if the IPR issue is resolved and there is no underscored prefix requirement, I'll publish immediately. Otherwise, maybe someday. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 13:52:51 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 NAA12729 for ; Sun, 5 Sep 2004 13:52:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85HFKtR006407; Sun, 5 Sep 2004 10:15:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85HFKEA006406; Sun, 5 Sep 2004 10:15:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85HFJck006397 for ; Sun, 5 Sep 2004 10:15:20 -0700 (PDT) (envelope-from roy+dated+1096996529.28b051@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85HGhR6010262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Sep 2004 17:16:49 GMT (envelope-from roy+dated+1096996529.28b051@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85HFTsA065725 for ; Sun, 5 Sep 2004 18:15:29 +0100 (BST) (envelope-from roy+dated+1096996529.28b051@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i85HFTpb065724 for ietf-mxcomp@imc.org; Sun, 5 Sep 2004 18:15:29 +0100 (BST) (envelope-from roy+dated+1096996529.28b051@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 05 Sep 2004 18:15:29 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16699.18864.756743.15183@giles.gnomon.org.uk> Date: Sun, 5 Sep 2004 18:15:28 +0100 To: ietf-mxcomp@imc.org Subject: DOC-BUG: We need another document: Use of EDNS0 in recursive servers X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nonetheless, Sender-ID compliant sites MUST use DNS recursive servers that support EDNS0 [RFC2671] and [RFC3226] in order to be able to receive large DNS RR sets I'm not sure this is exactly right. I assume that the intent is not to _require_ applications to use recursive servers (eg an implementation might incorporate its own EDNS0-compliant full-service resolver). I'm also rather uneasy about the notion of a 'sender-ID compliant site'. I think that the notion of a compliant site probably belongs in a BCP; standards track RFCs define protocols, not standards that sites should meet. Unfortunately you need that (or a similar) notion to say what you want to say; the Sender ID implementation doesn't have to support EDNS0 itself; the systems administrator at the site just has to point it an an EDNS0-compliant recursive server. I realize that it's a bit late to be suggesting that we need _another_ draft, but IMHO that's where such a requirement belongs. FWIW, it could be a very short draft :-) -roy From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 13:57: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 NAA13003 for ; Sun, 5 Sep 2004 13:57: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 i85HHqdq006744; Sun, 5 Sep 2004 10:17: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 i85HHqdP006743; Sun, 5 Sep 2004 10:17:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85HHpZ6006730 for ; Sun, 5 Sep 2004 10:17:51 -0700 (PDT) (envelope-from roy+dated+1096996683.f4b989@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85HJHu4010325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Sep 2004 17:19:23 GMT (envelope-from roy+dated+1096996683.f4b989@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85HI3un065749 for ; Sun, 5 Sep 2004 18:18:03 +0100 (BST) (envelope-from roy+dated+1096996683.f4b989@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i85HI3EU065748 for ietf-mxcomp@imc.org; Sun, 5 Sep 2004 18:18:03 +0100 (BST) (envelope-from roy+dated+1096996683.f4b989@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 05 Sep 2004 18:18:03 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16699.19019.101028.91532@giles.gnomon.org.uk> Date: Sun, 5 Sep 2004 18:18:03 +0100 To: ietf-mxcomp@imc.org Subject: DOC-BUG: Use of non-RFC2119 language: STRONGLY ENCOURAGED X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -protocol 2.1.6 says It is STRONGLY ENCOURAGED that published records remain small enough that query results will fit within 512 octets STRONGLY ENCOURAGED is not defined by RFC2119. I would suggest RECOMMENDED (which has the same meaning as SHOULD) Or alternatively, just write 'strongly encouraged' in lower case. The sense of the two possibly corrections is slightly different; I have no strong opinion as to which is better. -roy From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 13:57: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 NAA13033 for ; Sun, 5 Sep 2004 13:57:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85HQ5kh007549; Sun, 5 Sep 2004 10:26: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 i85HQ5Ct007548; Sun, 5 Sep 2004 10:26:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85HQ4SO007533 for ; Sun, 5 Sep 2004 10:26:04 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C40kn-000069-R4; Sun, 05 Sep 2004 13:24:38 -0400 Message-ID: <413B4C2D.1000209@solidmatrix.com> Date: Sun, 05 Sep 2004 13:26:05 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "william(at)elan.net" CC: "Michael R. Brumm" , IETF MARID WG Subject: Re: consensus call of RR prefix References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit william(at)elan.net wrote: > On Sun, 5 Sep 2004, Michael R. Brumm wrote: > >>- Requiring an underscored prefix to prevent this (likely non-existent) >>future problem prevents and slows adoption of MARID by those whose DNS >>providers do not allow underscores. It would seem strange if MARID >>provided TXT publishing to improve deployment, but then placed it in an >>underscored prefix which impedes deployment. > > > I have a question for Michael here: > Is "_" as part of the prefix name the only problem you see (or the > primarily one) as far as what you see wrong about introduced idea of > using prefixes for placement of SPF TXT records? > > Similarly if others here who have so far spoken against using prefix also > see underscore as the main problem, please also speak up as I believe it > is important issue for chairs to recongnize as far as arguments against it > and how strong technically these arguments are. > Doesn't SRV use _? From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 13:58:24 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 NAA13077 for ; Sun, 5 Sep 2004 13:58: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 i85HOiGD007375; Sun, 5 Sep 2004 10:24: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 i85HOi1X007372; Sun, 5 Sep 2004 10:24:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85HOhDp007362 for ; Sun, 5 Sep 2004 10:24:43 -0700 (PDT) (envelope-from roy+dated+1096997095.ba6d1f@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85HQASC011212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Sep 2004 17:26:16 GMT (envelope-from roy+dated+1096997095.ba6d1f@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85HOuZg065810 for ; Sun, 5 Sep 2004 18:24:56 +0100 (BST) (envelope-from roy+dated+1096997095.ba6d1f@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i85HOtBF065809 for ietf-mxcomp@imc.org; Sun, 5 Sep 2004 18:24:55 +0100 (BST) (envelope-from roy+dated+1096997095.ba6d1f@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 05 Sep 2004 18:24:55 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16699.19430.925469.845721@giles.gnomon.org.uk> Date: Sun, 5 Sep 2004 18:24:54 +0100 To: ietf-mxcomp@imc.org Subject: TECH-OMISSION: EDNS0 on authoritative servers should be mandated for large records X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit With the proviso that I believe this belongs in a BCP rather than a standards track document (as per my previous post, I believe we need a new draft therefore) We mandate that 'Sender-ID compliant sites' MUST use EDNS0 to fetch records. I believe we should also mandate that anyone publishing records that won't fit in a 512 byte UDP packet SHOULD use EDNS0-compliant authoritative name servers (or MUST if you prefer) -roy From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 14:49: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 OAA14903 for ; Sun, 5 Sep 2004 14:49: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 i85IOK5C015452; Sun, 5 Sep 2004 11:24:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85IOKBT015451; Sun, 5 Sep 2004 11:24:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85IOFP5015418 for ; Sun, 5 Sep 2004 11:24:19 -0700 (PDT) (envelope-from pk@TechFak.Uni-Bielefeld.DE) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i85IOPNC018977 for ; Sun, 5 Sep 2004 20:24:25 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i85IOOg02258 for ; Sun, 5 Sep 2004 20:24:24 +0200 (MEST) Message-Id: <200409051824.i85IOOg02258@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF MARID WG Subject: Re: consensus call of RR prefix In-reply-to: Your message of "Sun, 05 Sep 2004 17:51:19 BST." <16699.17415.492224.734011@giles.gnomon.org.uk> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2254.1094408663.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Sun, 05 Sep 2004 20:24:24 +0200 From: Peter Koch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Roy Badami wrote: > EDNS0 (RFC2535) provides a mechanism for sending larger DNS > transactions over UDP. RFC3226 (which is also referenced by Sender > ID) says that EDNS0 implementations MUST allow at least 1220 bytes, > and SHOULD allow at least 4000 bytes. this reference is questionable at best (read: DOC-BUG). RFC 3226 specifies behaviour of RFC2874-conformant DNS implementations (A6 is kinda dead now) and for DNSSEC-aware DNS implementations. None of both is relevant to the draft in question and, more importantly, it is suboptimal to reference a requirements document for DNS server implementations this way. If at all, the requirement would have to be specified explicitly for the 'SPF' RR type, e.g.: all DNS servers and resolvers implementing 'SPF' are required to support EDNS0 and ... size requirements ... But then, please note that RFC 3226 is rather old and especially it predates RFC 3597, so usually we do no longer assume that DNS implementations need to explicitly support a certain RR type. And, you can't just 'require' conformance for the intermediaries. However, based on deployment surveys you may *assume* RFC 3597 conformance. There has been work made available to this list (by Roy Arends, I guess), showing which SW versions are conformant. An example survey for the distribution of DNS server(!) versions can be found at http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-survey.pdf Also, Jakob Schlyter has done an extensive interoperability test for RFC 3597 implementations. Details can be found in the minutes of the DNSEXT meeting of IETF60. Bottom line: Size does matter. However, EDNS0 is there. Today on a moderate- size server (~5000 zones, non-representative sample, of course) 2/3 of all incoming queries (speaking of resolvers, not servers now) used EDNS0. -Peter From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 14:52: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 OAA15034 for ; Sun, 5 Sep 2004 14:52: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 i85ITqVG016085; Sun, 5 Sep 2004 11:29: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 i85ITqLp016084; Sun, 5 Sep 2004 11:29:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85ITpsI016077 for ; Sun, 5 Sep 2004 11:29:52 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59928) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1C41mC-0008VE-T8 (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Sun, 05 Sep 2004 19:30:08 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C41mA-0004Fa-Iu; Sun, 05 Sep 2004 19:30:06 +0100 Date: Sun, 5 Sep 2004 19:30:06 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Roy Badami cc: Tony Finch , ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra In-Reply-To: <16698.1388.231292.755112@giles.gnomon.org.uk> Message-ID: References: <16695.49071.671776.708651@giles.gnomon.org.uk> <16698.1388.231292.755112@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 4 Sep 2004, Roy Badami wrote: > > I suggest that an empty field body is defined to be one that is of > zero lenght, or consists entirely of linear whitespace. No, it's one that doesn't contain a valid email address. Tony. -- f.a.n.finch http://dotat.at/ FAEROES SOUTHEAST ICELAND: SOUTHWESTERLY 5 TO 7, DECREASING 4 AT TIMES. SHOWERS. GOOD &NBSP;. From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 15:25: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 PAA17429 for ; Sun, 5 Sep 2004 15:25:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85J0TxV020186; Sun, 5 Sep 2004 12:00:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85J0T7O020185; Sun, 5 Sep 2004 12:00:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85J0SvO020178 for ; Sun, 5 Sep 2004 12:00:29 -0700 (PDT) (envelope-from roy+dated+1097002841.5ccd41@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85J1vXG020625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Sep 2004 19:02:02 GMT (envelope-from roy+dated+1097002841.5ccd41@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i85J0f0l066412 for ; Sun, 5 Sep 2004 20:00:41 +0100 (BST) (envelope-from roy+dated+1097002841.5ccd41@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i85J0fkU066405 for ietf-mxcomp@imc.org; Sun, 5 Sep 2004 20:00:41 +0100 (BST) (envelope-from roy+dated+1097002841.5ccd41@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 05 Sep 2004 20:00:40 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16699.25176.185782.397897@giles.gnomon.org.uk> Date: Sun, 5 Sep 2004 20:00:40 +0100 To: Tony Finch Cc: Roy Badami , ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra In-Reply-To: References: <16695.49071.671776.708651@giles.gnomon.org.uk> <16698.1388.231292.755112@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tony" == Tony Finch writes: Tony> No, it's one that doesn't contain a valid email address. I really don't see how you can interpret the phrase 'non-empty' as meaning 'containing a valid e-mail address'. Malformed header fields are addressed by step 5; if the field body did not contain a valid email address, this would constitute a malformed header field, and the algorithm would not return any PRA. It's important that two implementations of the PRA algorithm never return two different answers as to the PRA, even in the presence of a malformed messages. (It is acceptable that one implementation returns an answer and another does not). What you propose is dangerous, because it depends on the interpretation of a 'valid e-mail address'; specifically, liberal implementations typically choose to accept addresses that are not strictly valid according to RRFC2822. If two implementations have a different opinion as to the validity of an e-mail address, that could result in them picking different headers. (This is precicely the flaw in the originial PRA algorithm in the Caller ID draft) The effect of this is that even if the users MUA is Sender ID aware, and displays the PRA, there's no guarantee it is displaying the same identity that was validated by the MTA. -roy From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 16:37: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 QAA21012 for ; Sun, 5 Sep 2004 16:37: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 i85KEBYm029701; Sun, 5 Sep 2004 13:14: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 i85KEBfE029700; Sun, 5 Sep 2004 13:14:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85KEAUB029681 for ; Sun, 5 Sep 2004 13:14:10 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i85KEKkQ032223 for ; Sun, 5 Sep 2004 21:14:20 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i85KEKft032222; Sun, 5 Sep 2004 21:14:20 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra References: <16695.49071.671776.708651@giles.gnomon.org.uk> <16698.1388.231292.755112@giles.gnomon.org.uk> <16699.25176.185782.397897@giles.gnomon.org.uk> From: Graham Murray Date: Sun, 05 Sep 2004 21:14:19 +0100 In-Reply-To: <16699.25176.185782.397897@giles.gnomon.org.uk> (Roy Badami's message of "Sun, 5 Sep 2004 20:00:40 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Roy Badami writes: > The effect of this is that even if the users MUA is Sender ID aware, > and displays the PRA, there's no guarantee it is displaying the same > identity that was validated by the MTA. Which is why it would be better for the MTA to create a header to inform the MUA of the PRA and for the MUA to display that. If this were done then it would be necessary to specify that the MTA MUST remove any such headers already in the mail. From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 17:06: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 RAA22369 for ; Sun, 5 Sep 2004 17:06: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 i85KjrDY033515; Sun, 5 Sep 2004 13:45: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 i85KjrZs033514; Sun, 5 Sep 2004 13:45:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85Kjp14033504 for ; Sun, 5 Sep 2004 13:45:52 -0700 (PDT) (envelope-from pk@TechFak.Uni-Bielefeld.DE) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i85KkBYo028646 for ; Sun, 5 Sep 2004 22:46:11 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i85KkA802616 for ; Sun, 5 Sep 2004 22:46:11 +0200 (MEST) Message-Id: <200409052046.i85KkA802616@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF MARID WG Subject: DOC-BUG in PRA: multiple mailboxes -> 'malformed' X-PGP-Fingerprint: 85 89 64 AD 73 79 92 1F C8 76 95 2D 15 09 19 93 X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2609.1094417164.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Sun, 05 Sep 2004 22:46:09 +0200 From: Peter Koch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: draft-ietf-marid-pra-00.txt says in item 5 of section 2: 5. A previous step has selected a single header from the message. If that header is malformed (e.g. it appears to contain multiple mailboxes, or the single mailbox is hopelessly malformed, or the This may falsely imply that multiple mailboxes are disallowed per se, which they aren't. However, for both From: and Resent-From: containing multiple mailboxes the required Sender: (or Resent-Sender:) should have been found and should have been preferred. Still the (Resent-)From: isn't malformed in terms of syntax, it's the "Sender:" constraint that isn't met. Suggested rewording: If that header is malformed (e.g. it appears to contain multiple mailboxes where inappropriate or lacks the clarifying corresponding Sender: header, ...) -Peter From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 17:07: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 RAA22405 for ; Sun, 5 Sep 2004 17:07:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85Kl9YF033689; Sun, 5 Sep 2004 13:47: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 i85Kl9Wx033688; Sun, 5 Sep 2004 13:47:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miranda.server-plant.co.uk (miranda.server-plant.co.uk [193.110.88.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85Kl7rL033670 for ; Sun, 5 Sep 2004 13:47:08 -0700 (PDT) (envelope-from johnp@idimo.com) Received: from idimo2 ([62.87.77.40]) (authenticated) by miranda.server-plant.co.uk (8.11.6/8.11.2) with ESMTP id i85KlGT16537 for ; Sun, 5 Sep 2004 21:47:17 +0100 Message-ID: <00b901c49389$875a6f30$284d573e@idimo2> From: "jpinkerton" To: References: <002e01c49281$f106aec0$2766f30a@development.greatgulfhomes.com> <413B2598.8070606@astrum.ch> Subject: Re: consensus call of RR prefix Date: Sun, 5 Sep 2004 21:56:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Matthias Leisi" To: "'IETF MARID WG'" Sent: Sunday, September 05, 2004 4:41 PM Subject: Re: consensus call of RR prefix > Which DNS providers do (not) allow subdomains and/or TXT records? A list of ones that do, is at http://www.spf.idimo.com It's not a complete list, but I will update it with information sent to me. Kind regards, John Pinkerton. johnp@idimo.com ICQ 313355492 From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 17:17: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 RAA22751 for ; Sun, 5 Sep 2004 17:17: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 i85Ks87x034581; Sun, 5 Sep 2004 13:54: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 i85Ks8BY034580; Sun, 5 Sep 2004 13:54:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85Ks7bZ034573 for ; Sun, 5 Sep 2004 13:54:07 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C440E-0000Fg-WC; Sun, 05 Sep 2004 16:52:47 -0400 Message-ID: <413B7CFD.6020402@solidmatrix.com> Date: Sun, 05 Sep 2004 16:54:21 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Graham Murray CC: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra References: <16695.49071.671776.708651@giles.gnomon.org.uk> <16698.1388.231292.755112@giles.gnomon.org.uk> <16699.25176.185782.397897@giles.gnomon.org.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Murray wrote: > Roy Badami writes: > > > >>The effect of this is that even if the users MUA is Sender ID aware, >>and displays the PRA, there's no guarantee it is displaying the same >>identity that was validated by the MTA. > > > Which is why it would be better for the MTA to create a header to > inform the MUA of the PRA and for the MUA to display that. If this > were done then it would be necessary to specify that the MTA MUST > remove any such headers already in the mail. > This would be a problem with multi-hop forwarders. Yakov From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 17:23:11 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 RAA22935 for ; Sun, 5 Sep 2004 17:23:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85L1Xgu035511; Sun, 5 Sep 2004 14:01:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85L1Xq4035510; Sun, 5 Sep 2004 14:01:33 -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 i85L1XCF035484 for ; Sun, 5 Sep 2004 14:01:33 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.152] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id B1C2640E4 for ; Sun, 5 Sep 2004 14:01:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200409051824.i85IOOg02258@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200409051824.i85IOOg02258@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: From: Mark Lentczner Subject: Re: consensus call of RR prefix Date: Sun, 5 Sep 2004 14:01:45 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i85L1XCF035502 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Three items to respond to: [-1-] On Sep 5, 2004, at 6:33 AM, william(at)elan.net wrote: >> -prefix does not solve the wildcard issue > Actually prefix helps wildcard issues and solves at least one of them. > It allows to avoid necessity to enter separate records for both > "example,com" > and for "*.example.com" while with prefix one record for > "*.example.com" > would suffice and cover both _prefix.example.com and anything else like > _prefix.subdonain.example.com. Usually, the use of the wild-card record is to say "-all" for anything in a subdomain, and hence this record is would not be the same as the domain's record: with prefix: _prefix.example.com IN SPF2 "spf2.0/pra +mx +a -all" *.example.com IN SPF2 "spf2.0/pra -all" without prefix: example.com IN SPF2 "spf2.0/pra +mx +a -all" *.example.com IN SPF2 "spf2.0/pra -all" There is no savings and no difference. On rare occasion when you want the same record, a prefix fails to help: with prefix: *.example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all" without prefix: example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all" *.example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all" It still makes no difference over-the-wire: Only one record would be ever returned, so this savings is only one administrative entry. Not a ringing endorsement in my mind. [-2-] On Sep 5, 2004, at 9:31 AM, Rand Wacker wrote: > The 480 byte limit is a limit of UDP. As has been pointed out, this limit is not in UDP, but in the original DNS spec, which was later removed with EDNS0. You can check what a server's limit is with a dig command like: dig +bufsize=1000 example.com txt You will find a line in the results like: ; EDNS: version: 0, flags:; udp: 4096 The 'udp' number gives the maximum size the server can support before falling over to TCP. If the resolver querying also does EDNS0, then the min of the two numbers can be used. Finding a resolver's advertised EDNS0 can be a bit tricky, involving tcpdump. On my servers, running several year old Linux distributions, the EDNS0 sizes were all either 2048 or 4096. [-3-] On Sep 5, 2004, at 11:24 AM, Peter Koch wrote: > this reference is questionable at best (read: DOC-BUG). RFC 3226 > specifies > behaviour of RFC2874-conformant DNS implementations (A6 is kinda dead > now) > and for DNSSEC-aware DNS implementations. None of both is relevant to > the draft > in question and, more importantly, it is suboptimal to reference a > requirements document for DNS server implementations this way. The actual text from the current draft is: "Sender-ID compliant sites MUST use DNS recursive servers that support EDNS0 [RFC2671] and [RFC3226] in order to be able to receive large DNS RR sets." This text, including the reference to RFC3226, came directly from Ólafur of DNS-EXT. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 18:19: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 SAA26133 for ; Sun, 5 Sep 2004 18:19: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 i85LsQfx043134; Sun, 5 Sep 2004 14:54:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i85LsQVJ043133; Sun, 5 Sep 2004 14:54:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85LsNeL043120 for ; Sun, 5 Sep 2004 14:54:25 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i85M4Ac0018043; Sun, 5 Sep 2004 18:04:10 -0400 From: To: "'Matthias Leisi'" , "'IETF MARID WG'" Subject: RE: consensus call of RR prefix Date: Sun, 5 Sep 2004 17:52:34 -0400 Message-ID: <00ec01c49392$a72effc0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <413B2598.8070606@astrum.ch> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Matthias Leisi > Sent: Sunday, September 05, 2004 10:41 AM > To: 'IETF MARID WG' > Subject: Re: consensus call of RR prefix > > > > > > terry@ashtonwoodshomes.com wrote: > > > -not all dns servers support "_" > > Just for clarification: Which DNS servers do /not/ support > underscores? Sorry, that should read: DNS providers whose UI on the server does not support "_". > > I know from testing that BIND 9 is happy with them; since > Microsoft uses > them for some AD stuff, I guess that at least newer > implementations of > their DNS services will not choke on them. > > Local DNS libraries seem to be able to handle it - at least I haven't > heard of resolver-library incompatibility with products that > use Apple's > Rendezvous, which is based on kind-of-SRV records and also use SRV's > _._ scheme. > > Of course, further testing would be fine, but technically > most relevant > pieces of DNS software around should not have issues underscores. > > > > -many dns providers do not allow subdomains (or not easily > via an interface, and we need to keep > > publishing easy or it won't get done)(yes I know many ISPs > don't support TXT RR either, but that > > *is* changing and it *is* an RFC compliant DNS standard, > even if SPF abuses it) > > Which DNS providers do (not) allow subdomains and/or TXT records? Again, its not just about whether the DNS provider refuses. My personal DNS provider does not support, TXT, so I had to wade through a support call (which turned into emails) to get them to set my vanity domain with an SPF record. But not everyone (most?) with domains (vanity or otherwise) would go to that effort. I expect many/most DNS providers will enhance their UI to allow TXT records (all I have contacted or heard about have said "coming soon"). But at least some (including mine) are not allowing subdomains or extensions beyond the usual www, ftp etc. (Course, the subdomain could become one of "the usual", if its ratified) > > Adding something a record for "_spf" should not be any different from > adding a "www" record to a domain. Agreed. But its not me that needs convincing, its the DNS providers. > > (Adding TXT records to the admin GUI of my non-profit ISP took me a > couple of minutes.) Agreed it can be done (providing the backend DNS server can do it). But some DNS providers have big fancy (aka crappy) integrated (often flash based, ugh!) UI's (e.g. look.ca) Changing those UI's can be non trivial. > > IMO, there are no technical or admin issues for or against RR > prefixes. Provided you don't consider deployment/adoption technical, and you never have to explain to a "* Certified * Engineer" how/why things actually work. You really cannot just look at technical issues, you have to look at all that are reasonably relevant and can have an actual impact. > Having said that, there are of course policy reasons to > consider - eg if > we go for a dedicated record type for "MARID", there is no need for a > prefix (after all, we don't have a prefix for MX records). Agreed. And that *is* where I think (and believe) we are going, our own RR type. > > Still IMO, a prefix would only make sense if the TXT record > workaround > were a long-term solution. I suspect within about 4 years of dedicated RR type approval the significant majority of published domains would have switched. (Or at least published new type, hence the second lookup on the TXT type becomes unnecessary). This opinion is based on the idea that those who published TXT would be just as willing/eager to adopt the RR type, and that the new RR type is approved and deployed BEFORE SPF publishing becomes a "standard requirement" before sending email. > As this quite possibly is not the intention > of this working group, using a prefix does not offer any > benefits other > than possibly keeping the DNS response size below the magical > 418 bytes, > a restriction which can be easily worked around using > redirects by those > few(?) that would need it. Agreed. Terry > > -- Matthias > > -- > Brain-Log http://matthias.leisi.net/ > From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 18:22:40 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 SAA26479 for ; Sun, 5 Sep 2004 18:22:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85M06Ff043691; Sun, 5 Sep 2004 15:00: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 i85M06mm043690; Sun, 5 Sep 2004 15:00:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85M04t4043680 for ; Sun, 5 Sep 2004 15:00:05 -0700 (PDT) (envelope-from pk@TechFak.Uni-Bielefeld.DE) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i85M0O1S003223 for ; Mon, 6 Sep 2004 00:00:24 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i85M0Ot02792 for ; Mon, 6 Sep 2004 00:00:24 +0200 (MEST) Message-Id: <200409052200.i85M0Ot02792@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF MARID WG Subject: DOC-BUG/TECH-OMISSION in -protocol: A vs AAAA X-PGP-Fingerprint: 85 89 64 AD 73 79 92 1F C8 76 95 2D 15 09 19 93 X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2788.1094421623.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 06 Sep 2004 00:00:24 +0200 From: Peter Koch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is about subsections 4.3, 4.4 and 4.5 of draft-ietf-marid-protocol-02 and I'm not sure whether it's a doc-bug or the wording is deliberately chosen. o In 4.3, although the mechanism is called "a", suggesting similarity to the IPv4 address RR type "A" combined with the "Note" in 3.1 both A and AAAA RR types need to be checked, don't they? o In 4.4 the draft now only talks about A tyep resolution when it comes to identifying the MX target. Not only is this inconsistent with 3.1, it also questions the conclusion for 4.3 above. o NB: "if is one of the MX hosts" should be changed to something like "if is an IP address of one of the MX hosts", since is an address and cannot *be* the host. o 4.5 :"This mechanism tests if 's name is within a particular domain" suggested rewording: "This mechanism tests if the DNS reverse mapping for exists and consistently points to a domain name within a particular domain". o 4.5 "perform a PTR lookup against " suggests to look for a PTR RR for the address, which isn't meant. Rewording similar to the one above. Nice DoS opportunity, btw. -Peter From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 18:47:26 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 SAA28008 for ; Sun, 5 Sep 2004 18:47:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85MKrPv045953; Sun, 5 Sep 2004 15:20: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 i85MKrRx045952; Sun, 5 Sep 2004 15:20:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85MKqXx045936 for ; Sun, 5 Sep 2004 15:20:52 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i85MK7tu003596; Mon, 6 Sep 2004 00:20:07 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i85MFqrM009874; Mon, 6 Sep 2004 00:15:52 +0200 From: Hadmut Danisch Date: Mon, 6 Sep 2004 00:15:52 +0200 To: terry@ashtonwoodshomes.com Cc: "'IETF MARID WG'" Subject: Re: consensus call of RR prefix Message-ID: <20040905221552.GA9714@danisch.de> References: <002e01c49281$f106aec0$2766f30a@development.greatgulfhomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002e01c49281$f106aec0$2766f30a@development.greatgulfhomes.com> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 04, 2004 at 09:20:18AM -0400, terry@ashtonwoodshomes.com wrote: > > -many dns providers do not allow subdomains (or not easily via an interface, and we need to keep > publishing easy or it won't get done) I don't understand this statement. Why should _marid IN TXT "blabla" be a subdomain and not supported while www IN A 1.2.3.4 is a normal entry not causing a subdomain? Where's the difference? I believe this is easier and more supported than placing the TXT record directly in the domain name. Not all interfaces support IN TXT "..." or @ IN TXT "..." and many users don't understand that. A TXT record for _marid is plain, strait forward, and simple. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 19:45:26 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 TAA01068 for ; Sun, 5 Sep 2004 19:45:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85NKGF0054699; Sun, 5 Sep 2004 16:20: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 i85NKGC3054698; Sun, 5 Sep 2004 16:20:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85NKFLl054691 for ; Sun, 5 Sep 2004 16:20:15 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i85NUCc0019287; Sun, 5 Sep 2004 19:30:12 -0400 From: To: "'Hadmut Danisch'" Cc: "'IETF MARID WG'" Subject: RE: consensus call of RR prefix Date: Sun, 5 Sep 2004 19:18:35 -0400 Message-ID: <011801c4939e$abea6e80$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20040905221552.GA9714@danisch.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Hadmut Danisch [mailto:hadmut@danisch.de] > Sent: Sunday, September 05, 2004 6:16 PM > To: terry@ashtonwoodshomes.com > Cc: 'IETF MARID WG' > Subject: Re: consensus call of RR prefix > > > On Sat, Sep 04, 2004 at 09:20:18AM -0400, > terry@ashtonwoodshomes.com wrote: > > > > -many dns providers do not allow subdomains (or not easily > via an interface, and we need to keep > > publishing easy or it won't get done) > > > I don't understand this statement. > > > > Why should > > _marid IN TXT "blabla" > > be a subdomain and not supported while > > www IN A 1.2.3.4 > > is a normal entry not causing a subdomain? Where's the difference? www is already built in (visibly or implied) for DNS providers UI. Non standard subdomains often are not. I am not saying this is correct (its not) or acceptable (that's a business model decision of DNS provider) but I believe it to be a reality for at least some DNS providers. > > > > > I believe this is easier and more supported than placing the > TXT record directly in the domain name. Not all interfaces support I disagree, I have seen more UI's that support TXT records (albeit very few, but apparently more and more every day) then support adhoc (beyond the standard www, ftp, etc) subdomains. > > IN TXT "..." > or > @ IN TXT "..." > > and many users don't understand that. A TXT record for _marid > is plain, strait forward, and simple. I agree *if* one understands how DNS works. I would hazard a guess that a significant number of owners of domain names wouldn't. This alone does not constitute grounds for non-deployment of _marid, but it is still a valid point against. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > > > regards > Hadmut > From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 19:52:34 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 TAA01444 for ; Sun, 5 Sep 2004 19:52:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85NSGbF055573; Sun, 5 Sep 2004 16:28: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 i85NSGvV055572; Sun, 5 Sep 2004 16:28:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i85NSFNH055531 for ; Sun, 5 Sep 2004 16:28:15 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so140596rnk for ; Sun, 05 Sep 2004 16:28:19 -0700 (PDT) Received: by 10.38.171.2 with SMTP id t2mr1089077rne; Sun, 05 Sep 2004 16:28:18 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Sun, 5 Sep 2004 16:28:18 -0700 (PDT) Message-ID: <94df60cf0409051628393e4481@mail.gmail.com> Date: Sun, 5 Sep 2004 19:28:18 -0400 From: Reply-To: To: Peter Koch Subject: Re: DOC-BUG/TECH-OMISSION in -protocol: A vs AAAA Cc: IETF MARID WG In-Reply-To: <200409052200.i85M0Ot02792@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200409052200.i85M0Ot02792@grimsvotn.TechFak.Uni-Bielefeld.DE> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 06 Sep 2004 00:00:24 +0200, Peter Koch wrote: > > o In 4.3, although the mechanism is called "a", suggesting similarity to > the IPv4 address RR type "A" combined with the "Note" in 3.1 both A and > AAAA RR types need to be checked, don't they? Interesting. Now that you've pointed it out, I think there might be an ambiguity. In particular, I always assumed that, for example, "a/24" meant check IPv4, while "a//64" meant check IPv6, and just "a" meant check both (same as "a/32//128"). But I guess it might be possible to interpret "a/24" as equivalent to "a/24//128" and "a//64" as equivalent to "a/32//128". In fact, reading section 4 pedantically, I think that may be the more exact interpretation. This is slightly annoying, because it would have been nice to have a mechanism to restrict a particular use of the mechanism to IPv4 or IPv6. In fact, while we are nitpicking, the capitalization of "cidr-length" is not consistent. Section 4 uses CIDR-length, while 4.6 uses "cidr-length". Moreover, that term is never formally defined. Therefore, in addition to fixing the ambiguity above, I also propose the following change to section 4.6. Change: If the cidr-length is omitted, the ip4-cidr-length is taken to be "/32" and the ip6-cidr-length is taken to be "/128". To: If ip4-cidr-length is omitted, it is taken to be "/32". If ip6-cidr-length is omitted, it is taken to be "/128". In fact, it's probably too late for this, but I wonder if for consistency the grammar shouldn't have been: IP6 = "ip6" ":" ip6-network [ "/" ip6-cidr-length ] and the default "//128". David From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 20:19: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 UAA02407 for ; Sun, 5 Sep 2004 20:19: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 i85Nrw6w058707; Sun, 5 Sep 2004 16:53: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 i85Nrwqf058706; Sun, 5 Sep 2004 16:53:58 -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 i85NrvpN058695 for ; Sun, 5 Sep 2004 16:53:57 -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 i8604J3h021235; Sun, 5 Sep 2004 17:04:19 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8604Jdw021232; Sun, 5 Sep 2004 17:04:19 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 5 Sep 2004 17:04:19 -0700 (PDT) From: "william(at)elan.net" To: Mark Lentczner cc: IETF MARID WG Subject: Re: consensus call of RR prefix 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 Sun, 5 Sep 2004, Mark Lentczner wrote: > Three items to respond to: > > [-1-] > On Sep 5, 2004, at 6:33 AM, william(at)elan.net wrote: > >> -prefix does not solve the wildcard issue > > Actually prefix helps wildcard issues and solves at least one of them. > > It allows to avoid necessity to enter separate records for both > > "example,com" and for "*.example.com" while with prefix one record for > > "*.example.com" would suffice and cover both _prefix.example.com and > > anything else like _prefix.subdonain.example.com. > > Usually, the use of the wild-card record is to say "-all" for anything > in a subdomain, and hence this record is would not be the same as the > domain's record: That depends on the use of wildcards. When wildcards are used in parallel with wildcard MX entries, then the SPF record for domain and widlcard subdomains will most likely be the same. Different situation is for somebody who just wants to say that there are no working subdomains under his domain, then "-all" can be used. But do remember that wildcard will actually not work for any subdomain that is deligated (i.e. ones that have their own direct "A", "MX" or any other record) so this might not have much value as I don't think spoofing non-existing hosts is very common and these can be quickly cought by just checking if the host actually exists... > with prefix: > _prefix.example.com IN SPF2 "spf2.0/pra +mx +a -all" > *.example.com IN SPF2 "spf2.0/pra -all" > > without prefix: > example.com IN SPF2 "spf2.0/pra +mx +a -all" > *.example.com IN SPF2 "spf2.0/pra -all" I assert that if you have wildcard MX record, then you would actually want wildcard subdomain record to be exactly the same, see above. > There is no savings and no difference. On rare occasion when you want > the same record, a prefix fails to help: > > with prefix: > *.example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all" > > without prefix: > example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all" > *.example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all" > > It still makes no difference over-the-wire: Only one record would be > ever returned, so this savings is only one administrative entry. Not a > ringing endorsement in my mind. I agree with above, there is no difference in the wire, the difference is only that administrator needs to enter one record instead of two. And yes, this is not very strong reason to do it, but it does mean that on at least one issue (be it a small one), the prefix does help with wildcards where as every other issue is exactly the same no matter if prefix is used or not. So really we should not put any statement like that "-prefix does not solve the wildcard issue", as not using prefix does not solve these issues either! -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 22:26:48 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 WAA08882 for ; Sun, 5 Sep 2004 22:26:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i861tVVf075565; Sun, 5 Sep 2004 18:55:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i861tVD9075564; Sun, 5 Sep 2004 18:55:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i861tT3t075554 for ; Sun, 5 Sep 2004 18:55:30 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 91016 invoked from network); 6 Sep 2004 01:55:49 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 6 Sep 2004 01:55:49 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "'IETF MARID WG'" Subject: RE: consensus call of RR prefix Date: Sun, 5 Sep 2004 21:55:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040905221552.GA9714@danisch.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hadmut Danisch > Sent: Sunday, September 05, 2004 6:16 PM > To: terry@ashtonwoodshomes.com > Cc: 'IETF MARID WG' > Subject: Re: consensus call of RR prefix > > Why should > > _marid IN TXT "blabla" > > be a subdomain and not supported while > > www IN A 1.2.3.4 > > is a normal entry not causing a subdomain? Where's the difference? > > I believe this is easier and more supported than placing the > TXT record directly in the domain name. Not all interfaces support > > IN TXT "..." > or > @ IN TXT "..." > > and many users don't understand that. A TXT record for _marid > is plain, strait forward, and simple. > I can't tell you why, but today, I can do all of those you list through my DNS provider except, _marid. I could do marid without the _, but without the _, you lose some of the collision avoidance potential. Trying to add an A record for _marid gets me this error: "Host names may only contain 0-9, A-Z, or hyphen (-) characters." Is that incorrect? Yes. Is that common? Yes. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Sun Sep 5 22:34: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 WAA09252 for ; Sun, 5 Sep 2004 22:34: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 i8629bx0078221; Sun, 5 Sep 2004 19:09:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8629bsw078220; Sun, 5 Sep 2004 19:09:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8629aEj078212 for ; Sun, 5 Sep 2004 19:09:37 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i862JVc0022303; Sun, 5 Sep 2004 22:19:31 -0400 From: To: "'william(at)elan.net'" , "'Mark Lentczner'" Cc: "'IETF MARID WG'" Subject: RE: consensus call of RR prefix Date: Sun, 5 Sep 2004 22:07:53 -0400 Message-ID: <011b01c493b6$52a39640$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of > william(at)elan.net > Sent: Sunday, September 05, 2004 8:04 PM > To: Mark Lentczner > Cc: IETF MARID WG > Subject: Re: consensus call of RR prefix > > > > > On Sun, 5 Sep 2004, Mark Lentczner wrote: > > > Three items to respond to: > > > > [-1-] > > On Sep 5, 2004, at 6:33 AM, william(at)elan.net wrote: > > >> -prefix does not solve the wildcard issue > > > Actually prefix helps wildcard issues and solves at least > one of them. > > > It allows to avoid necessity to enter separate records for both > > > "example,com" and for "*.example.com" while with prefix > one record for > > > "*.example.com" would suffice and cover both > _prefix.example.com and > > > anything else like _prefix.subdonain.example.com. > > > > Usually, the use of the wild-card record is to say "-all" > for anything > > in a subdomain, and hence this record is would not be the > same as the > > domain's record: > > That depends on the use of wildcards. When wildcards are used > in parallel > with wildcard MX entries, then the SPF record for domain and widlcard > subdomains will most likely be the same. > > Different situation is for somebody who just wants to say > that there are > no working subdomains under his domain, then "-all" can be > used. But do > remember that wildcard will actually not work for any > subdomain that is > deligated (i.e. ones that have their own direct "A", "MX" or > any other > record) so this might not have much value as I don't think spoofing > non-existing hosts is very common and these can be quickly > cought by just > checking if the host actually exists... > > > with prefix: > > _prefix.example.com IN SPF2 "spf2.0/pra +mx +a -all" > > *.example.com IN SPF2 "spf2.0/pra -all" > > > > without prefix: > > example.com IN SPF2 "spf2.0/pra +mx +a -all" > > *.example.com IN SPF2 "spf2.0/pra -all" > > I assert that if you have wildcard MX record, then you would > actually want > wildcard subdomain record to be exactly the same, see above. > > > There is no savings and no difference. On rare occasion > when you want > > the same record, a prefix fails to help: > > > > with prefix: > > *.example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all" > > > > without prefix: > > example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all" > > *.example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all" > > > > It still makes no difference over-the-wire: Only one record > would be > > ever returned, so this savings is only one administrative > entry. Not a > > ringing endorsement in my mind. > > I agree with above, there is no difference in the wire, the > difference is > only that administrator needs to enter one record instead of two. > > And yes, this is not very strong reason to do it, but it does mean > that on at least one issue (be it a small one), the prefix does help > with wildcards where as every other issue is exactly the same no > matter if prefix is used or not. So really we should not put any > statement like that "-prefix does not solve the wildcard issue", > as not using prefix does not solve these issues either! Please relax, "-prefix does not solve the wildcard issue" does *not* mean/imply "lack of prefix solves the wildcard issue", because if it did, then the statement would be "-prefix causes an issue with wildcards". There are wildcard issues that exist without prefixes, if they didn't, there wouldn't be any issue for us to discuss... There are wildcard issues that are as yet unresolved (albeit rare). I thought that prefixes were proposed as a solution (weren't they?) and were found not to be a resolution. If that was not the case my mistake. But either way, the statement is accurate as having a prefix does not actually *solve* a wildcard issue. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > > -- > William Leibzon > Elan Networks > william@elan.net > From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 00:09:17 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 AAA14416 for ; Mon, 6 Sep 2004 00:09: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 i863g74f041084; Sun, 5 Sep 2004 20:42: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 i863g70m041083; Sun, 5 Sep 2004 20:42:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i863g6Gp041074 for ; Sun, 5 Sep 2004 20:42:06 -0700 (PDT) (envelope-from SRS0=GrHSRcoT=L3=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i863gP39004925 for ; Mon, 6 Sep 2004 05:42:25 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409060342.I863GJ82004890@asarian-host.net> Date: Mon, 06 Sep 2004 03:42:25 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: consensus call of RR prefix X-Trace: Diu6/1Pnr8ZJ9Vqjr1Zor4akkF8CRj4MBrDLuHPwxY7JdsSypC+aUppovkc0U3VKJi1mIeQlj7XowIo9LFBHww== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQTvcoTFqW1BleBN9AQFZNgf/XCxzGxvd9bX9Ku+hHhXilkbcDLUDXVID X+/eZ0QMeh2C+8ry/65dwm++3ytR+EonInVqQplPFjfR7Q3KiV5fbmARrF/A9YAn C+x233Jk7LMGAgV8BnBw6FNmrI3FYgJ0vyQZo9/2Ep4P8vSlDe0nOQCAo8/8Q6LM 1lwBLqY3iHFPDWzIDb9fjEYnVfhBt2EoNXu+9/iOsdK7y9D72JARW7ZmY2hl1Q3y /5A7XAUrxZ5DW1EdB86UywJBsTStQZNZhJMKNWDf4j4rjo7eHkv4hXCRwqI2Xj+Y WyoCezyzeCsZWVWAOs+GEeyKgt56Koag7sSVtV9P7PwJhzNFJz9VFA== =7Yn8 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> Why should >> >> _marid IN TXT "blabla" >> >> be a subdomain and not supported while >> >> www IN A 1.2.3.4 >> >> is a normal entry not causing a subdomain? If we require an underscored _marid prefix to prevent potential collisions with existing namespace, are we then not dealing with a circular reasoning here? I mean, if the underscore prefix is not widely deployed because few DNS providers support it, then choosing an underscored prefix to avoid collision leads to having to make world-wide changes to providers' User Interfaces, so that the _marid prefic can be widely deployed; after which time you lost the advantage again of not running the risk of collision. In that case, we might as well drop the underscore requirement to begin with. - Mark From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 01:23: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 BAA17972 for ; Mon, 6 Sep 2004 01:23:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i864p5wO050241; Sun, 5 Sep 2004 21:51: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 i864p5rO050240; Sun, 5 Sep 2004 21:51:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i864p4aw050206 for ; Sun, 5 Sep 2004 21:51:04 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i864pJL2005049 for ; Mon, 6 Sep 2004 05:51:19 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i864pJoP005048; Mon, 6 Sep 2004 05:51:19 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra References: <16695.49071.671776.708651@giles.gnomon.org.uk> <16698.1388.231292.755112@giles.gnomon.org.uk> <16699.25176.185782.397897@giles.gnomon.org.uk> <413B7CFD.6020402@solidmatrix.com> From: Graham Murray Date: Mon, 06 Sep 2004 05:51:19 +0100 In-Reply-To: <413B7CFD.6020402@solidmatrix.com> (Yakov Shafranovich's message of "Sun, 05 Sep 2004 16:54:21 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov Shafranovich writes: > Graham Murray wrote: > >> Roy Badami writes: >> >>>The effect of this is that even if the users MUA is Sender ID aware, >>>and displays the PRA, there's no guarantee it is displaying the same >>>identity that was validated by the MTA. >> Which is why it would be better for the MTA to create a header to >> inform the MUA of the PRA and for the MUA to display that. If this >> were done then it would be necessary to specify that the MTA MUST >> remove any such headers already in the mail. >> > > This would be a problem with multi-hop forwarders. Why? Sender-ID only authenticates the last hop anyway, so the PRA which the MUA would derive should always be the same as that derived and validated by the last MTA handling the email. From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 02:11: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 CAA01720 for ; Mon, 6 Sep 2004 02:11:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i865ghND073007; Sun, 5 Sep 2004 22:42: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 i865ghEF073006; Sun, 5 Sep 2004 22:42:43 -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 i865ghqI073000 for ; Sun, 5 Sep 2004 22:42:43 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i865go0I010023; Sun, 5 Sep 2004 22:42:50 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <96D67050-FFC7-11D8-BB5A-000A95AC5778@isipp.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: DEPLOY: Rejection of Sender ID does not result in standardiza tion of SPF Classic Date: Sun, 5 Sep 2004 22:42:50 -0700 To: Dean Anderson 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 >> And the the relative lack of a proficiency barrier to entry. > > This is a popular myth. Proficiency is not a problem. The abusers are > quite proficient, and quite determined, and frequently quite > resourceful. I meant lack of proficiency at accessing (heck, even just *grokking*) Usenet by the end users. People who have a clue as to what Usenet is, let alone who can gain sufficient proficiency to use it, are a tiny minority compared those who know what blogs, wiki, and even "bboard" are. This is getting horribly off-topic now, for which I apologize. I just wanted to clarify my statement. Anne From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 02:11: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 CAA01814 for ; Mon, 6 Sep 2004 02:11:32 -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 i865l7aY075311; Sun, 5 Sep 2004 22:47: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 i865l7vb075310; Sun, 5 Sep 2004 22:47:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sasl.smtp.pobox.com (puzzle.sasl.smtp.pobox.com [207.8.226.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i865l6u6075297 for ; Sun, 5 Sep 2004 22:47:06 -0700 (PDT) (envelope-from McQuilWP@pobox.com) Received: from localhost.localdomain (localhost [127.0.0.1]) by puzzle.pobox.com (Postfix) with ESMTP id D8AE813909D; Mon, 6 Sep 2004 01:45:17 -0400 (EDT) Received: from MCQWP2 (ip68-7-159-196.sd.sd.cox.net [68.7.159.196]) by puzzle.pobox.com (Postfix) with ESMTP id 0B845139081; Mon, 6 Sep 2004 01:45:17 -0400 (EDT) Date: Sun, 5 Sep 2004 22:47:25 -0700 From: Bill McQuillan X-Mailer: The Bat! (v2.11) Personal X-Priority: 3 (Normal) Message-ID: <1099091374.20040905224725@pobox.com> To: MARID Subject: Re: consensus call of RR prefix In-Reply-To: <200409060342.I863GJ82004890@asarian-host.net> References: <200409060342.I863GJ82004890@asarian-host.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-09-05, Mark wrote: > If we require an underscored _marid prefix to prevent potential collisions > with existing namespace, are we then not dealing with a circular reasoning > here? > I mean, if the underscore prefix is not widely deployed because few DNS > providers support it, then choosing an underscored prefix to avoid collision > leads to having to make world-wide changes to providers' User Interfaces, so > that the _marid prefic can be widely deployed; after which time you lost the > advantage again of not running the risk of collision. I believe the reason for the underscore is that it is, in fact, NOT a valid *hostname* character, but it IS valid in a domain name. It seems to be a common, but incorrect, belief that DNS is only for hostnames. -- Bill McQuillan From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 02:38: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 CAA05831 for ; Mon, 6 Sep 2004 02:38: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 i866CVZU089484; Sun, 5 Sep 2004 23:12:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i866CVkJ089483; Sun, 5 Sep 2004 23:12:31 -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 i866CTwO089461 for ; Sun, 5 Sep 2004 23:12:30 -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 1C4Ck6-0004qQ-ST for ietf-mxcomp@imc.org; Mon, 06 Sep 2004 01:12:52 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 06 Sep 2004 01:12:42 -0500 In-Reply-To: (Ted Hardie's message of "Fri, 3 Sep 2004 12:30:28 -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: Obstacles between us and the finish line 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.6 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 Ted Hardie writes: > At 8:13 PM -0500 9/2/04, wayne wrote: >> >> > 4) IP licensing: I'm not dogmatic about the GPL or commercial >>> licenses, but there are significant MTAs and mail filters that fall >>> under both kinds of licenses, and several others to boot. I think >>> that any proposal that has incompatible IP licensing needs to be >>> dropped. >> >>Sadly, in response to this post back in July, Ted Hardie (the IETF >>Area Director for this WG), told us to stop worry about IP licensing >>issues. I believe the mess we are in right now is a direct result of >>this. Instead of getting the IP licensing issue resolved *much* >>earlier on, we now have a crisis and a no-win situation. > > There's no reference to which post of mine is meant, but I > assume http://www.imc.org/ietf-mxcomp/mail-archive/msg02748.html > is the one to which this refers. I'm sorry, I should have been clearer. I was referring to your earlier post: http://www.imc.org/ietf-mxcomp/mail-archive/msg02660.html > That post did not say "stop worrying about the licensing issues", > it said "Discuss licensing in terms of the engineering decisions" > or more fully: In the post I was referring to, Shevek was describing the friction caused by the use of new/unfamiliar licenses and how people often picked familiar licenses instead. In response you wrote, in part: : I urge the working group to stop fixating on this and go back to reviewing : and contributing to the specifications. This list is intended to focus on : the engineering needed to get its charter done, and we have enough distractions : without raising this spectre from its well-deserved grave. In neither post did you take steps to get the IPR license issue resolved. I'm afraid that the IPR issue have never been placed in the grave and this spectre will continue to be raised as long as the patent license terms conflict with so much of the existing email infrastructure. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 03:02: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 DAA06811 for ; Mon, 6 Sep 2004 03:02: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 i866axfe099518; Sun, 5 Sep 2004 23:36: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 i866axC9099517; Sun, 5 Sep 2004 23:36:59 -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 i866aq0Q099446 for ; Sun, 5 Sep 2004 23:36:59 -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.8/8.12.8) with ESMTP id i866bB1U022006 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 6 Sep 2004 02:37:12 -0400 Message-Id: <6.1.2.0.2.20040906022550.06b8dd70@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 06 Sep 2004 02:31:52 -0400 To: MARID From: Daniel Senie Subject: Re: consensus call of RR prefix In-Reply-To: <1099091374.20040905224725@pobox.com> References: <200409060342.I863GJ82004890@asarian-host.net> <1099091374.20040905224725@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 01:47 AM 9/6/2004, Bill McQuillan wrote: >On Sun, 2004-09-05, Mark wrote: > > If we require an underscored _marid prefix to prevent potential collisions > > with existing namespace, are we then not dealing with a circular reasoning > > here? > > > I mean, if the underscore prefix is not widely deployed because few DNS > > providers support it, then choosing an underscored prefix to avoid > collision > > leads to having to make world-wide changes to providers' User > Interfaces, so > > that the _marid prefic can be widely deployed; after which time you > lost the > > advantage again of not running the risk of collision. > >I believe the reason for the underscore is that it is, in fact, NOT a >valid *hostname* character, but it IS valid in a domain name. It seems to >be a common, but incorrect, belief that DNS is only for hostnames. So let me get this straight. Folks are worried about the companies some people outsource their DNS to (instead of running their own servers) not handling _marid or _foo or whatever the tag would be. But folks are not worried about updating name server software to support a new RR type and getting that software deployed, and are not worried about getting MTA software updated to handle new a new capability and get that deployed. Am I the only one who thinks this is looney? If SPF or SenderID become accepted, then people will update MTA software to make it work. They will update DNS server software to make it work. And if outsourced DNS providers wish to remain competitive, they'll add capabilities to their GUIs. Let the market handle it. It sure seems like folks are getting hung up over what's probably the EASIEST thing to deal with, that being finding a DNS outsourcer (if you even need one) that'll publish the records you request. Let's get back to deciding what's right at the protocol level, and leave the business decisions of web-interfaced DNS providers out of the discussion. I, for one, would like to hear more on the technical merits of using _spf or _marid or _foo vs. not using it. From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 03:18: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 DAA07361 for ; Mon, 6 Sep 2004 03:18: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 i866tXth007111; Sun, 5 Sep 2004 23:55:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i866tXTn007110; Sun, 5 Sep 2004 23:55:33 -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 i866tWBx007095 for ; Sun, 5 Sep 2004 23:55:32 -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 1C4DPr-0005K0-2u for ietf-mxcomp@imc.org; Mon, 06 Sep 2004 01:55:56 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 06 Sep 2004 01:55:50 -0500 In-Reply-To: (Andrew Newton's message of "Fri, 3 Sep 2004 17:33:48 -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: consensus call on MUST/SHOULD language for TXT records 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.6 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 Andrew Newton writes: > Despite lack of agreement on the outcome, there is agreement on the > stated positions. In the words of Olafur: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant > state during phase-in. I know the chairs asked to not discuss the IPR issue any more, but the SenderID license seems to rule out option 2. According to section 1.2, a "Licensed Implementation" must be complaint with all required portions of the SenderID. While the SenderID license only directly references marid-pra and marid-core, the marid-core I-D has a normative reference to the marid-protocol I-D and section 3 of marid-core requires you to use the check_host function. So, if marid-protocol says that check_host MUST query the SPF RR and an implementation doesn't, then it is not confromant and the implementation does not qualify to use the SenderID license. If you are in a situation such as Jim Lyon described at the iterim meeting where you are in a pure Microsoft network, the Windows API doesn't even have the ability to query for new RR types, you are kind of out of luck. As Jim described it, you can't even code up raw UDP packets because they won't make it out of the network. The problems of the license requiring conformance was brought up by Dan Quinlan back in June, if I recall correctly. This is just one example of such a problem. So, if we are planning on supporting SenderID, it appears that we MUST allow everyone to always be conformant at all times. This means that we MUST NOT require implementations to query SPF RRs. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 03:42: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 DAA08640 for ; Mon, 6 Sep 2004 03:42: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 i867G8Wj015195; Mon, 6 Sep 2004 00:16: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 i867G8K5015194; Mon, 6 Sep 2004 00:16:08 -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 i867G3o9015148 for ; Mon, 6 Sep 2004 00:16:04 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id B62D526C077; Mon, 6 Sep 2004 09:16:24 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 8C3F026C068; Mon, 6 Sep 2004 09:16:23 +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 i867GNm7730910; Mon, 6 Sep 2004 09:16:23 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 59BDFFACC; Mon, 6 Sep 2004 09:16:23 +0200 (CEST) Date: Mon, 6 Sep 2004 09:16:23 +0200 From: Stephane Bortzmeyer To: Peter Koch Cc: IETF MARID WG Subject: Re: DOC-BUG/TECH-OMISSION in -protocol: A vs AAAA Message-ID: <20040906071623.GB18151@nic.fr> References: <200409052200.i85M0Ot02792@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409052200.i85M0Ot02792@grimsvotn.TechFak.Uni-Bielefeld.DE> 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+20040523i 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 Mon, Sep 06, 2004 at 12:00:24AM +0200, Peter Koch wrote a message of 27 lines which said: > o In 4.3, although the mechanism is called "a", suggesting > similarity to the IPv4 address RR type "A" Unfortunately, yes, there is a potential for confusion, but this is probably for historical reasons. > combined with the "Note" in 3.1 both A and AAAA RR types need to be > checked, don't they? Yes. > o In 4.4 the draft now only talks about A tyep resolution when it > comes to identifying the MX target. Not only is this inconsistent > with 3.1, it also questions the conclusion for 4.3 above. Already reported: http://www.imc.org/ietf-mxcomp/mail-archive/msg03518.html From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 03:45:44 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 DAA08987 for ; Mon, 6 Sep 2004 03:45: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 i867O1Vs018222; Mon, 6 Sep 2004 00:24: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 i867O1BC018220; Mon, 6 Sep 2004 00:24: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 i867O0Pn018210 for ; Mon, 6 Sep 2004 00:24: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 i867YW9X031475; Mon, 6 Sep 2004 00:34:32 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i867YWXF031471; Mon, 6 Sep 2004 00:34:32 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 6 Sep 2004 00:34:32 -0700 (PDT) From: "william(at)elan.net" To: Daniel Senie cc: MARID Subject: Re: consensus call of RR prefix In-Reply-To: <6.1.2.0.2.20040906022550.06b8dd70@mail.amaranth.net> 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, 6 Sep 2004, Daniel Senie wrote: > So let me get this straight. > > Folks are worried about the companies some people outsource their DNS to > (instead of running their own servers) not handling _marid or _foo or > whatever the tag would be. But folks are not worried about updating name > server software to support a new RR type and getting that software > deployed, and are not worried about getting MTA software updated to handle > new a new capability and get that deployed. Folks are worried about both cases. The two cases are different and require different handling. First of all with new RR type, it is not only dns servers but some resolvers that may need to be updated, this is a process that takes quite a bit longer and requires recompiling dns servers and/or resolvers, people installing new software, etc. On the other hand with "_" prefix, all dns servers and resolvers can handle it. It is only that to managed these servers, number of providers have deployed custom GUI interfaces. In some cases, these interfaces set correct characters to be used and they have disallowed use of "_". It would not be hard to correct it - most of these GUI are interpted scripts (perl cgi, php, asp, etc) and to disallow those characters they have a filter function (that function checks if all characters in hostname or domain name are alphanumeric or "-") which is the only one that will need to be updated to allow "_" character. Not very hard to do and they really should have done it by now considering SRV records have existed for several years now. > Am I the only one who thinks this is looney? If SPF or SenderID become > accepted, then people will update MTA software to make it work. They will > update DNS server software to make it work. And if outsourced DNS providers > wish to remain competitive, they'll add capabilities to their GUIs. Let the > market handle it. I agree with you. If MARID becomes popular within a year all GUI will be able to handle underscores if its part of the standard. Its just a very easy fix for those who dont - see above. > It sure seems like folks are getting hung up over what's probably the > EASIEST thing to deal with, that being finding a DNS outsourcer (if you > even need one) that'll publish the records you request. > > Let's get back to deciding what's right at the protocol level, and leave > the business decisions of web-interfaced DNS providers out of the discussion. > > I, for one, would like to hear more on the technical merits of using _spf > or _marid or _foo vs. not using it. Using it allows to avoid collisions with other TXT records or with any other possible use of SPF in the future. And it gives a good example for anybody else who is considering temporarily using TXT records for their experiment. BTW - I now support that both TXT and SPF RR records be done in SRV way: _smtp._tcp.example.com. IN TXT "SPF2.0/PRA ..." _smtp._tcp.example.com. IN SPF "SPF2.0/PRA ..." -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 04:06: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 EAA12321 for ; Mon, 6 Sep 2004 04:06:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i867eZeJ025599; Mon, 6 Sep 2004 00:40: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 i867eZCo025598; Mon, 6 Sep 2004 00:40:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miranda.server-plant.co.uk (miranda.server-plant.co.uk [193.110.88.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i867eXFN025557 for ; Mon, 6 Sep 2004 00:40:34 -0700 (PDT) (envelope-from johnp@idimo.com) Received: from idimo2 ([62.87.73.157]) (authenticated) by miranda.server-plant.co.uk (8.11.6/8.11.2) with ESMTP id i867emT24223 for ; Mon, 6 Sep 2004 08:40:49 +0100 Message-ID: <006101c493e4$d418d400$9d49573e@idimo2> From: "jpinkerton" To: References: <200409060342.I863GJ82004890@asarian-host.net> <1099091374.20040905224725@pobox.com> <6.1.2.0.2.20040906022550.06b8dd70@mail.amaranth.net> Subject: Re: consensus call of RR prefix Date: Mon, 6 Sep 2004 09:39:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Daniel Senie" To: "MARID" Sent: Monday, September 06, 2004 8:31 AM Subject: Re: consensus call of RR prefix > > At 01:47 AM 9/6/2004, Bill McQuillan wrote: > > > >On Sun, 2004-09-05, Mark wrote: > > > If we require an underscored _marid prefix to prevent potential collisions > > > with existing namespace, are we then not dealing with a circular reasoning > > > here? > > > > > I mean, if the underscore prefix is not widely deployed because few DNS > > > providers support it, then choosing an underscored prefix to avoid > > collision > > > leads to having to make world-wide changes to providers' User > > Interfaces, so > > > that the _marid prefic can be widely deployed; after which time you > > lost the > > > advantage again of not running the risk of collision. > > > >I believe the reason for the underscore is that it is, in fact, NOT a > >valid *hostname* character, but it IS valid in a domain name. It seems to > >be a common, but incorrect, belief that DNS is only for hostnames. > > So let me get this straight. > > Folks are worried about the companies some people outsource their DNS to > (instead of running their own servers) not handling _marid or _foo or > whatever the tag would be. But folks are not worried about updating name > server software to support a new RR type and getting that software > deployed, and are not worried about getting MTA software updated to handle > new a new capability and get that deployed. > > Am I the only one who thinks this is looney? If SPF or SenderID become > accepted, then people will update MTA software to make it work. They will > update DNS server software to make it work. And if outsourced DNS providers > wish to remain competitive, they'll add capabilities to their GUIs. Let the > market handle it. > > It sure seems like folks are getting hung up over what's probably the > EASIEST thing to deal with, that being finding a DNS outsourcer (if you > even need one) that'll publish the records you request. > > Let's get back to deciding what's right at the protocol level, and leave > the business decisions of web-interfaced DNS providers out of the discussion. > > I, for one, would like to hear more on the technical merits of using _spf > or _marid or _foo vs. not using it. Me too - I am lost now - would someone like to summarise the requirement for a sub-domain at all. The reasoning has got lost in the chaff of whether it's possible - which it is, or will be once the standard hits the streets. I will happily add the names of DNS providers that have this facility to the list at www.dns.idimo.com so that there is the beginnings of a reference for people who want to experiment. Please see the notes on the website. Slainte, JohnP. johnp@idimo.com ICQ 313355492 From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 04:56:59 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 EAA15302 for ; Mon, 6 Sep 2004 04:56: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 i868RWQi046656; Mon, 6 Sep 2004 01:27:32 -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 i868RWd9046655; Mon, 6 Sep 2004 01:27:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i868RWEh046643 for ; Mon, 6 Sep 2004 01:27:32 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1C4Eqx-0007Ki-00 for ietf-mxcomp@imc.org; Mon, 06 Sep 2004 09:27:55 +0100 Message-ID: <044201c493ea$fcdfc410$0200000a@ringo> From: "Chris Haynes" To: References: <16695.49071.671776.708651@giles.gnomon.org.uk><16698.1388.231292.755112@giles.gnomon.org.uk><16699.25176.185782.397897@giles.gnomon.org.uk> Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra Date: Mon, 6 Sep 2004 09:24:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "Graham Murray" suggested: > > Roy Badami writes: > > > > The effect of this is that even if the users MUA is Sender ID aware, > > and displays the PRA, there's no guarantee it is displaying the same > > identity that was validated by the MTA. > > Which is why it would be better for the MTA to create a header to > inform the MUA of the PRA and for the MUA to display that. If this > were done then it would be necessary to specify that the MTA MUST > remove any such headers already in the mail. > This introduces its own security weakness: If the senders are forging the additional tag, and the MTA, for some reason or another, is not removing the headers - the MUA cannot detect that the header is bad. See my post: http://www.imc.org/ietf-mxcomp/mail-archive/msg03118.html for some of the circumstances in which this can occur. You end up with the MTA including time-stamps and host-identities in the additional header, and then you have to cryptographically sign it, and give the MUA the means to validate the signature. It's almost as easy just to sign the entire original message and solve the whole problem at one stroke! Chris Haynes From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 06:29: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 GAA20230 for ; Mon, 6 Sep 2004 06:29: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 i86A2Vw1088694; Mon, 6 Sep 2004 03:02:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i86A2VTf088690; Mon, 6 Sep 2004 03:02:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i86A2Qvp088594 for ; Mon, 6 Sep 2004 03:02:27 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-5.tower-48.messagelabs.com!1094464962!4920728 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 6102 invoked from network); 6 Sep 2004 10:02:43 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-5.tower-48.messagelabs.com with SMTP; 6 Sep 2004 10:02:43 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Sep 2004 11:02:42 +0100 Received: (qmail 6794 invoked from network); 5 Sep 2004 09:59:58 -0000 Received: from unknown (HELO ?10.0.1.2?) (10.191.100.2) by matt?dev.int.star.co.uk with SMTP; 5 Sep 2004 09:59:58 -0000 In-Reply-To: References: <4042BB90-FD92-11D8-B236-000A95AC67AA@messagelabs.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: Ryan Malayter , "Michael R. Brumm" , IETF MARID WG From: Matt Sergeant Subject: Re: (DEPLOY) In Support of Sender ID Date: Mon, 6 Sep 2004 11:02:42 +0100 To: Rand Wacker X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 06 Sep 2004 10:02:42.0484 (UTC) FILETIME=[A652E740:01C493F8] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 Sep 2004, at 20:16, Rand Wacker wrote: > Sender ID approved mail provides you with the benefit in that it is > authenticating a well-comprehended user address, the From: header. > This > is something that's easy for users and admins to comprehend and > whitelist. > Whitelisting of the envelope is more complex and won't be understood > by a > large portion of users out there. Unfortunately whitelisting and blacklisting of addresses happens today (in most MTAs that I'm aware of) on the envelope address, not the headers, and since a whitelisting has to override a blacklisting you're suggesting a significant shift in operating procedure (from rejection at MAIL FROM to rejection at EODATA). As someone responsible for anti-spam for billions of mails per month I can't imagine that's a change we'd want to make lightly, especially given the increased cost of holding off the rejection until EODATA. Another thing to remember is that the people at the coal face of spam attacks don't want to be able to whitelist more. They want to get rid of more spam. Those who want to be able to improve whitelisting have something to sell you (this isn't necessarily bad, but it tends to be true). Some have argued that being able to validate and accredit domains will allow you to turn up the strength of your spam filters, but anyone who has worked on real world spam filters (SpamAssassin and a commercial filter here) will be able to tell you that this is very much non trivial. We would make the change if it had a significant benefit to our customers, but in this thread there has already been what I consider strong enough proof (in response to your large bank example) that everything we need for whitelisting even complex mail routing is possible using the envelope address anyway. While today there are a number of MUAs that don't display the envelope address, the MUAs will have to change to display whichever of the MAIL FROM or the PRA we're validating. Furthermore, almost none of the businesses we work with allow their users to whitelist addresses of their own choosing, at least not with without admin approval. This stuff happens today on the envelope, and while it has taken some training it is not a significant barrier. I agree with you that we should move forwards with Sender-ID assuming Microsoft can fix their license issues. Certainly one of the benefits of moving forwards is to approve -protocol, which is the real meat of Unified SPF and will bring us gains when we come to implementing crypto validation. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 06:30:41 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 GAA20303 for ; Mon, 6 Sep 2004 06:30:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86A3nZd089576; Mon, 6 Sep 2004 03:03: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 i86A3nhQ089573; Mon, 6 Sep 2004 03:03:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i86A3kJG089511 for ; Mon, 6 Sep 2004 03:03:47 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-11.tower-48.messagelabs.com!1094465048!4875132 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 20751 invoked from network); 6 Sep 2004 10:04:08 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-11.tower-48.messagelabs.com with SMTP; 6 Sep 2004 10:04:08 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Sep 2004 11:04:07 +0100 Received: (qmail 6807 invoked from network); 5 Sep 2004 10:01:24 -0000 Received: from unknown (HELO ?10.0.1.2?) (10.191.100.2) by matt?dev.int.star.co.uk with SMTP; 5 Sep 2004 10:01:24 -0000 In-Reply-To: <20040903200311.GD91563@bitshift.org> References: <4042BB90-FD92-11D8-B236-000A95AC67AA@messagelabs.com> <4138CA8C.5070004@solidmatrix.com> <20040903200311.GD91563@bitshift.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <17C7ABE0-FFEC-11D8-A366-000A95AC67AA@messagelabs.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Matt Sergeant Subject: Re: (DEPLOY) In Support of Sender ID Date: Mon, 6 Sep 2004 11:04:08 +0100 To: "Mark C. Langston" X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 06 Sep 2004 10:04:07.0828 (UTC) FILETIME=[D9315D40:01C493F8] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 Sep 2004, at 21:03, Mark C. Langston wrote: > On Fri, Sep 03, 2004 at 03:48:28PM -0400, Yakov Shafranovich wrote: >> >> It can also serve as a basis for reputation and accreditation systems. >> >> Remember that spam is multipronged, and this is another tool in the >> toolbox. No one is talking about this as the final solution for spam. > > It's important to realize that there is no one single "solution for > spam". Much like the security arena, any successful anti-spam strategy > will need to take a "layered onion" approach: multiple, diverse tools > and techniques, none sufficient on their own, that provide a > comprehensive solution when deployed together. This means that a > robust > anti-spam solution will encompass authentication, reputation, > acceditation, whitelisting, blacklisting, filtering, and other > techniques, at various points in an organization's infrastructure. > > There is no anti-spam magic bullet, nor a simple, all-in-one appliance > with a single management interface that'll solve all your spam > problems. > A single firewall does not a security strategy make; a single anti-spam > tool does not an anti-spam strategy make. I don't think anyone on this list needs to be reminded of this, at least not those participating. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 07:52: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 HAA27656 for ; Mon, 6 Sep 2004 07:52: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 i86BRMio014248; Mon, 6 Sep 2004 04:27:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i86BRMuF014247; Mon, 6 Sep 2004 04:27:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86BRJ4n014232 for ; Mon, 6 Sep 2004 04:27:21 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i86BbNni032146; Mon, 6 Sep 2004 07:37:23 -0400 From: To: "'Graham Murray'" , Subject: RE: TECH-ERROR/DOC-BUG: empty fields in -pra Date: Mon, 6 Sep 2004 07:25:22 -0400 Message-ID: <016101c49404$40611220$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Graham Murray > Sent: Monday, September 06, 2004 12:51 AM > To: ietf-mxcomp@imc.org > Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra > > > > Yakov Shafranovich writes: > > > Graham Murray wrote: > > > >> Roy Badami writes: > >> > >>>The effect of this is that even if the users MUA is Sender > ID aware, > >>>and displays the PRA, there's no guarantee it is > displaying the same > >>>identity that was validated by the MTA. > >> Which is why it would be better for the MTA to create a header to > >> inform the MUA of the PRA and for the MUA to display that. If this > >> were done then it would be necessary to specify that the MTA MUST > >> remove any such headers already in the mail. > >> > > > > This would be a problem with multi-hop forwarders. > > Why? Sender-ID only authenticates the last hop anyway, so the PRA > which the MUA would derive should always be the same as that derived > and validated by the last MTA handling the email. > The header fields are there for a reason, its an inline log of the email to assist mail administrators to diagnose email issues (not just forgery/phishing, but also routing issues, secondary MX issues, etc). (Or allow skilled email users to analyze validity of incoming mail). Suppressing this type of information is unacceptable to me, and my admins who are told to look at the headers BEFORE calling support. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 09:09: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 JAA02775 for ; Mon, 6 Sep 2004 09:09:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86Cfu59025520; Mon, 6 Sep 2004 05:41: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 i86CfuQ6025519; Mon, 6 Sep 2004 05:41:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86Cft4L025503 for ; Mon, 6 Sep 2004 05:41:55 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i86Cg8ec013963 for ; Mon, 6 Sep 2004 13:42:08 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i86Cg8i0013962; Mon, 6 Sep 2004 13:42:08 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra References: <016101c49404$40611220$2766f30a@development.greatgulfhomes.com> From: Graham Murray Date: Mon, 06 Sep 2004 13:42:08 +0100 In-Reply-To: <016101c49404$40611220$2766f30a@development.greatgulfhomes.com> (terry@ashtonwoodshomes.com's message of "Mon, 6 Sep 2004 07:25:22 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: writes: > The header fields are there for a reason, its an inline log of the email to assist mail > administrators to diagnose email issues (not just forgery/phishing, but also routing issues, > secondary MX issues, etc). (Or allow skilled email users to analyze validity of incoming mail). > > Suppressing this type of information is unacceptable to me, and my admins who are told to look at > the headers BEFORE calling support. I agree with all of that. Yet at the moment there is no PRA header inserted by the MTA. All the other headers would be left intact and each email would have just one additional header (showing the PRA as calculated and authenticated) inserted by the final MTA or MDA. This would be useful to both the MUA and the admin examining headers. So nothing would be taken away from the information currently available. From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 09:39: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 JAA04432 for ; Mon, 6 Sep 2004 09:39: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 i86DAgKE029150; Mon, 6 Sep 2004 06:10:42 -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 i86DAgg8029149; Mon, 6 Sep 2004 06:10:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86DAf8U029140 for ; Mon, 6 Sep 2004 06:10:41 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i86DKkni001295; Mon, 6 Sep 2004 09:20:46 -0400 From: To: "'Graham Murray'" , Subject: RE: TECH-ERROR/DOC-BUG: empty fields in -pra Date: Mon, 6 Sep 2004 09:09:06 -0400 Message-ID: <017201c49412$b16f4c80$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Graham Murray > Sent: Monday, September 06, 2004 8:42 AM > To: ietf-mxcomp@imc.org > Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra > > > > writes: > > > The header fields are there for a reason, its an inline log > of the email to assist mail > > administrators to diagnose email issues (not just > forgery/phishing, but also routing issues, > > secondary MX issues, etc). (Or allow skilled email users > to analyze validity of incoming mail). > > > > Suppressing this type of information is unacceptable to me, > and my admins who are told to look at > > the headers BEFORE calling support. > > I agree with all of that. Yet at the moment there is no PRA header > inserted by the MTA. All the other headers would be left intact and No, that's not what I saw proposed; specifically I was objecting to: "If this were done then it would be necessary to specify that the MTA MUST remove any such headers already in the mail." From the earlier message. That is what I was objecting to. I understood that to mean that some or all headers the PRA was based on would be removed. Was my interpretation incorrect? Terry > each email would have just one additional header (showing the PRA as > calculated and authenticated) inserted by the final MTA or MDA. This > would be useful to both the MUA and the admin examining headers. So > nothing would be taken away from the information currently available. > From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 09:47:49 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 JAA04820 for ; Mon, 6 Sep 2004 09:47:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86DHeu3030446; Mon, 6 Sep 2004 06:17:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i86DHeHD030445; Mon, 6 Sep 2004 06:17:40 -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 i86DHe22030438 for ; Mon, 6 Sep 2004 06:17:40 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 4411726C077; Mon, 6 Sep 2004 15:18:05 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id E484226C068; Mon, 6 Sep 2004 15:18:03 +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 i86DI3m7842125; Mon, 6 Sep 2004 15:18:03 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 65090FAD0; Mon, 6 Sep 2004 15:18:03 +0200 (CEST) Date: Mon, 6 Sep 2004 15:18:03 +0200 From: Stephane Bortzmeyer To: Graham Murray Cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra Message-ID: <20040906131803.GA9539@nic.fr> References: <016101c49404$40611220$2766f30a@development.greatgulfhomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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+20040523i 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 Mon, Sep 06, 2004 at 01:42:08PM +0100, Graham Murray wrote a message of 16 lines which said: > I agree with all of that. Yet at the moment there is no PRA header > inserted by the MTA. All the other headers would be left intact and > each email would have just one additional header (showing the PRA as > calculated and authenticated) inserted by the final MTA or MDA. Why only one? Why not a "Responsible-From" inserted at each administrative organization boundary? (Like "Received" inserted at each MTA boundary.) Each SenderID machine and each MUA would use the first "Responsible-From" (the last inserted) to find the PRA. But a lot more information would be available for debugging. From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 10:47: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 KAA10073 for ; Mon, 6 Sep 2004 10:47:45 -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 i86EKG3l039122; Mon, 6 Sep 2004 07:20: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 i86EKG16039121; Mon, 6 Sep 2004 07:20:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86EKFK2039105 for ; Mon, 6 Sep 2004 07:20:16 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i86EKZ2s015231 for ; Mon, 6 Sep 2004 15:20:35 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i86EKZ15015230; Mon, 6 Sep 2004 15:20:35 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra References: <017201c49412$b16f4c80$2766f30a@development.greatgulfhomes.com> From: Graham Murray Date: Mon, 06 Sep 2004 15:20:35 +0100 In-Reply-To: <017201c49412$b16f4c80$2766f30a@development.greatgulfhomes.com> (terry@ashtonwoodshomes.com's message of "Mon, 6 Sep 2004 09:09:06 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: writes: >>From the earlier message. > > That is what I was objecting to. I understood that to mean that some or all headers the PRA was > based on would be removed. Was my interpretation incorrect? Yes, it was incorrect but that was my fault for not making my meaning clear. My suggestion was that the MTA should insert a new header (for the MUA and human) to show the PRA it calculated and authenticated. Also, to avoid spoofing, that it also removes any pre-existing instances of this new header so that the user will only see the one inserted by the MTA/MDA from which the MUA fetched the mail. This being similar behaviour to SpamAssassin which removes any pre-existing "X-Spam-*" headers before adding its own. From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 11:28: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 LAA12561 for ; Mon, 6 Sep 2004 11:28:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86F1npk045604; Mon, 6 Sep 2004 08:01: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 i86F1nxV045603; Mon, 6 Sep 2004 08:01:49 -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 i86F1nCG045595 for ; Mon, 6 Sep 2004 08:01:49 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id CD7AB26C078; Mon, 6 Sep 2004 17:02:14 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 6717826C068; Mon, 6 Sep 2004 17:02:13 +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 i86F2Dm7877231; Mon, 6 Sep 2004 17:02:13 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 2A81BFACC; Mon, 6 Sep 2004 17:02:13 +0200 (CEST) Date: Mon, 6 Sep 2004 17:02:13 +0200 From: Stephane Bortzmeyer To: Graham Murray Cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra Message-ID: <20040906150213.GA20236@nic.fr> References: <017201c49412$b16f4c80$2766f30a@development.greatgulfhomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Sep 06, 2004 at 03:20:35PM +0100, Graham Murray wrote a message of 18 lines which said: > My suggestion was that the MTA should insert a new header (for the > MUA and human) to show the PRA it calculated and > authenticated. Also, to avoid spoofing, that it also removes any > pre-existing instances of this new header so that the user will only > see the one inserted by the MTA/MDA from which the MUA fetched the > mail. This being similar behaviour to SpamAssassin which removes any > pre-existing "X-Spam-*" headers before adding its own. Pre-existing "X-Spam-*" headers are indeed useless (or dangerous since they can be forged) but, since SenderID authenticates a channel, not the end-to-end message, pre-existing "Responsible-From" (or whatever the name of the PRA header is) are still useful. The situation of these PRA headers, to me, is closer from the "Received" headers, where nobody objects there are several instances of them (and sometimes some forged ones). From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 12:55:41 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 MAA17326 for ; Mon, 6 Sep 2004 12:55:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86GNFS7056731; Mon, 6 Sep 2004 09:23:15 -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 i86GNFGL056730; Mon, 6 Sep 2004 09:23:15 -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 i86GN6px056701 for ; Mon, 6 Sep 2004 09:23:08 -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 A444317111 for ; Mon, 6 Sep 2004 12:32:35 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra In-Reply-To: Your message of "Mon, 06 Sep 2004 15:18:03 +0200." <20040906131803.GA9539@nic.fr> Date: Mon, 06 Sep 2004 12:32:35 -0400 Message-Id: <20040906163235.A444317111@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephane Bortzmeyer wrote: > Why only one? Why not a "Responsible-From" inserted at each > administrative organization boundary? (Like "Received" inserted at > each MTA boundary.) That would help, but not enough, due to the current deployment of SMTP. SMTP is "end to end", in that clients talk directly to servers. It's easy to validate the previous hop: you've got the IP. email *messages* aren't "end to end", or, at least, aren't *verifiable* to be end to end, ias they could have been modified in transit, or forged. (Barring signed messages...) What you're talking about is changing the forwarding methodology from: message -> message' -> message'' -> message''' -> ... to: forward(forward(forward(forward(message)))) The first method forwards messages which may, or may not, be related to each other. They certainly *appear* to be related, and the "received" lines indicate some relationship, but that relationship is difficult to follow or prove, as the whole PRA argument has shown. The second method "tunnels" the message though multiple forwarders. Each forwarder not only accepts responsibility for the message, it attests to the fact that other forwarders have accepted responsibility for their behavior. In the security world, these methods are used to create multiple nested virtual tunnels. The tunneling & layering is *required*, because the intermediaries know about only their neighbours, and don't trust anyone else. To first order, the number of nested tunnels indicates the number of trust boundaries that the message has crossed. This method works for VPN's, because the sites doing the tunnelling don't futz with the message content. (They often can't, because the content is itself signed and encrypted). This method does NOT work for SMTP, because there are too many broken MTA implementations which change the message contents. So a "Responsible-From" inserted at each administrative organization boundary would be a good idea, but it would have to be tied both to the message, and to the party claiming responsibility. That's hard. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 14:03: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 OAA21951 for ; Mon, 6 Sep 2004 14:03: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 i86HYgLW065849; Mon, 6 Sep 2004 10:34:42 -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 i86HYgFg065848; Mon, 6 Sep 2004 10:34:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86HYfQL065837 for ; Mon, 6 Sep 2004 10:34:41 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so316299rnk for ; Mon, 06 Sep 2004 10:35:05 -0700 (PDT) Received: by 10.38.78.70 with SMTP id a70mr1511879rnb; Mon, 06 Sep 2004 10:35:05 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Mon, 6 Sep 2004 10:35:05 -0700 (PDT) Message-ID: <94df60cf040906103516c31f24@mail.gmail.com> Date: Mon, 6 Sep 2004 13:35:05 -0400 From: Reply-To: To: IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 06 Sep 2004 01:55:50 -0500, wayne wrote: > > In Andrew Newton writes: > > > Despite lack of agreement on the outcome, there is agreement on the > > stated positions. In the words of Olafur: > > 1) Specify everyone to be compliant at all times. > > 2) Specify clearly full complaint state and tolerate non-compliant > > state during phase-in. > >... > > So, if we are planning on supporting SenderID, it appears that we MUST > allow everyone to always be conformant at all times. This means that > we MUST NOT require implementations to query SPF RRs. The standard can be written in such a way that senders MUST publish SPF records and MAY publish TXT records, while receivers MUST check SPF records and MAY check TXT records. Only the receiving MTA is covered by the patent license. Compliant implementations will have to check SPF records. If the recursive DNS server an implementation talks to is broken, that probably doesn't mean the MTA implementation is non-conformant. But it would be kind of amusing if Microsoft sued everyone with a broken DNS server. (I know they are always looking for new ways to get people to upgrade...) David From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 14:39: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 OAA23970 for ; Mon, 6 Sep 2004 14:39: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 i86IFmQE071517; Mon, 6 Sep 2004 11:15: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 i86IFmjO071516; Mon, 6 Sep 2004 11:15:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86IFl3f071505 for ; Mon, 6 Sep 2004 11:15:48 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4O0h-0001Qs-EZ; Mon, 06 Sep 2004 14:14:35 -0400 Message-ID: <413CA967.3080202@solidmatrix.com> Date: Mon, 06 Sep 2004 14:16:07 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: mazieres@gmail.com CC: IETF MARID WG Subject: Re: consensus call on MUST/SHOULD language for TXT records References: <94df60cf040906103516c31f24@mail.gmail.com> In-Reply-To: <94df60cf040906103516c31f24@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit mazieres@gmail.com wrote: > On Mon, 06 Sep 2004 01:55:50 -0500, wayne wrote: > >>In Andrew Newton writes: >> >> >>>Despite lack of agreement on the outcome, there is agreement on the >>>stated positions. In the words of Olafur: >>>1) Specify everyone to be compliant at all times. >>>2) Specify clearly full complaint state and tolerate non-compliant >>>state during phase-in. >> >>... >> >>So, if we are planning on supporting SenderID, it appears that we MUST >>allow everyone to always be conformant at all times. This means that >>we MUST NOT require implementations to query SPF RRs. > > > The standard can be written in such a way that senders MUST publish > SPF records and MAY publish TXT records, while receivers MUST check > SPF records and MAY check TXT records. > One way to doing is to specify that RR records are checked first, and TXT records checked second. Yakov From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 15:01: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 PAA25042 for ; Mon, 6 Sep 2004 15:01:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86IZRVA074263; Mon, 6 Sep 2004 11:35:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i86IZRS2074262; Mon, 6 Sep 2004 11:35:27 -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 i86IZRCl074253 for ; Mon, 6 Sep 2004 11:35:27 -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 i86IZHiq003693; Mon, 6 Sep 2004 11:35:17 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Sep 2004 11:35:17 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , Hadmut Danisch Cc: Andrew Newton , IETF MARID WG Subject: RE: consensus call of RR prefix Date: Mon, 6 Sep 2004 11:35:17 -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 Yakov Shafranovich > Sent: Saturday, September 04, 2004 9:48 PM > Hadmut Danisch wrote: > I would add to that that others in the IETF may use MARID as a > precendent to argue for the use of TXT record. This may > quickly increase > the possible number of them. Therefore, I am for the prefix as well. I beleive that prefixing is very likely to be necessary. Pragmatically however we loose backwards compatibility with the deployed base. I think that if we take any step that loses backwards compatibility then we should introduce a prefix. So if we have versioning then we should have a prefix. Losing backwards compatibilty for the sake of a prefix does not seem like a good deal. What I would like to do is to drop the idea of a new RR tag, and define a prefix for use with the TXT record to be introduced in the same way. In my view the RR tag value defines a syntax, the prefix defines a semantics. There is no need to introduce a new RR tag unless you require a new syntax, which MARID does not. From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 15:37:17 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 PAA27554 for ; Mon, 6 Sep 2004 15:37: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 i86JF1AX079965; Mon, 6 Sep 2004 12:15: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 i86JF1Vs079964; Mon, 6 Sep 2004 12:15:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86JEx4W079949 for ; Mon, 6 Sep 2004 12:15:00 -0700 (PDT) (envelope-from roy+dated+1097090090.f6101b@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i86JGMK3067395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Sep 2004 19:16:28 GMT (envelope-from roy+dated+1097090090.f6101b@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i86JEpBo071436 for ; Mon, 6 Sep 2004 20:14:51 +0100 (BST) (envelope-from roy+dated+1097090090.f6101b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i86JEpEP071435 for ietf-mxcomp@imc.org; Mon, 6 Sep 2004 20:14:51 +0100 (BST) (envelope-from roy+dated+1097090090.f6101b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Mon, 06 Sep 2004 20:14:48 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.46887.731478.462121@giles.gnomon.org.uk> Date: Mon, 6 Sep 2004 20:14:47 +0100 To: Graham Murray Cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra In-Reply-To: References: <16695.49071.671776.708651@giles.gnomon.org.uk> <16698.1388.231292.755112@giles.gnomon.org.uk> <16699.25176.185782.397897@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Graham" == Graham Murray writes: Graham> Which is why it would be better for the MTA to create a Graham> header to inform the MUA of the PRA and for the MUA to Graham> display that. If this were done then it would be necessary Graham> to specify that the MTA MUST remove any such headers Graham> already in the mail. I think this has the potential to make things worse (or at least more confusing) where a Sender ID aware MUA is used with a non-Sender ID MTA. -roy From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 15:53:22 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 PAA28331 for ; Mon, 6 Sep 2004 15:53:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86JUX9s081997; Mon, 6 Sep 2004 12:30:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i86JUXT0081996; Mon, 6 Sep 2004 12:30:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86JUV9I081988 for ; Mon, 6 Sep 2004 12:30:32 -0700 (PDT) (envelope-from sb0-066750c6ac-johnl@iecc.com) Received: (qmail 16758 invoked by uid 100); 6 Sep 2004 19:30:31 -0000 Date: 6 Sep 2004 19:30:31 -0000 Message-ID: <20040906193031.16757.qmail@tom.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: TECH: use fetchmail algorithm to select header address to verify Organization: I.E.C.C., Trumansburg NY USA Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The widely used fetchmail package includes a section of code that determines the most likely responsible party for an e-mail message. Its algorithm is similar to PRA but not identical. This part of fetchmail was added in about 1996 and has been in daily use since then by thousands of users all over the world during the past eight years. The fetchmail code is under the GPL, but as far as I know, nobody claims proprietary rights over its algorithms. Eric Raymond, whose name is on the 2001 copyright notice in the file, doesn't. Since it was published so long ago it's unlikely that any claims are yet to surface. It checks headers in the following order: Return-Path: (envelope MAIL FROM address, as noted in code below) Resent-Sender: Sender: Resent-From: From: Reply-To: Apparently-From: My proposal is to use this scheme to determine the address to check, perhaps deleting the Apparently-From: check since it's not a header that's ever appeared in an RFC. One can argue whether this is the best possible set and order of headers to check, but since it's worked in practice for so long, I see no reason to mess with it. If there's interest in this, I'd be happy to help write it up as an I-D. Personally, I don't think that any sort of sender domain vs. IP address check is particularly useful as an anti-spam or anti-forgery measure, but since MARID seems determined to publish something along those lines, it might as well use the best proven technology available. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I shook hands with Senators Dole and Inouye," said Tom, disarmingly. --- lines 918-946 of transact.c from fetchmail 6.2.0 --- /* * If there is a Return-Path address on the message, this was * almost certainly the MAIL FROM address given the originating * sendmail. This is the best thing to use for logging the * message origin (it sets up the right behavior for bounces and * mailing lists). Otherwise, fall down to the next available * envelope address (which is the most probable real sender). * *** The order is important! *** * This is especially useful when receiving mailing list * messages in multidrop mode. if a local address doesn't * exist, the bounce message won't be returned blindly to the * author or to the list itself but rather to the list manager * (ex: specified by "Sender:") which is much less annoying. This * is true for most mailing list packages. */ if( !msgblk.return_path[0] ){ char *ap = NULL; if (resent_sender_offs >= 0 && (ap = nxtaddr(msgblk.headers + resent_sender_offs))); else if (sender_offs >= 0 && (ap = nxtaddr(msgblk.headers + sender_offs))); else if (resent_from_offs >= 0 && (ap = nxtaddr(msgblk.headers + resent_from_offs))); else if (from_offs >= 0 && (ap = nxtaddr(msgblk.headers + from_offs))); else if (reply_to_offs >= 0 && (ap = nxtaddr(msgblk.headers + reply_to_offs))); else if (app_from_offs >= 0 && (ap = nxtaddr(msgblk.headers + app_from_offs))); /* multi-line MAIL FROM addresses confuse SMTP terribly */ if (ap && !strchr(ap, '\n')) { strncpy(msgblk.return_path, ap, sizeof(msgblk.return_path)); msgblk.return_path[sizeof(msgblk.return_path)-1] = '\0'; } } From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 15:54: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 PAA28437 for ; Mon, 6 Sep 2004 15:54:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86JWGjt082177; Mon, 6 Sep 2004 12:32: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 i86JWGDl082176; Mon, 6 Sep 2004 12:32:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from trillian.net.astrum.ch (trillian.net.astrum.ch [213.144.132.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86JWFfJ082169 for ; Mon, 6 Sep 2004 12:32:15 -0700 (PDT) (envelope-from matthias@astrum.ch) Received: from localhost (localhost [127.0.0.1]) by trillian.net.astrum.ch (Postfix) with ESMTP id 043E05BE24 for ; Mon, 6 Sep 2004 21:32:15 +0200 (CEST) Received: from astrum.ch (marvin.net.astrum.ch [213.144.132.250]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by trillian.net.astrum.ch (Postfix) with ESMTP id 4111A5BE27 for ; Mon, 6 Sep 2004 21:32:14 +0200 (CEST) Message-ID: <413CBB3D.40402@astrum.ch> Date: Mon, 06 Sep 2004 21:32:13 +0200 From: Matthias Leisi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-ch, de-de, de, en-us, en, fr MIME-Version: 1.0 To: IETF MARID WG Subject: [DOCBUG] -submitter, 5.3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at astrum.ch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [I'm not sure whether I have overlooked this already being posted] -submitter, Section 5.3 Mobile User: | Here is an example of the SMTP session between the MTAs at | consolidatedmessanger.net and almamater.edu.example. | | S: 220 almamater.edu.example ESMTP server ready | C: EHLO mobile.net.example "consolidatemessanger.net" should probably be "mobile.net.example". -- Matthias -- Brain-Log http://matthias.leisi.net/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 15:58: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 PAA28599 for ; Mon, 6 Sep 2004 15:58: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 i86JU78l081638; Mon, 6 Sep 2004 12:30: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 i86JU7sG081637; Mon, 6 Sep 2004 12:30:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from trillian.net.astrum.ch (trillian.net.astrum.ch [213.144.132.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86JU5v0081623 for ; Mon, 6 Sep 2004 12:30:06 -0700 (PDT) (envelope-from matthias@astrum.ch) Received: from localhost (localhost [127.0.0.1]) by trillian.net.astrum.ch (Postfix) with ESMTP id 8FC6B5BE23 for ; Mon, 6 Sep 2004 21:29:58 +0200 (CEST) Received: from astrum.ch (marvin.net.astrum.ch [213.144.132.250]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by trillian.net.astrum.ch (Postfix) with ESMTP id A1C0B5B8A5 for ; Mon, 6 Sep 2004 21:29:57 +0200 (CEST) Message-ID: <413CBAB5.50103@astrum.ch> Date: Mon, 06 Sep 2004 21:29:57 +0200 From: Matthias Leisi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-ch, de-de, de, en-us, en, fr MIME-Version: 1.0 To: IETF MARID WG Subject: [DEPLOY] General Issue w/ISPs blocking Port 25 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at astrum.ch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Since a few days, I check for SPF records at the MTA, and I noticed one particular issue. I'm not sure whether the drafts (-submit) are the right place to mention this issue, or whether some BCP would be appropriate. I've encountered a number of ISPs where users are unable to do outbound connections with dst port 25, but are limited to the ISPs Smarthost. Although I haven't seen it yet, but I suspect that Port 587 as per RFC 2476 (Message Submission) may be blocked as well if it's use is adopted more widely. Obviously, that is pretty efficient to stop certain categories of junk (-sources), and is generally not an issue, if the Smarthost allows arbitrary 821/822 From's. However, with strict SPF (or SenderId) checking, this /does/ become an issue, since a domain owner will most likely not add some random Smarthost to the list of designated mailers. -submitter mentions the use of SUBMIT briefly, but maybe the implications of the (how common?) blocking of dst port 25 should be mentioned. -- Matthias PS: The naming of SUBMITTER vs. SUBMIT protocol is somewhat confusing. -- Brain-Log http://matthias.leisi.net/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 16:34: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 QAA00562 for ; Mon, 6 Sep 2004 16:34: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 i86K9Qkl086476; Mon, 6 Sep 2004 13:09:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i86K9Q4v086475; Mon, 6 Sep 2004 13:09:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86K9P7K086469 for ; Mon, 6 Sep 2004 13:09:25 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4PmD-0007UZ-Rm; Mon, 06 Sep 2004 16:07:46 -0400 Message-ID: <413CC3EC.3080603@solidmatrix.com> Date: Mon, 06 Sep 2004 16:09:16 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Matthias Leisi CC: IETF MARID WG Subject: Re: [DEPLOY] General Issue w/ISPs blocking Port 25 References: <413CBAB5.50103@astrum.ch> In-Reply-To: <413CBAB5.50103@astrum.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit See: http://www.ietf.org/internet-drafts/draft-hutzler-spamops-01.txt Matthias Leisi wrote: > > Since a few days, I check for SPF records at the MTA, and I noticed one > particular issue. I'm not sure whether the drafts (-submit) are the > right place to mention this issue, or whether some BCP would be > appropriate. > > I've encountered a number of ISPs where users are unable to do outbound > connections with dst port 25, but are limited to the ISPs Smarthost. > Although I haven't seen it yet, but I suspect that Port 587 as per RFC > 2476 (Message Submission) may be blocked as well if it's use is adopted > more widely. > > Obviously, that is pretty efficient to stop certain categories of junk > (-sources), and is generally not an issue, if the Smarthost allows > arbitrary 821/822 From's. > > However, with strict SPF (or SenderId) checking, this /does/ become an > issue, since a domain owner will most likely not add some random > Smarthost to the list of designated mailers. > > -submitter mentions the use of SUBMIT briefly, but maybe the > implications of the (how common?) blocking of dst port 25 should be > mentioned. > > -- Matthias > > PS: The naming of SUBMITTER vs. SUBMIT protocol is somewhat confusing. > From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 16:38: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 QAA00756 for ; Mon, 6 Sep 2004 16:38:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86KIICq087515; Mon, 6 Sep 2004 13:18: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 i86KIIat087514; Mon, 6 Sep 2004 13:18:18 -0700 (PDT) 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 i86KIHpp087498 for ; Mon, 6 Sep 2004 13:18:18 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Mon, 06 Sep 2004 16:18:15 -0400 id 0000000000157945.00000000413CC607.000012EE X-IMAP-Sender: mrsam@courier-mta.com References: <20040906193031.16757.qmail@tom.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: TECH: use fetchmail algorithm to select header address to verify Date: Mon, 06 Sep 2004 16:18:14 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-4587-1094501894-0001"; 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-4587-1094501894-0001 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit John Levine writes: > I know, nobody claims proprietary rights over its algorithms. Eric > Raymond, whose name is on the 2001 copyright notice in the file, > doesn't. Since it was published so long ago it's unlikely that any > claims are yet to surface. I like this. Combine this with SPF-classic, and you have a functional, unencumbered alternative to Sender-ID. --=_mimegpg-commodore.email-scan.com-4587-1094501894-0001 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBPMYGx9p3GYHlUOIRAuImAJ0UDLShdhujnZ+4jy9egCWd1zvIkwCfZVrM R8xyuLHxs1tH4YoW9MKeneY= =IZw/ -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-4587-1094501894-0001-- From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 16:49: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 QAA01392 for ; Mon, 6 Sep 2004 16:49: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 i86KQcVX088310; Mon, 6 Sep 2004 13:26: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 i86KQcGT088309; Mon, 6 Sep 2004 13:26:38 -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 i86KQclF088301 for ; Mon, 6 Sep 2004 13:26:38 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 6243226C070; Mon, 6 Sep 2004 22:26:38 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 300D726C06E; Mon, 6 Sep 2004 22:26:37 +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 i86KQbm7926286; Mon, 6 Sep 2004 22:26:37 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 01067FACC; Mon, 6 Sep 2004 22:26:36 +0200 (CEST) Date: Mon, 6 Sep 2004 22:26:36 +0200 From: Stephane Bortzmeyer To: John Levine Cc: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify Message-ID: <20040906202636.GB7029@nic.fr> References: <20040906193031.16757.qmail@tom.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040906193031.16757.qmail@tom.iecc.com> 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 Mon, Sep 06, 2004 at 07:30:31PM -0000, John Levine wrote a message of 74 lines which said: > My proposal is to use this scheme to determine the address to check, Nice idea but, as discussions on this group showed, there is little hope to have a consensus on this algorithm. Hence the "unified SPF" (http://spf.pobox.com/unified/) idea which disconnects the protocol and the DNS RR from the choice of the domain used for the validation. "Unified SPF" gives you several choices for this domain and your (fetchmail's) algorithm could be one of them. > If there's interest in this, I'd be happy to help write it up as an > I-D. Good idea, but as a part of "Unified SPF", like PRA is (see http://spf.pobox.com/unified/7-pra.txt as an example). From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 17:26:48 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 RAA03200 for ; Mon, 6 Sep 2004 17:26:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86L5tPW092730; Mon, 6 Sep 2004 14:05:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i86L5tb6092729; Mon, 6 Sep 2004 14:05:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86L5soV092722 for ; Mon, 6 Sep 2004 14:05:54 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4Qew-0001db-7W; Mon, 06 Sep 2004 17:04:18 -0400 Message-ID: <413CD12D.2050303@solidmatrix.com> Date: Mon, 06 Sep 2004 17:05:49 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Sam Varshavchik CC: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Varshavchik wrote: > John Levine writes: > >> I know, nobody claims proprietary rights over its algorithms. Eric >> Raymond, whose name is on the 2001 copyright notice in the file, >> doesn't. Since it was published so long ago it's unlikely that any >> claims are yet to surface. > > > I like this. > > Combine this with SPF-classic, and you have a functional, unencumbered > alternative to Sender-ID. > > Lets see if taking PRA out will take care of IPR in marid-core. Yakov From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 17:26: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 RAA03218 for ; Mon, 6 Sep 2004 17:26: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 i86L4kB6092629; Mon, 6 Sep 2004 14:04: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 i86L4k4m092628; Mon, 6 Sep 2004 14:04:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86L4jlx092618 for ; Mon, 6 Sep 2004 14:04:46 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4Qdl-0001Zs-A7; Mon, 06 Sep 2004 17:03:05 -0400 Message-ID: <413CD0DB.7010902@solidmatrix.com> Date: Mon, 06 Sep 2004 17:04:27 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Stephane Bortzmeyer CC: John Levine , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> <20040906202636.GB7029@nic.fr> In-Reply-To: <20040906202636.GB7029@nic.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > On Mon, Sep 06, 2004 at 07:30:31PM -0000, > John Levine wrote > a message of 74 lines which said: > > >>My proposal is to use this scheme to determine the address to check, > > > Nice idea but, as discussions on this group showed, there is little > hope to have a consensus on this algorithm. Hence the "unified SPF" > (http://spf.pobox.com/unified/) idea which disconnects the protocol > and the DNS RR from the choice of the domain used for the > validation. "Unified SPF" gives you several choices for this domain > and your (fetchmail's) algorithm could be one of them. The consensus if any so far has been in regards to PRA. I haven't seen anybody posting yet in regards to this one. Personally, I am very for using fetchmail's algorithm if it helps take care of the IPR issues. But there is still IPR issues with marid-core and I am not sure if this will take care of it. Yakov From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 17:44: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 RAA03915 for ; Mon, 6 Sep 2004 17:44: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 i86LN2TY095218; Mon, 6 Sep 2004 14:23: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 i86LN28w095217; Mon, 6 Sep 2004 14:23:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86LN1G1095210 for ; Mon, 6 Sep 2004 14:23:02 -0700 (PDT) (envelope-from roy+dated+1097097775.464b1c@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i86LOSYc079304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Sep 2004 21:24:34 GMT (envelope-from roy+dated+1097097775.464b1c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i86LMt1e072138 for ; Mon, 6 Sep 2004 22:22:55 +0100 (BST) (envelope-from roy+dated+1097097775.464b1c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i86LMtjV072137 for ietf-mxcomp@imc.org; Mon, 6 Sep 2004 22:22:55 +0100 (BST) (envelope-from roy+dated+1097097775.464b1c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Mon, 06 Sep 2004 22:22:54 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.54574.131760.728158@giles.gnomon.org.uk> Date: Mon, 6 Sep 2004 22:22:54 +0100 To: John Levine Cc: ietf-mxcomp@imc.org Subject: TECH: use fetchmail algorithm to select header address to verify In-Reply-To: <20040906193031.16757.qmail@tom.iecc.com> References: <20040906193031.16757.qmail@tom.iecc.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "John" == John Levine writes: John> The widely used fetchmail package includes a section of code John> that determines the most likely responsible party for an John> e-mail message. Its algorithm is similar to PRA but not John> identical. I think the fetchmail algorithm is a red herring. It basically boils down to: determine the envelope sender from the headers. If you've got a broken MTA, then use an algorithm which is similar to the PRA. If that fails, there's yet another fallback. If we're doing this at the SMTP level -- which is the prefered place for the MARID check -- then the envelope sender is always known, without any recourse to the headers, to this just boils down to using the envelope sender (a la SPF). Having an a complex fallback algorithm solely for use with post-SMTP checkers that live behind broken MTAs seems the wrong solution for MARID (though it was the correct engineering approach for fetchmail). -roy From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 18:03:11 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 SAA04989 for ; Mon, 6 Sep 2004 18:03:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86LgC37097321; Mon, 6 Sep 2004 14:42: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 i86LgCgQ097320; Mon, 6 Sep 2004 14:42:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86LgCZ8097313 for ; Mon, 6 Sep 2004 14:42:12 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1C4RFS-000Klj-00; Mon, 06 Sep 2004 22:42:02 +0100 Message-ID: <06fa01c49459$eea41f30$0200000a@ringo> From: "Chris Haynes" To: "Harry Katz" Cc: "IETF MARID WG" References: Subject: Re: Motion to abandon Sender ID Date: Mon, 6 Sep 2004 22:38:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Harry, In a discussion elsewhere there has been uncertainty as to the exact meaning and implications of the phrase 'used in combination' in your statement below. If you were able to confirm that the Microsoft disclosure / IPR claims do not cover the marid-core spec. taken in isolation, that would be extremely helpful and could allay some people's concerns. Chris Haynes "Harry Katz" helpfully stated: > > Our IPR disclosure filed with the IETF and available at > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-marid-core.txt is > quite specific and covers the marid-core and marid-pra specs used in > combination. That's all. We do not, to the best of my knowledge, have > any IPR claims related to either marid-protocol, which describes the > SPF2 record format, or marid-submitter. > > > From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 18:39: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 SAA07696 for ; Mon, 6 Sep 2004 18:39:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86MHDNI002236; Mon, 6 Sep 2004 15:17:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i86MHDLQ002235; Mon, 6 Sep 2004 15:17:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86MHC5d002226 for ; Mon, 6 Sep 2004 15:17:13 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 4387E28B30 for ; Tue, 7 Sep 2004 00:17:13 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08438-04 for ; Tue, 7 Sep 2004 00:17:09 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 93BBC28B2E; Tue, 7 Sep 2004 00:17:09 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Tue, 7 Sep 2004 00:17:09 +0200 (CEST) Message-ID: <45524.127.0.0.1.1094509029.squirrel@127.0.0.1> In-Reply-To: <20040906193031.16757.qmail@tom.iecc.com> References: <20040906193031.16757.qmail@tom.iecc.com> Date: Tue, 7 Sep 2004 00:17:09 +0200 (CEST) Subject: Re: TECH: use fetchmail algorithm to select header address to verify From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit John Levine a écrit : > > The widely used fetchmail package includes a section of code that > determines the most likely responsible party for an e-mail message. > Its algorithm is similar to PRA but not identical. > > This part of fetchmail was added in about 1996 and has been in daily > use since then by thousands of users all over the world during the > past eight years. The fetchmail code is under the GPL, but as far as > I know, nobody claims proprietary rights over its algorithms. Eric > Raymond, whose name is on the 2001 copyright notice in the file, > doesn't. Since it was published so long ago it's unlikely that any > claims are yet to surface. This finding is excellent and the idea is very smart. IANAL, but I believe this is clearly and doubtlessly old enough "prior art" in determining the purported sender of a message by checking the presence of a succession of defined headers in an email, no matter what exact headers are used, this is blatantly similar to the PRA method. I believe this should probably be enough to invalidate any pretention from MS of owning the "property" of such an "invention", and probably breaks the validity of their (yet undisclosed precisely) patent claim. (Anyway, even if this is really good news on the PRA standpoint, I still personally technically much prefer that we should stick to 2821 MAIL FROM as Classic-SPF does.) -- Michel Bouissou OpenPGP ID 0xDDE8AC6E paléogallicisme : style "vieille France" From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 18:41: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 SAA07860 for ; Mon, 6 Sep 2004 18:41: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 i86MJSF3002454; Mon, 6 Sep 2004 15:19: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 i86MJSPh002452; Mon, 6 Sep 2004 15:19:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86MJRbp002443 for ; Mon, 6 Sep 2004 15:19:27 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4Ro4-0005BZ-2J; Mon, 06 Sep 2004 18:17:48 -0400 Message-ID: <413CE267.6050401@solidmatrix.com> Date: Mon, 06 Sep 2004 18:19:19 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Chris Haynes CC: Harry Katz , IETF MARID WG Subject: Re: Motion to abandon Sender ID References: <06fa01c49459$eea41f30$0200000a@ringo> In-Reply-To: <06fa01c49459$eea41f30$0200000a@ringo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I would add to this that the same phrase appears in the IPR disclosure itself (http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-marid-core.txt): "C. If an Internet-Draft or RFC includes multiple parts and it is not reasonably apparent which part of such Internet-Draft or RFC is alleged to be covered by the patent information disclosed in Section V(A) or V(B), it is helpful if the discloser identifies here the sections of the Internet-Draft or RFC that are alleged to be so covered. Both Sender ID: Authenticating E-mail and Purported Responsible Address in E-mail Messages in combination. " Chris Haynes wrote: > Harry, > > In a discussion elsewhere there has been uncertainty as to the exact meaning and > implications of the phrase 'used in combination' in your statement below. > > If you were able to confirm that the Microsoft disclosure / IPR claims do not > cover the marid-core spec. taken in isolation, that would be extremely helpful > and could allay some people's concerns. > > Chris Haynes > > > > > "Harry Katz" helpfully stated: > > > >>Our IPR disclosure filed with the IETF and available at >>http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-marid-core.txt is >>quite specific and covers the marid-core and marid-pra specs used in >>combination. That's all. We do not, to the best of my knowledge, have >>any IPR claims related to either marid-protocol, which describes the >>SPF2 record format, or marid-submitter. >> >> >> > > > > > > From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 19:04: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 TAA09128 for ; Mon, 6 Sep 2004 19:04: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 i86MdiWQ004363; Mon, 6 Sep 2004 15:39: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 i86Mdiw4004362; Mon, 6 Sep 2004 15:39:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86MdiQc004355 for ; Mon, 6 Sep 2004 15:39:44 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i86Mda632457; Mon, 6 Sep 2004 15:39:36 -0700 Date: Tue, 7 Sep 2004 07:39:28 +0900 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <626048219.20040907073928@brandenburg.com> To: Roy Badami CC: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify In-Reply-To: <16700.54574.131760.728158@giles.gnomon.org.uk> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy, RB> If we're doing this at the SMTP level -- which is the prefered place RB> for the MARID check -- then the envelope sender is always known, RB> without any recourse to the headers, to this just boils down to using RB> the envelope sender (a la SPF). I assume you are not talking about SUBMITTER. Because there is no such value as "envelope sender". Hopefully, you do not mean the bounce address, MailFrom, since of course it need not correlate with sender or from at all. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 19:14: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 TAA09854 for ; Mon, 6 Sep 2004 19:14:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86MpSGj006183; Mon, 6 Sep 2004 15:51: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 i86MpS83006182; Mon, 6 Sep 2004 15:51:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86MpRXk006175 for ; Mon, 6 Sep 2004 15:51:27 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4SJ3-0006gh-5Q; Mon, 06 Sep 2004 18:49:49 -0400 Message-ID: <413CE9E5.2000609@solidmatrix.com> Date: Mon, 06 Sep 2004 18:51:17 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Michel Bouissou CC: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> <45524.127.0.0.1.1094509029.squirrel@127.0.0.1> In-Reply-To: <45524.127.0.0.1.1094509029.squirrel@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Michel Bouissou wrote: > John Levine a écrit : > >>The widely used fetchmail package includes a section of code that >>determines the most likely responsible party for an e-mail message. >>Its algorithm is similar to PRA but not identical. >> >>This part of fetchmail was added in about 1996 and has been in daily >>use since then by thousands of users all over the world during the >>past eight years. The fetchmail code is under the GPL, but as far as >>I know, nobody claims proprietary rights over its algorithms. Eric >>Raymond, whose name is on the 2001 copyright notice in the file, >>doesn't. Since it was published so long ago it's unlikely that any >>claims are yet to surface. > > > This finding is excellent and the idea is very smart. IANAL, but I believe > this is clearly and doubtlessly old enough "prior art" in determining the > purported sender of a message by checking the presence of a succession of > defined headers in an email, no matter what exact headers are used, this > is blatantly similar to the PRA method. > > I believe this should probably be enough to invalidate any pretention from > MS of owning the "property" of such an "invention", and probably breaks > the validity of their (yet undisclosed precisely) patent claim. > Even if there isn't enough time for the lawyers to get back to us, nevertheless an alternative draft without IPR problems should be preferred according to RFC 3668, section 8 unless it is superior: " In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. " Yakov From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 19:18:40 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 TAA10165 for ; Mon, 6 Sep 2004 19:18:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86MvBC7006983; Mon, 6 Sep 2004 15:57: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 i86MvB6L006982; Mon, 6 Sep 2004 15:57:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86MvA4t006973 for ; Mon, 6 Sep 2004 15:57:11 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 739BC28B37; Tue, 7 Sep 2004 00:57:11 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09865-05; Tue, 7 Sep 2004 00:57:07 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id C4C0128B2E; Tue, 7 Sep 2004 00:57:07 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Tue, 7 Sep 2004 00:57:07 +0200 (CEST) Message-ID: <45800.127.0.0.1.1094511427.squirrel@127.0.0.1> In-Reply-To: <413CE9E5.2000609@solidmatrix.com> References: <20040906193031.16757.qmail@tom.iecc.com> <45524.127.0.0.1.1094509029.squirrel@127.0.0.1> <413CE9E5.2000609@solidmatrix.com> Date: Tue, 7 Sep 2004 00:57:07 +0200 (CEST) Subject: Re: TECH: use fetchmail algorithm to select header address to verify From: "Michel Bouissou" To: "Yakov Shafranovich" Cc: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Yakov Shafranovich a écrit : >> >> I believe this should probably be enough to invalidate any pretention >> from MS of owning the "property" of such an "invention", and probably >> breaks the validity of their (yet undisclosed precisely) patent claim. > > Even if there isn't enough time for the lawyers to get back to us, > nevertheless an alternative draft without IPR problems should be > preferred according to RFC 3668, section 8 unless it is superior: Sure, I definitely share this point of view. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 19:42:57 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 TAA11506 for ; Mon, 6 Sep 2004 19:42: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 i86NJb9B010456; Mon, 6 Sep 2004 16:19:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i86NJb9Q010455; Mon, 6 Sep 2004 16:19:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86NJZjO010439 for ; Mon, 6 Sep 2004 16:19:35 -0700 (PDT) (envelope-from roy+dated+1097104769.60fcb0@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i86NL4UC089948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Sep 2004 23:21:10 GMT (envelope-from roy+dated+1097104769.60fcb0@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i86NJTNe072642 for ; Tue, 7 Sep 2004 00:19:29 +0100 (BST) (envelope-from roy+dated+1097104769.60fcb0@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i86NJTTE072635 for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 00:19:29 +0100 (BST) (envelope-from roy+dated+1097104769.60fcb0@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 07 Sep 2004 00:19:28 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16700.61568.149508.266801@giles.gnomon.org.uk> Date: Tue, 7 Sep 2004 00:19:28 +0100 To: Dave Crocker Cc: Roy Badami , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify In-Reply-To: <626048219.20040907073928@brandenburg.com> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Dave" == Dave Crocker writes: Dave> Because there is no such value as "envelope sender". I use the term "envelope sender" to mean the MAIL FROM address. I regard this as common usage. The purpose of fetchmail is to obtain mail by verious means (often POP or IMAP) that may not give direct access to the envelope, and to reinsert the mail into the SMTP stream. It is typically used by people who have POP accounts but want to deliver their mail to an MTA on a local machine. In order to do this it needs to determine a "sensible" value to use for the SMTP MAIL FROM when transfering the mail to the local MTA. As you'll see from the posted algorithm, it's first choice is to use the *actual* previous value of the MAIL FROM, as identified by the Return-Path header. If this isn't available, as a fallback it appears to use something very similar to the PRA algorithm, with a couple of extra cases at the end. As I said before, this is a red herring. The only reason the fetchmail algorithm exists is because it has to operate in an environment where the value of MAIL FROM isn't available. I don't see its relevent to MARID work. -roy From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 20:05: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 UAA12960 for ; Mon, 6 Sep 2004 20:05: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 i86NfCMG013832; Mon, 6 Sep 2004 16:41: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 i86NfCkU013831; Mon, 6 Sep 2004 16:41:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from invasion.mail.pas.earthlink.net (invasion.mail.pas.earthlink.net [207.217.120.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86NfCQK013824 for ; Mon, 6 Sep 2004 16:41:12 -0700 (PDT) (envelope-from tripp@corp.earthlink.net) Received: from user-11fag3e.dsl.mindspring.com ([66.245.64.110] helo=[192.168.0.4]) by invasion.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 4.34) id 1C4T6n-0005rE-B1; Mon, 06 Sep 2004 16:41:13 -0700 In-Reply-To: <413CBAB5.50103@astrum.ch> References: <413CBAB5.50103@astrum.ch> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3AF11838-005E-11D9-82A0-000A95BDB38A@corp.earthlink.net> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Tripp Cox Subject: Re: [DEPLOY] General Issue w/ISPs blocking Port 25 Date: Mon, 6 Sep 2004 19:41:09 -0400 To: Matthias Leisi X-Mailer: Apple Mail (2.619) X-ELNK-Trace: 3507b2fe2d9b3ca5cc16ce54e02836f0308860774c94dbc142a95a3997133780350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.64.110 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sep 6, 2004, at 3:29 PM, Matthias Leisi wrote: > > I've encountered a number of ISPs where users are unable to do > outbound connections with dst port 25, but are limited to the ISPs > Smarthost. Although I haven't seen it yet, but I suspect that Port 587 > as per RFC 2476 (Message Submission) may be blocked as well if it's > use is adopted more widely. The recommended best practices for port 587 are that: * Access providers SHALL NOT block the port. * Submission agents MUST employ some means of authentication for submitters. Tripp From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 20:08: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 UAA13121 for ; Mon, 6 Sep 2004 20:08:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86NlwgJ014980; Mon, 6 Sep 2004 16:47: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 i86NlwgV014979; Mon, 6 Sep 2004 16:47:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86NlwDl014973 for ; Mon, 6 Sep 2004 16:47:58 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i86Nlqa02790; Mon, 6 Sep 2004 16:47:53 -0700 Date: Tue, 7 Sep 2004 08:32:51 +0900 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <195063211.20040907083251@brandenburg.com> To: Roy Badami CC: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify In-Reply-To: <16700.61568.149508.266801@giles.gnomon.org.uk> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy, RB> I use the term "envelope sender" to mean the MAIL FROM address. I RB> regard this as common usage. that would be fine, except that it is not the semantics of that field, and using that term has caused significant confusion. and all of this has been discussed extensively on this list and other. the more recent and accurate term that has attained 'common usage' is "bounce address". unless and until these discussions start using terminology carefully, there is no hope of achieving consensus that means anything. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 20:10: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 UAA13326 for ; Mon, 6 Sep 2004 20:10: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 i86No4Tf015603; Mon, 6 Sep 2004 16:50: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 i86No4jE015602; Mon, 6 Sep 2004 16:50:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i86No3Vg015595 for ; Mon, 6 Sep 2004 16:50:03 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 6 Sep 2004 16:50:05 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 06 Sep 2004 16:50:06 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 6 Sep 2004 16:50:04 -0700 Received: from df-dogbert-msg.exchange.corp.microsoft.com ([157.54.5.14]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Sep 2004 16:50:03 -0700 Content-class: urn:content-classes:message Subject: RE: [Deploy] Insufficient Microsoft IPR disclosure MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Sep 2004 16:49:56 -0700 x-mimeole: Produced By Microsoft Exchange V8.0.155.1 Message-ID: Thread-Topic: [Deploy] Insufficient Microsoft IPR disclosure thread-index: A8+Sjx46H1/x3B9pTR+kz/RxSQhQyQB3K9/w From: "Jim Lyon" To: "Tripp Cox" , X-OriginalArrivalTime: 06 Sep 2004 23:50:03.0331 (UTC) FILETIME=[3A930930:01C4946C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i86No3Vg015596 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tripp, If you scroll down on the page that Microsoft referenced, you'll find a link to the actual license text (http://download.microsoft.com/download/b/d/3/bd3b5463-c461-409c-b29f-51 2218d3f3e6/senderid_license.pdf) -- Jim Lyon -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Tripp Cox Sent: Saturday, September 04, 2004 7:43 AM To: ietf-mxcomp@imc.org Subject: [Deploy] Insufficient Microsoft IPR disclosure First, let me say that I think the proposed Sender-ID framework is a great first step in creating a low-overhead, global sender authentication framework. I would like nothing more than to deploy Sender-ID at EarthLink, however a lack of information in the Microsoft IPR claims and associated license at present will prevent me from doing so, base on the following advise from EarthLink counsel. The IETF's position on the provision of IP rights in connection with a particular patent holder that is proposing a standard require that "working groups and participants have as much information about any IPR constraints on a technical proposal as possible." What we have received, to date, from Microsoft is a short description of what Microsoft intends to include within its license. A link to this licensing position can be found at: http://www.microsoft.com/mscorp/ip/standards. Among the areas of concern for EarthLink include: Timing of the disclosure: The IPR for the IETF requires timely disclosure of all relevant licensing terms. As stated in Section 6.2 of Intellectual Property Rights in IETF Technology: "Timely IPR disclosure is important because working group need to have as much information as they can while they are evaluating alternative solutions." Substance of Grant and Lack of Disclosure Microsoft's proposed license does not meet the requirements of the IPR. While Microsoft states that it is willing to license all of its potential IPR to implement the standard on a royalty-free basis, Microsoft must also disclose any other terms and conditions in connection with this license. The disclosure by Microsoft fails to indicate these terms and conditions. As a result, we are not able to determine whether the license granted by Microsoft will fully enable the full use of Sender ID within a proposed standard and if there are any other impacts to integrally related areas that may not explicitly be included in the standard but may be necessary to fully exploit the standard. Without having access to the terms and conditions of the Microsoft license, this situation cannot fully be evaluated. In addition, it is not clear if all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to the proposed standard a) under a royalty-free and otherwise reasonable and non-discriminatory license, or b) under a license that contains reasonable and non-discriminatory terms and conditions, including a reasonable royalty or other payment, or c) without the need to obtain a license from the IPR holder. The answer to these questions is not clear and, as we understand it, Microsoft has been unwilling to address these issues. If Microsoft would be willing to address these issues in a satisfactory manner, then EarthLink would be willing and able to lend its support to the proposed standard. From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 20:30: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 UAA14709 for ; Mon, 6 Sep 2004 20:30:32 -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 i8708YYR018813; Mon, 6 Sep 2004 17:08:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8708YsV018812; Mon, 6 Sep 2004 17:08:34 -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 i8708Xes018802 for ; Mon, 6 Sep 2004 17:08:33 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LEIRQZ8FQ800005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Mon, 06 Sep 2004 17:08:32 -0700 (PDT) Date: Mon, 06 Sep 2004 17:07:38 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: TECH: use fetchmail algorithm to select header address to verify In-reply-to: "Your message dated Tue, 07 Sep 2004 00:19:28 +0100" <16700.61568.149508.266801@giles.gnomon.org.uk> To: Roy Badami Cc: Dave Crocker , Roy Badami , ietf-mxcomp@imc.org Message-id: <01LEJZ4UL3C000005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > >>>>> "Dave" == Dave Crocker writes: > Dave> Because there is no such value as "envelope sender". > I use the term "envelope sender" to mean the MAIL FROM address. I > regard this as common usage. I'm not sure it is common usage, but that's certainly how I interpreted it. > The purpose of fetchmail is to obtain mail by verious means (often POP > or IMAP) that may not give direct access to the envelope, and to > reinsert the mail into the SMTP stream. > It is typically used by people who have POP accounts but want to > deliver their mail to an MTA on a local machine. > In order to do this it needs to determine a "sensible" value to use > for the SMTP MAIL FROM when transfering the mail to the local MTA. As > you'll see from the posted algorithm, it's first choice is to use the > *actual* previous value of the MAIL FROM, as identified by the > Return-Path header. If this isn't available, as a fallback it appears > to use something very similar to the PRA algorithm, with a couple of > extra cases at the end. > As I said before, this is a red herring. The only reason the > fetchmail algorithm exists is because it has to operate in an > environment where the value of MAIL FROM isn't available. > I don't see its relevent to MARID work. Nice analysis. I completely agree with it. The algorithms may be similar but their goals are quite different. Ned From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 21:00: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 VAA17040 for ; Mon, 6 Sep 2004 21:00: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 i870SKC3021982; Mon, 6 Sep 2004 17:28:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i870SKdW021981; Mon, 6 Sep 2004 17:28:20 -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 i870SJ0l021954 for ; Mon, 6 Sep 2004 17:28:19 -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.8/8.12.8) with ESMTP id i870S91U021234 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 20:28:10 -0400 Message-Id: <6.1.2.0.2.20040906201948.07135ec0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 06 Sep 2004 20:26:14 -0400 To: "Jim Lyon" From: Daniel Senie Subject: RE: [Deploy] Insufficient Microsoft IPR disclosure Cc: ietf-mxcomp@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 07:49 PM 9/6/2004, you wrote: >Tripp, > >If you scroll down on the page that Microsoft referenced, you'll find a >link to the actual license text >(http://download.microsoft.com/download/b/d/3/bd3b5463-c461-409c-b29f-51 >2218d3f3e6/senderid_license.pdf) But not the patent application contents, nor any guarantees about what additional claims Microsoft might add to the claims over the years following submission of the application. Regardless of the wording of the license (and I do have issues with the wording of the license), this is badness. At this point, though, the whole thing appears moot. If open source folks won't use the mechanism, it's not going to reach critical mass in deployment and thus is going to fail. Years from now, we'll be able to look back and see that there was a chance to save the utility of email. but Microsoft's lawyers insisted on protecting their questionable IPR, rather than benefitting in a much greater way from saving the utility of email for the planet. So sorry. >-- Jim Lyon > > >-----Original Message----- >From: owner-ietf-mxcomp@mail.imc.org >[mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Tripp Cox >Sent: Saturday, September 04, 2004 7:43 AM >To: ietf-mxcomp@imc.org >Subject: [Deploy] Insufficient Microsoft IPR disclosure > > >First, let me say that I think the proposed Sender-ID framework is a >great >first step in creating a low-overhead, global sender authentication >framework. I would like nothing more than to deploy Sender-ID at >EarthLink, however a lack of information in the Microsoft IPR claims and > >associated license at present will prevent me from doing so, base on the > >following advise from EarthLink counsel. > >The IETF's position on the provision of IP rights in connection with a >particular patent holder that is proposing a standard require that >"working >groups and participants have as much information about any IPR >constraints >on a technical proposal as possible." What we have received, to date, >from >Microsoft is a short description of what Microsoft intends to include >within its license. A link to this licensing position can be found at: >http://www.microsoft.com/mscorp/ip/standards. > >Among the areas of concern for EarthLink include: > >Timing of the disclosure: > >The IPR for the IETF requires timely disclosure of all relevant >licensing >terms. As stated in Section 6.2 of Intellectual Property Rights in IETF > >Technology: "Timely IPR disclosure is important because working group >need >to have as much information as they can while they are evaluating >alternative solutions." > >Substance of Grant and Lack of Disclosure > >Microsoft's proposed license does not meet the requirements of the IPR. > >While Microsoft states that it is willing to license all of its >potential >IPR to implement the standard on a royalty-free basis, Microsoft must >also >disclose any other terms and conditions in connection with this license. > >The disclosure by Microsoft fails to indicate these terms and >conditions. >As a result, we are not able to determine whether the license granted by > >Microsoft will fully enable the full use of Sender ID within a proposed >standard and if there are any other impacts to integrally related areas >that may not explicitly be included in the standard but may be necessary >to >fully exploit the standard. Without having access to the terms and >conditions of the Microsoft license, this situation cannot fully be >evaluated. In addition, it is not clear if all persons will be able to > >obtain the right to implement, use, distribute and exercise other rights > >with respect to the proposed standard a) under a royalty-free and >otherwise >reasonable and non-discriminatory license, or b) under a license that >contains reasonable and non-discriminatory terms and conditions, >including a reasonable royalty or other payment, or c) without the need >to >obtain a license from the IPR holder. The answer to these questions is >not >clear and, as we understand it, Microsoft has been unwilling to address >these issues. > >If Microsoft would be willing to address these issues in a >satisfactory manner, then EarthLink would be willing and able to lend >its >support to the proposed standard. From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 21:28: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 VAA18524 for ; Mon, 6 Sep 2004 21:28: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 i8713A8Q027046; Mon, 6 Sep 2004 18:03:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8713A7j027045; Mon, 6 Sep 2004 18:03:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87139OC027039 for ; Mon, 6 Sep 2004 18:03:10 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4UMR-0005p2-FN; Mon, 06 Sep 2004 21:01:32 -0400 Message-ID: <413D087F.7090505@solidmatrix.com> Date: Mon, 06 Sep 2004 21:01:51 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Roy Badami CC: Dave Crocker , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> In-Reply-To: <16700.61568.149508.266801@giles.gnomon.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy Badami wrote: >>>>>>"Dave" == Dave Crocker writes: > > > Dave> Because there is no such value as "envelope sender". > > I use the term "envelope sender" to mean the MAIL FROM address. I > regard this as common usage. > > The purpose of fetchmail is to obtain mail by verious means (often POP > or IMAP) that may not give direct access to the envelope, and to > reinsert the mail into the SMTP stream. > > It is typically used by people who have POP accounts but want to > deliver their mail to an MTA on a local machine. > > In order to do this it needs to determine a "sensible" value to use > for the SMTP MAIL FROM when transfering the mail to the local MTA. As > you'll see from the posted algorithm, it's first choice is to use the > *actual* previous value of the MAIL FROM, as identified by the > Return-Path header. If this isn't available, as a fallback it appears > to use something very similar to the PRA algorithm, with a couple of > extra cases at the end. > > As I said before, this is a red herring. The only reason the > fetchmail algorithm exists is because it has to operate in an > environment where the value of MAIL FROM isn't available. > > I don't see its relevent to MARID work. What about the algorithms here: http://email.uoa.gr/projects/fromfilter/doc/fromfilter.html#toc9 and http://docs.sun.com/source/816-6091-10/contents.htm#CONVERSION "The email message's originator address is taken from one of the following five sources, shown in decreasing order of preference: 1. Resent-from: 4. Sender: 2. From: 5. Envelope From: 3. Resent-sender:" From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 21:35: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 VAA18750 for ; Mon, 6 Sep 2004 21:35: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 i871B7VV027910; Mon, 6 Sep 2004 18:11: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 i871B7DC027909; Mon, 6 Sep 2004 18:11:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i871B5RT027893 for ; Mon, 6 Sep 2004 18:11:06 -0700 (PDT) (envelope-from roy+dated+1097111459.df99aa@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i871CZle099688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Sep 2004 01:12:42 GMT (envelope-from roy+dated+1097111459.df99aa@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i871B0Aa073441 for ; Tue, 7 Sep 2004 02:11:00 +0100 (BST) (envelope-from roy+dated+1097111459.df99aa@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i871B0lL073438 for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 02:11:00 +0100 (BST) (envelope-from roy+dated+1097111459.df99aa@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 07 Sep 2004 02:10:58 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.2722.149695.20569@giles.gnomon.org.uk> Date: Tue, 7 Sep 2004 02:10:58 +0100 To: Yakov Shafranovich Cc: Roy Badami , Dave Crocker , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify In-Reply-To: <413D087F.7090505@solidmatrix.com> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > "The email message's originator address is taken from one of the > following five sources, shown in decreasing order of preference: > 1. Resent-from: 4. Sender: > 2. From: 5. Envelope From: > 3. Resent-sender:" What about it? The PRA algorithm isn't arbitrary; it's based on the RFC(2)822 definitions of the fields. The above algorithm makes no sense to me. The fact that someone has used it for something in the past is not a justification for using it here. -roy From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 21:57: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 VAA20911 for ; Mon, 6 Sep 2004 21:57: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 i871Wk64030870; Mon, 6 Sep 2004 18:32: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 i871Wkde030869; Mon, 6 Sep 2004 18:32:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i871WjUA030862 for ; Mon, 6 Sep 2004 18:32:45 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4UpC-00078E-02; Mon, 06 Sep 2004 21:31:10 -0400 Message-ID: <413D0FB7.9080903@solidmatrix.com> Date: Mon, 06 Sep 2004 21:32:39 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Roy Badami CC: Dave Crocker , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> In-Reply-To: <16701.2722.149695.20569@giles.gnomon.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy Badami wrote: >>"The email message's originator address is taken from one of the >>following five sources, shown in decreasing order of preference: >>1. Resent-from: 4. Sender: >>2. From: 5. Envelope From: >>3. Resent-sender:" > > > What about it? > > The PRA algorithm isn't arbitrary; it's based on the RFC(2)822 > definitions of the fields. > So let me get this straight. RFC 2822 (section 3.6.2) defines "Sender" as "mailbox of the agent responsible for the actual transmission of the message" which would be the party that actually put the email message into the initial SMTP transaction. The same RFC (section 3.6.6) represents "one individual" who "resends a message on behalf of one or more others". Now, I am an SMTP developer and after reading the RFC I want to find out who put the original message into the mail system. In order to determine the actual party who sent the original message according to the RFC I would have to look for the "Sender" field. If it is not present, then the "From" header is used since the RFC states (section 3.6.2) "if the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used." However, since the same RFC states that "Resent" fields are basically the same as the regular "Sender" and "From" fields in cases where the email is forwarded and re-introduced into the email system, I would have to parse "Resent-Sender" first, then "Resent-From", and only after that the regular "Sender" and "From" fields. Now if all of this is stated in the RFC directly, what exactly is the IPR that is being claimed here? This seems to me explicit in the RFC itself. > The above algorithm makes no sense to me. The fact that someone has > used it for something in the past is not a justification for using it > here. > I will agree with you that it will not sufficient for our purposes where we care about the original party who put the email into the email system, not the original author of the message, but it might be good enough for prior art. Yakov From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 22:09: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 WAA21459 for ; Mon, 6 Sep 2004 22:09: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 i871iqbj032639; Mon, 6 Sep 2004 18:44: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 i871iqXk032638; Mon, 6 Sep 2004 18:44:52 -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 i871ip1x032632 for ; Mon, 6 Sep 2004 18:44:52 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LEIRQZ8FQ800005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Mon, 06 Sep 2004 18:44:53 -0700 (PDT) Date: Mon, 06 Sep 2004 18:35:29 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: TECH: use fetchmail algorithm to select header address to verify In-reply-to: "Your message dated Mon, 06 Sep 2004 21:01:51 -0400" <413D087F.7090505@solidmatrix.com> To: Yakov Shafranovich Cc: Roy Badami , Dave Crocker , ietf-mxcomp@imc.org Message-id: <01LEK2IAH4YQ00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > Roy Badami wrote: > >>>>>>"Dave" == Dave Crocker writes: > > > > > > Dave> Because there is no such value as "envelope sender". > > > > I use the term "envelope sender" to mean the MAIL FROM address. I > > regard this as common usage. > > > > The purpose of fetchmail is to obtain mail by verious means (often POP > > or IMAP) that may not give direct access to the envelope, and to > > reinsert the mail into the SMTP stream. > > > > It is typically used by people who have POP accounts but want to > > deliver their mail to an MTA on a local machine. > > > > In order to do this it needs to determine a "sensible" value to use > > for the SMTP MAIL FROM when transfering the mail to the local MTA. As > > you'll see from the posted algorithm, it's first choice is to use the > > *actual* previous value of the MAIL FROM, as identified by the > > Return-Path header. If this isn't available, as a fallback it appears > > to use something very similar to the PRA algorithm, with a couple of > > extra cases at the end. > > > > As I said before, this is a red herring. The only reason the > > fetchmail algorithm exists is because it has to operate in an > > environment where the value of MAIL FROM isn't available. > > > > I don't see its relevent to MARID work. > What about the algorithms here: > http://email.uoa.gr/projects/fromfilter/doc/fromfilter.html#toc9 > and > http://docs.sun.com/source/816-6091-10/contents.htm#CONVERSION > "The email message's originator address is taken from one of the > following five sources, shown in decreasing order of preference: > 1. Resent-from: 4. Sender: > 2. From: 5. Envelope From: > 3. Resent-sender:" I can't speak to the fromfilter algorithm, but the algorithm you dug out of Sun's documentation is one of a family of algorithms designed to be used as part of a gateway from Internet mail, with its rich set of addressing fields, to some other system (in this case SMS) with a relative paucity of fields. The intent of these algorithms is to assign a certain set of semantics to replies generated by the more limited environment. Similar algorithms have been devised for many such systems, including but not limited to cc:Mail, Microsoft Mail, WordPerfect Office, Novell MHS, and VMS MAIL. Given that the intent of PRA is to derive a responsible address, not to determine a place to send replies, I consider all of these to be red herrings as well, albeit ones pulled out of a different kettle. Ned From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 22:59: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 WAA24269 for ; Mon, 6 Sep 2004 22:59: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 i872YB5h039284; Mon, 6 Sep 2004 19:34: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 i872YBrx039283; Mon, 6 Sep 2004 19:34:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i872YATD039258 for ; Mon, 6 Sep 2004 19:34:11 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from 192.168.1.10 ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 06 Sep 2004 22:34:05 -0400 id 0030C968.413D1E1D.00007990 From: David Blacka To: IETF MARID WG Subject: Re: consensus call of RR prefix Date: Mon, 6 Sep 2004 22:34:25 -0400 User-Agent: KMail/1.5.4 References: <200409051824.i85IOOg02258@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: Organization: Verisign, Inc. Cc: Mark Lentczner MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200409062234.25224.davidb@verisignlabs.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i872YBTD039278 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sunday 05 September 2004 5:01 pm, Mark Lentczner wrote: > Usually, the use of the wild-card record is to say "-all" for anything > in a subdomain, and hence this record is would not be the same as the > domain's record: > > with prefix: > _prefix.example.com IN SPF2 "spf2.0/pra +mx +a -all" > *.example.com IN SPF2 "spf2.0/pra -all" > > without prefix: > example.com IN SPF2 "spf2.0/pra +mx +a -all" > *.example.com IN SPF2 "spf2.0/pra -all" This is not a valid use of DNS wildcards, assuming I understand the problem you are trying to solve. In your example, "*.example.com IN SPF2 "spf2.0/pra -all", would only match names in example.com that do not exist (actually, the matching behavior is a bit more subtle that that). But, as has been pointed out on this list more than once, saying "-all" for non-existent names is unnecessary. What I think you are really after is to put a "-all" SPF2 record for every (other) existing A, AAAA, and MX record. There is no convenient DNS construct for this behavior. > The actual text from the current draft is: > "Sender-ID compliant sites MUST use DNS recursive servers that support > EDNS0 [RFC2671] and [RFC3226] in order to be able to receive large DNS > RR sets." > > This text, including the reference to RFC3226, came directly from > Ólafur of DNS-EXT. I have a hard time seeing how using EDNS0 rises to the level of MUST. Since querying for and publishing SPF2 or TXT records will not, in the typical case, cause truncation without EDNS0, this should be a SHOULD, not a MUST. That is, using EDNS0 is a good idea, but hardly a requirement. -- David Blacka Sr. Engineer Verisign Applied Research From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 23:07: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 XAA24909 for ; Mon, 6 Sep 2004 23:07:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i872hlY1040310; Mon, 6 Sep 2004 19:43:47 -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 i872hltB040309; Mon, 6 Sep 2004 19:43:47 -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 i872hkpf040302 for ; Mon, 6 Sep 2004 19:43:46 -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 1C4VxP-0008Hu-Tv for ietf-mxcomp@imc.org; Mon, 06 Sep 2004 21:43:48 -0500 To: "IETF MARID WG" References: <20040906193031.16757.qmail@tom.iecc.com> From: wayne Reply-To: "IETF MARID WG" Date: Mon, 06 Sep 2004 21:43:43 -0500 In-Reply-To: <20040906193031.16757.qmail@tom.iecc.com> (John Levine's message of "6 Sep 2004 19:30:31 -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: TECH: use fetchmail algorithm to select header address to verify 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.6 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 <20040906193031.16757.qmail@tom.iecc.com> John Levine writes: > > [proposed alternative to the PRA deleted] > > If there's interest in this, I'd be happy to help write it up as an > I-D. [...] As much as I would love to discuss this, the co-chairs are repeatedly asked us to not discuss alternative proposals until such time as we are finished working on the current I-Ds. I realize this puts us in somewhat of a awkward situation, since many people saying, in effect, that we must go forward with SenderID because it is the only thing around. As usual for threads, there has been a certain amount of topic drift, in this case into the subject of what the PRA and various other similar algorithms are trying to accomplish. I think this is an interesting topic and it isn't clear to me that what the PRA is trying to accomplish and the "identitity" that it creates is all that useful. However, I'm not sure that the co-chairs are even interesting in seeing a drawn out discussion on this either. I think we were supposed to discuss that May. As a result of those discussions back in May, the co-chairs ruled that we would focus on RFC2821 identities, and the charter says that discussions of other identities would be ruled out of order. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 23:43: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 XAA27071 for ; Mon, 6 Sep 2004 23:43: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 i8739CnN043486; Mon, 6 Sep 2004 20:09:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8739CNS043485; Mon, 6 Sep 2004 20:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8739B5M043472 for ; Mon, 6 Sep 2004 20:09:11 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 9100 invoked from network); 7 Sep 2004 03:09:11 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 7 Sep 2004 03:09:11 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "IETF MARID WG" Subject: RE: [DEPLOY] General Issue w/ISPs blocking Port 25 Date: Mon, 6 Sep 2004 23:09:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <413CBAB5.50103@astrum.ch> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Matthias Leisi > Sent: Monday, September 06, 2004 3:30 PM > To: IETF MARID WG > Subject: [DEPLOY] General Issue w/ISPs blocking Port 25 > > Since a few days, I check for SPF records at the MTA, and I noticed one > particular issue. I'm not sure whether the drafts (-submit) are the > right place to mention this issue, or whether some BCP would be > appropriate. > > I've encountered a number of ISPs where users are unable to do outbound > connections with dst port 25, but are limited to the ISPs Smarthost. > Although I haven't seen it yet, but I suspect that Port 587 as per RFC > 2476 (Message Submission) may be blocked as well if it's use is adopted > more widely. > > Obviously, that is pretty efficient to stop certain categories of junk > (-sources), and is generally not an issue, if the Smarthost allows > arbitrary 821/822 From's. > > However, with strict SPF (or SenderId) checking, this /does/ become an > issue, since a domain owner will most likely not add some random > Smarthost to the list of designated mailers. > > -submitter mentions the use of SUBMIT briefly, but maybe the > implications of the (how common?) blocking of dst port 25 should be > mentioned. > Is use of SUBMITTER were clarified as I suggested here: http://www.imc.org/ietf-mxcomp/mail-archive/msg04034.html Then transparent redirection would no longer be an issue, because the PRA should be in the domain of the smarthost. If the smarthost uses a SUBMITTER from it's domain and an appropriate RFC 2822 header so it validates, the domain owner you mention doesn't have to worry about this. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Mon Sep 6 23:51:17 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 XAA27604 for ; Mon, 6 Sep 2004 23:51:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873M0bw045239; Mon, 6 Sep 2004 20:22:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i873M01q045238; Mon, 6 Sep 2004 20:22:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873LxeR045227 for ; Mon, 6 Sep 2004 20:21:59 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4WWv-0003a2-7s for ietf-mxcomp@imc.org; Mon, 06 Sep 2004 23:20:25 -0400 Message-ID: <413D2951.3040300@solidmatrix.com> Date: Mon, 06 Sep 2004 23:21:53 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > As a result of those discussions back in May, the co-chairs ruled that > we would focus on RFC2821 identities, and the charter says that > discussions of other identities would be ruled out of order. > And which exact RFC 2821 identity are we focusing on? Except for SUBMITTER I don't see any other one. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 00:09:59 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 AAA28568 for ; Tue, 7 Sep 2004 00:09:58 -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 i873hVdo047652; Mon, 6 Sep 2004 20:43:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i873hVsU047651; Mon, 6 Sep 2004 20:43:31 -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 i873hT0W047641 for ; Mon, 6 Sep 2004 20:43:30 -0700 (PDT) (envelope-from sb0-0668d08819-johnl@iecc.com) Received: (qmail 13801 invoked by uid 100); 7 Sep 2004 03:43:32 -0000 Date: 7 Sep 2004 03:43:32 -0000 Message-ID: <20040907034332.13800.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: RR sizes, was consensus call of RR prefix In-Reply-To: <16699.17415.492224.734011@giles.gnomon.org.uk> Organization: I.E.C.C., Trumansburg NY USA Cc: roy@gnomon.org.uk Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >EDNS0 (RFC2535) provides a mechanism for sending larger DNS >transactions over UDP. RFC3226 (which is also referenced by Sender >ID) says that EDNS0 implementations MUST allow at least 1220 bytes, >and SHOULD allow at least 4000 bytes. An acquaintance who's tried out EDNS0 tells me that it is surprisingly hard to deploy and has worse interoperation problems than I would have expected. The first category of problems is what one might call the braindead firewall problem -- a whole lot of firewalls know that a DNS packet can never ever be bigger than 512 bytes, so they throw bigger packets away. While there are well-documented configuration fixes for them all, there are a whole lot of firewalls with this misfeature, to the extent that the folklore among Windows admins (Windows has a widely available EDNS0 client) is not to turn on EDNS0. The second is the probe problem. An EDNS0 client sends a request with a pseudo-RR asking for a big response, and then falls back to regular queries if the server doesn't grok EDNS0. But servers un-grok EDNS0 in a remarkable number of unfortunate ways, including sending back responses without the request's sequence number or any other way to figure out what request it's responding to, or sending no response at all. Since the number of EDNS0 servers is small, even with well behaved servers EDNS0 clients send roughly twice as many requests as they would otherwise, one to probe and then one to do the actual request. Clients can try to keep a cache to remember the results of prior probes but even that runs into trouble when you have a bunch of servers responding to the same IP and they're not all the same. The point of all this is that big responses will continue to be a problem probably forever. I think that the way to keep the response size down is to deploy new RR types as quickly as possiblee. Prefixes are less helpful since as soon as you have wildcards (which really do exist in mail domains) all the records all end up in all the nodes anyway. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I shook hands with Senators Dole and Inouye," said Tom, disarmingly. -- 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 Tue Sep 7 00:16: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 AAA28979 for ; Tue, 7 Sep 2004 00:16:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873ruja049418; Mon, 6 Sep 2004 20:53: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 i873ruq9049417; Mon, 6 Sep 2004 20:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i873rtna049406 for ; Mon, 6 Sep 2004 20:53:55 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 03:53:54 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "Yakov Shafranovich" Subject: RE: TECH: use fetchmail algorithm to select header address to verify Date: Mon, 6 Sep 2004 21:54:12 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <413D2951.3040300@solidmatrix.com> Importance: Normal X-OriginalArrivalTime: 07 Sep 2004 03:53:54.0158 (UTC) FILETIME=[4B3A10E0:01C4948E] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > As a result of those discussions back in May, the co-chairs ruled that > we would focus on RFC2821 identities, and the charter says that > discussions of other identities would be ruled out of order. Yakov Shafranovich wrote: >And which exact RFC 2821 identity are we focusing on? Except for >SUBMITTER I don't see any other one. Wayne mistyped and meant RFC 2822 identities. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 00:45: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 AAA00454 for ; Tue, 7 Sep 2004 00:45: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 i874Lkhx053229; Mon, 6 Sep 2004 21:21: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 i874LklG053228; Mon, 6 Sep 2004 21:21:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i874LiXZ053207 for ; Mon, 6 Sep 2004 21:21:45 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 04:21:41 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "Dave Crocker" Subject: RE: TECH: use fetchmail algorithm to select header address to verify Date: Mon, 6 Sep 2004 22:22:00 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <195063211.20040907083251@brandenburg.com> Importance: Normal X-OriginalArrivalTime: 07 Sep 2004 04:21:41.0857 (UTC) FILETIME=[2D40BD10:01C49492] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy Badami wrote: > I use the term "envelope sender" to mean the MAIL FROM address. I > regard this as common usage. Dave Crocker wrote: > that would be fine, except that it is not the semantics of that field, > and using that term has caused significant confusion. and all of this > has been discussed extensively on this list and other. > the more recent and accurate term that has attained 'common usage' is > "bounce address". ( "envelope sender" == "envelope from" == "bounce address" == "2821 from" == "821 from" == "MAIL FROM" ) I suppose we could argue about semantics and further digress from the MARID charter, but all of these terms mean the same and are pretty commonly used ("envelope sender" is certainly one of the more common ones and has been in use for several decades). Search Google Groups if you disagree. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 01:36: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 BAA03799 for ; Tue, 7 Sep 2004 01:36: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 i875Akrb062220; Mon, 6 Sep 2004 22:10: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 i875Akqp062219; Mon, 6 Sep 2004 22:10:46 -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 i875Aj4q062209 for ; Mon, 6 Sep 2004 22:10:45 -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 1C4YFf-0001T6-CM for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 00:10:48 -0500 To: "IETF MARID WG" References: <20040906193031.16757.qmail@tom.iecc.com> <413D2951.3040300@solidmatrix.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 07 Sep 2004 00:10:43 -0500 In-Reply-To: <413D2951.3040300@solidmatrix.com> (Yakov Shafranovich's message of "Mon, 06 Sep 2004 23:21:53 -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: TECH: use fetchmail algorithm to select header address to verify 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.6 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 <413D2951.3040300@solidmatrix.com> Yakov Shafranovich writes: > wayne wrote: >> As a result of those discussions back in May, the co-chairs ruled that >> we would focus on RFC2821 identities, and the charter says that >> discussions of other identities would be ruled out of order. >> > > And which exact RFC 2821 identity are we focusing on? Except for > SUBMITTER I don't see any other one. Well, SUBMITTER is the explanation that Andy gave me (via personal email) as to why SenderID and the PRA are 2821 identities. That explanation seemed strange to me, but there ya go. The co-chair ruling on focusing on 2821 identities was posted here: http://www.imc.org/ietf-mxcomp/mail-archive/msg01161.html I've brought this subject up a couple of times before, for example at: http://www.imc.org/ietf-mxcomp/mail-archive/msg02598.html -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 02:19:48 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 CAA20886 for ; Tue, 7 Sep 2004 02:19:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i875sskO086117; Mon, 6 Sep 2004 22:54:54 -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 i875ssc1086116; Mon, 6 Sep 2004 22:54:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i875sq61085971 for ; Mon, 6 Sep 2004 22:54:53 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i875skDx024688 for ; Tue, 7 Sep 2004 06:54:46 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i875skFX024687; Tue, 7 Sep 2004 06:54:46 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> <45524.127.0.0.1.1094509029.squirrel@127.0.0.1> <413CE9E5.2000609@solidmatrix.com> From: Graham Murray Date: Tue, 07 Sep 2004 06:54:46 +0100 In-Reply-To: <413CE9E5.2000609@solidmatrix.com> (Yakov Shafranovich's message of "Mon, 06 Sep 2004 18:51:17 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov Shafranovich writes: > Even if there isn't enough time for the lawyers to get back to us, > nevertheless an alternative draft without IPR problems should be > preferred according to RFC 3668, section 8 unless it is superior: > > " In general, IETF working groups prefer technologies with no known IPR > claims or, for technologies with claims against them, an offer of > royalty-free licensing. But IETF working groups have the discretion > to adopt technology with a commitment of fair and non-discriminatory > terms, or even with no licensing commitment, if they feel that this > technology is superior enough to alternatives with fewer IPR claims > or free licensing to outweigh the potential cost of the licenses. > " While IANAL, it could be argued that the Microsoft Sender-ID licence is not non-discriminatory as it (according to many people here, including lawyers) discriminates against open-source implementations. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 02: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 CAA22198 for ; Tue, 7 Sep 2004 02:34:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8768MkF092127; Mon, 6 Sep 2004 23:08:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8768MDD092126; Mon, 6 Sep 2004 23:08:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8768LsZ092078 for ; Mon, 6 Sep 2004 23:08:21 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i8768J7a024832 for ; Tue, 7 Sep 2004 07:08:19 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i8768JqQ024831; Tue, 7 Sep 2004 07:08:19 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> From: Graham Murray Date: Tue, 07 Sep 2004 07:08:19 +0100 In-Reply-To: <413D0FB7.9080903@solidmatrix.com> (Yakov Shafranovich's message of "Mon, 06 Sep 2004 21:32:39 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov Shafranovich writes: > Now, I am an SMTP developer and after reading the RFC I want to find out > who put the original message into the mail system. In order to determine > the actual party who sent the original message according to the RFC I > would have to look for the "Sender" field. If it is not present, then > the "From" header is used since the RFC states (section 3.6.2) "if the > originator of the message can be indicated by a single mailbox and the > author and transmitter are identical, the "Sender:" field SHOULD NOT be > used." However, since the same RFC states that "Resent" fields are > basically the same as the regular "Sender" and "From" fields in cases > where the email is forwarded and re-introduced into the email system, I > would have to parse "Resent-Sender" first, then "Resent-From", and only > after that the regular "Sender" and "From" fields. And by the same RFC, some of the situations which some discussion on this last has suggested that Resent-* headers might be inserted (by the MTA) are not valid usage of those fields. If the mail is originally addressed to me@alumni.org and is then forwarded to my "real" address me@example.com, then it is valid for alumni.org to add Resent-* headers. But if example.com sends mail via an ISP or MSP isp.com then it is not valid (as some have suggested here to enable the PRA to match) for isp.com to add Resent-* headers to all outgoing mail from its customers. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 02:36:09 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 CAA22353 for ; Tue, 7 Sep 2004 02:36: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 i876Evij094799; Mon, 6 Sep 2004 23: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 i876Evlf094798; Mon, 6 Sep 2004 23:14:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i876EqQp094726 for ; Mon, 6 Sep 2004 23:14:56 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 06:14:49 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: RE: TECH: use fetchmail algorithm to select header address to verify Date: Tue, 7 Sep 2004 00:15:09 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 07 Sep 2004 06:14:49.0766 (UTC) FILETIME=[FB297460:01C494A1] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > Well, SUBMITTER is the explanation that Andy gave me (via personal > email) as to why SenderID and the PRA are 2821 identities. That > explanation seemed strange to me, but there ya go. Bah! If so, that's a pretty *interesting* interpretation; interesting as in "I disagree". wayne wrote: > The co-chair ruling on focusing on 2821 identities was posted here: > http://www.imc.org/ietf-mxcomp/mail-archive/msg01161.html > > I've brought this subject up a couple of times before, for example at: > http://www.imc.org/ietf-mxcomp/mail-archive/msg02598.html Hmmm, I thought the ruling had been changed to use 2822 identities in order to allow this wonderful collaboration that is SenderID... Thanks for the background information. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 04:46:11 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 EAA01223 for ; Tue, 7 Sep 2004 04:46: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 i878IoJS045585; Tue, 7 Sep 2004 01:18:50 -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 i878IoX0045584; Tue, 7 Sep 2004 01:18:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i878IUbm045386 for ; Tue, 7 Sep 2004 01:18:49 -0700 (PDT) (envelope-from SRS0+cdae3b82a2e6926aca13+380+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.129.125]) by canuck.infradead.org with asmtp (Exim 4.33 #1 (Red Hat Linux)) id 1C4bBH-0007mo-RQ; Tue, 07 Sep 2004 04:18:24 -0400 Subject: Re: TECH: use fetchmail algorithm to select header address to verify From: David Woodhouse To: Graham Murray Cc: ietf-mxcomp@imc.org In-Reply-To: References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> Content-Type: text/plain; charset=UTF-8 Date: Tue, 07 Sep 2004 09:14:00 +0100 Message-Id: <1094544840.4996.52.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 2004-09-07 at 07:08 +0100, Graham Murray wrote: > And by the same RFC, some of the situations which some discussion on > this last has suggested that Resent-* headers might be inserted (by > the MTA) are not valid usage of those fields. If the mail is > originally addressed to me@alumni.org and is then forwarded to my > "real" address me@example.com, then it is valid for alumni.org to add > Resent-* headers. Says §3.6.6 of RFC2822: "Resent fields SHOULD be added to any message that is reintroduced by a user into the transport system." Note 'by a user'. This implies that it shouldn't be done when the message is forwarded automatically. But there's no need for inference -- it's made quite explicit a couple of paragraphs further down: "Note: Reintroducing a message into the transport system and using resent fields is a different operation from "forwarding". "Forwarding" has two meanings: One sense of forwarding is... <...irrelevant to us right now ...> ...On the other hand, forwarding is also used to mean when a mail transport program gets a message and forwards it on to a different destination for final delivery. Resent header fields are not intended for use with either type of forwarding." It is _not_ valid for 'alumni.org' to add Resent-* headers when forwarding mail to your current address. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 05:50: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 FAA05508 for ; Tue, 7 Sep 2004 05:50:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i879MrSW071811; Tue, 7 Sep 2004 02:22: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 i879Mr9B071810; Tue, 7 Sep 2004 02:22:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i879Mq7p071795 for ; Tue, 7 Sep 2004 02:22:53 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58812) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C4cBe-0002wN-PG (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 10:22:50 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4cBe-00043B-CE; Tue, 07 Sep 2004 10:22:50 +0100 Date: Tue, 7 Sep 2004 10:22:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "Michael R. Brumm" cc: IETF MARID WG Subject: RE: TECH OMISSION: Stronger checks against email forgery In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 27 Aug 2004, Michael R. Brumm wrote: > > The (2821 MAIL FROM) bounce address is irrelevant? This seems absurd > considering how many bounces (containing spam and viruses) I get for > messages I never sent. If you want to solve that problem set up something like BATV. Sender-ID and SPF do not solve the backscatter problem; at best they might ameliorate it. Tony. -- f.a.n.finch http://dotat.at/ SELSEY BILL TO LYME REGIS: EAST OR NORTHEAST 5 OR 6. FAIR. GOOD OR MODERATE. MODERATE TO ROUGH. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 05:50: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 FAA05526 for ; Tue, 7 Sep 2004 05:50: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 i879R6iU073764; Tue, 7 Sep 2004 02:27: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 i879R6HR073763; Tue, 7 Sep 2004 02:27:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i879R5rP073752 for ; Tue, 7 Sep 2004 02:27:06 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59712) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1C4cFU-0007H6-Vz (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 10:26:48 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4cFU-0004pQ-UL; Tue, 07 Sep 2004 10:26:48 +0100 Date: Tue, 7 Sep 2004 10:26:48 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Jim Lyon cc: IETF MARID WG Subject: RE: TECH OMISSION: Stronger checks against email forgery In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> Message-ID: References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 27 Aug 2004, Jim Lyon wrote: > > I continue to disagree. There are too many scenarios where the bounce > address is uncorrelated with the MTA that's delivering a message; this > means that any scheme that attempts to reject mail based on those two > inputs (bounce address and IP addr of sending MTA) will have too many > false rejections. What makes the PRA different from the bounce address from this point of view? Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE: WESTERLY BACKING SOUTHERLY 3 OR 4, OCCASIONALLY 5 AT FIRST. FAIR. GOOD. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 05:56: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 FAA05773 for ; Tue, 7 Sep 2004 05:56: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 i879VWSd075594; Tue, 7 Sep 2004 02:31:32 -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 i879VWJg075593; Tue, 7 Sep 2004 02:31:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i879VVo8075583 for ; Tue, 7 Sep 2004 02:31:32 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:60642) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C4cK2-00056H-Fe (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 10:31:30 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4cJs-0005hu-88 for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 10:31:20 +0100 Date: Tue, 7 Sep 2004 10:31:20 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: TECH-ERROR (-core): misuse of Resent- fields Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Secttion 7.2 recommends a use of the Resent-From: header field in direct contradiction to RFC 2822, which describes how those fields are currently used. Tony. -- f.a.n.finch http://dotat.at/ COLWYN BAY TO THE MULL OF GALLOWAY INCLUDING THE ISLE OF MAN: EAST 3 OR 4. FAIR. GOOD. SLIGHT. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 06:34: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 GAA08935 for ; Tue, 7 Sep 2004 06:34: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 i87ABGDn092582; Tue, 7 Sep 2004 03:11: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 i87ABGL5092581; Tue, 7 Sep 2004 03:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87ABFqG092571 for ; Tue, 7 Sep 2004 03:11:15 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40747) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C4cwS-0005gL-Oi (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 11:11:12 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4cwS-0005C3-NX for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 11:11:12 +0100 Date: Tue, 7 Sep 2004 11:11:12 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: TECH-OMISSION (-core): multiple alias-forwarding hops Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The draft does not specify whether 822 or 2822 semantics should be followed when adding Resent- header fields when forwarding a message. Should existing Resent- fields be removed or renamed or retained? Should the new fields be added amongst the trace fields or after the trace fields? What are the interoperability implications of either choice? Tony. -- f.a.n.finch http://dotat.at/ MULL OF KINTYRE TO ARDNAMURCHAN POINT: SOUTHEAST 3. FAIR. GOOD. SLIGHT TO MODERATE. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 06:34:22 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 GAA08968 for ; Tue, 7 Sep 2004 06:34: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 i87A6nGh090851; Tue, 7 Sep 2004 03:06: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 i87A6nd7090850; Tue, 7 Sep 2004 03:06:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87A6mb8090836 for ; Tue, 7 Sep 2004 03:06:48 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39716) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1C4csA-0002DG-Vg (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 11:06:46 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4csA-0004JG-UT for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 11:06:46 +0100 Date: Tue, 7 Sep 2004 11:06:46 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: TECH-OMISSION (-core): alias-forwarding and multiple recipients Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It is not clear how alias-forwarders are supposed to handle messages with multiple recipients. When handling such a message, Exim and some other MTAs will determine the final alias destination(s) of all addresses in the recipient list before delivery starts, so that only one copy of the message needs to be sent to each destination host. Say for example a message is sent to two addresses at an alumni forwarding service: fanf2@alumni.cam.ac.uk, abc123@alumni.cam.ac.uk. If both of these addresses happen to forward to the same place, say dot@dotat.at and abc123@dotat.at, then the alumni.cam.ac.uk system will want to send one copy of the message to the dotat.at system with multiple recipients. What address should it use in the Resent-From: header? It can't use both addresses, because then it would have to add a Resent-Sender: header and we get back to the original question (and anyway the draft doesn't allow for alias-forwarders to add a Resent-Sender: header). Perhaps the forwarder should just use mailer-daemon@alumni.cam.ac.uk as the Resent-From: address on all messages it handles? The problem is more tricky of the forwarder is dealing with multiple virtual domains. The central email relay of the University of Cambridge (known as ppsw.cam.ac.uk) handles over 150 virtual mail domains. Which domain should it use in the Resent-From: address when a message was originally sent to addresses in two different domains which alias-forward to the same domain? Since ppsw.cam.ac.uk is a valid mail domain used only for operational purposes, perhaps it should just add Resent-From: mailer-daemon@ppsw.cam.ac.uk to all messages it handles? Note that this would not do anything to protect the mail domains that are actually used by our users! Tony. -- f.a.n.finch http://dotat.at/ BISCAY: EAST OR NORTHEAST 5 OR 6, OCCASIONALLY 7 IN NORTH. THUNDERY SHOWERS. MODERATE OR GOOD. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 06:39: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 GAA10260 for ; Tue, 7 Sep 2004 06:39:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87AGCRN094513; Tue, 7 Sep 2004 03:16: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 i87AGCqX094512; Tue, 7 Sep 2004 03:16:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87AGBV6094501 for ; Tue, 7 Sep 2004 03:16:12 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42280) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C4d1G-0006ju-DO (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 11:16:10 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4d1G-0006JJ-CE for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 11:16:10 +0100 Date: Tue, 7 Sep 2004 11:16:10 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: TECH-ERROR (-core): current practice Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Section 7.2 says: Some of today's forwarders already add an appropriate header (although many of them use Sender rather than Resent-From.) This is completely incorrect. Most alias-forwarders add nothing. Some add a non-standard and undocumented header. Tony. -- f.a.n.finch http://dotat.at/ RATTRAY HEAD TO BERWICK ON TWEED: VARIABLE BECOMING EAST OR SOUTHEAST 3 OR 4. FAIR. GOOD. SLIGHT. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 06:40: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 GAA10557 for ; Tue, 7 Sep 2004 06:40:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87AHbAd095111; Tue, 7 Sep 2004 03:17:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87AHbQj095110; Tue, 7 Sep 2004 03:17:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87AHaIv095097 for ; Tue, 7 Sep 2004 03:17:37 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42604) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C4d2Z-00076r-Ua (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 11:17:31 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4d2Z-0006cn-Ta for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 11:17:31 +0100 Date: Tue, 7 Sep 2004 11:17:31 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: DOC-BUG (-core): typo Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 7.4 Third-Party Mailers: "third-part" should be "third-party" (missing y). Tony. -- f.a.n.finch http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: SOUTH OR SOUTHEAST 3. FAIR. GOOD. SLIGHT TO MODERATE. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 07:46: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 HAA14644 for ; Tue, 7 Sep 2004 07:46: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 i87BIKJ9013168; Tue, 7 Sep 2004 04:18:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87BIK7T013167; Tue, 7 Sep 2004 04:18:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87BIJDG013160 for ; Tue, 7 Sep 2004 04:18:20 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56718) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1C4dzM-0000Ok-4a (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 12:18:16 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4dzM-0002Ci-3b for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 12:18:16 +0100 Date: Tue, 7 Sep 2004 12:18:16 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: TECH-ERROR (-core): introduction Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This document describes a mechanism such that receiving MTAs, MDAs and/or MUAs can recognize [forged] mail Sender-ID can only reliably identify unforged email. It cannot reliably identify forged email, because it falsely rejects legitimate email if it has been alias-forwarded, or if it was sent by a roaming user. Tony. -- f.a.n.finch http://dotat.at/ SELSEY BILL TO LYME REGIS: EAST OR NORTHEAST 5 OR 6. FAIR. GOOD OR MODERATE. MODERATE TO ROUGH. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 07:46: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 HAA14662 for ; Tue, 7 Sep 2004 07:46: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 i87BKYOr013426; Tue, 7 Sep 2004 04:20:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87BKYdP013425; Tue, 7 Sep 2004 04:20:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87BKX1f013415 for ; Tue, 7 Sep 2004 04:20:33 -0700 (PDT) (envelope-from roy+dated+1097148024.57d81c@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87BMA2p073436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Sep 2004 11:22:16 GMT (envelope-from roy+dated+1097148024.57d81c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87BKPLa076132 for ; Tue, 7 Sep 2004 12:20:25 +0100 (BST) (envelope-from roy+dated+1097148024.57d81c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i87BKP9k076131 for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 12:20:25 +0100 (BST) (envelope-from roy+dated+1097148024.57d81c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 07 Sep 2004 12:20:20 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.39284.7011.504276@giles.gnomon.org.uk> Date: Tue, 7 Sep 2004 12:20:20 +0100 To: Yakov Shafranovich Cc: Roy Badami , Dave Crocker , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify In-Reply-To: <413D0FB7.9080903@solidmatrix.com> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Yakov" == Yakov Shafranovich writes: >> The above algorithm makes no sense to me. The fact that >> someone has used it for something in the past is not a >> justification for using it here. >> Yakov> I will agree with you that it will not sufficient for our Yakov> purposes where we care about the original party who put the Yakov> email into the email system, not the original author of the Yakov> message, but it might be good enough for prior art. No. I mean it simply makes no sense. Since the from field in mandatory, the algorithm will never proceed beyond step 2. Steps 3 to 5 will only ever be reached if the message is malformed. -roy From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 08:10: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 IAA16019 for ; Tue, 7 Sep 2004 08:10: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 i87Bk1p0016866; Tue, 7 Sep 2004 04:46: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 i87Bk1nu016865; Tue, 7 Sep 2004 04:46:01 -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 i87Bk0vU016858 for ; Tue, 7 Sep 2004 04:46:00 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 665B426C06E; Tue, 7 Sep 2004 13:46:01 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 3BDB226C091; Tue, 7 Sep 2004 13:46:00 +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 i87Bjxm71035080; Tue, 7 Sep 2004 13:45:59 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 74622FACE; Tue, 7 Sep 2004 13:45:59 +0200 (CEST) Date: Tue, 7 Sep 2004 13:45:59 +0200 From: Stephane Bortzmeyer To: Yakov Shafranovich Cc: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify Message-ID: <20040907114559.GA27441@nic.fr> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413D0FB7.9080903@solidmatrix.com> 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 Mon, Sep 06, 2004 at 09:32:39PM -0400, Yakov Shafranovich wrote a message of 49 lines which said: > Now if all of this is stated in the RFC directly, what exactly is > the IPR that is being claimed here? This seems to me explicit in the > RFC itself. We all agree that the patent claim from Microsoft is almost certainly obvious / frivolous / invalid. Almost all software patents are. Microsoft is not known for interesting contributions to computer science, only for massive patent filing (see http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,775,781.WKU.&OS=PN/6,775,781&RS=PN/6,775,781 which basically patents every program like sudo or calife). But it does not solve the issue: should we take the risk? Should we move to the standards track with such a threat, which will probably deter many people? An individual outside of the US (software patents are still illegal in Europe, see http://swpat.ffii.org/) can do it (I did it in http://www.imc.org/ietf-mxcomp/mail-archive/msg03656.html, a message which certainly infringes Microsoft ridiculous IPR claims). But most organizations will not. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 09:23: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 JAA20420 for ; Tue, 7 Sep 2004 09:23: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 i87CsU0O024753; Tue, 7 Sep 2004 05:54: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 i87CsUkS024752; Tue, 7 Sep 2004 05:54:30 -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 i87CsT7v024739 for ; Tue, 7 Sep 2004 05:54:29 -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; Tue, 07 Sep 2004 08:54:28 -0400 id 0011B824.413DAF84.000051E2 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <20040906193031.16757.qmail@tom.iecc.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0AEC9791-00CD-11D9-9A6B-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: TECH: use fetchmail algorithm to select header address to verify Date: Tue, 7 Sep 2004 08:54:23 -0400 To: "IETF MARID WG" 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 Sep 6, 2004, at 10:43 PM, wayne wrote: > As much as I would love to discuss this, the co-chairs are repeatedly > asked us to not discuss alternative proposals until such time as we > are finished working on the current I-Ds. Wayne, Is your proposal a different algorithm for using the headers? Or is it more than that? -andy From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 09:25: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 JAA20605 for ; Tue, 7 Sep 2004 09:25:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87CxU6Q025274; Tue, 7 Sep 2004 05:59: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 i87CxUFJ025273; Tue, 7 Sep 2004 05:59:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87CxTUD025260 for ; Tue, 7 Sep 2004 05:59:29 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4fXm-00041U-Dm; Tue, 07 Sep 2004 08:57:54 -0400 Message-ID: <413DB0AC.3030505@solidmatrix.com> Date: Tue, 07 Sep 2004 08:59:24 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Stephane Bortzmeyer CC: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <20040907114559.GA27441@nic.fr> In-Reply-To: <20040907114559.GA27441@nic.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > On Mon, Sep 06, 2004 at 09:32:39PM -0400, > Yakov Shafranovich wrote > a message of 49 lines which said: > > >>Now if all of this is stated in the RFC directly, what exactly is >>the IPR that is being claimed here? This seems to me explicit in the >>RFC itself. > > > We all agree that the patent claim from Microsoft is almost certainly > obvious / frivolous / invalid. Almost all software patents > are. Microsoft is not known for interesting contributions to computer > science, only for massive patent filing (see > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,775,781.WKU.&OS=PN/6,775,781&RS=PN/6,775,781 > which basically patents every program like sudo or calife). > > But it does not solve the issue: should we take the risk? Should we > move to the standards track with such a threat, which will probably > deter many people? > In the past there have been at least two cases where a WG moved ahead with the standard and disregarded the IPR claims as frivilious: IDN and Walid patent, and IPSec and UUNet's patent. Therefore, one optionl could be to consider the IPR claims as meanigless, especially in light of prior art, and move on. Of course, that only works if deployment is not hindered. Based on the Apache and Debian statements, as well as others, it may be too late for that. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 10:04:50 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 KAA23595 for ; Tue, 7 Sep 2004 10:04:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Dd4dF029059; Tue, 7 Sep 2004 06:39: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 i87Dd4lw029058; Tue, 7 Sep 2004 06:39:04 -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 i87Dd3bg029052 for ; Tue, 7 Sep 2004 06:39:03 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 3AB0C26C097; Tue, 7 Sep 2004 15:39:05 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id CE3DF26C096; Tue, 7 Sep 2004 15:39:03 +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 i87Dd3m7587969; Tue, 7 Sep 2004 15:39:03 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 9E171FACE; Tue, 7 Sep 2004 15:39:03 +0200 (CEST) Date: Tue, 7 Sep 2004 15:39:03 +0200 From: Stephane Bortzmeyer To: Tony Finch Cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR (-core): introduction Message-ID: <20040907133903.GA5488@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 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 Tue, Sep 07, 2004 at 12:18:16PM +0100, Tony Finch wrote a message of 13 lines which said: > Sender-ID can only reliably identify unforged email. It cannot > reliably identify forged email, because it falsely rejects > legitimate email if it has been alias-forwarded, or if it was sent > by a roaming user. I suggest to elaborate a bit. SenderID is not SPF and has better features to deal with alias-forwarded messages (submitter, PRA). From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 10:06:40 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 KAA23742 for ; Tue, 7 Sep 2004 10:06:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Dh8oE029395; Tue, 7 Sep 2004 06: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 i87Dh8PK029394; Tue, 7 Sep 2004 06:43:08 -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 i87Dh751029386 for ; Tue, 7 Sep 2004 06:43:08 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id D32E526C06F; Tue, 7 Sep 2004 15:43:09 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 6F43F26C06E; Tue, 7 Sep 2004 15:43:08 +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 i87Dh8m7593251; Tue, 7 Sep 2004 15:43:08 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 4CE2BFACE; Tue, 7 Sep 2004 15:43:08 +0200 (CEST) Date: Tue, 7 Sep 2004 15:43:08 +0200 From: Stephane Bortzmeyer To: Tony Finch Cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR (-core): current practice Message-ID: <20040907134308.GB5488@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 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 Tue, Sep 07, 2004 at 11:16:10AM +0100, Tony Finch wrote a message of 14 lines which said: > This is completely incorrect. Most alias-forwarders add > nothing. Some add a non-standard and undocumented header. Does anyone has a comprehensive list of major MTAs' behaviour? For instance (just tested): Postfix 2.1 with ".forward" : adds a Delivered-To (not mentioned in RFC 2822) but no Resent-something From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 10:10:48 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 KAA24153 for ; Tue, 7 Sep 2004 10:10:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87DhAVM029406; Tue, 7 Sep 2004 06:43:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87DhAGm029405; Tue, 7 Sep 2004 06:43:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Dh9rw029398 for ; Tue, 7 Sep 2004 06:43:10 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4gE2-0006Oi-SF; Tue, 07 Sep 2004 09:41:35 -0400 Message-ID: <413DBAE7.1030504@solidmatrix.com> Date: Tue, 07 Sep 2004 09:43:03 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Tony Finch CC: Jim Lyon , IETF MARID WG Subject: Re: TECH OMISSION: Stronger checks against email forgery References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony Finch wrote: > On Fri, 27 Aug 2004, Jim Lyon wrote: > >>I continue to disagree. There are too many scenarios where the bounce >>address is uncorrelated with the MTA that's delivering a message; this >>means that any scheme that attempts to reject mail based on those two >>inputs (bounce address and IP addr of sending MTA) will have too many >>false rejections. > > > What makes the PRA different from the bounce address from this point of > view? > The PRA algorithm tries to guess the most recent "Sender" for the message - i.e. the one that is being used for this SMTP hop. The bounce address on the other hand originates from the original hop and stays that way throughout multiple SMTP hops. Two related points I want to stress as well: 1. The verification is no longer being done on bounce address, that would mean that domains are not protected from bounces. In a case where multiple SMTP hops take place with non-compliant MTAs, and the last hop using a compliant MTA, the bounces will be directed to the original domain, even though it is using Sender ID. 2. The "Sender" header is being verified over the "From" header. While according to the RFC that is the agent introducing the message into the email system, the "Sender" header is not displayed in MUAs. Therefore, in a compliant MTA but non-compliant MUA, it is still possible to fool the system by using a valid "Sender" header with fake "From" headers. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 10:13:26 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 KAA24398 for ; Tue, 7 Sep 2004 10:13:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87DoGsn030229; Tue, 7 Sep 2004 06:50: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 i87DoG2l030228; Tue, 7 Sep 2004 06:50:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87DoFjG030222 for ; Tue, 7 Sep 2004 06:50:15 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57292) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1C4gML-0006Le-0k (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 14:50:09 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4gMK-0005OC-UC; Tue, 07 Sep 2004 14:50:08 +0100 Date: Tue, 7 Sep 2004 14:50:08 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Yakov Shafranovich cc: Jim Lyon , IETF MARID WG Subject: Re: TECH OMISSION: Stronger checks against email forgery In-Reply-To: <413DBAE7.1030504@solidmatrix.com> Message-ID: References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 7 Sep 2004, Yakov Shafranovich wrote: > Tony Finch wrote: > > On Fri, 27 Aug 2004, Jim Lyon wrote: > > > > > I continue to disagree. There are too many scenarios where the bounce > > > address is uncorrelated with the MTA that's delivering a message; this > > > means that any scheme that attempts to reject mail based on those two > > > inputs (bounce address and IP addr of sending MTA) will have too many > > > false rejections. > > > > What makes the PRA different from the bounce address from this point of > > view? > > The PRA algorithm tries to guess the most recent "Sender" for the message - > i.e. the one that is being used for this SMTP hop. The bounce address on the > other hand originates from the original hop and stays that way throughout > multiple SMTP hops. This is also true for the PRA, since no existing MTAs add Resent-From: header fields when alias-forwarding. Tony. -- f.a.n.finch http://dotat.at/ DOGGER: NORTHEAST 4 OR 5. FAIR. GOOD. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 11:26: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 LAA29697 for ; Tue, 7 Sep 2004 11:26: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 i87EZ39x034483; Tue, 7 Sep 2004 07:35:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87EZ3kQ034482; Tue, 7 Sep 2004 07:35:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87EZ03C034472 for ; Tue, 7 Sep 2004 07:35:02 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1C4h3m-0007vj-00 for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 15:35:02 +0100 Message-ID: <095d01c494e7$7432f7b0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> Subject: Re: TECH OMISSION: Stronger checks against email forgery Date: Tue, 7 Sep 2004 15:32:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "Yakov Shafranovich" commented: > > Tony Finch wrote: > > > On Fri, 27 Aug 2004, Jim Lyon wrote: > > > >>I continue to disagree. There are too many scenarios where the bounce > >>address is uncorrelated with the MTA that's delivering a message; this > >>means that any scheme that attempts to reject mail based on those two > >>inputs (bounce address and IP addr of sending MTA) will have too many > >>false rejections. > > > > > > What makes the PRA different from the bounce address from this point of > > view? > > > > The PRA algorithm tries to guess the most recent "Sender" for the > message - i.e. the one that is being used for this SMTP hop. The bounce > address on the other hand originates from the original hop and stays > that way throughout multiple SMTP hops. > > Two related points I want to stress as well: > 1. The verification is no longer being done on bounce address, that > would mean that domains are not protected from bounces. In a case where > multiple SMTP hops take place with non-compliant MTAs, and the last hop > using a compliant MTA, the bounces will be directed to the original > domain, even though it is using Sender ID. Or directed to whatever address was given in the Mail-From (which need not be related to the actual origin of the message). It could be intended that the bounce (perhaps with malicious content) be sent to the 'victim' identified in the Mail-From, and an additional 'benefit' of the intentional bounce is that the reputation of the 'final hop', Sender-ID-compliant node, or of the one before it, might thereby be damaged. > 2. The "Sender" header is being verified over the "From" header. While > according to the RFC that is the agent introducing the message into the > email system, the "Sender" header is not displayed in MUAs. Therefore, > in a compliant MTA but non-compliant MUA, it is still possible to fool > the system by using a valid "Sender" header with fake "From" headers. > > Yakov > > > Chris Haynes From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 11:53:48 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 LAA02499 for ; Tue, 7 Sep 2004 11:53:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87FKJQo037951; Tue, 7 Sep 2004 08:20:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87FKJ1O037950; Tue, 7 Sep 2004 08:20:19 -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 i87FKHWJ037944 for ; Tue, 7 Sep 2004 08:20:18 -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 1C4hlV-0008Gs-8A for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 10:20:20 -0500 To: "IETF MARID WG" References: <20040906193031.16757.qmail@tom.iecc.com> <0AEC9791-00CD-11D9-9A6B-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 07 Sep 2004 10:20:13 -0500 In-Reply-To: <0AEC9791-00CD-11D9-9A6B-000A95B3BA44@hxr.us> (Andrew Newton's message of "Tue, 7 Sep 2004 08:54:23 -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: TECH: use fetchmail algorithm to select header address to verify 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.6 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 <0AEC9791-00CD-11D9-9A6B-000A95B3BA44@hxr.us> Andrew Newton writes: > On Sep 6, 2004, at 10:43 PM, wayne wrote: > >> As much as I would love to discuss this, the co-chairs are repeatedly >> asked us to not discuss alternative proposals until such time as we >> are finished working on the current I-Ds. > > Wayne, > > Is your proposal a different algorithm for using the headers? Or is > it more than that? It is a fair amount different than either the PRA or the fetchmail algorithms. I believe that protecting the From: header is *CRITICAL* because it is the only thing that is usually shown by MUAs that are out in the field today and that is what is needed to stop phishing. As such, the only header that is checked is the From: header. As has been pointed out many times, in a (vast?) majority of cases, email is one hop, person to person, where the 2821.MAILFROM is the same as the 2822.From:. I such cases, there is no reason to check anything other than that single email address and SenderID is already the same as SPF-classic. In the cases where the 2821.MAILFROM is not the same as the 2822.From:, most of it is due to some sort of forwarding/redirection that the end user receiving the email has set up. For example, mailing lists and things like acm.org. In almost all cases, it is easy to identify something to whitelist on. Many times, the end user will not even need tell a spam filter/MUA about it, it can be automatically determined. My ideas about this stuff is actually heavily based on the way SpamAssassin does its auto-whitelists. There are cases that my method doesn't work very well on. For example, if a company outsources their email for things like customer web orders and wants a different 2821.MAILFROM vs the 2821.From:, then there is nothing to whitelist on. I such cases, the company and ESP will need to depend on an accreditation system. Or, they could rework how they are doing things so that the From: header will authenticate. Also, stuff that is BCC'ed may need to fall back to far less reliable things like the HELO domain. The many different and ever-changing list of valid HELO domains, however, can usually be collected via normal traffic, so an automated system could detect such cases. My hurriedly authored I-D can be found at: http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt (This was supposed to be part of the Unified-SPF collection of I-Ds, but I didn't get word from Meng not to submit it until too late.) -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 13:04:50 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 NAA10273 for ; Tue, 7 Sep 2004 13:04:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87GYEDR045338; Tue, 7 Sep 2004 09: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 i87GYEH0045337; Tue, 7 Sep 2004 09:34:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87GYElS045331 for ; Tue, 7 Sep 2004 09:34:14 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 7 Sep 2004 09:34:17 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Sep 2004 09:34:18 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 09:34:17 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 09:34:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Motion to abandon Sender ID Date: Tue, 7 Sep 2004 09:34:15 -0700 Message-ID: Thread-Topic: Motion to abandon Sender ID thread-index: AcSUWl/dv+W6JsQUSrOJNah0OWF1kwAnam/Q From: "Harry Katz" To: "Chris Haynes" , "IETF MARID WG" X-OriginalArrivalTime: 07 Sep 2004 16:34:16.0708 (UTC) FILETIME=[8462BC40:01C494F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i87GYElS045332 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, September 06, 2004 2:39 PM, Chris Haynes [mailto:chris@harvington.org.uk] wrote: > "Harry Katz" helpfully stated: > > > > > > Our IPR disclosure filed with the IETF and available at > > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-marid-core.txt > > is quite specific and covers the marid-core and marid-pra specs used > > in combination. That's all. We do not, to the best of my knowledge, > > have any IPR claims related to either marid-protocol, which describes > > the SPF2 record format, or marid-submitter. > Harry, > > In a discussion elsewhere there has been uncertainty as to > the exact meaning and implications of the phrase 'used in > combination' in your statement below. > > If you were able to confirm that the Microsoft disclosure / > IPR claims do not cover the marid-core spec. taken in > isolation, that would be extremely helpful and could allay > some people's concerns. > > Chris Haynes Confirmed. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 13:05:34 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 NAA10389 for ; Tue, 7 Sep 2004 13:05:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87GdowX045830; Tue, 7 Sep 2004 09:39:50 -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 i87GdoJi045829; Tue, 7 Sep 2004 09:39:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87GdnbW045819 for ; Tue, 7 Sep 2004 09:39:49 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4iyy-0008Sj-Fg; Tue, 07 Sep 2004 12:38:15 -0400 Message-ID: <413DE41E.5060504@solidmatrix.com> Date: Tue, 07 Sep 2004 12:38:54 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Tony Finch CC: Jim Lyon , IETF MARID WG Subject: Re: TECH OMISSION: Stronger checks against email forgery References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony Finch wrote: > On Tue, 7 Sep 2004, Yakov Shafranovich wrote: > >>Tony Finch wrote: >> >>>On Fri, 27 Aug 2004, Jim Lyon wrote: >>> >>> >>>>I continue to disagree. There are too many scenarios where the bounce >>>>address is uncorrelated with the MTA that's delivering a message; this >>>>means that any scheme that attempts to reject mail based on those two >>>>inputs (bounce address and IP addr of sending MTA) will have too many >>>>false rejections. >>> >>>What makes the PRA different from the bounce address from this point of >>>view? >> >>The PRA algorithm tries to guess the most recent "Sender" for the message - >>i.e. the one that is being used for this SMTP hop. The bounce address on the >>other hand originates from the original hop and stays that way throughout >>multiple SMTP hops. > > > This is also true for the PRA, since no existing MTAs add Resent-From: > header fields when alias-forwarding. > I think we are going in circles. Validating the bounce address only prevents false bounces but allows phishing, validating "Sender" does not stop phishing but allows bounces plus does not take into account forwarding, validating the "from" headers stops phishing but allows bounces. Which one of these do we really want? Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 13:09:55 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 NAA11284 for ; Tue, 7 Sep 2004 13:09:54 -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 i87GhnaO047212; Tue, 7 Sep 2004 09:43: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 i87Ghn4b047211; Tue, 7 Sep 2004 09:43:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Ghmod047178 for ; Tue, 7 Sep 2004 09:43:48 -0700 (PDT) (envelope-from rmalayter@bai.org) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: TECH OMISSION: Stronger checks against email forgery Date: Tue, 7 Sep 2004 11:43:47 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEBC8F@cliff.bai.org> Thread-Topic: TECH OMISSION: Stronger checks against email forgery thread-index: AcSU4S8Zi5OQDScfRFGmbk4YD0fWzwADuv7w From: "Ryan Malayter" To: "Yakov Shafranovich" , "Tony Finch" Cc: "Jim Lyon" , "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i87Ghmod047205 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Yakov Shafranovich] > 2. The "Sender" header is being verified over the "From" > header. While according to the RFC that is the agent > introducing the message into the email system, the > "Sender" header is not displayed in MUAs. This may be one of the rare cases where Microsoft MUAs are "more RFC compliant" than most others; Outlook 2000 and newer do in fact show a message with a Sender header as "From on behalf of ". But then again, even the latest Outlook 2003SP1/ Outlook Express versions do *not* handle the "resent-from" and "resent-sender" headers that are part of the Microsoft PRA algorithm (and RFC-2822). Obviously, MS will change this in future versions of their MUAs, but as it stands now, sender ID will not be very effective at preventing phishing and other types of forgery. (Outlook Express doesn't appear to do anything with even the "Sender" header, in any version I've tried). I always thought that rewriting the RFC-2822 "From" header at the MDA to show the PRA in some fashion should be a MAY or SHOULD action in the Sender-ID spec, to handle legacy MUAs that don't show the PRA fields to the user. -- Ryan From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 13:17:40 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 NAA11771 for ; Tue, 7 Sep 2004 13:17: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 i87GnI54047789; Tue, 7 Sep 2004 09:49: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 i87GnITq047788; Tue, 7 Sep 2004 09:49:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87GnHSC047782 for ; Tue, 7 Sep 2004 09:49:17 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4j87-0000j4-R6; Tue, 07 Sep 2004 12:47:40 -0400 Message-ID: <413DE67F.5040908@solidmatrix.com> Date: Tue, 07 Sep 2004 12:49:03 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Ryan Malayter CC: Tony Finch , Jim Lyon , IETF MARID WG Subject: Re: TECH OMISSION: Stronger checks against email forgery References: <792DE28E91F6EA42B4663AE761C41C2A02CEBC8F@cliff.bai.org> In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEBC8F@cliff.bai.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ryan Malayter wrote: > [Yakov Shafranovich] > >>2. The "Sender" header is being verified over the "From" >>header. While according to the RFC that is the agent >>introducing the message into the email system, the >>"Sender" header is not displayed in MUAs. > > > This may be one of the rare cases where Microsoft MUAs are "more RFC > compliant" than most others; Outlook 2000 and newer do in fact show a > message with a Sender header as "From on behalf of header>". > Is that majority of the installed base? And even if it, if we are worried about broken Microsoft DNS servers which are a minority, then for sure we should worry about broken MUAs as well which are a minority. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 13:21:44 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 NAA12001 for ; Tue, 7 Sep 2004 13:21:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87GuuL4048269; Tue, 7 Sep 2004 09:56: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 i87GuuFH048268; Tue, 7 Sep 2004 09:56:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Guu2B048262 for ; Tue, 7 Sep 2004 09:56:56 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 7 Sep 2004 09:56:59 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Sep 2004 09:57:00 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 09:56:58 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 09:56:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [DOCBUG] -submitter, 5.3 Date: Tue, 7 Sep 2004 09:56:57 -0700 Message-ID: Thread-Topic: [DOCBUG] -submitter, 5.3 thread-index: AcSUSedN+orYSljMS+CJKW2lEERd9AAsbePw From: "Harry Katz" To: "Matthias Leisi" , "IETF MARID WG" X-OriginalArrivalTime: 07 Sep 2004 16:56:58.0595 (UTC) FILETIME=[B0223330:01C494FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i87Guu2B048263 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Good catch! Thanks. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Matthias Leisi > Sent: Monday, September 06, 2004 12:32 PM > To: IETF MARID WG > Subject: [DOCBUG] -submitter, 5.3 > > > [I'm not sure whether I have overlooked this already being posted] > > -submitter, Section 5.3 Mobile User: > > | Here is an example of the SMTP session between the MTAs at > | consolidatedmessanger.net and almamater.edu.example. > | > | S: 220 almamater.edu.example ESMTP server ready > | C: EHLO mobile.net.example > > "consolidatemessanger.net" should probably be "mobile.net.example". > > -- Matthias > > -- > Brain-Log http://matthias.leisi.net/ > > From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 13:21:49 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 NAA12027 for ; Tue, 7 Sep 2004 13:21:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Gps6Y047925; Tue, 7 Sep 2004 09:51:54 -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 i87GpskB047924; Tue, 7 Sep 2004 09:51:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87GprTh047918 for ; Tue, 7 Sep 2004 09:51:53 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38177) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C4jCD-0001mt-Fo (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 17:51:53 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4jCD-0006sm-Bg; Tue, 07 Sep 2004 17:51:53 +0100 Date: Tue, 7 Sep 2004 17:51:53 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Yakov Shafranovich cc: Jim Lyon , IETF MARID WG Subject: Re: TECH OMISSION: Stronger checks against email forgery In-Reply-To: <413DE41E.5060504@solidmatrix.com> Message-ID: References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> <413DE41E.5060504@solidmatrix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 7 Sep 2004, Yakov Shafranovich wrote: > > I think we are going in circles. You are missing my point, which is that Jim Lyon's justification is incorrect. The PRA is not significantly better correlated with the originating MTA than the bounce address. Tony. -- f.a.n.finch http://dotat.at/ LANDS END TO ST DAVIDS HEAD INCLUDING THE BRISTOL CHANNEL: NORTHEAST VEERING EAST 4 OR 5, OCCASIONALLY 6 IN SOUTH. FAIR. MODERATE OR GOOD. SLIGHT OR MODERATE. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 13:25:49 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 NAA12498 for ; Tue, 7 Sep 2004 13:25: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 i87Gv56Z048281; Tue, 7 Sep 2004 09:57: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 i87Gv547048280; Tue, 7 Sep 2004 09:57:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Gv4Qd048273 for ; Tue, 7 Sep 2004 09:57:04 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4jFl-0001AM-C9; Tue, 07 Sep 2004 12:55:33 -0400 Message-ID: <413DE859.4080301@solidmatrix.com> Date: Tue, 07 Sep 2004 12:56:57 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Tony Finch CC: IETF MARID WG Subject: Re: TECH OMISSION: Stronger checks against email forgery References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> <413DE41E.5060504@solidmatrix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony Finch wrote: > On Tue, 7 Sep 2004, Yakov Shafranovich wrote: > >>I think we are going in circles. > > > You are missing my point, which is that Jim Lyon's justification is > incorrect. The PRA is not significantly better correlated with the > originating MTA than the bounce address. > No I got you, I agree with you actually assuming that your comment about the forwarding behavior is correct. I was referring to the WG in general. I think the current identity has its issues, and all of the alternatives have issues as well. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 13: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 NAA13841 for ; Tue, 7 Sep 2004 13: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 i87HB7CS049531; Tue, 7 Sep 2004 10:11: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 i87HB7n2049530; Tue, 7 Sep 2004 10:11:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.oasis-open.org (host194.oasis-open.org [65.211.1.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with SMTP id i87HB5gx049519 for ; Tue, 7 Sep 2004 10:11:06 -0700 (PDT) (envelope-from robin@oasis-open.org) Received: (qmail 19563 invoked by uid 500); 7 Sep 2004 17:55:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Sep 2004 17:55:09 -0000 Date: Tue, 7 Sep 2004 13:55:09 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: ipr-wg@ietf.org cc: IETF MARID WG 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: A question about IETF process: On September 3, 2004 Andrew Newton wrote to the members of the IETF MARID WG via the 'ietf-mxcomp' list, on behalf of the WG co-chairs (Marshall T. Rose, Andrew Newton) "... We ask that all participants respond to these messages without regard to the IPR issue now before the working group..." [1] Question: Are IETF WG chairs empowered under IETF rules to require that a technical proposal/issue be [considered and] responded to "without regard" to IPR concerns that WG members might have, viz., with regard to a particular IPR declaration and/or with regard to IPR concerns in general? It is not clear whether the language "We ask" might be (A) a polite request or recommendation, or whether it could also be (B) an instruction based upon the authority of the chair to so restrict contributed responses on the WG list, backed by sanctions. [IEEE has the latter, as I understand its WG rules.] Thanks, Robin Cover [1] http://www.imc.org/ietf-mxcomp/mail-archive/msg04201.html From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 14:06:48 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 OAA16479 for ; Tue, 7 Sep 2004 14:06:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87HZV04051631; Tue, 7 Sep 2004 10:35:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87HZVeT051630; Tue, 7 Sep 2004 10:35:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87HZVTp051624 for ; Tue, 7 Sep 2004 10:35:31 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 7 Sep 2004 10:35:34 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Sep 2004 10:35:34 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 10:35:34 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 10:35:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DOC-BUG: Terminology: Purported Responsible Address Date: Tue, 7 Sep 2004 10:35:33 -0700 Message-ID: Thread-Topic: DOC-BUG: Terminology: Purported Responsible Address thread-index: AcSSxGQwtl0YuXDmTsCOWlG1aab4IgCPGddg From: "Harry Katz" To: "Roy Badami" , , X-OriginalArrivalTime: 07 Sep 2004 17:35:33.0849 (UTC) FILETIME=[1421EC90:01C49501] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i87HZVTp051625 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Saturday, September 04, 2004 2:07 PM, Roy Badami wrote: > >>>>> "mazieres" == writes: > > mazieres> I think the term Primary would be unfortunate, because > mazieres> in a lot of settings, the PRA doesn't really equate to > mazieres> people's intuitive notion of primary address. > > Agreed; it was just the best I could come up with that kept > the acronym PRA (not that that's essential) > > mazieres> How about "Preceding Responsible Address" or better > mazieres> "Previous Responsible Address." > > I like both of those. > > Ultimately it's just a name, and I don't _really_ care what > it is. I can happily live with 'purported responsible > address' as long as we accept that it is simply the name for > this identity, and not just a term we use to refer to an (as > yet unnamed) underlying concept when we're unsure of its accuracy. > > -roy In that case, I suggest we leave the name unchanged. I think the current name is reasonably accurate and I don't see much value in changing it. Thanks. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 14:06: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 OAA16498 for ; Tue, 7 Sep 2004 14:06: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 i87HX0gX051454; Tue, 7 Sep 2004 10:33:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87HX0jb051453; Tue, 7 Sep 2004 10:33:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87HX0Cv051447 for ; Tue, 7 Sep 2004 10:33:00 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 7 Sep 2004 10:33:03 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Sep 2004 10:33:03 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 10:33:03 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 10:33:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH-ERROR (-core): misuse of Resent- fields Date: Tue, 7 Sep 2004 10:33:02 -0700 Message-ID: Thread-Topic: TECH-ERROR (-core): misuse of Resent- fields thread-index: AcSUvwIVwZZ93u6fShuFYKT2HJvjAAAQT6Sw From: "Harry Katz" To: "Tony Finch" , X-OriginalArrivalTime: 07 Sep 2004 17:33:03.0000 (UTC) FILETIME=[BA383180:01C49500] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i87HX0Cv051448 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tuesday, September 07, 2004 2:31 AM, Tony Finch wrote: > Secttion 7.2 recommends a use of the Resent-From: header > field in direct contradiction to RFC 2822, which describes > how those fields are currently used. > > Tony. This was discussed way back in April. See my post of 4/20/2004 at http://www.imc.org/ietf-mxcomp/mail-archive/msg00950.html. I've extracted the relevent portion below: [snip] Unfortunately, the RFC is by no means clear on this point. In fact it's quite ambiguous. First the RFC states that Resent- headers SHOULD be added whenever a user "reintroduces" a message into the transport system, without clearly defining what "reintroduces" means or how it occurs. Now presumably under circumstances of some description, having seen a message delivered into my inbox I can press a hypothetical 'reintroduce' button (if not, then what are the headers for?). Having just received the message (so the original recipient has seen final delivery), the reintroduction must be headed for some other location; it must be a "forward" by *some* definition of the word. The RFC also talks about the "user" reintroducing the message without specifying which piece of software is acting on the user's behalf. The key point is this: if it's OK (indeed recommended) to add these headers when a human "reintroduces" a message into the transport stream, surely it's OK for an automated agent to do that on a user's behalf. It boils down to the fact that the language quoted is not consistent: it says use the headers, but not with "forwarding" (without defining the term) yet clearly their only utility is in conjunction with forwarding by any reasonable definition of the word. Lastly, the RFC states that Resent- headers are not "intended" for use in some types of forwarding, but *does not* prescribe that they MUST NOT be used in this way. Thus, we believe our proposed use of Resent- headers is indeed permissible. I would further suggest, given the threat posed to email by the spam crisis, that this would be an "opportune moment" to broaden the "intended" use of these fields. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 14:24: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 OAA17815 for ; Tue, 7 Sep 2004 14:24: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 i87HlIIF052856; Tue, 7 Sep 2004 10:47: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 i87HlIqp052855; Tue, 7 Sep 2004 10:47:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87HlHAc052847 for ; Tue, 7 Sep 2004 10:47:18 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45845) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1C4k3p-00051z-Rc (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 18:47:17 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4k3p-00075G-QO; Tue, 07 Sep 2004 18:47:17 +0100 Date: Tue, 7 Sep 2004 18:47:17 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Harry Katz cc: ietf-mxcomp@imc.org Subject: RE: TECH-ERROR (-core): misuse of Resent- fields In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 7 Sep 2004, Harry Katz wrote: > > Unfortunately, the RFC is by no means clear on this point. In fact it's > quite ambiguous. I disagree. > Now presumably under circumstances of some description, having seen a > message delivered into my inbox I can press a hypothetical 'reintroduce' > button (if not, then what are the headers for?). It's not hypothetical: Pine has such a function (which it confusingly calls "bounce"). We use it quite frequently to resend a message to the address it should have been sent to in the first place (e.g. from the webmaster team to the postmaster team). > It boils down to the fact that the language quoted is not consistent: it > says use the headers, but not with "forwarding" (without defining the > term) yet clearly their only utility is in conjunction with forwarding > by any reasonable definition of the word. It has a whole paragraph dedicated to defining the two usual meanings of forwarding, viz. encapsulation forwarding (using the MIME type message/rfc822 or non-MIME encapsulation in the body of the new message) and alias forwarding (as implemented by the Sieve redirect command and the Unix .forward and /etc/aliases files). "Reintroduction" is explicitly defined to be neither of these actions, whether or not you think it is a kind of forwarding. It is unfortunate that most of the terminology in this area is ambiguous, and this is not helped by willful misinterpretation of a document that is trying to be clear about which meaning is intended. Tony. -- f.a.n.finch http://dotat.at/ WHITBY TO THE WASH: NORTHEAST VEERING EAST 4 OR 5. FAIR. GOOD. SLIGHT OR MODERATE. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 14:59: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 OAA20537 for ; Tue, 7 Sep 2004 14:59: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 i87IUl4j057655; Tue, 7 Sep 2004 11:30:47 -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 i87IUlWV057653; Tue, 7 Sep 2004 11:30:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87IUkpk057643 for ; Tue, 7 Sep 2004 11:30:46 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 7 Sep 2004 11:30:50 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Sep 2004 11:30:49 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 11:30:49 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 11:30:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH-ERROR (-core): misuse of Resent- fields Date: Tue, 7 Sep 2004 11:30:49 -0700 Message-ID: Thread-Topic: TECH-ERROR (-core): misuse of Resent- fields thread-index: AcSVAsS2/fow+MVeRDCtV+37tYNDOQABUNCw From: "Harry Katz" To: "Tony Finch" , X-OriginalArrivalTime: 07 Sep 2004 18:30:49.0590 (UTC) FILETIME=[CC77D960:01C49508] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i87IUkpk057644 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tuesday, September 07, 2004 10:47 AM, Tony Finch [mailto:fanf2@hermes.cam.ac.uk] wrote: > It is unfortunate that most of the terminology in this area > is ambiguous, and this is not helped by willful > misinterpretation of a document that is trying to be clear > about which meaning is intended. I agree the terminology is ambiguous. I disagree that we're engaging in "willful misinterpretation". A somewhat broader interpretation perhaps, but one which both is reasonable and useful under the circumstances. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 15:30:55 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 PAA23787 for ; Tue, 7 Sep 2004 15:30: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 i87J1fBN060265; Tue, 7 Sep 2004 12:01: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 i87J1foW060264; Tue, 7 Sep 2004 12:01:41 -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 i87J1ex3060257 for ; Tue, 7 Sep 2004 12:01:40 -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 CE8CE414C7; Tue, 7 Sep 2004 12:01:36 -0700 (PDT) Subject: Re: TECH OMISSION: Stronger checks against email forgery From: Douglas Otis To: Yakov Shafranovich Cc: Tony Finch , Jim Lyon , IETF MARID WG In-Reply-To: <413DE41E.5060504@solidmatrix.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> <413DE41E.5060504@solidmatrix.com> Content-Type: text/plain Message-Id: <1094583693.20922.165.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 07 Sep 2004 12:01:33 -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 Tue, 2004-09-07 at 09:38, Yakov Shafranovich wrote: > Tony Finch wrote: > > On Tue, 7 Sep 2004, Yakov Shafranovich wrote: > >> Tony Finch wrote: > >>> On Fri, 27 Aug 2004, Jim Lyon wrote: > >>> > >>>> I continue to disagree. There are too many scenarios where the bounce > >>>> address is uncorrelated with the MTA that's delivering a message; this > >>>> means that any scheme that attempts to reject mail based on those two > >>>> inputs (bounce address and IP addr of sending MTA) will have too many > >>>> false rejections. > >>> > >>> What makes the PRA different from the bounce address from this point of > >>> view? > >> > >> The PRA algorithm tries to guess the most recent "Sender" for the message - > >> i.e. the one that is being used for this SMTP hop. The bounce address on the > >> other hand originates from the original hop and stays that way throughout > >> multiple SMTP hops. > > > > This is also true for the PRA, since no existing MTAs add Resent-From: > > header fields when alias-forwarding. > > I think we are going in circles. Validating the bounce address only > prevents false bounces but allows phishing, validating "Sender" does not > stop phishing but allows bounces plus does not take into account > forwarding, validating the "from" headers stops phishing but allows > bounces. Which one of these do we really want? Sender-ID is selecting a Mailbox Domain from a series of headers considered related to the most recent MTA outside of the recipients administrative region. Sender-ID header selection prioritizes RFC2822 >From as _last_ in the selection process. This selection process attempts to reduce rejection rates, but is no better at stopping phishing as a result. At least using MAIL FROM, there will be a better understanding which header is being inspected. Rather than devising a scheme that can safely treat a relationship of the MTA to Mailbox Domains for From and MAIL FROM as nominal lists, the attempt to use these lists to also authorize the MTA creates incompatibility and vulnerability to attack. Although these Mailbox Domain lists may color mail with respect to certainty, they will remain at a weak level of certainty, even after removing Mailbox Domain portability. Tony was right in that Sender-ID can not identify forged messages, nor can Sender-ID reliably identify valid messages. The MTA must be authenticated independent of these nominal Mailbox Domain lists in order to establish a reliable name for reputation assertions. Another major benefit in isolating MTA authentication from Mailbox Domain relationships, is that this greatly simplifies associating Mailbox Domains with MTA servers. With an MTA name, an MTA address list is not needed. With an MTA name, a secondary lookup for addresses is not needed to validate the Mailbox Domain. With an MTA name, these Mailbox Domain relationships can be expressed within a single DNS lookup without the use of a text script! By making MTA authentication independent of the Mailbox Domain relationships, those wishing to retain their freedom in the use of their return mailbox address will not impact MTA authentication and reputation checks. Those not declaring these nominative lists to be comprehensive, do not offer an avenue where "open-ended" records become exploited by spammers. A real danger with Sender-ID, in addition to making the MTA prone to attack, is created by false expectations the headers are reliably checked. This will only lead spammers to exploit the many Sender-ID weaknesses. What is needed is a lightweight method of authenticating the MTA, where other relationships are then established upon this relatively solid foundation. Sender-ID does not offer a suitable foundation, as it is premised upon the integrity of the RFC2822 information which can not be verified. If there is a problem, Sender-ID fails to isolate the source of the problem. If there is a problem, Sender-ID may mis-identify the sender and cause serious harm. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 15:30: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 PAA23807 for ; Tue, 7 Sep 2004 15:30: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 i87J4FCt060396; Tue, 7 Sep 2004 12:04:15 -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 i87J4FQt060395; Tue, 7 Sep 2004 12:04:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87J4Ewp060388 for ; Tue, 7 Sep 2004 12:04:14 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i87J3d1i029682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Sep 2004 12:03:40 -0700 (PDT) Received: from [129.46.75.181] (carbuncle.qualcomm.com [129.46.75.181]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i87J3aUV005740; Tue, 7 Sep 2004 12:03:37 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Tue, 7 Sep 2004 12:03:35 -0700 To: Robin Cover , ipr-wg@ietf.org From: Ted Hardie Subject: Re: Cc: IETF MARID WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To clarify further, the chairs have asked the working group to respond to a specific set of consensus calls on technical matters related to a specification in an extended working group last call. They have _not_ asked the working group not to consider IPR issues as a whole; there is a lively discussion of that within the working group. This is a tool to make it easier to pull the threads of conversation apart, and it is sorely needed in a working group as active as MARID. They have similarly asked folks to preface email messages in the working group last call with topic prefixes like: DEPLOY, TECH-OMISSION, and DOC-BUG. As the AD for this group, I was informed in advance of their intention to use these tools to focus discussion, and I agree that they are needed. I do not believe that they in any way have prevented folks from discussing the IPR issue; they are simply ways to keep conversational flow on technical topics going. regards, Ted Hardie co-Area Director, Applications At 1:55 PM -0400 9/7/04, Robin Cover wrote: >A question about IETF process: > >On September 3, 2004 Andrew Newton wrote to the members of the >IETF MARID WG via the 'ietf-mxcomp' list, on behalf of the >WG co-chairs (Marshall T. Rose, Andrew Newton) > > "... We ask that all participants respond to these > messages without regard to the IPR issue now before > the working group..." [1] > >Question: > >Are IETF WG chairs empowered under IETF rules to require that >a technical proposal/issue be [considered and] responded to "without >regard" to IPR concerns that WG members might have, viz., >with regard to a particular IPR declaration and/or with regard >to IPR concerns in general? > >It is not clear whether the language "We ask" might be (A) a >polite request or recommendation, or whether it could also >be (B) an instruction based upon the authority of the chair to >so restrict contributed responses on the WG list, backed by >sanctions. [IEEE has the latter, as I understand its WG rules.] > >Thanks, >Robin Cover > >[1] http://www.imc.org/ietf-mxcomp/mail-archive/msg04201.html From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 16:09:24 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 QAA27073 for ; Tue, 7 Sep 2004 16:09:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Jel4J062954; Tue, 7 Sep 2004 12:40:47 -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 i87JelUX062953; Tue, 7 Sep 2004 12:40:47 -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 i87JekmV062941 for ; Tue, 7 Sep 2004 12:40:46 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i87Jegp6010921; Tue, 7 Sep 2004 12:40:46 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Sep 2004 12:40:42 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'william(at)elan.net'" , Daniel Senie Cc: MARID Subject: RE: consensus call of RR prefix Date: Tue, 7 Sep 2004 12:40:42 -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: > BTW - I now support that both TXT and SPF RR records be done > in SRV way: > _smtp._tcp.example.com. IN TXT "SPF2.0/PRA ..." > _smtp._tcp.example.com. IN SPF "SPF2.0/PRA ..." I would support this as well. What we have here is a set of policy extensions that are bound to ONE protocol. Over time all protocols are going to require a similar mechanism to allow them to advertise their security policy. If we define the special case we will inevitably end up defining the general case in due course, sure as SRV followed MX. Phill From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 16:11: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 QAA27224 for ; Tue, 7 Sep 2004 16:11: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 i87Jj2Ph063174; Tue, 7 Sep 2004 12:45: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 i87Jj2Eu063173; Tue, 7 Sep 2004 12:45:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange2003.ad.skymv.com (mail.skymv.com [66.120.210.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Jj2N6063167 for ; Tue, 7 Sep 2004 12:45:02 -0700 (PDT) (envelope-from csg@habeas.com) Received: from [10.4.1.84] ([10.4.1.84]) by exchange2003.ad.skymv.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 12:43:17 -0700 Message-ID: <413E0FB7.6070402@habeas.com> Date: Tue, 07 Sep 2004 12:44:55 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Finch CC: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR (-core): misuse of Resent- fields References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Sep 2004 19:43:17.0125 (UTC) FILETIME=[EBCD0B50:01C49512] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony Finch wrote: >>Now presumably under circumstances of some description, having seen a >>message delivered into my inbox I can press a hypothetical 'reintroduce' >>button (if not, then what are the headers for?). >> >> >It's not hypothetical: Pine has such a function (which it confusingly >calls "bounce"). We use it quite frequently to resend a message to the >address it should have been sent to in the first place (e.g. from the >webmaster team to the postmaster team). > FWIW, Apple's OS X client has the same feature, called "Redirect." It sets Resent-Date, -From, -To, and -Message-ID correctly. I thought it was alreadly widely understood that Sender-ID violates the RFC2822 defined semantics for Resent-From ? From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 16:14:24 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 QAA27413 for ; Tue, 7 Sep 2004 16:14:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87JltWp063301; Tue, 7 Sep 2004 12:47:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87Jltg8063300; Tue, 7 Sep 2004 12:47:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Jlsbu063292 for ; Tue, 7 Sep 2004 12:47:55 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4lv0-0003nn-H3; Tue, 07 Sep 2004 15:46:19 -0400 Message-ID: <413E1044.5010202@solidmatrix.com> Date: Tue, 07 Sep 2004 15:47:16 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Harry Katz CC: Tony Finch , ietf-mxcomp@imc.org Subject: Re: TECH-ERROR (-core): misuse of Resent- fields References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Harry Katz wrote: > On Tuesday, September 07, 2004 10:47 AM, Tony Finch > [mailto:fanf2@hermes.cam.ac.uk] wrote: > > >>It is unfortunate that most of the terminology in this area >>is ambiguous, and this is not helped by willful >>misinterpretation of a document that is trying to be clear >>about which meaning is intended. > > > I agree the terminology is ambiguous. I disagree that we're engaging in > "willful misinterpretation". A somewhat broader interpretation perhaps, > but one which both is reasonable and useful under the circumstances. > Harry, I would suggest that marid-core adds a note pointing to the approriate section in RFC 2822 stating that the draft is modifying the behavior suggested in the RFC and that RFC 2822 is being ambigious. BTW, Pete Resnick is lurking here so we can ask him straight out. In particular the following message suggests that Harry may be right (http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/0952.html): "It says that the Resent- headers are for MUA resending, not for MUA encapsulated-message forwarding and not for /etc/aliases or .forward forwarding. Read the paragraph starting "Note:" in section 3.6.6 of RFC 2822. In one of the IETF jabber sessions, I raised this very point. See the the 15:58:43 entry of: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-04-19.html (I've included a copy of this part of the log at the end of this post) After the jabber session I asked Pete Resnick, the editor of RFC2822 to clarify the issue. He said that when RFC2822 was written, the language about forwarders was intended to be about .forward files. Further, he said, now that the spam discussion has been raised, some consider forwarding services, such as pobox.com, to be gateways rather than forwarders. That is, the email is coming out of the transport system and being re-introduced, just like a mailing list. " See that entire message. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 16:15: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 QAA27594 for ; Tue, 7 Sep 2004 16:15: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 i87Jmo08063344; Tue, 7 Sep 2004 12:48:50 -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 i87JmoLG063343; Tue, 7 Sep 2004 12:48:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87JmnJI063335 for ; Tue, 7 Sep 2004 12:48:49 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4lvu-0003qs-4y; Tue, 07 Sep 2004 15:47:16 -0400 Message-ID: <413E1082.9070909@solidmatrix.com> Date: Tue, 07 Sep 2004 15:48:18 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Douglas Otis CC: Tony Finch , Jim Lyon , IETF MARID WG Subject: Re: TECH OMISSION: Stronger checks against email forgery References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> <413DE41E.5060504@solidmatrix.com> <1094583693.20922.165.camel@ddev.mail-abuse.org> In-Reply-To: <1094583693.20922.165.camel@ddev.mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > On Tue, 2004-09-07 at 09:38, Yakov Shafranovich wrote: > >>Tony Finch wrote: >> >>>On Tue, 7 Sep 2004, Yakov Shafranovich wrote: >>> >>>>Tony Finch wrote: >>>> >>>>>On Fri, 27 Aug 2004, Jim Lyon wrote: >>>>> >>>>> >>>>>>I continue to disagree. There are too many scenarios where the bounce >>>>>>address is uncorrelated with the MTA that's delivering a message; this >>>>>>means that any scheme that attempts to reject mail based on those two >>>>>>inputs (bounce address and IP addr of sending MTA) will have too many >>>>>>false rejections. >>>>> >>>>>What makes the PRA different from the bounce address from this point of >>>>>view? >>>> >>>>The PRA algorithm tries to guess the most recent "Sender" for the message - >>>>i.e. the one that is being used for this SMTP hop. The bounce address on the >>>>other hand originates from the original hop and stays that way throughout >>>>multiple SMTP hops. >>> >>>This is also true for the PRA, since no existing MTAs add Resent-From: >>>header fields when alias-forwarding. >> >>I think we are going in circles. Validating the bounce address only >>prevents false bounces but allows phishing, validating "Sender" does not >>stop phishing but allows bounces plus does not take into account >>forwarding, validating the "from" headers stops phishing but allows >>bounces. Which one of these do we really want? > > > Sender-ID is selecting a Mailbox Domain from a series of headers > considered related to the most recent MTA outside of the recipients > administrative region. Sender-ID header selection prioritizes RFC2822 >>From as _last_ in the selection process. This selection process > attempts to reduce rejection rates, but is no better at stopping > phishing as a result. At least using MAIL FROM, there will be a better > understanding which header is being inspected. > Aren't we basically trying to deduce the "mailbox of the agent responsible for the actual transmission of the message". Basically you want to know who was the original agent or "Sender" was that put that email into the email system. To me it sounds like the original "purpotable responsible address" is the same as guessing "the agent responsible for the actual transmission of the message"? If so, RFC 2822, section 3.6.2, is very clear that the "Sender" field indicates that. That's step 3 in PRA. However, the same RFC states in section 3.6.2 "If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used". That's step 4 of PRA. The PRA draft states explicetely that those 2 steps are taken directly from RFC 2822 (don't see any IPR). Now for the resent blocks, the same RFC in section 3.6.6 states that the "Resent-XXX" fields are simply placeholders for previous versions of the same "Sender" and "From" fields. Therefore, there is a preference for "Resent-Sender" just like there is a preference for "Sender" described above. That's why steps 1-2 come before 3-4, and step 1 comes before step 2 (still no IPR). Now the interesting part here is deciding how to pick the proper "Resent" header. The PRA algorithm picks the first "Resent-Sender" unless there is a "Resent-From" before with "Return-Path" or "Received" in between. The RFC states that: A. "Resent fields SHOULD be added to any message that is reintroduced by a user into the transport system." B. "A separate set of resent fields SHOULD be added each time this is done." C. "All of the resent fields corresponding to a particular resending of the message SHOULD be together." D. "Each new set of resent fields is prepended to the message; that is, the most recent set of resent fields appear earlier in the message." Picking the earliest Resent block is based on #D and B, picking an earlier "Resent-From" if separated from the other Resent headers is based on #C (and I still see no IPR). Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 17:33:57 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 RAA09157 for ; Tue, 7 Sep 2004 17:33: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 i87L69ID068338; Tue, 7 Sep 2004 14:06: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 i87L69Pu068337; Tue, 7 Sep 2004 14:06:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87L67Gx068325 for ; Tue, 7 Sep 2004 14:06:08 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i87L5ihD001715 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Sep 2004 17:05:44 -0400 Date: Tue, 7 Sep 2004 17:05:44 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Tony Finch cc: "Michael R. Brumm" , IETF MARID WG Subject: RE: TECH OMISSION: Stronger checks against email forgery 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 Tue, 7 Sep 2004, Tony Finch wrote: > > On Fri, 27 Aug 2004, Michael R. Brumm wrote: > > > > The (2821 MAIL FROM) bounce address is irrelevant? This seems absurd > > considering how many bounces (containing spam and viruses) I get for > > messages I never sent. > > If you want to solve that problem set up something like BATV. > Sender-ID and SPF do not solve the backscatter problem; at best > they might ameliorate it. Actually, they make it __much__ worse. Instead of getting bounces to email addresses that actually don't exist, you will get 100% of the email bounced from the relay (open or closed makes no difference) from which the mail was rejected. There are several invariants: Every user/abuser has an ISP that provides them with relay services. Every user/abuser has access to those relay services right up until their account is shut off, due to complaints. Abusers send directly because its easier than finding a relay or carrying a list of relays in the payload. SPF identifies the internal relays quite nicely. Relay services benefit regular users. Now abusers can enjoy the same benefits. The joe-job'd target gets more bounced mail. Abusers (well, anti-spammers actually) used to send mail through open relays to sites that blocked that open relay. Few sites blocked open relays, but the relay abusers often knew exactly which sites used open relay blacklists. The result would bounce the messages back to the joe-job, seemingly from the open relay directly. Of course, closed relays could be abused the same way, but rarely were. Funny how "ethical" these abusers were. But the target was still inundated with email, and sometimes had to abandon their addresses. Open relay operaters managed to get that kind of abuse under control by blocking the open relay blacklists from scanning, and thus depriving them lists of relays to abuse. Eventually the relay blacklists closed down last year. though they never really blocked much email. Open relay abuse has dropped off significantly in the last year. Now, with SPF, they will bring back those bad old days. --Dean From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 17:36:24 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 RAA09214 for ; Tue, 7 Sep 2004 17:36: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 i87L844P068504; Tue, 7 Sep 2004 14:08: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 i87L84MQ068503; Tue, 7 Sep 2004 14:08:04 -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 i87L8483068496 for ; Tue, 7 Sep 2004 14:08:04 -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 90C33414C8; Tue, 7 Sep 2004 14:08:07 -0700 (PDT) Subject: Re: TECH OMISSION: Stronger checks against email forgery From: Douglas Otis To: Yakov Shafranovich Cc: Tony Finch , Jim Lyon , IETF MARID WG In-Reply-To: <413E1082.9070909@solidmatrix.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> <413DE41E.5060504@solidmatrix.com> <1094583693.20922.165.camel@ddev.mail-abuse.org> <413E1082.9070909@solidmatrix.com> Content-Type: text/plain Message-Id: <1094591285.20922.216.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 07 Sep 2004 14:08:05 -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 Tue, 2004-09-07 at 12:48, Yakov Shafranovich wrote: > Douglas Otis wrote: > > On Tue, 2004-09-07 at 09:38, Yakov Shafranovich wrote: > >> Tony Finch wrote: > >>> On Tue, 7 Sep 2004, Yakov Shafranovich wrote: > >>>> Tony Finch wrote: > >>>>> On Fri, 27 Aug 2004, Jim Lyon wrote: > >>>>> > >>>>>> I continue to disagree. There are too many scenarios where the bounce > >>>>>> address is uncorrelated with the MTA that's delivering a message; this > >>>>>> means that any scheme that attempts to reject mail based on those two > >>>>>> inputs (bounce address and IP addr of sending MTA) will have too many > >>>>>> false rejections. > >>>>> > >>>>> What makes the PRA different from the bounce address from this point of > >>>>> view? > >>>> > >>>> The PRA algorithm tries to guess the most recent "Sender" for the message - > >>>> i.e. the one that is being used for this SMTP hop. The bounce address on the > >>>> other hand originates from the original hop and stays that way throughout > >>>> multiple SMTP hops. > >>> > >>> This is also true for the PRA, since no existing MTAs add Resent-From: > >>> header fields when alias-forwarding. > >> > >> I think we are going in circles. Validating the bounce address only > >> prevents false bounces but allows phishing, validating "Sender" does not > >> stop phishing but allows bounces plus does not take into account > >> forwarding, validating the "from" headers stops phishing but allows > >> bounces. Which one of these do we really want? > > > > Sender-ID is selecting a Mailbox Domain from a series of headers > > considered related to the most recent MTA outside of the recipients > > administrative region. Sender-ID header selection prioritizes RFC2822 > > From as _last_ in the selection process. This selection process > > attempts to reduce rejection rates, but is no better at stopping > > phishing as a result. At least using MAIL FROM, there will be a better > > understanding which header is being inspected. > > Aren't we basically trying to deduce the "mailbox of the agent > responsible for the actual transmission of the message". Basically you > want to know who was the original agent or "Sender" was that put that > email into the email system. To me it sounds like the original > "purportable responsible address" is the same as guessing "the agent > responsible for the actual transmission of the message"? The recipient will be looking at the RFC 2822 From, where there is a new expectation they will be seeing some other header being checked. It remains, Sender-ID is not an effective tool against phishing. Sender-ID is also not an effective tool for stopping other types of abuse. To abate abuse, a reliable reputation mechanism must be possible. There is no reliable name obtained with Sender-ID. > If so, RFC 2822, section 3.6.2, is very clear that the "Sender" field > indicates that. That's step 3 in PRA. However, the same RFC states in > section 3.6.2 "If the originator of the message can be indicated by a > single mailbox and the author and transmitter are identical, the > "Sender:" field SHOULD NOT be used". That's step 4 of PRA. The PRA draft > states explicitly that those 2 steps are taken directly from RFC 2822 > (don't see any IPR). The EHLO domain tracks the "sender" without the need to sort headers. Make this field a visible part of the sender identification. It does not require any IPR either and authentication could always result in a high degree of certainty. > Now for the resent blocks, the same RFC in section 3.6.6 states that the > "Resent-XXX" fields are simply placeholders for previous versions of the > same "Sender" and "From" fields. Therefore, there is a preference for > "Resent-Sender" just like there is a preference for "Sender" described > above. That's why steps 1-2 come before 3-4, and step 1 comes before > step 2 (still no IPR). What is the substantial difference between these headers and the name contained within the EHLO domain? There a tremendous advantage using the MTA name to establish MTA to Mailbox Domain relationships for either MAIL FROM or From. Why care about these other headers? > Now the interesting part here is deciding how to pick the proper > "Resent" header. The PRA algorithm picks the first "Resent-Sender" > unless there is a "Resent-From" before with "Return-Path" or "Received" > in between. The RFC states that: > A. "Resent fields SHOULD be added to any message that is reintroduced by > a user into the transport system." > B. "A separate set of resent fields SHOULD be added each time this is done." > C. "All of the resent fields corresponding to a particular resending of > the message SHOULD be together." > D. "Each new set of resent fields is prepended to the message; that is, > the most recent set of resent fields appear earlier in the message." > > Picking the earliest Resent block is based on #D and B, picking an > earlier "Resent-From" if separated from the other Resent headers is > based on #C (and I still see no IPR). Making a Mailbox Domain list that nominally relates to the MTA name will encompass a vast majority of the mail without touching upon issues of whether the Sender-ID IPR is obvious. By making the MTA authentication a separate function, then simply marking mail as being outside this MTA name/Mailbox Domain relationship is little different than selecting an invisible header compared against an address list unrelated to the From or MAIL FROM. Just use the EHLO domain. By always exposing the EHLO domain as visible, the recipient will soon recognize these From/EHLO names used in tandem. It is too dangerous to block mail based upon Sender-ID. A reputation check based upon the MTA name would allow a safe method of blocking mail however. If the goal is to assist the recipient decide what is valid mail and what is not, the visible MTA name compared against a nominal or restrictive list of MAIL FROM or From Mailbox Domains provides a superior outcome. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 17:47: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 RAA10134 for ; Tue, 7 Sep 2004 17:47: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 i87LKq3c070434; Tue, 7 Sep 2004 14:20: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 i87LKq6n070433; Tue, 7 Sep 2004 14:20:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87LKpHR070426 for ; Tue, 7 Sep 2004 14:20:51 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [10.0.0.120] ([10.0.0.120]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 14:20:54 -0700 Subject: RE: consensus call of RR prefix From: Max Kanat-Alexander To: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094592054.29323.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Sep 2004 14:20:54 -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-09-05 at 10:16, Scott Kitterman wrote: > For me, the issue isn't BIND, but the web front end that my DNS provider > uses to enable me to enter data. For the record, www.pairnic.com currently > does the following: Frankly, with the momentum and requests I've been seeing from my customers, I suspect that most large DNS providers will work on supporting anything that Sender ID requires, provided that the IPR issues are resolved and it can be included in SpamAssassin. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 17:49: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 RAA10478 for ; Tue, 7 Sep 2004 17:49: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 i87LKQR3070402; Tue, 7 Sep 2004 14:20:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87LKQ0x070401; Tue, 7 Sep 2004 14:20:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87LKQFS070394 for ; Tue, 7 Sep 2004 14:20:26 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [10.0.0.120] ([10.0.0.120]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 14:20:29 -0700 Subject: RE: consensus call of RR prefix From: Max Kanat-Alexander To: ietf-mxcomp@imc.org In-Reply-To: <00c801c49341$c85e5840$2766f30a@development.greatgulfhomes.com> References: <00c801c49341$c85e5840$2766f30a@development.greatgulfhomes.com> Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094592029.29323.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Sep 2004 14:20:29 -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-09-05 at 05:13, terry@ashtonwoodshomes.com wrote: > -implementing a prefix adds complexity (comprehension complexity if > nothing else) For me as a system administrator, I would say that it simplifies keeping track of my DNS records. > -many dns providers do not support users adding subdomains (or not > through the UI anyway) Those same DNS providers probably don't support TXT records (and certainly won't support SPF records). > -prefix does not solve the wildcard issue Though wildcards are rarely used. > -one can use redirect in a small record to a subdomain (simulating > prefix) if one really wants prefix That's true. Do most DNS servers support this easily, and are the admins who would need it aware? Probably, but I don't actually know. > Anything that hinders deployment needs to be considered for benefit > and lack of alternatives. In my experience (we were the first company with a commercial MTA to implement Caller ID), no customer who talked to me has ever had a problem with the prefix. The TXT record was a more common problem. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 17:53:57 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 RAA10992 for ; Tue, 7 Sep 2004 17:53: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 i87LUZJi071058; Tue, 7 Sep 2004 14:30: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 i87LUZn2071057; Tue, 7 Sep 2004 14:30:35 -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 i87LUYYX071048 for ; Tue, 7 Sep 2004 14:30:34 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 5BEFF40C4 for ; Tue, 7 Sep 2004 14:30:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <413E0FB7.6070402@habeas.com> References: <413E0FB7.6070402@habeas.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <24E9AA78-0115-11D9-BB96-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: TECH-ERROR (-core): misuse of Resent- fields Date: Tue, 7 Sep 2004 14:30:30 -0700 To: IETF MARID WG 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 Sep 7, 2004, at 12:44 PM, Carl S. Gutekunst wrote: > FWIW, Apple's OS X client has the same feature, called "Redirect." It > sets Resent-Date, -From, -To, and -Message-ID correctly. FWIW^2, Apple's OS X client also displays these fields for received messages that have them! The From: field is shown in the message list in the From column. But, when you open the message to read it, the headers at the top have Resent-From and Resent-To right above the corresponding From and To lines. Neat! - Mark From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 18:12: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 SAA12807 for ; Tue, 7 Sep 2004 18:12: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 i87LkCSi071947; Tue, 7 Sep 2004 14:46: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 i87LkCWW071946; Tue, 7 Sep 2004 14:46:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vodka.at-once.com (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87LkBL8071934 for ; Tue, 7 Sep 2004 14:46:12 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vodka.at-once.com (8.12.11/8.12.11) with ESMTP id i87Lk7RP017627; Tue, 7 Sep 2004 14:46:08 -0700 Subject: Re: consensus call on MUST/SHOULD language for TXT records From: Ryan Ordway To: Andrew Newton Cc: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1094593567.16943.6.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Sep 2004 14:46:07 -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-09-03 at 14:33, Andrew Newton wrote: > Despite lack of agreement on the outcome, there is agreement on the > stated positions. In the words of Olafur: > 1) Specify everyone to be compliant at all times. > 2) Specify clearly full complaint state and tolerate non-compliant > state during phase-in. My vote is for 1. I believe allowing non-compliance is an invitation for non-compliance. -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 18:12:59 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 SAA12834 for ; Tue, 7 Sep 2004 18:12: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 i87LjNbM071891; Tue, 7 Sep 2004 14:45:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87LjNjr071890; Tue, 7 Sep 2004 14:45:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87LjMrp071883 for ; Tue, 7 Sep 2004 14:45:22 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4nkg-0002JN-E5; Tue, 07 Sep 2004 17:43:47 -0400 Message-ID: <413E2BDF.5040700@solidmatrix.com> Date: Tue, 07 Sep 2004 17:45:03 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Douglas Otis CC: Tony Finch , Jim Lyon , IETF MARID WG Subject: Re: TECH OMISSION: Stronger checks against email forgery References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> <413DE41E.5060504@solidmatrix.com> <1094583693.20922.165.camel@ddev.mail-abuse.org> <413E1082.9070909@solidmatrix.com> <1094591285.20922.216.camel@ddev.mail-abuse.org> In-Reply-To: <1094591285.20922.216.camel@ddev.mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: >>Aren't we basically trying to deduce the "mailbox of the agent >>responsible for the actual transmission of the message". Basically you >>want to know who was the original agent or "Sender" was that put that >>email into the email system. To me it sounds like the original >>"purportable responsible address" is the same as guessing "the agent >>responsible for the actual transmission of the message"? > > > The recipient will be looking at the RFC 2822 From, where there is a new > expectation they will be seeing some other header being checked. It > remains, Sender-ID is not an effective tool against phishing. Sender-ID > is also not an effective tool for stopping other types of abuse. To > abate abuse, a reliable reputation mechanism must be possible. There is > no reliable name obtained with Sender-ID. > I think the intent was to introduce the entity of "original sender" of the message although I would have to agree with you that by itself it might not be too useful. Of course, considering that if Outlook 2000 and some other MUAs actually displays that header, it will have some use for those MUAs. But, what about SUBMITTER or RFC2821 MAIL FROM bounce address? Purely from the technical viewpoint, are they reliable? All could be forged including EHLO. > >>If so, RFC 2822, section 3.6.2, is very clear that the "Sender" field >>indicates that. That's step 3 in PRA. However, the same RFC states in >>section 3.6.2 "If the originator of the message can be indicated by a >>single mailbox and the author and transmitter are identical, the >>"Sender:" field SHOULD NOT be used". That's step 4 of PRA. The PRA draft >>states explicitly that those 2 steps are taken directly from RFC 2822 >>(don't see any IPR). > > > The EHLO domain tracks the "sender" without the need to sort headers. > Make this field a visible part of the sender identification. It does > not require any IPR either and authentication could always result in a > high degree of certainty. > The key difference between EHLO and "Sender" is that EHLO is MTA-specific while "Sender" is specific to the message itself. A single EHLO value may cover messages originating from multiple domains. Therefore using the "Sender" field or "SUBMITTER" allows for granularity where a specific MTA may be authorized to relay email for one domain and not another, like an ISP's outgoing MTA. Of course, like someone has mentioned before, there are less MTAs then domains, and it might be useful to work with the MTAs alone. I agree that the reliability is much less for PRA then EHLO, but on the other hand SUBMITTER should be no worse than EHLO. So EHLO would not be an option, if the granularity described above is desired. And I still argue that the entire PRA algorithm is obvious to anyone reading the RFC so the IPR issue is probably moot. > >>Now for the resent blocks, the same RFC in section 3.6.6 states that the >>"Resent-XXX" fields are simply placeholders for previous versions of the >>same "Sender" and "From" fields. Therefore, there is a preference for >>"Resent-Sender" just like there is a preference for "Sender" described >>above. That's why steps 1-2 come before 3-4, and step 1 comes before >>step 2 (still no IPR). > > > What is the substantial difference between these headers and the name > contained within the EHLO domain? There a tremendous advantage using > the MTA name to establish MTA to Mailbox Domain relationships for either > MAIL FROM or From. Why care about these other headers? > See above. > >>Now the interesting part here is deciding how to pick the proper >>"Resent" header. The PRA algorithm picks the first "Resent-Sender" >>unless there is a "Resent-From" before with "Return-Path" or "Received" >>in between. The RFC states that: >>A. "Resent fields SHOULD be added to any message that is reintroduced by >> a user into the transport system." >>B. "A separate set of resent fields SHOULD be added each time this is done." >>C. "All of the resent fields corresponding to a particular resending of >>the message SHOULD be together." >>D. "Each new set of resent fields is prepended to the message; that is, >>the most recent set of resent fields appear earlier in the message." >> >>Picking the earliest Resent block is based on #D and B, picking an >>earlier "Resent-From" if separated from the other Resent headers is >>based on #C (and I still see no IPR). > > > Making a Mailbox Domain list that nominally relates to the MTA name will > encompass a vast majority of the mail without touching upon issues of > whether the Sender-ID IPR is obvious. By making the MTA authentication > a separate function, then simply marking mail as being outside this MTA > name/Mailbox Domain relationship is little different than selecting an > invisible header compared against an address list unrelated to the From > or MAIL FROM. Just use the EHLO domain. By always exposing the EHLO > domain as visible, the recipient will soon recognize these From/EHLO > names used in tandem. It is too dangerous to block mail based upon > Sender-ID. A reputation check based upon the MTA name would allow a > safe method of blocking mail however. > > If the goal is to assist the recipient decide what is valid mail and > what is not, the visible MTA name compared against a nominal or > restrictive list of MAIL FROM or From Mailbox Domains provides a > superior outcome. > I am not sure which would be superior. EHLO is not being used today anywhere, and similarly for phishing the 2821 MAIL FROM bounce address is not displayed to the end user. From the viewpoint of phishing, it makes perfect sense to work with the message itself, not the channel. I don't see how the invisible EHLO is any better than the invisible "Sender". If anything, SUBMITTER or 2821 MAIL FROM, or 2822 "from" would be superior. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 18:22:57 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 SAA13831 for ; Tue, 7 Sep 2004 18:22: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 i87LuNJB072496; Tue, 7 Sep 2004 14:56:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87LuNVB072495; Tue, 7 Sep 2004 14:56:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vodka.at-once.com (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87LuNNa072482 for ; Tue, 7 Sep 2004 14:56:23 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vodka.at-once.com (8.12.11/8.12.11) with ESMTP id i87LuMw0017641; Tue, 7 Sep 2004 14:56:22 -0700 Subject: Re: consensus call of RR prefix From: Ryan Ordway To: Andrew Newton Cc: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1094594181.16943.11.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Sep 2004 14:56:21 -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-09-03 at 14:32, Andrew Newton wrote: > Therefore, that leaves one under-discussed question: should a prefix be > used to avoid collision with other records as one measure of preventing > the requirement of DNS over TCP? No. 1) Inconsistent with SPF RR that doesn't use a prefix 2) Causes deployment headaches for those who use DNS providers whose web-based tools cannot handle sub-domains or underscore characters. -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 18:50: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 SAA15558 for ; Tue, 7 Sep 2004 18:50:32 -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 i87MP1g9075064; Tue, 7 Sep 2004 15:25: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 i87MP1Ch075063; Tue, 7 Sep 2004 15:25:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87MP0Cl075054 for ; Tue, 7 Sep 2004 15:25:00 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4oNA-0004wC-NZ; Tue, 07 Sep 2004 18:23:32 -0400 Message-ID: <413E3531.7010906@solidmatrix.com> Date: Tue, 07 Sep 2004 18:24:49 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Roy Badami CC: Dave Crocker , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> In-Reply-To: <16702.13483.861326.183032@giles.gnomon.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy Badami wrote: >>>>>>"Yakov" == Yakov Shafranovich writes: > > > Yakov> Now if all of this is stated in the RFC directly, what > Yakov> exactly is the IPR that is being claimed here? This seems > Yakov> to me explicit in the RFC itself. > > I believe that the PRA algorithm, at least in outline, is obvious to a > practitioner skilled in the art. > > I'm sure it's pretty much what everyone does mentally when they read > the headers of a message (yeah, ok, I'm a geek, I assume that everyone > understands the semantics of the headers :-) > Then according to RFC 3668 we can safely ignore the IPR claims is irrelevant and frivilous like it has been done before with IDN and IPSec. Or can we? Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 18:50: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 SAA15566 for ; Tue, 7 Sep 2004 18:50:32 -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 i87MMja2074909; Tue, 7 Sep 2004 15:22:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87MMjSA074908; Tue, 7 Sep 2004 15:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87MMiRR074892 for ; Tue, 7 Sep 2004 15:22:44 -0700 (PDT) (envelope-from roy+dated+1097187759.abfdb1@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87MOUbj037915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Sep 2004 22:24:36 GMT (envelope-from roy+dated+1097187759.abfdb1@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87MMesN080126 for ; Tue, 7 Sep 2004 23:22:40 +0100 (BST) (envelope-from roy+dated+1097187759.abfdb1@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i87MMeQa080125 for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 23:22:40 +0100 (BST) (envelope-from roy+dated+1097187759.abfdb1@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 07 Sep 2004 23:22:36 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16702.13483.861326.183032@giles.gnomon.org.uk> Date: Tue, 7 Sep 2004 23:22:35 +0100 To: Yakov Shafranovich Cc: Roy Badami , Dave Crocker , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify In-Reply-To: <413D0FB7.9080903@solidmatrix.com> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Yakov" == Yakov Shafranovich writes: Yakov> Now if all of this is stated in the RFC directly, what Yakov> exactly is the IPR that is being claimed here? This seems Yakov> to me explicit in the RFC itself. I believe that the PRA algorithm, at least in outline, is obvious to a practitioner skilled in the art. I'm sure it's pretty much what everyone does mentally when they read the headers of a message (yeah, ok, I'm a geek, I assume that everyone understands the semantics of the headers :-) -roy From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 18:57: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 SAA16009 for ; Tue, 7 Sep 2004 18:57: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 i87MUwGm075384; Tue, 7 Sep 2004 15:30:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87MUwUq075383; Tue, 7 Sep 2004 15:30:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87MUvQv075375 for ; Tue, 7 Sep 2004 15:30:57 -0700 (PDT) (envelope-from roy+dated+1097188255.c7ff0d@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87MWjIO038803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Sep 2004 22:32:51 GMT (envelope-from roy+dated+1097188255.c7ff0d@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87MUtru080220 for ; Tue, 7 Sep 2004 23:30:55 +0100 (BST) (envelope-from roy+dated+1097188255.c7ff0d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i87MUt8K080219 for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 23:30:55 +0100 (BST) (envelope-from roy+dated+1097188255.c7ff0d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 07 Sep 2004 23:30:54 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16702.13981.721611.38408@giles.gnomon.org.uk> Date: Tue, 7 Sep 2004 23:30:53 +0100 To: Yakov Shafranovich Cc: Harry Katz , Tony Finch , ietf-mxcomp@imc.org Subject: Re: TECH-ERROR (-core): misuse of Resent- fields In-Reply-To: <413E1044.5010202@solidmatrix.com> References: <413E1044.5010202@solidmatrix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Yakov" == Yakov Shafranovich writes: Yakov> I would suggest that marid-core adds a note pointing to the Yakov> approriate section in RFC 2822 stating that the draft is Yakov> modifying the behavior suggested in the RFC and that RFC Yakov> 2822 is being ambigious. I would go further. I concurr with Tony Finch that Sender ID modifies the intent of these headers. I don't think that is a bad thing; I just think we should be explicit about it. -roy From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 18:58: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 SAA16065 for ; Tue, 7 Sep 2004 18:58: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 i87MSAIS075203; Tue, 7 Sep 2004 15:28:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87MSAs6075202; Tue, 7 Sep 2004 15:28:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87MS90T075196 for ; Tue, 7 Sep 2004 15:28:10 -0700 (PDT) (envelope-from roy+dated+1097188088.f81b13@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87MTw5c038322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Sep 2004 22:30:04 GMT (envelope-from roy+dated+1097188088.f81b13@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87MS8ej080179 for ; Tue, 7 Sep 2004 23:28:08 +0100 (BST) (envelope-from roy+dated+1097188088.f81b13@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i87MS8lw080178 for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 23:28:08 +0100 (BST) (envelope-from roy+dated+1097188088.f81b13@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 07 Sep 2004 23:28:07 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16702.13815.34842.345047@giles.gnomon.org.uk> Date: Tue, 7 Sep 2004 23:28:07 +0100 To: Tony Finch Cc: ietf-mxcomp@imc.org Subject: TECH-ERROR (-core): misuse of Resent- fields In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tony" == Tony Finch writes: Tony> Secttion 7.2 recommends a use of the Resent-From: header Tony> field in direct contradiction to RFC 2822, which describes Tony> how those fields are currently used. Arguably that's a DOC-BUG. Arguably the best way to rsolve this is for Sender ID to explicitly update RFC2822 in this respect. -roy From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 19:08: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 TAA16488 for ; Tue, 7 Sep 2004 19:08:32 -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 i87MiKpc076909; Tue, 7 Sep 2004 15:44:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87MiKE3076908; Tue, 7 Sep 2004 15:44:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vodka.at-once.com (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87MiK0c076901 for ; Tue, 7 Sep 2004 15:44:20 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vodka.at-once.com (8.12.11/8.12.11) with ESMTP id i87MiJrJ017732; Tue, 7 Sep 2004 15:44:19 -0700 Subject: Re: consensus call of RR prefix From: Ryan Ordway To: Andrew Newton Cc: IETF MARID WG In-Reply-To: <1094594181.16943.11.camel@vodka> References: <1094594181.16943.11.camel@vodka> Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1094597059.16943.13.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Sep 2004 15:44:19 -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 Tue, 2004-09-07 at 14:56, Ryan Ordway wrote: > On Fri, 2004-09-03 at 14:32, Andrew Newton wrote: > > > Therefore, that leaves one under-discussed question: should a prefix be > > used to avoid collision with other records as one measure of preventing > > the requirement of DNS over TCP? > > No. > > 1) Inconsistent with SPF RR that doesn't use a prefix > 2) Causes deployment headaches for those who use > DNS providers whose web-based tools cannot handle > sub-domains or underscore characters. Granted, said providers probably can't handle SPF RRs or TXT records either. -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 19:10: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 TAA16644 for ; Tue, 7 Sep 2004 19:10: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 i87Mfwlc076762; Tue, 7 Sep 2004 15:41: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 i87Mfw5N076761; Tue, 7 Sep 2004 15:41:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87MfvTg076755 for ; Tue, 7 Sep 2004 15:41:57 -0700 (PDT) (envelope-from roy+dated+1097188915.697c26@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87MhkiF039805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Sep 2004 22:43:51 GMT (envelope-from roy+dated+1097188915.697c26@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87MftIv080368 for ; Tue, 7 Sep 2004 23:41:55 +0100 (BST) (envelope-from roy+dated+1097188915.697c26@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i87MftmP080367 for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 23:41:55 +0100 (BST) (envelope-from roy+dated+1097188915.697c26@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 07 Sep 2004 23:41:55 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16702.14642.564899.579365@giles.gnomon.org.uk> Date: Tue, 7 Sep 2004 23:41:54 +0100 To: Tony Finch Cc: ietf-mxcomp@imc.org Subject: TECH-OMISSION (-core): alias-forwarding and multiple recipients In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tony" == Tony Finch writes: Tony> It is not clear how alias-forwarders are supposed to handle Tony> messages with multiple recipients. When handling such a Tony> message, Exim and some other MTAs will determine the final Tony> alias destination(s) of all addresses in the recipient list Tony> before delivery starts, so that only one copy of the message Tony> needs to be sent to each destination host. It seems to me that the best solution would be for the forwarder to send a separate copy of the message for each recipient, so it can in each case use the original destination address in the Resent-From field. -roy From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 19:15:09 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 TAA16919 for ; Tue, 7 Sep 2004 19:15: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 i87MlotR077076; Tue, 7 Sep 2004 15:47:50 -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 i87Mlo3x077075; Tue, 7 Sep 2004 15:47:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Mlnwg077068 for ; Tue, 7 Sep 2004 15:47:50 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42210) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1C4okh-0000Qn-4d (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 23:47:51 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4okh-0006OI-31; Tue, 07 Sep 2004 23:47:51 +0100 Date: Tue, 7 Sep 2004 23:47:51 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Roy Badami cc: ietf-mxcomp@imc.org Subject: Re: TECH-OMISSION (-core): alias-forwarding and multiple recipients In-Reply-To: <16702.14642.564899.579365@giles.gnomon.org.uk> Message-ID: References: <16702.14642.564899.579365@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 7 Sep 2004, Roy Badami wrote: > > It seems to me that the best solution would be for the forwarder to > send a separate copy of the message for each recipient, so it can in > each case use the original destination address in the Resent-From > field. This is both suboptimal and technically extremely difficult to do without de-optimising all email handling, as opposed to just the cases that are a problem for Sender-ID. If you consider also alias-forwarding via a departmental server it's even worse. Tony. -- f.a.n.finch http://dotat.at/ THE MULL OF GALLOWAY TO MULL OF KINTYRE INCLUDING THE FIRTH OF CLYDE AND THE NORTH CHANNEL: EAST VEERING SOUTHEAST 3 OR 4, OCCASIONALLY 5 LATER. FAIR. GOOD. SLIGHT. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 19:16:04 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 TAA16952 for ; Tue, 7 Sep 2004 19:16: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 i87MqRSw077259; Tue, 7 Sep 2004 15:52:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87MqR0E077258; Tue, 7 Sep 2004 15:52:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87MqQbm077252 for ; Tue, 7 Sep 2004 15:52:26 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4oni-0006Lj-JB; Tue, 07 Sep 2004 18:50:58 -0400 Message-ID: <413E3B9F.8020303@solidmatrix.com> Date: Tue, 07 Sep 2004 18:52:15 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Ryan Ordway CC: Andrew Newton , IETF MARID WG Subject: Re: consensus call of RR prefix References: <1094594181.16943.11.camel@vodka> In-Reply-To: <1094594181.16943.11.camel@vodka> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ryan Ordway wrote: > On Fri, 2004-09-03 at 14:32, Andrew Newton wrote: > > >>Therefore, that leaves one under-discussed question: should a prefix be >>used to avoid collision with other records as one measure of preventing >>the requirement of DNS over TCP? > > > No. > > 1) Inconsistent with SPF RR that doesn't use a prefix We could move the RR into the same address space. > 2) Causes deployment headaches for those who use > DNS providers whose web-based tools cannot handle > sub-domains or underscore characters. > I don't know how wide spread that would be. Based on the comments on the lists, there are already issues with TXT records and provider support. Collissions with other TXT records worry me more which is why I would rather see a prefix or use SRV. I can almost bet you that within a year of MARID someone else will use us as precedent for another RR/TXT experiment. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 19:49:11 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 TAA18564 for ; Tue, 7 Sep 2004 19:49: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 i87N8jc4078080; Tue, 7 Sep 2004 16:08: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 i87N8jre078079; Tue, 7 Sep 2004 16:08:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87N8hFv078073 for ; Tue, 7 Sep 2004 16:08:43 -0700 (PDT) (envelope-from roy+dated+1097190521.896e2c@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87NAWi0042391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Sep 2004 23:10:38 GMT (envelope-from roy+dated+1097190521.896e2c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87N8fPN080783 for ; Wed, 8 Sep 2004 00:08:41 +0100 (BST) (envelope-from roy+dated+1097190521.896e2c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i87N8fMU080776 for ietf-mxcomp@imc.org; Wed, 8 Sep 2004 00:08:41 +0100 (BST) (envelope-from roy+dated+1097190521.896e2c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 08 Sep 2004 00:08:40 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16702.16248.216444.508042@giles.gnomon.org.uk> Date: Wed, 8 Sep 2004 00:08:40 +0100 To: Tony Finch Cc: Roy Badami , ietf-mxcomp@imc.org Subject: Re: TECH-OMISSION (-core): alias-forwarding and multiple recipients In-Reply-To: References: <16702.14642.564899.579365@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tony" == Tony Finch writes: Tony> This is both suboptimal How common is it for a forwarder to receive a message with multiple recipients all of which require forwarding to the same MX...? Tony> and technically extremely difficult to do without Tony> de-optimising all email handling, as opposed to just the Tony> cases that are a problem for Sender-ID. Do you mean that it's difficult to configure existing MTAs to behave in this way, or that it would be difficult to introduce such functionality into an MTA...? I would find the latter surprizing... I'm assuming that if Sender ID progresses to Proposed Standard, then the major MTAs will grow native support for it... Tony> If you consider also alias-forwarding via a departmental Tony> server it's even worse. If all departmental MTAs are upgraded to be Sender ID compliant, I don't see the problem problem? You only add Resent-From when you're forwarding outside of your adminstrative domain. During the transtion you may need to keep track of which departmental servers are Sender ID compliant and which are not, of course... -roy From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 20:21: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 UAA20856 for ; Tue, 7 Sep 2004 20:21:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87NnSZW081286; Tue, 7 Sep 2004 16:49: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 i87NnSTw081285; Tue, 7 Sep 2004 16:49:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87NnSYd081279 for ; Tue, 7 Sep 2004 16:49:28 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i87NnKa10959; Tue, 7 Sep 2004 16:49:20 -0700 Date: Wed, 8 Sep 2004 08:49:09 +0900 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1322218026.20040908084909@brandenburg.com> To: Yakov Shafranovich CC: Roy Badami , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify In-Reply-To: <413E3531.7010906@solidmatrix.com> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yakov, YS> Then according to RFC 3668 we can safely ignore the IPR claims is YS> irrelevant and frivilous like it has been done before with IDN and YS> IPSec. Or can we? My own guidance about whether to to treat an IPR claim seriously -- particularly when it includes legal filings -- is to decide whether the claimant has the means and the resolve to pursue them. The costs of being in IPR litigation are awesome, no matter how frivolous one might believe the claims to be. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 20:21:14 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 UAA20876 for ; Tue, 7 Sep 2004 20:21:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87NmfcT080843; Tue, 7 Sep 2004 16:48: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 i87Nmflf080842; Tue, 7 Sep 2004 16:48:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87NmeQS080836 for ; Tue, 7 Sep 2004 16:48:40 -0700 (PDT) (envelope-from roy+dated+1097192919.bac7c7@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87NoUAr045950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Sep 2004 23:50:36 GMT (envelope-from roy+dated+1097192919.bac7c7@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87NmdRV081092 for ; Wed, 8 Sep 2004 00:48:39 +0100 (BST) (envelope-from roy+dated+1097192919.bac7c7@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i87NmdeL081091 for ietf-mxcomp@imc.org; Wed, 8 Sep 2004 00:48:39 +0100 (BST) (envelope-from roy+dated+1097192919.bac7c7@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 08 Sep 2004 00:48:39 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16702.18646.586787.527779@giles.gnomon.org.uk> Date: Wed, 8 Sep 2004 00:48:38 +0100 To: ietf-mxcomp@imc.org Subject: DOC-BUG: -pra intro In-Reply-To: <16698.4157.543727.884195@giles.gnomon.org.uk> References: <16698.4157.543727.884195@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Roy" == Roy Badami writes: Roy> (See also my separate post suggesting that we rename the Roy> purported responsible address so as to remove the word Roy> "purported") FWIW, I've withdrawn that proposal. I still believe the other changes to the intro of -pra are appropriate, however. -roy From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 20:21: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 UAA20897 for ; Tue, 7 Sep 2004 20:21: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 i87Ne8Ap080438; Tue, 7 Sep 2004 16:40: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 i87Ne8e1080437; Tue, 7 Sep 2004 16:40:08 -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 i87Ne8Zf080431 for ; Tue, 7 Sep 2004 16:40:08 -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 81EE64149B; Tue, 7 Sep 2004 16:40:13 -0700 (PDT) Subject: Re: TECH OMISSION: Stronger checks against email forgery From: Douglas Otis To: Yakov Shafranovich Cc: Tony Finch , Jim Lyon , IETF MARID WG In-Reply-To: <413E2BDF.5040700@solidmatrix.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> <413DE41E.5060504@solidmatrix.com> <1094583693.20922.165.camel@ddev.mail-abuse.org> <413E1082.9070909@solidmatrix.com> <1094591285.20922.216.camel@ddev.mail-abuse.org> <413E2BDF.5040700@solidmatrix.com> Content-Type: text/plain Message-Id: <1094600411.20922.330.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 07 Sep 2004 16:40:12 -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 Tue, 2004-09-07 at 14:45, Yakov Shafranovich wrote: > Douglas Otis wrote: > > >> Aren't we basically trying to deduce the "mailbox of the agent > >> responsible for the actual transmission of the message". Basically you > >> want to know who was the original agent or "Sender" was that put that > >> email into the email system. To me it sounds like the original > >> "purportable responsible address" is the same as guessing "the agent > >> responsible for the actual transmission of the message"? > > > > The recipient will be looking at the RFC 2822 From, where there is a new > > expectation they will be seeing some other header being checked. It > > remains, Sender-ID is not an effective tool against phishing. Sender-ID > > is also not an effective tool for stopping other types of abuse. To > > abate abuse, a reliable reputation mechanism must be possible. There is > > no reliable name obtained with Sender-ID. > > I think the intent was to introduce the entity of "original sender" of > the message although I would have to agree with you that by itself it > might not be too useful. Of course, considering that if Outlook 2000 and > some other MUAs actually displays that header, it will have some use for > those MUAs. > > But, what about SUBMITTER or RFC2821 MAIL FROM bounce address? Purely > from the technical viewpoint, are they reliable? All could be forged > including EHLO. It is much more difficult to forge the EHLO name. Unlike Sender-ID PRA/Submitter or RFC2821 MAIL FROM, there is no presumption of the integrity of the mail channel for assessing a particular message based upon the EHLO name. The EHLO name, as a host name, must reference a record that scales to the number of IP addresses of a host, unlike SPF or Sender-ID that could encompass the entire Internet. Unlike a record intended for routing, this MTA record must ensure authentication is possible. This record also indicates the host is authorized by the domain to send mail. The certainty of the authenticated MTA name allows for asserting reputation. An error made establishing an accountable name could be devastating for a reputation service. Sender-ID and SPF simple leave too many avenues open for this name to be spoofed. In addition, unlike Sender-ID or SPF, there is no presumption that the MAIL FROM or From mailbox domain will be constrained. MTA authentication operates independently of the mailbox domain relationship. > >> If so, RFC 2822, section 3.6.2, is very clear that the "Sender" field > >> indicates that. That's step 3 in PRA. However, the same RFC states in > >> section 3.6.2 "If the originator of the message can be indicated by a > >> single mailbox and the author and transmitter are identical, the > >> "Sender:" field SHOULD NOT be used". That's step 4 of PRA. The PRA draft > >> states explicitly that those 2 steps are taken directly from RFC 2822 > >> (don't see any IPR). > > > > The EHLO domain tracks the "sender" without the need to sort headers. > > Make this field a visible part of the sender identification. It does > > not require any IPR either and authentication could always result in a > > high degree of certainty. > > The key difference between EHLO and "Sender" is that EHLO is > MTA-specific while "Sender" is specific to the message itself. Perhaps a poor choice of words. The sender as identified using the PRA, such as Resent-From, could easily result in any of the same names as found in the EHLO name. Neither offer a direct relationship to the author of the message. The MTA name verifies the administrative domain accountable for delivered messages. If the mailbox domain is then related to MTA names, this arrives at the goal of mailbox domains authorizing these MTA names. It is also safe to handle this relationship as being either nominal or absolute. This MTA name authorization can be done within a single DNS lookup without the need for subsequent lookups. > A single EHLO value may cover messages originating from multiple domains. There is no limitation on the EHLO domain with respect to the number of domains claimed. A service provider may elect to assert an EHLO name to correspond to the customer being relayed. > Therefore using the "Sender" field or "SUBMITTER" allows for granularity > where a specific MTA may be authorized to relay email for one domain and > not another, like an ISP's outgoing MTA. Of course, like someone has > mentioned before, there are less MTAs then domains, and it might be > useful to work with the MTAs alone. > > I agree that the reliability is much less for PRA then EHLO, but on the > other hand SUBMITTER should be no worse than EHLO. So EHLO would not be > an option, if the granularity described above is desired. Submitter is based upon the PRA. Submitter can be no better than the PRA as a result. Yes, there is much less reliability of the PRA as compared to the EHLO domain. There is also a greater likelihood there will be fewer EHLO domains compared to mailbox domains. A mail provider that keeps track of their outbound SMTP logs and quickly terminates the typical spammer will earn a good reputation and will be offering a valuable service. There is no need to restrict the RFC2822 From address, if the provider authenticates their clients using any number of methods. How this control is achieved should be left to the mail provider, and using the EHLO name affords this flexibility. > And I still argue that the entire PRA algorithm is obvious to anyone > reading the RFC so the IPR issue is probably moot. I see nothing to justify using the PRA algorithm. These headers are of no value when compared to the EHLO domain. > >> Now for the resent blocks, the same RFC in section 3.6.6 states that the > >> "Resent-XXX" fields are simply placeholders for previous versions of the > >> same "Sender" and "From" fields. Therefore, there is a preference for > >> "Resent-Sender" just like there is a preference for "Sender" described > >> above. That's why steps 1-2 come before 3-4, and step 1 comes before > >> step 2 (still no IPR). > > > > > > What is the substantial difference between these headers and the name > > contained within the EHLO domain? There a tremendous advantage using > > the MTA name to establish MTA to Mailbox Domain relationships for either > > MAIL FROM or From. Why care about these other headers? > > See above. There is nothing that limits the granularity of the EHLO name, but there are reasons for wanting fewer entities to assess reputations. If the EHLO name is compared against a name list referenced by the mailbox domain, this arrives at the desired goal of assessing the mail channel against the mailbox domains as a separate and optional operation. > >> Now the interesting part here is deciding how to pick the proper > >> "Resent" header. The PRA algorithm picks the first "Resent-Sender" > >> unless there is a "Resent-From" before with "Return-Path" or "Received" > >> in between. The RFC states that: > >> A. "Resent fields SHOULD be added to any message that is reintroduced by > >> a user into the transport system." > >> B. "A separate set of resent fields SHOULD be added each time this is done." > >> C. "All of the resent fields corresponding to a particular resending of > >> the message SHOULD be together." > >> D. "Each new set of resent fields is prepended to the message; that is, > >> the most recent set of resent fields appear earlier in the message." > >> > >> Picking the earliest Resent block is based on #D and B, picking an > >> earlier "Resent-From" if separated from the other Resent headers is > >> based on #C (and I still see no IPR). > > > > Making a Mailbox Domain list that nominally relates to the MTA name will > > encompass a vast majority of the mail without touching upon issues of > > whether the Sender-ID IPR is obvious. By making the MTA authentication > > a separate function, then simply marking mail as being outside this MTA > > name/Mailbox Domain relationship is little different than selecting an > > invisible header compared against an address list unrelated to the From > > or MAIL FROM. Just use the EHLO domain. By always exposing the EHLO > > domain as visible, the recipient will soon recognize these From/EHLO > > names used in tandem. It is too dangerous to block mail based upon > > Sender-ID. A reputation check based upon the MTA name would allow a > > safe method of blocking mail however. > > > > If the goal is to assist the recipient decide what is valid mail and > > what is not, the visible MTA name compared against a nominal or > > restrictive list of MAIL FROM or From Mailbox Domains provides a > > superior outcome. > > I am not sure which would be superior. EHLO is not being used today > anywhere, and similarly for phishing the 2821 MAIL FROM bounce address > is not displayed to the end user. From the viewpoint of phishing, it > makes perfect sense to work with the message itself, not the channel. I > don't see how the invisible EHLO is any better than the invisible > "Sender". If anything, SUBMITTER or 2821 MAIL FROM, or 2822 "from" would > be superior. The EHLO name is a stronger identity that can safely support reputation assertions. If there are any illegal activity, an authenticated MTA name also identifies where logs can be found as evidence. Authenticating the MTA name allows an extremely simple name list to express the relationship between the mailbox domain and the MTA name. This gets rid of the need for dozens or hundreds of DNS lookups and complex macro scripts needed within SPF or Sender-ID. These lists can look something like: _mp._smtp.my-mailbox-domain.com. PTR big-isp.com PTR ads-r-us.com PTR webs-r-us.com Where a EHLO domain of mx01.nw.big-isp.com is recognized as sending mail on behalf of my-mailbox-domain.com. This relationship can be considered "required" or "nominal" without creating any exploit risk as with either SPF or Sender-ID. If there is abuse found, the reputation would be against the EHLO name and not the mailbox domain, as this mailbox identity is simply too weak. There are also advantages and greater freedoms afforded by establishing a hierarchy of accountability. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 20:22:49 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 UAA21003 for ; Tue, 7 Sep 2004 20:22:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87NlBp9080770; Tue, 7 Sep 2004 16:47: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 i87NlBKQ080769; Tue, 7 Sep 2004 16:47:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87NlAFp080763 for ; Tue, 7 Sep 2004 16:47:11 -0700 (PDT) (envelope-from roy+dated+1097192829.93f166@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87Nn0do045646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Sep 2004 23:49:06 GMT (envelope-from roy+dated+1097192829.93f166@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i87Nl9MT081066 for ; Wed, 8 Sep 2004 00:47:09 +0100 (BST) (envelope-from roy+dated+1097192829.93f166@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i87Nl9pd081059 for ietf-mxcomp@imc.org; Wed, 8 Sep 2004 00:47:09 +0100 (BST) (envelope-from roy+dated+1097192829.93f166@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 08 Sep 2004 00:47:08 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16702.18556.384658.31447@giles.gnomon.org.uk> Date: Wed, 8 Sep 2004 00:47:08 +0100 To: Roy Badami Cc: ietf-mxcomp@imc.org Subject: DOC-BUG: Terminology: Purported Responsible Address In-Reply-To: <16698.394.983773.516925@giles.gnomon.org.uk> References: <16698.394.983773.516925@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Roy" == Roy Badami writes: Roy> In the case of a Sender ID checker, the term makes sense. Roy> The identity is only purported; we don't know yet if the Roy> message is forged. Well, no one followed up on this, and on reflection I think maybe "Purported Responsible Address" isn't such a bad term. It doesn't seem particularly inappropriate even in contexts where the message is know to be authentic. A message always purports to be from someone; in the case of an authentic mesasge the purported sender may be known to be the same as the actual sender (and in the case of a well-intentioned sender this will typically be the case). So I withdraw my proposal; I think "Purported Responsible Address" is fine; but it should be clear that this is just the name for the result of the PRA algorithm, without any implications as to the accuracy (or otherwise) of the identity. -roy From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 20:43:41 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 UAA22465 for ; Tue, 7 Sep 2004 20:43:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8807lbd083346; Tue, 7 Sep 2004 17:07:47 -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 i8807l4C083345; Tue, 7 Sep 2004 17:07:47 -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 i8807kcx083329 for ; Tue, 7 Sep 2004 17:07:46 -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.8/8.12.8) with ESMTP id i8807c1W018157 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 7 Sep 2004 20:07:40 -0400 Message-Id: <6.1.2.0.2.20040907195401.06177eb8@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 07 Sep 2004 19:56:03 -0400 To: ietf-mxcomp@imc.org From: Daniel Senie Subject: Re: TECH-OMISSION (-core): alias-forwarding and multiple recipients In-Reply-To: <16702.14642.564899.579365@giles.gnomon.org.uk> References: <16702.14642.564899.579365@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 06:41 PM 9/7/2004, Roy Badami wrote: > >>>>> "Tony" == Tony Finch writes: > > Tony> It is not clear how alias-forwarders are supposed to handle > Tony> messages with multiple recipients. When handling such a > Tony> message, Exim and some other MTAs will determine the final > Tony> alias destination(s) of all addresses in the recipient list > Tony> before delivery starts, so that only one copy of the message > Tony> needs to be sent to each destination host. > >It seems to me that the best solution would be for the forwarder to >send a separate copy of the message for each recipient, so it can in >each case use the original destination address in the Resent-From >field. This is a significant change that would be quite problematic. The mechanism exists and is heavily used. My opinion is that a method to work with it is needed, as there's zero likelihood of depricating its use worldwide (let alone the efficiency reasons why deprication would be a terrible idea). From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 20:55:44 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 UAA23295 for ; Tue, 7 Sep 2004 20:55:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i880Kr5i083929; Tue, 7 Sep 2004 17:20: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 i880Kr4U083928; Tue, 7 Sep 2004 17:20:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i880Kqgb083922 for ; Tue, 7 Sep 2004 17:20:52 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 19:25:33 -0400 Received: from ([65.10.119.153]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 769931312; Tue, 07 Sep 2004 19:25:32 -0400 Message-ID: <007901c49530$e4794c60$6401a8c0@hdev1> From: "Hector Santos" To: "Yakov Shafranovich" , "Roy Badami" Cc: "Roy Badami" , "Dave Crocker" , References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> Subject: Re: TECH: use fetchmail algorithm to select header address to verify Date: Tue, 7 Sep 2004 19:17:47 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 ----- Original Message ----- From: "Roy Badami" To: "Yakov Shafranovich" Cc: "Roy Badami" ; "Dave Crocker" ; Sent: Tuesday, September 07, 2004 6:22 PM Subject: Re: TECH: use fetchmail algorithm to select header address to verify > > >>>>> "Yakov" == Yakov Shafranovich writes: > > Yakov> Now if all of this is stated in the RFC directly, what > Yakov> exactly is the IPR that is being claimed here? This seems > Yakov> to me explicit in the RFC itself. > > I believe that the PRA algorithm, at least in outline, is obvious to a > practitioner skilled in the art. No doubt about that. Hence the reason I am not at all concern about it. However, the only way possible a stronger claim can be made if a new "identity" is introduced that is outside standard or legacy practice. If this is the case, it would have to be a IETF standardized "identity" before I begin bothering with it but I won't support it if there is an IPR associated with it. > I'm sure it's pretty much what everyone does mentally when they read > the headers of a message (yeah, ok, I'm a geek, I assume that everyone > understands the semantics of the headers :-) Its not so much the "process, method or logic" to get a particular state, but the natural fact the information is natural available. This is a very important aspect of the patent process. It is akin to receiving a letter with no return address or one that is not recognizable, and this claim is attempting to protect the process of a) opening the letter and b) reading it to search for something recognizable. --- Hector Santos, CTO WINSERVER "Wildcat! Interactive Net Server" http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 20:57: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 UAA23372 for ; Tue, 7 Sep 2004 20:57:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i880NnwZ084041; Tue, 7 Sep 2004 17:23: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 i880Nnx7084040; Tue, 7 Sep 2004 17:23:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i880Nnq1084034 for ; Tue, 7 Sep 2004 17:23:49 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 7 Sep 2004 17:23:52 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Sep 2004 17:23:50 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 17:23:51 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 17:24:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH-OMISSION:Submitter concept should be expanded to include Peristent User Accounts (PUA) Date: Tue, 7 Sep 2004 17:23:52 -0700 Message-ID: Thread-Topic: TECH-OMISSION:Submitter concept should be expanded to include Peristent User Accounts (PUA) thread-index: AcSRCFjtJf7H2AjHQeuJSPmujb/OwAEMMgGw From: "Harry Katz" To: "Scott Kitterman" , "IETF MXCOMP \(E-mail\)" X-OriginalArrivalTime: 08 Sep 2004 00:24:25.0422 (UTC) FILETIME=[3216E6E0:01C4953A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i880Nnq1084035 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, September 02, 2004 9:02 AM, Scott Kitterman wrote: [snip] > 3. Explicitly add a third possible source for submitter, the > Persistent User Account (PUA). This would allow providers of > shared MTA services to add as a submitter the local (to the > shared MTA) e-mail address of the user that submitted the > message to the MTA. This was discussed on the list in July. > Here is the start of the thread: > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02633.html > > This would seem to be a much simpler solution for shared MTA > providers to implement than trying to determine which domains > their customers are authorized to send from. It also gives a > full address (no just a domain) that has agreed to be > responsible for the message. Also, if Submitter failed a > check during 2821 checking, I believe the message could be > rejected before data. > > This approach is hinted at in the examples (see the last > paragraph of Page 7), but use in this manner is never > described in the actual specification. > The reason I was thinking this might be a DOC-BUG is that > examples shouldn't introduce new functionality. My apologies for the delay in responding. In looking at this suggestion carefully, I'm inclined to leave the spec "as is" but to strengthen the wording of Example 5.3 to more clearly illustrate its use in this case. My reasons are that today PRA clearly tied to identities carried in the RFC 2822 message headers. I think it's important to keep it that way. Among other things this permits validation by the receiving server that the sender hasn't lied about the SUBMITTER value. Also, since there are a variety of possible behaviors by ISPs in this situation, I think it's important to allow them flexibility. Lastly, I think the method of Example 5.3 is a good way of addressing the scenario you've raised without requiring changes to the normative portion of the spec. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 21:24: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 VAA24953 for ; Tue, 7 Sep 2004 21:24:32 -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 i880hNjt084936; Tue, 7 Sep 2004 17:43:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i880hNix084935; Tue, 7 Sep 2004 17:43:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i880hM9w084926 for ; Tue, 7 Sep 2004 17:43:23 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C4qWz-0007j3-Iu; Tue, 07 Sep 2004 20:41:49 -0400 Message-ID: <413E5598.8030009@solidmatrix.com> Date: Tue, 07 Sep 2004 20:43:04 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Dave Crocker CC: Roy Badami , ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> <1322218026.20040908084909@brandenburg.com> In-Reply-To: <1322218026.20040908084909@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave Crocker wrote: > Yakov, > > YS> Then according to RFC 3668 we can safely ignore the IPR claims is > YS> irrelevant and frivilous like it has been done before with IDN and > YS> IPSec. Or can we? > > > My own guidance about whether to to treat an IPR claim seriously -- > particularly when it includes legal filings -- is to decide whether > the claimant has the means and the resolve to pursue them. > There is definitely means here, but I am not sure about the resolve. Somehow I don't think they will make fools out of themselves, especially considering that the FAT patent is being challenged. > The costs of being in IPR litigation are awesome, no matter how > frivolous one might believe the claims to be. > Considering what happened to the Eolas and FAT patents, challenging a patent is now an option as well and is much cheaper. In any case, does this mean that anyone claiming IPR rights can stop the standards process? That's not the reading I get from the cases of IDN and IPSec. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 21: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 VAA25203 for ; Tue, 7 Sep 2004 21:28: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 i880lIuT085163; Tue, 7 Sep 2004 17:47: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 i880lIJL085162; Tue, 7 Sep 2004 17:47:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i880lINR085154 for ; Tue, 7 Sep 2004 17:47:18 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [10.0.0.120] ([10.0.0.120]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 17:47:22 -0700 Subject: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? From: Max Kanat-Alexander To: ietf-mxcomp@imc.org Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094604442.30734.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Sep 2004 17:47:22 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Section 4. Mechanism Definitions: "If a CIDR-length is specified, then only the specified number of high-order bits of and the IP address are compared for equality." Caller ID provided a similar description of how to read IPs from an element, and a customer and I were uncertain about one thing: Is it OK to write 1.2.3/24, or MUST I write 1.2.3.0/24? It would be easier for implementation if the second form was required. My apologies if this has already been mentioned or discussed elsewhere. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 22:36:57 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 WAA29926 for ; Tue, 7 Sep 2004 22:36: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 i8822DRP092088; Tue, 7 Sep 2004 19:02:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8822D7L092087; Tue, 7 Sep 2004 19:02:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8822CE7092081 for ; Tue, 7 Sep 2004 19:02:12 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (unknown [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id 52162132CD1; Tue, 7 Sep 2004 22:00:45 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 61E1E61E; Tue, 7 Sep 2004 22:02:17 -0400 (EDT) Date: Tue, 7 Sep 2004 22:02:17 -0400 From: Meng Weng Wong To: Max Kanat-Alexander Cc: ietf-mxcomp@imc.org Subject: Re: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? Message-ID: <20040908020217.GB23667@dumbo.pobox.com> References: <1094604442.30734.11.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094604442.30734.11.camel@localhost.localdomain> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 07, 2004 at 05:47:22PM -0700, Max Kanat-Alexander wrote: | | Is it OK to write 1.2.3/24, or MUST I write 1.2.3.0/24? It would be | easier for implementation if the second form was required. | | My apologies if this has already been mentioned or discussed elsewhere. | I have the feeling that people are going to write the first form, so we might as well require implementations to support it. As long as it's not ambiguous, lazy is okay. Similarly "ipv4" and "ipv6" being synonyms for "ip4" and "ip6", and "a:1.2.3.4" being interpreted as "ip4:1.2.3.4". That seems to happen rather often. From owner-ietf-mxcomp@mail.imc.org Tue Sep 7 23:19:17 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 XAA02582 for ; Tue, 7 Sep 2004 23:19:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i882lWVW095781; Tue, 7 Sep 2004 19:47:32 -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 i882lWac095780; Tue, 7 Sep 2004 19:47:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i882lViL095774 for ; Tue, 7 Sep 2004 19:47:31 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [10.0.0.120] ([10.0.0.120]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 19:47:36 -0700 Subject: Re: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? From: Max Kanat-Alexander To: ietf-mxcomp@imc.org In-Reply-To: <20040908020217.GB23667@dumbo.pobox.com> References: <1094604442.30734.11.camel@localhost.localdomain> <20040908020217.GB23667@dumbo.pobox.com> Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094611655.30967.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Sep 2004 19:47:36 -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 Tue, 2004-09-07 at 19:02, Meng Weng Wong wrote: > I have the feeling that people are going to write the first > form, so we might as well require implementations to support > it. As long as it's not ambiguous, lazy is okay. OK, great. Yeah, we modified our Caller ID implementation to accept it because webtv was doing it. I'll just be glad to have it stated that we do have to read IPs written that way. > Similarly "ipv4" and "ipv6" being synonyms for "ip4" and > "ip6", and "a:1.2.3.4" being interpreted as "ip4:1.2.3.4". > That seems to happen rather often. Yeah, "liberal in what you accept" certainly doesn't do any harm, there. :-) -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 00:40:44 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 AAA06657 for ; Wed, 8 Sep 2004 00: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 i88493dJ001045; Tue, 7 Sep 2004 21:09:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88493dX001044; Tue, 7 Sep 2004 21:09:03 -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 i88491CN001036 for ; Tue, 7 Sep 2004 21:09:02 -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 1C4tlV-00081t-W5 for ietf-mxcomp@imc.org; Tue, 07 Sep 2004 23:09:08 -0500 To: "IETF MARID WG" References: <1094604442.30734.11.camel@localhost.localdomain> <20040908020217.GB23667@dumbo.pobox.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 07 Sep 2004 23:09:01 -0500 In-Reply-To: <20040908020217.GB23667@dumbo.pobox.com> (Meng Weng Wong's message of "Tue, 7 Sep 2004 22:02:17 -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: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? 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.6 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 <20040908020217.GB23667@dumbo.pobox.com> Meng Weng Wong writes: > On Tue, Sep 07, 2004 at 05:47:22PM -0700, Max Kanat-Alexander wrote: > | > | Is it OK to write 1.2.3/24, or MUST I write 1.2.3.0/24? It would be > | easier for implementation if the second form was required. > | > | My apologies if this has already been mentioned or discussed elsewhere. > > I have the feeling that people are going to write the first > form, so we might as well require implementations to support > it. As long as it's not ambiguous, lazy is okay. > > Similarly "ipv4" and "ipv6" being synonyms for "ip4" and > "ip6", and "a:1.2.3.4" being interpreted as "ip4:1.2.3.4". > That seems to happen rather often. Over the last year or so, Meng and I have gone around and around on this issue. In general, Meng appears to be willing to let implementations do whatever they want to try to fix up errors in SPF records. I, on the other hand, think that it is very important to have a consistent interpretation of an SPF record between implementations. I strongly believe that implementations MUST detect all syntax errors and return PermError in such cases. If we want to support these common deviations from the spec, I think we should put them into the spec and have all implementations support them. This is email we are talking about, not some formatting of a web page. I think it would be very bad to require ever implementation of SPF/SenderID to know about weird voodoo magic that is needed to work reliably the way web browers are required to know. I think SPF records should be handled much more like a Java virtual machine, where all errors are (in theory) detected and (in theory) all results are the same everywhere. I have submitted patches to require strict syntax checking. Neither Meng nor Mark appear to be concerned about this issue and they control the spec. I've pretty much given up on this issue. I suspect that one day, someone will write up a big compatibility guide so that publishers know what kind of stuff they can get away with, and implementers will know what kind of bogus stuff will get thrown their way that everyone else "does the right thing" with. For those who want to review the subject, here are a couple of posts to the SPF-discuss mailing list: http://archives.listbox.com/spf-discuss@v2.listbox.com/200403/0424.html http://archives.listbox.com/spf-discuss@v2.listbox.com/200403/0428.html http://archives.listbox.com/spf-discuss@v2.listbox.com/200403/0441.html -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 01:43: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 BAA12043 for ; Wed, 8 Sep 2004 01:43: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 i8859UlE006686; Tue, 7 Sep 2004 22:09: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 i8859UYd006685; Tue, 7 Sep 2004 22:09:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8859Ull006675 for ; Tue, 7 Sep 2004 22:09:30 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [192.168.10.100] ([216.233.212.162]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for ietf-mxcomp@imc.org; Tue, 7 Sep 2004 22:09:35 -0700 Subject: Re: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? From: Max Kanat-Alexander To: IETF MARID WG In-Reply-To: References: <1094604442.30734.11.camel@localhost.localdomain> <20040908020217.GB23667@dumbo.pobox.com> Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094620175.3400.3.camel@max.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Sep 2004 22:09:35 -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 Tue, 2004-09-07 at 21:09, wayne wrote: > If we want to support these common deviations from the spec, I think > we should put them into the spec and have all implementations support > them. I agree. The common deviations that Meng and I just discussed should be specified as being allowed. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 x23 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 03:12: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 DAA15886 for ; Wed, 8 Sep 2004 03:12:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i886hI5C048433; Tue, 7 Sep 2004 23:43: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 i886hIYk048431; Tue, 7 Sep 2004 23:43:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i886hGAh048347 for ; Tue, 7 Sep 2004 23:43:17 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so550345rnk for ; Tue, 07 Sep 2004 23:43:09 -0700 (PDT) Received: by 10.38.74.61 with SMTP id w61mr2537825rna; Tue, 07 Sep 2004 23:43:09 -0700 (PDT) Received: by 10.38.164.37 with HTTP; Tue, 7 Sep 2004 23:43:08 -0700 (PDT) Message-ID: <94df60cf04090723434890338d@mail.gmail.com> Date: Wed, 8 Sep 2004 02:43:08 -0400 From: Reply-To: To: Roy Badami Subject: Re: DOC-BUG: Terminology: Purported Responsible Address Cc: ietf-mxcomp@imc.org In-Reply-To: <16702.18556.384658.31447@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16698.394.983773.516925@giles.gnomon.org.uk> <16702.18556.384658.31447@giles.gnomon.org.uk> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 8 Sep 2004 00:47:08 +0100, Roy Badami wrote: > > >>>>> "Roy" == Roy Badami writes: > > Roy> In the case of a Sender ID checker, the term makes sense. > Roy> The identity is only purported; we don't know yet if the > Roy> message is forged. > > Well, no one followed up on this, and on reflection I think maybe > "Purported Responsible Address" isn't such a bad term. Of course, we could also just call it the "Patented Responsible Address"... David From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 04:46: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 EAA21142 for ; Wed, 8 Sep 2004 04:46: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 i888ChKB081188; Wed, 8 Sep 2004 01:12: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 i888Chqt081187; Wed, 8 Sep 2004 01:12:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i888CeAn081165 for ; Wed, 8 Sep 2004 01:12:43 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:60187) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1C4xZH-0002bC-8O (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 09:12:39 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4xZH-0004kd-4H; Wed, 08 Sep 2004 09:12:39 +0100 Date: Wed, 8 Sep 2004 09:12:39 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Roy Badami cc: ietf-mxcomp@imc.org Subject: Re: TECH-OMISSION (-core): alias-forwarding and multiple recipients In-Reply-To: <16702.16248.216444.508042@giles.gnomon.org.uk> Message-ID: References: <16702.14642.564899.579365@giles.gnomon.org.uk> <16702.16248.216444.508042@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Sep 2004, Roy Badami wrote: > > How common is it for a forwarder to receive a message with multiple > recipients all of which require forwarding to the same MX...? If we disabled the multiple recipient function our outgoing message load would rise by 20%. > Do you mean that it's difficult to configure existing MTAs to behave > in this way, or that it would be difficult to introduce such > functionality into an MTA...? I mean that it's effectively impossible to disable the multiple recipient function selectively (i.e. only in the cases that are a problem for Sender-ID). Tony. -- f.a.n.finch http://dotat.at/ MULL OF KINTYRE TO ARDNAMURCHAN POINT: SOUTHEAST 3 OR LESS INCREASING 4 OR 5. FAIR. GOOD. SLIGHT. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 05:35: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 FAA24702 for ; Wed, 8 Sep 2004 05:35: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 i88969Zn099578; Wed, 8 Sep 2004 02:06: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 i889695A099577; Wed, 8 Sep 2004 02:06:09 -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 i889667f099520 for ; Wed, 8 Sep 2004 02:06:09 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id C2D2B26C06E; Wed, 8 Sep 2004 11:06:00 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 9543426C094; Wed, 8 Sep 2004 11:05:59 +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 i8895xm7796629; Wed, 8 Sep 2004 11:05:59 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 4C17EFACC; Wed, 8 Sep 2004 11:05:59 +0200 (CEST) Date: Wed, 8 Sep 2004 11:05:59 +0200 From: Stephane Bortzmeyer To: Yakov Shafranovich Cc: ietf-mxcomp@imc.org Subject: Re: TECH: use fetchmail algorithm to select header address to verify Message-ID: <20040908090559.GA12165@nic.fr> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413E3531.7010906@solidmatrix.com> 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 Tue, Sep 07, 2004 at 06:24:49PM -0400, Yakov Shafranovich wrote a message of 23 lines which said: > Then according to RFC 3668 we can safely ignore the IPR claims is > irrelevant and frivilous like it has been done before with IDN and > IPSec. Or can we? Of course, nobody can be really sure. IMHO, given the already existing statements by the Apache Foundation or the Debian people, if we want these groups to deply SenderID, we need a very clear statement for the IETF that the IETF regards this patent claim as frivolous (because too trivial) and/or invalid (because of prior art) and suggests they are ignored. Is there a consensus in this WG to make such a statement? Also, the big difference with IDN is not the validity of the patent claim (they are both ridiculous) but the size of the company which owns it. Despite what was being said here, we should not evaluate the patent claim only on the basis of the licence terms. In the real world, the size and the amount of rogueness already displayed by the holder is much more important. I still believe the risk is too high. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 06:45: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 GAA28704 for ; Wed, 8 Sep 2004 06:45:04 -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 i88AC65Z024174; Wed, 8 Sep 2004 03:12: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 i88AC6DK024173; Wed, 8 Sep 2004 03:12:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88AC4Tq024158 for ; Wed, 8 Sep 2004 03:12:05 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57052) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1C4zQo-0003Yh-Ob (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 11:12:02 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4zQo-0001jf-IS; Wed, 08 Sep 2004 11:12:02 +0100 Date: Wed, 8 Sep 2004 11:12:02 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org cc: Tony Finch Subject: DEPLOY: not at the University of Cambridge Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I work for the University of Cambridge Computing Service where I define and implement our anti-spam and anti-virus policies on the central email relays. We will not be implementing Sender-ID for reasons mostly related to the forwarding problem, explained in more detail below. Most of these reasons apply to all designated sender schemes, so we won't be implementing SPF either. Our central message store has about 32,000 users. The relays are used by a few thousand more users in various departments and colleges. We also have an alumni forwarding service with something over 20,000 users. As well as the alumni forwarding service, about 7% of our message store users forward their email off-site. These users are likely to lose legitimate email because of Sender-ID checks at the destination sites. We can mitigate this problem by adding Resent-From: fields to the headers of messages we handle, but this will interfere with the resend function of MUAs in common use in the University since they generally follow 822 semantics not 2822 semantics for this field. There are also serious problems deciding what address to put in the field without de-optimising messages with multiple recipients and without confusing users. We do not know how many of our users forward email to Cambridge from other sites, and it is very difficult to find out. We can only implement Sender-ID checks if we also whitelist sites that forward to Cambridge, in order to avoid erroneously rejecting legitimate email. It will be extremely difficult to create and maintain the whitelist, both because it is hard to find out which sites should be on the list and because it is hard to keep up with changes in the list of outgoing MTAs at those sites. Sender-ID records won't make it easier to maintain the list because forwarding sites that are Sender-ID compliant won't need to be on the list. We are doing all the things that are necessary to be able to advertise Sender-ID: we have always kept tight control over which machines are permitted to send email directly to the public Internet and we block port 25 for the rest; and we have an authenticated submission service for roaming users (though it is taking time for users to find out about it). However we expect that because of the prevalence of forwarding in academia and because of the likelihood that recipient sites will not properly mitigate the forwarding problem, to advertise Sender-ID records will cause legitimate email from our users to be erroneously rejected. The University is a federal organization with a strongly delegated management structure. The Computing Service does not have a monopoly over the provision of email services, so the colleges and departments use the central email services to a greater or lesser extent at their choice. We would have to perform a much more detailed liaison exercise than usual to work out what the implications of implementing Sender-ID would be for email travelling between the various parts of the University. My colleague Philip Haze, who wrote the MTA that we use, has already stated that Exim will not be able to support Sender-ID because of Microsoft's intellectual property licence. -- Tony Finch http://www.cus.cam.ac.uk/~fanf2/ Mail Support, University of Cambridge Computing Service New Museums Site, Pembroke Street, Cambridge, CB2 3QH From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 06:45: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 GAA28722 for ; Wed, 8 Sep 2004 06:45: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 i88ADMHO024739; Wed, 8 Sep 2004 03:13:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88ADMi2024738; Wed, 8 Sep 2004 03:13:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88ADLuk024695 for ; Wed, 8 Sep 2004 03:13:21 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 19551 invoked from network); 8 Sep 2004 10:15:00 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 8 Sep 2004 10:15:00 -0000 In-Reply-To: <413E5598.8030009@solidmatrix.com> References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> <1322218026.20040908084909@brandenburg.com> <413E5598.8030009@solidmatrix.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: Dave Crocker , Roy Badami , ietf-mxcomp@imc.org From: Margaret Olson Subject: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] Date: Wed, 8 Sep 2004 06:13:18 -0400 To: Yakov Shafranovich 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 [I changed the tag and subject to match the topic of discussion] On Sep 7, 2004, at 8:43 PM, Yakov Shafranovich wrote: > > Dave Crocker wrote: >> My own guidance about whether to to treat an IPR claim seriously -- >> particularly when it includes legal filings -- is to decide whether >> the claimant has the means and the resolve to pursue them. > > There is definitely means here, but I am not sure about the resolve. > Somehow I don't think they will make fools out of themselves, > especially considering that the FAT patent is being challenged. > >> The costs of being in IPR litigation are awesome, no matter how >> frivolous one might believe the claims to be. > > Considering what happened to the Eolas and FAT patents, challenging a > patent is now an option as well and is much cheaper. > > In any case, does this mean that anyone claiming IPR rights can stop > the standards process? That's not the reading I get from the cases of > IDN and IPSec. My reading of the IPR situation is that the MS patent is defensive - it ensures that they (and we) can use the technology. Their license is positioned for maximum defensive value. I believe they (and we) would have been better off sacrificing some of the legal defense value for sub-licensing and more open source compatibility, but they obviously disagree. In fairness, I'll point out that they have effectively volunteered to pay for any patent defense that is necessary, and perhaps can not be blamed too much for a zealous approach to preventing litigation expense. I suggest ignoring the patent. It's not in their interests to litigate this kind of defensive (read: bogus) patent if they can possibly help it - avoiding patent litigation is the entire point of defensive patents. We'll only see litigation if someone decides to file a competing patent claim and prevent MS (and the rest of us) from using Sender ID. In this scenario a patent holder with deep pockets is a desirable. The idea that any email authentication algorithm that is not currently encumbered will remain so in the face of something as potent as spam prevention strikes me as a bit naive. Others have posted on the state of the USPTO office an software patents, so I won't repeat that here. A patent holder focused on milking the patent, rather than protecting large and profitable businesses, would produce far worse licensing terms. A patent holder acting on behalf of the open source community would presumably produce a more open source friendly license. But no patent claim is a temporary situation. We need to be realistic about this, and I suspect MS's position in many reflects painful experience with failing to patent things that the rest of us would call either obvious or long standing prior art. My experience has certainly been that it if it is useful, you need to patent it if you expect to continue to use it. Margaret. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 06:54:40 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 GAA29254 for ; Wed, 8 Sep 2004 06:54:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88APXIA029280; Wed, 8 Sep 2004 03:25:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88APXxb029279; Wed, 8 Sep 2004 03:25:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88APWKi029267 for ; Wed, 8 Sep 2004 03:25:33 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 31114 invoked from network); 8 Sep 2004 10:27:13 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 8 Sep 2004 10:27:13 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <1094604442.30734.11.camel@localhost.localdomain> <20040908020217.GB23667@dumbo.pobox.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <69F94660-0181-11D9-AFEC-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit From: Margaret Olson Subject: Re: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? Date: Wed, 8 Sep 2004 06:25:32 -0400 To: "IETF MARID WG" 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 Sep 8, 2004, at 12:09 AM, wayne wrote: > > In <20040908020217.GB23667@dumbo.pobox.com> Meng Weng Wong > writes: >> >> I have the feeling that people are going to write the first >> form, so we might as well require implementations to support >> it. As long as it's not ambiguous, lazy is okay. >> >> Similarly "ipv4" and "ipv6" being synonyms for "ip4" and >> "ip6", and "a:1.2.3.4" being interpreted as "ip4:1.2.3.4". >> That seems to happen rather often. > > > [snip] > I strongly believe that implementations MUST detect all syntax errors > and return PermError in such cases. > > If we want to support these common deviations from the spec, I think > we should put them into the spec and have all implementations support > them. > I can not agree more. A spec that has a large number of common deviations is not a spec. It's a series of suggestions, and you wind up with a myriad of implementations doing all kinds of things, and it becomes impossible for a publisher to know if the record is really right or not. A spec with many deviations tends to encourage more deviations and "improvements". Consistency is a BIG part of keeping it simple. I don't mind if the syntax is extended to include the variants listed above, but it needs to be in the spec. This reasoning applies to the MUST and SHOULD debate about TXT and the new SPF RR as well. If it's allowed, say so. If it's not, it's an error. And don't spec things that many implementations can't comply with! > This is email we are talking about, not some formatting of a web > page. I think it would be very bad to require ever implementation of > SPF/SenderID to know about weird voodoo magic that is needed to work > reliably the way web browers are required to know. Well, it's pretty bad on a web page too. The browser mess wastes buckets of development time in every organization all over the world. Let's not do that. Margaret. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 08:27: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 IAA05943 for ; Wed, 8 Sep 2004 08:27: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 i88Bwm7U045386; Wed, 8 Sep 2004 04:58: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 i88Bwmi9045385; Wed, 8 Sep 2004 04:58:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88BwlwI045376 for ; Wed, 8 Sep 2004 04:58:48 -0700 (PDT) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id 80C86BC1BA; Wed, 8 Sep 2004 07:58:46 -0400 (EDT) Subject: Re: TECH-OMISSION (-core): alias-forwarding and multiple recipients In-Reply-To: "from Tony Finch at Sep 8, 2004 09:12:39 am" To: ietf-mxcomp@imc.org Date: Wed, 8 Sep 2004 07:58:46 -0400 (EDT) Reply-To: ietf-mxcomp@imc.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20040908115846.80C86BC1BA@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony Finch: > > On Wed, 8 Sep 2004, Roy Badami wrote: > > > > How common is it for a forwarder to receive a message with multiple > > recipients all of which require forwarding to the same MX...? > > If we disabled the multiple recipient function our outgoing message load > would rise by 20%. > > > Do you mean that it's difficult to configure existing MTAs to behave > > in this way, or that it would be difficult to introduce such > > functionality into an MTA...? > > I mean that it's effectively impossible to disable the multiple recipient > function selectively (i.e. only in the cases that are a problem for > Sender-ID). That's a too general claim. Sure, the simplest approach is to disable multi-recipient deliveries for all messages that contain at least one alias-forwarded recipient. This is not needed when the MTA stores sufficient additional information so that the scheduler can make a more informed decision (such as the before aliasing recipient address in addition to the final recipient). Wietse From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 09:16:17 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 JAA10253 for ; Wed, 8 Sep 2004 09:16:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Cr2XJ050953; Wed, 8 Sep 2004 05:53: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 i88Cr2BW050952; Wed, 8 Sep 2004 05:53:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88CqsXt050934 for ; Wed, 8 Sep 2004 05:53:01 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i88D1BWc030005; Wed, 8 Sep 2004 09:01:17 -0400 From: To: "'Margaret Olson'" , "'Yakov Shafranovich'" Cc: "'Dave Crocker'" , "'Roy Badami'" , Subject: RE: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] Date: Wed, 8 Sep 2004 08:49:02 -0400 Message-ID: <044201c495a2$3a259a80$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Margaret Olson > Sent: Wednesday, September 08, 2004 6:13 AM > To: Yakov Shafranovich > Cc: Dave Crocker; Roy Badami; ietf-mxcomp@imc.org > Subject: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select > header address to verify] > > > > [I changed the tag and subject to match the topic of discussion] > > On Sep 7, 2004, at 8:43 PM, Yakov Shafranovich wrote: > > > > > Dave Crocker wrote: > >> My own guidance about whether to to treat an IPR claim seriously -- > >> particularly when it includes legal filings -- is to decide whether > >> the claimant has the means and the resolve to pursue them. > > > > There is definitely means here, but I am not sure about the > resolve. > > Somehow I don't think they will make fools out of themselves, > > especially considering that the FAT patent is being challenged. > > > >> The costs of being in IPR litigation are awesome, no matter how > >> frivolous one might believe the claims to be. > > > > Considering what happened to the Eolas and FAT patents, > challenging a > > patent is now an option as well and is much cheaper. > > > > In any case, does this mean that anyone claiming IPR rights > can stop > > the standards process? That's not the reading I get from > the cases of > > IDN and IPSec. > > My reading of the IPR situation is that the MS patent is > defensive - it > ensures that they (and we) can use the technology. Their license is > positioned for maximum defensive value. Then why have such a restrictive license, indeed one that forces your competitors to inform you of what they are working on? > I believe they (and we) would have been better off sacrificing some of the legal defense value for > sub-licensing and more open source compatibility, but they obviously disagree. There is no disagreement. You believe their patent is purely defensive. Its clearly not *just* defensive else why that discriminatory and/or restrictive license??? > In fairness, I'll point out that they have effectively > volunteered to pay for any patent defense that is necessary, and Of course, and what they get out of it is control from their competing MTA products: preventing the competing MTA products from altering/enhancing/improving the MARID (thereby preventing them from getting an edge with a better product). Someone please correct me if I am wrong. (Please let me be wrong) > perhaps can not be blamed too much for a zealous approach to > preventing > litigation expense. > > I suggest ignoring the patent. It's not in their interests to > litigate > this kind of defensive (read: bogus) patent if they can possibly help > it - avoiding patent litigation is the entire point of defensive > patents. We'll only see litigation if someone decides to file a > competing patent claim and prevent MS (and the rest of us) from using > Sender ID. In this scenario a patent holder with deep pockets is a > desirable. > > The idea that any email authentication algorithm that is not > currently > encumbered will remain so in the face of something as potent as spam > prevention strikes me as a bit naive. Others have posted on the state > of the USPTO office an software patents, so I won't repeat > that here. A > patent holder focused on milking the patent, rather than protecting > large and profitable businesses, would produce far worse licensing > terms. A patent holder acting on behalf of the open source community > would presumably produce a more open source friendly license. But no > patent claim is a temporary situation. We need to be realistic about > this, and I suspect MS's position in many reflects painful experience > with failing to patent things that the rest of us would call either > obvious or long standing prior art. My experience has certainly been > that it if it is useful, you need to patent it if you expect to > continue to use it. Sure, OK. But that still does NOT require a discriminatory and/or restrictive license!!! Terry > > Margaret. > From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 09:17: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 JAA10324 for ; Wed, 8 Sep 2004 09:17:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88CnDBl050209; Wed, 8 Sep 2004 05:49:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88CnD6a050208; Wed, 8 Sep 2004 05:49:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88CnBue050196 for ; Wed, 8 Sep 2004 05:49:12 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-7.tower-48.messagelabs.com!1094647748!5008280 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 25713 invoked from network); 8 Sep 2004 12:49:08 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-7.tower-48.messagelabs.com with SMTP; 8 Sep 2004 12:49:08 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Sep 2004 13:49:08 +0100 Received: (qmail 10830 invoked from network); 7 Sep 2004 12:46:13 -0000 Received: from unknown (HELO ?10.0.1.2?) (10.191.100.2) by matt?dev.int.star.co.uk with SMTP; 7 Sep 2004 12:46:13 -0000 In-Reply-To: <413DE41E.5060504@solidmatrix.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> <413DBAE7.1030504@solidmatrix.com> <413DE41E.5060504@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7903A85B-0195-11D9-AD2C-000A95AC67AA@messagelabs.com> Content-Transfer-Encoding: 7bit Cc: Tony Finch , Jim Lyon , IETF MARID WG From: Matt Sergeant Subject: Re: TECH OMISSION: Stronger checks against email forgery Date: Wed, 8 Sep 2004 13:49:07 +0100 To: Yakov Shafranovich X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 08 Sep 2004 12:49:08.0063 (UTC) FILETIME=[3B04D6F0:01C495A2] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7 Sep 2004, at 17:38, Yakov Shafranovich wrote: > I think we are going in circles. Validating the bounce address only > prevents false bounces but allows phishing, validating "Sender" does > not stop phishing but allows bounces plus does not take into account > forwarding, validating the "from" headers stops phishing but allows > bounces. Which one of these do we really want? Validating the "from" headers in no way stops phishing. It may give us some comfort to think that in some future we might be able to whitelist "from" headers, with some certainty that they aren't forged, but that's all it does. A whitelist (or reputation list) does not stop phishing. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 09:25: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 JAA10703 for ; Wed, 8 Sep 2004 09:25:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88D2MNJ051643; Wed, 8 Sep 2004 06:02:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88D2MMi051642; Wed, 8 Sep 2004 06:02:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88D2L7g051635 for ; Wed, 8 Sep 2004 06:02:21 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:32943) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1C525c-0006qj-FE (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 14:02:20 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C525c-0008AB-Dz for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 14:02:20 +0100 Date: Wed, 8 Sep 2004 14:02:20 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: Re: TECH-OMISSION (-core): alias-forwarding and multiple recipients In-Reply-To: <20040908115846.80C86BC1BA@spike.porcupine.org> Message-ID: References: <20040908115846.80C86BC1BA@spike.porcupine.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Sep 2004, Wietse Venema wrote: > Tony Finch: > > > > I mean that it's effectively impossible to disable the multiple recipient > > function selectively (i.e. only in the cases that are a problem for > > Sender-ID). > > That's a too general claim. You're right, I need to go into more detail. > Sure, the simplest approach is to disable multi-recipient deliveries for > all messages that contain at least one alias-forwarded recipient. This > is not needed when the MTA stores sufficient additional information so > that the scheduler can make a more informed decision (such as the before > aliasing recipient address in addition to the final recipient). The problem is that (in general) my systems don't have enough local information to know that a message they are passing from the Internet to somewhere inside the University is later going to pass back out (which is when the change needs to be made). In many cases the message will pass back out via a route which does not pass though my systems. Roy Badami points out that I could add a Resent-From: header whenever a message leaves my jurisdiction, whether that is further into the University or out to the Internet. This depends on the servers in departments and colleges to do the right thing, if we want the University as a whole to be compliant. It also restricts the proportion of email that can have multiple recipients. This is all a great deal of effort and complexity. It's much simpler to gain compliance by just sticking Resent-From: mailer-daemon@ppsw.cam.ac.uk on every message (ppsw is the name of our relay for historical reasons); this is not in the spirit of Sender-ID but it does the job without de-optimising everything. Tony. -- f.a.n.finch http://dotat.at/ SOUTH FITZROY: CYCLONIC 3 OR 4. THUNDERY SHOWERS. MODERATE OR GOOD. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 10:06:11 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 KAA13142 for ; Wed, 8 Sep 2004 10:06:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88DbQWu055223; Wed, 8 Sep 2004 06:37:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88DbQcH055222; Wed, 8 Sep 2004 06:37:26 -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 i88DbPqJ055211 for ; Wed, 8 Sep 2004 06:37:25 -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, 08 Sep 2004 09:37:22 -0400 id 0015F9D7.413F0B12.00006D80 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 09:37:18 -0400 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 It is the opinion of the co-chairs at this time (before the end of last call) that the MARID working group has no consensus regarding the deployment of Sender ID. This lack of consensus centers around the IPR associated with the PRA algorithm. Since predicting deployment is a subjective matter and not strictly a technical concern, we would like to offer the working group a proposal for modifying Sender ID that would take the issue of deployment out of the hands of the IETF and place it in the hands of the ultimate decision-makers, the systems and network administrators of the Internet. We feel that this is where decisions of deployment should really be made. It is also the opinion of the co-chairs that many in the working group are willing to deploy MAIL FROM checking as specified in draft-mengwong-spf. Therefore, we ask for consideration of the following proposal: The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) ver-minor = 1*DIGIT ver-scope = "pra" / "mailfrom" / name name = alpha *( alpha / digit / "-" / "_" / "." ) And the following stipulations: 1) "mailfrom" checking will be defined in a new draft 2) multiple records are allowed 3) a scope (e.g. "pra") can only appear in one record of one type for validity purposes The question before the working group: assuming no technical errors with the above, is there anybody who vehemently objects with this proposal? -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 11:07:22 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 LAA18802 for ; Wed, 8 Sep 2004 11:07:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88EbskK061551; Wed, 8 Sep 2004 07:37:54 -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 i88EbsfR061550; Wed, 8 Sep 2004 07:37:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Ebr1h061543 for ; Wed, 8 Sep 2004 07:37:53 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52572) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1C53a5-0006ZK-5V (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 15:37:53 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C53a4-0001k8-PF; Wed, 08 Sep 2004 15:37:52 +0100 Date: Wed, 8 Sep 2004 15:37:52 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Message-ID: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Sep 2004, Andrew Newton wrote: > > It is the opinion of the co-chairs at this time (before the end of last call) > that the MARID working group has no consensus regarding the deployment of > Sender ID. This lack of consensus centers around the IPR associated with the > PRA algorithm. Isn't there also IPR associated with the -core document? > The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > ver-minor = 1*DIGIT > ver-scope = "pra" / "mailfrom" / name > name = alpha *( alpha / digit / "-" / "_" / "." ) Will there also be a helo scope? We can't use either pra or mailfrom because they break forwarding. Tony. -- f.a.n.finch http://dotat.at/ ST DAVIDS HEAD TO COLWYN BAY, INCLUDING ST GEORGES CHANNEL: EAST 3 OR 4, OCCASIONALLY 5 LATER. FAIR. GOOD. SLIGHT. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 11:15: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 LAA19283 for ; Wed, 8 Sep 2004 11:15: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 i88EibYn062254; Wed, 8 Sep 2004 07:44:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88Eibnq062253; Wed, 8 Sep 2004 07:44:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Eib01062247 for ; Wed, 8 Sep 2004 07:44:37 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C53f4-0005Jm-Ec; Wed, 08 Sep 2004 10:43:02 -0400 Message-ID: <413F1ACC.4070401@solidmatrix.com> Date: Wed, 08 Sep 2004 10:44:28 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Andrew Newton CC: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > It is also the opinion of the co-chairs that many in the working group > are willing to deploy MAIL FROM checking as specified in > draft-mengwong-spf. Therefore, we ask for consideration of the > following proposal: > > The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > ver-minor = 1*DIGIT > ver-scope = "pra" / "mailfrom" / name > name = alpha *( alpha / digit / "-" / "_" / "." ) > > And the following stipulations: > > 1) "mailfrom" checking will be defined in a new draft > 2) multiple records are allowed > 3) a scope (e.g. "pra") can only appear in one record of one type for > validity purposes > > The question before the working group: assuming no technical errors with > the above, is there anybody who vehemently objects with this proposal? > I like it but what happens if I want to do both mailfrom and pra, would I publish two records? Does this also increase a chance for collisions perhaps needing a prefix? If the scope of a Sender-ID record could be used to signify many things, does that mean that beside mailfrom and pra, other extensions are possible in the future? Would that require an IANA registry? Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 11:38: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 LAA21657 for ; Wed, 8 Sep 2004 11:38: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 i88F74hL064702; Wed, 8 Sep 2004 08:07: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 i88F74cZ064701; Wed, 8 Sep 2004 08:07:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88F73Sn064695 for ; Wed, 8 Sep 2004 08:07:04 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1C542I-0004Vy-00; Wed, 08 Sep 2004 16:07:02 +0100 Message-ID: <0e0401c495b5$1a8612f0$0200000a@ringo> From: "Chris Haynes" To: "Tony Finch" Cc: "IETF MARID WG" , "Harry Katz" , "Andrew Newton" References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 16:04:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Tony Finch asked: > > Isn't there also IPR associated with the -core document? In anticipation of the opportunity to use marid-core on its own, i.e. not in conjunction with marid-pra, I asked Harry a similar question, and got the reply: http://www.imc.org/ietf-mxcomp/mail-archive/msg04413.html Chris Haynes From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 11:38: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 LAA21710 for ; Wed, 8 Sep 2004 11:38: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 i88FClj2065351; Wed, 8 Sep 2004 08:12:47 -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 i88FClwo065350; Wed, 8 Sep 2004 08:12:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FCl7c065330 for ; Wed, 8 Sep 2004 08:12:47 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i88FCg3V022690 for ; Wed, 8 Sep 2004 08:12:42 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id B704784F865; Wed, 8 Sep 2004 08:12:42 -0700 (PDT) Date: Wed, 8 Sep 2004 08:12:42 -0700 From: "Mark C. Langston" To: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040908151242.GZ99172@bitshift.org> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 8:08AM up 6 days, 14:05, 9 users, load averages: 0.04, 0.04, 0.03 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 08, 2004 at 03:37:52PM +0100, Tony Finch wrote: > > On Wed, 8 Sep 2004, Andrew Newton wrote: > > > > It is the opinion of the co-chairs at this time (before the end of last call) > > that the MARID working group has no consensus regarding the deployment of > > Sender ID. This lack of consensus centers around the IPR associated with the > > PRA algorithm. > > Isn't there also IPR associated with the -core document? It's my understanding (based in part on a recent clarification by Mr. Katz as requested by Yakov and others) that -core in isolation is unencumbered. I suggested a few weeks ago that if the IPR was truly a show-stopper that we may want to consider just going ahead without the document embodying PRA; I'm still okay with that solution. I'll need to think a bit about Andrew's specific suggestion, but it looks fine on the face of it. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 11:40: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 LAA21926 for ; Wed, 8 Sep 2004 11:40:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FDNdL065421; Wed, 8 Sep 2004 08:13:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88FDNRO065420; Wed, 8 Sep 2004 08:13:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FDN0c065407 for ; Wed, 8 Sep 2004 08:13:23 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i88FDKwg008117 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Sep 2004 08:13:21 -0700 Date: Wed, 8 Sep 2004 08:13:20 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Message-ID: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> 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, 8 Sep 2004, Andrew Newton wrote: > And the following stipulations: > > 1) "mailfrom" checking will be defined in a new draft > 2) multiple records are allowed > 3) a scope (e.g. "pra") can only appear in one record of one type for > validity purposes > > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? While I am personally in favor of allowing multiple scopes in the same record, I think that this proposal will cause more problems than it seemingly might solve, specifically for forwarders. In particular, there is nothing in the current drafts that explain how to modify messages or envelopes to allow forwarding/mail list/mx backup operation...and I'm really hoping you're not suggesting we simply bring SRS in to the fold. -Rand From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 11:40: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 LAA21947 for ; Wed, 8 Sep 2004 11:40: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 i88F7vUt064778; Wed, 8 Sep 2004 08:07: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 i88F7vnK064777; Wed, 8 Sep 2004 08:07:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88F7sQS064767 for ; Wed, 8 Sep 2004 08:07:55 -0700 (PDT) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id 12FF2BC1B5; Wed, 8 Sep 2004 11:07:55 -0400 (EDT) Subject: Re: TECH-OMISSION (-core): alias-forwarding and multiple recipients In-Reply-To: "from Tony Finch at Sep 8, 2004 02:02:20 pm" To: ietf-mxcomp@imc.org Date: Wed, 8 Sep 2004 11:07:54 -0400 (EDT) Reply-To: ietf-mxcomp@imc.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20040908150755.12FF2BC1B5@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony Finch: > > On Wed, 8 Sep 2004, Wietse Venema wrote: > > Tony Finch: > > > > > > I mean that it's effectively impossible to disable the multiple recipient > > > function selectively (i.e. only in the cases that are a problem for > > > Sender-ID). > > > > That's a too general claim. > > You're right, I need to go into more detail. > > > Sure, the simplest approach is to disable multi-recipient deliveries for > > all messages that contain at least one alias-forwarded recipient. This > > is not needed when the MTA stores sufficient additional information so > > that the scheduler can make a more informed decision (such as the before > > aliasing recipient address in addition to the final recipient). > > The problem is that (in general) my systems don't have enough local > information to know that a message they are passing from the Internet to > somewhere inside the University is later going to pass back out (which is > when the change needs to be made). In many cases the message will pass > back out via a route which does not pass though my systems. The Sender ID spec suggests that Sender ID information is added by the MTA that does the aliasing/forwarding. Isn't the whole problem that you are trying to move that function from the aliasing/forwarding MTA to a gateway MTA? Please forgive the ASCII art: -> relay -> inside machine internet alias/forward <---------- some recipients There is a problem when you try to move that function from the aliasing/forwarding MTA to the inbound relay, because the inbound relay does not have enough information. Either the inbound relay would slap on the same generic Resent- information on all mail, or it would have to de-optimize all inbound deliveries and give each recipient their own Resent- information, on the odd chance that some will be forwarded out. Likewise, there is a problem when you try to move that function from the aliasing/forwarding MTA to an outbound relay. Only the aliasing/forwarding MTA has accurate information. The outbound relay would have to slap the same Resent- information on all mail. Wietse From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 11:42: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 LAA22188 for ; Wed, 8 Sep 2004 11:42: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 i88FIJ6H065984; Wed, 8 Sep 2004 08:18:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88FIJbg065983; Wed, 8 Sep 2004 08:18:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from Garovirus.uqss.uquebec.ca (garovirus.uqss.uquebec.ca [192.77.51.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FIIrF065924 for ; Wed, 8 Sep 2004 08:18:18 -0700 (PDT) (envelope-from gfk@logidac.com) Received: from maestro ([132.214.200.206]) by Garovirus.uqss.uquebec.ca (8.12.10/8.12.8) with SMTP id i88FI7NK019532 for ; Wed, 8 Sep 2004 11:18:10 -0400 Message-ID: <013b01c495b7$210e8510$cec8d684@sraq.intra> From: "Guillaume Filion" To: "IETF MARID WG" References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 11:18:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Garovirus-MailScanner: Found to be clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tony Finch" wrote: > Isn't there also IPR associated with the -core document? No, the IPR is associated with -core and -pra taken together. Harry Katz from Microsoft confirmed it yesterday in: http://www.imc.org/ietf-mxcomp/mail-archive/msg04413.html ---------------------- From: "Harry Katz" Sent: Tuesday, September 07, 2004 12:34 PM Subject: RE: Motion to abandon Sender ID > If you were able to confirm that the Microsoft disclosure / > IPR claims do not cover the marid-core spec. taken in > isolation, that would be extremely helpful and could allay > some people's concerns. > > Chris Haynes Confirmed. ---------------------- Best, GFK's -- Guillaume Filion, ing. jr Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 11:48:11 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 LAA22661 for ; Wed, 8 Sep 2004 11:48:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FFs3l065730; Wed, 8 Sep 2004 08:15:54 -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 i88FFsdG065729; Wed, 8 Sep 2004 08:15:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88FFrKE065719 for ; Wed, 8 Sep 2004 08:15:53 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-3.tower-48.messagelabs.com!1094656549!3883013 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 18203 invoked from network); 8 Sep 2004 15:15:49 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-3.tower-48.messagelabs.com with SMTP; 8 Sep 2004 15:15:49 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Sep 2004 16:15:48 +0100 Received: (qmail 11630 invoked from network); 7 Sep 2004 15:12:54 -0000 Received: from unknown (HELO ?10.0.1.2?) (10.191.100.2) by matt?dev.int.star.co.uk with SMTP; 7 Sep 2004 15:12:54 -0000 In-Reply-To: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Andrew Newton , IETF MARID WG From: Matt Sergeant Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 16:15:48 +0100 To: Tony Finch X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 08 Sep 2004 15:15:48.0910 (UTC) FILETIME=[B8BB84E0:01C495B6] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8 Sep 2004, at 15:37, Tony Finch wrote: > Isn't there also IPR associated with the -core document? Not directly: http://www.imc.org/ietf-mxcomp/mail-archive/msg04413.html ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 11:52:04 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 LAA23124 for ; Wed, 8 Sep 2004 11:52:04 -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 i88FQnSP066919; Wed, 8 Sep 2004 08:26: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 i88FQnYG066918; Wed, 8 Sep 2004 08:26:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FQmWk066911 for ; Wed, 8 Sep 2004 08:26:49 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C54Jw-00009p-VB; Wed, 08 Sep 2004 11:25:17 -0400 Message-ID: <413F24B2.7010202@solidmatrix.com> Date: Wed, 08 Sep 2004 11:26:42 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Tony Finch CC: Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony Finch wrote: > On Wed, 8 Sep 2004, Andrew Newton wrote: > >>It is the opinion of the co-chairs at this time (before the end of last call) >>that the MARID working group has no consensus regarding the deployment of >>Sender ID. This lack of consensus centers around the IPR associated with the >>PRA algorithm. > > > Isn't there also IPR associated with the -core document? > Only when used in conjuction with PRA: http://article.gmane.org/gmane.ietf.mxcomp/4590 Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 12:02: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 MAA23929 for ; Wed, 8 Sep 2004 12:02: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 i88FawRW068381; Wed, 8 Sep 2004 08:36: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 i88FawGp068380; Wed, 8 Sep 2004 08:36:58 -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 i88FavIx068371 for ; Wed, 8 Sep 2004 08:36:57 -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, 08 Sep 2004 11:36:57 -0400 id 0015F9D7.413F2719.00007B07 In-Reply-To: <413F1ACC.4070401@solidmatrix.com> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <413F1ACC.4070401@solidmatrix.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: IETF MARID WG From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 11:36:52 -0400 To: Yakov Shafranovich 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 Sep 8, 2004, at 10:44 AM, Yakov Shafranovich wrote: > I like it but what happens if I want to do both mailfrom and pra, > would I publish two records? The intent of the syntax is to allow one record to specify both pra and mailfrom if they are the same. If they are not the same, then a record for each is allowed. -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 12:02: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 MAA23951 for ; Wed, 8 Sep 2004 12:02: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 i88Fe4nr068760; Wed, 8 Sep 2004 08:40: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 i88Fe4n1068759; Wed, 8 Sep 2004 08:40:04 -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 i88Fe4Fc068752 for ; Wed, 8 Sep 2004 08:40:04 -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, 08 Sep 2004 11:40:04 -0400 id 0015F9D7.413F27D5.00007BCD In-Reply-To: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <57F66614-01AD-11D9-9A6B-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 11:40:00 -0400 To: Rand Wacker 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 Sep 8, 2004, at 11:13 AM, Rand Wacker wrote: > While I am personally in favor of allowing multiple scopes in the same > record, I think that this proposal will cause more problems than it > seemingly might solve, specifically for forwarders. > > In particular, there is nothing in the current drafts that explain how > to > modify messages or envelopes to allow forwarding/mail list/mx backup > operation...and I'm really hoping you're not suggesting we simply bring > SRS in to the fold. Are you talking about the MAIL FROM case or the PRA case? Otherwise, I do not understand your objection. -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 12:07:49 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 MAA24180 for ; Wed, 8 Sep 2004 12:07:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FfE8D068879; Wed, 8 Sep 2004 08:41: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 i88FfEp5068878; Wed, 8 Sep 2004 08:41:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FfEG0068872 for ; Wed, 8 Sep 2004 08:41:14 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i88FfGet014224 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Sep 2004 08:41:16 -0700 Date: Wed, 8 Sep 2004 08:41:16 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <57F66614-01AD-11D9-9A6B-000A95B3BA44@hxr.us> Message-ID: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <57F66614-01AD-11D9-9A6B-000A95B3BA44@hxr.us> 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, 8 Sep 2004, Andrew Newton wrote: > On Sep 8, 2004, at 11:13 AM, Rand Wacker wrote: > > > While I am personally in favor of allowing multiple scopes in the same > > record, I think that this proposal will cause more problems than it > > seemingly might solve, specifically for forwarders. > > > > In particular, there is nothing in the current drafts that explain how > > to modify messages or envelopes to allow forwarding/mail list/mx > > backup operation...and I'm really hoping you're not suggesting we > > simply bring SRS in to the fold. > > Are you talking about the MAIL FROM case or the PRA case? Otherwise, I > do not understand your objection. The envelope bounce address (MAIL FROM) case. You're right, it wouldn't make sense otherwise. ;) -Rand From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 12:10: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 MAA24350 for ; Wed, 8 Sep 2004 12:10:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FchHK068568; Wed, 8 Sep 2004 08:38: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 i88Fch0p068567; Wed, 8 Sep 2004 08:38:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Fcgnb068561 for ; Wed, 8 Sep 2004 08:38:43 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C54VW-0000yD-Lh; Wed, 08 Sep 2004 11:37:15 -0400 Message-ID: <413F277F.7080806@solidmatrix.com> Date: Wed, 08 Sep 2004 11:38:39 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Andrew Newton CC: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <413F1ACC.4070401@solidmatrix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > On Sep 8, 2004, at 10:44 AM, Yakov Shafranovich wrote: > >> I like it but what happens if I want to do both mailfrom and pra, >> would I publish two records? > > > The intent of the syntax is to allow one record to specify both pra and > mailfrom if they are the same. If they are not the same, then a record > for each is allowed. > Can you give an example of both? From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 12:16: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 MAA24675 for ; Wed, 8 Sep 2004 12:16:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FqXgV070694; Wed, 8 Sep 2004 08:52:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88FqX25070693; Wed, 8 Sep 2004 08:52:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FqWt4070686 for ; Wed, 8 Sep 2004 08:52:32 -0700 (PDT) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id 2A45FBC1B5; Wed, 8 Sep 2004 11:52:35 -0400 (EDT) Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> "from Andrew Newton at Sep 8, 2004 09:37:18 am" To: ietf-mxcomp@imc.org Date: Wed, 8 Sep 2004 11:52:35 -0400 (EDT) Reply-To: ietf-mxcomp@imc.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20040908155235.2A45FBC1B5@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton: > It is also the opinion of the co-chairs that many in the working group > are willing to deploy MAIL FROM checking as specified in > draft-mengwong-spf. Therefore, we ask for consideration of the > following proposal: > > The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > ver-minor = 1*DIGIT > ver-scope = "pra" / "mailfrom" / name > name = alpha *( alpha / digit / "-" / "_" / "." ) > > And the following stipulations: > > 1) "mailfrom" checking will be defined in a new draft > 2) multiple records are allowed > 3) a scope (e.g. "pra") can only appear in one record of one type for > validity purposes > > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? draft-mengwong-spf ('mailfrom') changes the return-path, and would need a companion document that fixes the sender notification problem. Wietse From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 12:17:14 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 MAA24727 for ; Wed, 8 Sep 2004 12:17: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 i88FjSmO069471; Wed, 8 Sep 2004 08:45: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 i88FjSq2069470; Wed, 8 Sep 2004 08:45:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FjRl2069462 for ; Wed, 8 Sep 2004 08:45:28 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (unknown [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id 0976C132CD1; Wed, 8 Sep 2004 11:43:54 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id E41B348C; Wed, 8 Sep 2004 11:45:29 -0400 (EDT) Date: Wed, 8 Sep 2004 11:45:29 -0400 From: Meng Weng Wong To: Rand Wacker Cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040908154529.GE23667@dumbo.pobox.com> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 08, 2004 at 08:13:20AM -0700, Rand Wacker wrote: | | In particular, there is nothing in the current drafts that explain how to | modify messages or envelopes to allow forwarding/mail list/mx backup | operation...and I'm really hoping you're not suggesting we simply bring | SRS in to the fold. | If we specify that spf/HELO and spf/SUBMITTER always override spf/MAIL-FROM, then there is no need for SRS. For example, at the envelope level only, given Alice sending mail to Bob who forwards to Robert, Step 1: HELO alice.mta MAIL FROM: RCPT TO: DATA From: Step 2: HELO bob.mta MAIL FROM: SUBMITTER= RCPT TO: DATA Resent-From: At step 2, the receiver can apply spf/HELO tests (or SPF Lite or CSV or even IP based whitelisting) to bob.mta, and approve the forwarder based on that. The receiver can also apply spf/SUBMITTER tests to , and approve the forwarder based on that. Whether the receiver trusts the forwarder through a global mechanism such as trusted-forwarder.org, or through a local whitelist of known forwarders, or simply wishes to apply an open-by-default policy or a closed-by-default policy, can be up to them. I predict that commercial forwarding services will do SRS anyway. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 12:18: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 MAA24806 for ; Wed, 8 Sep 2004 12:18: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 i88FtZRh071042; Wed, 8 Sep 2004 08:55: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 i88FtZDl071041; Wed, 8 Sep 2004 08:55:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp4g.bellsouth.com (aismtp4g.bellsouth.com [139.76.165.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FtYIg071013 for ; Wed, 8 Sep 2004 08:55:34 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01AL10015010117.ad.bls.com ([90.152.52.44] [90.152.52.44]) by aismtp4g.bellsouth.com with ESMTP; Wed, 8 Sep 2004 11:55:29 -0400 Received: from 01al10015010110.ad.bls.com ([90.152.52.23]) by 01AL10015010117.ad.bls.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Sep 2004 10:55:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? Date: Wed, 8 Sep 2004 10:55:29 -0500 Message-Id: <67A0E82B46DF094299204399257A2CC1F096ED@bre2k10p-55> Thread-Topic: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? Thread-Index: AcSVPj/622PJSaYtTVWny8iwQqf49gAfZ/Pw From: "Sauer, Damon" To: "Max Kanat-Alexander" , X-OriginalArrivalTime: 08 Sep 2004 15:55:29.0583 (UTC) FILETIME=[43B963F0:01C495BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i88FtYIg071036 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Section 4. Mechanism Definitions: > > > Is it OK to write 1.2.3/24, or MUST I write 1.2.3.0/24? It would be easier for implementation if the >second form was required. > > I would prefer MUST in this case. Would save a few lines of code and doesn't limit anything. > > -Max >-- >Maxwell Kanat-Alexander >2nd Level Tech Support Engineer, USA >Kerio Technologies, Inc. Regards, Damon Sauer From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 12:35:34 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 MAA25862 for ; Wed, 8 Sep 2004 12:35:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88G7G52072382; Wed, 8 Sep 2004 09:07: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 i88G7GCS072381; Wed, 8 Sep 2004 09:07:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88G6vRf072347 for ; Wed, 8 Sep 2004 09:07:16 -0700 (PDT) (envelope-from SRS0+19e4d8ec20e27d415c90+381+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C54yC-0004O0-Pa; Wed, 08 Sep 2004 17:06:53 +0100 Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope From: David Woodhouse To: Tony Finch Cc: Andrew Newton , IETF MARID WG In-Reply-To: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1094659611.4083.512.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 08 Sep 2004 17:06:52 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-08 at 15:37 +0100, Tony Finch wrote: > > The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) > > > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > > ver-minor = 1*DIGIT > > ver-scope = "pra" / "mailfrom" / name > > name = alpha *( alpha / digit / "-" / "_" / "." ) > > Will there also be a helo scope? > > We can't use either pra or mailfrom because they break forwarding. A HELO scope would be useful. I could publish records for that, whereas I could not publish records for either pra or mailfrom for much the same reasons as Tony has already described. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 12:42: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 MAA26457 for ; Wed, 8 Sep 2004 12:42: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 i88GF6RP073042; Wed, 8 Sep 2004 09:15: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 i88GF6OO073041; Wed, 8 Sep 2004 09:15:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88GF6lR073026 for ; Wed, 8 Sep 2004 09:15:06 -0700 (PDT) (envelope-from SRS0+19e4d8ec20e27d415c90+381+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C556A-0004Pw-4W; Wed, 08 Sep 2004 17:15:07 +0100 Subject: RE: TECH-ERROR (-core): misuse of Resent- fields From: David Woodhouse To: Harry Katz Cc: Tony Finch , ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1094660104.4083.528.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 08 Sep 2004 17:15:05 +0100 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 2004-09-07 at 10:33 -0700, Harry Katz wrote: > Lastly, the RFC states that Resent- headers are not "intended" for use > in some types of forwarding, but *does not* prescribe that they MUST NOT > be used in this way. > Thus, we believe our proposed use of Resent- headers is indeed > permissible. I would further suggest, given the threat posed to email > by the spam crisis, that this would be an "opportune moment" to broaden > the "intended" use of these fields. Why reuse existing fields which mean something different, instead of adding new fields or perhaps adding to the Received: header? It seems strange to hijack the Resent-* fields instead of just doing something new. Since we're discussing RFC2822 -- your mail software fails to follow the recommendation of §3.6.4 that reply messages SHOULD have "In-Reply-To:" and "References:" fields. Please could you ensure that this gets fixed. It is impolite to participate in public fora while breaking the threading information. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:05: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 NAA27958 for ; Wed, 8 Sep 2004 13:05:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88GdZT3075466; Wed, 8 Sep 2004 09:39: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 i88GdZGT075465; Wed, 8 Sep 2004 09:39:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailserver.corp.mailfrontier.com (blackcomb.mailfrontier.com [209.144.181.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88GdYEM075444 for ; Wed, 8 Sep 2004 09:39:34 -0700 (PDT) (envelope-from nleon@mailfrontier.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? Date: Wed, 8 Sep 2004 09:39:36 -0700 Message-ID: <42FE9417C0B0374B9D4234DC867819AC0C37E7@mailserver.corp.mailfrontier.com> Thread-Topic: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? Thread-Index: AcSVTL5+jVwi2U58TXG0MfuRaW2tVAAdXzQQ From: "Nate Leon" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i88GdYEM075460 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hmmm... so "64/8" would be valid ? I'm not very comfortable with that. n8 -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Meng Weng Wong Sent: Tuesday, September 07, 2004 7:02 PM To: Max Kanat-Alexander Cc: ietf-mxcomp@imc.org Subject: Re: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? On Tue, Sep 07, 2004 at 05:47:22PM -0700, Max Kanat-Alexander wrote: | | Is it OK to write 1.2.3/24, or MUST I write 1.2.3.0/24? It would be | easier for implementation if the second form was required. | | My apologies if this has already been mentioned or discussed elsewhere. | I have the feeling that people are going to write the first form, so we might as well require implementations to support it. As long as it's not ambiguous, lazy is okay. Similarly "ipv4" and "ipv6" being synonyms for "ip4" and "ip6", and "a:1.2.3.4" being interpreted as "ip4:1.2.3.4". That seems to happen rather often. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:18: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 NAA28722 for ; Wed, 8 Sep 2004 13:18:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88GsGXn076938; Wed, 8 Sep 2004 09:54: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 i88GsGUn076937; Wed, 8 Sep 2004 09:54:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mynah.mail.pas.earthlink.net (mynah.mail.pas.earthlink.net [207.217.120.228]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88GsF0f076931 for ; Wed, 8 Sep 2004 09:54:15 -0700 (PDT) (envelope-from tripp@corp.earthlink.net) Received: from atl3-dmz.fw.earthlink.net ([199.174.117.121] helo=[10.30.102.141]) by mynah.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 4.34) id 1C55i6-0006EB-Fs; Wed, 08 Sep 2004 09:54:18 -0700 In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Tripp Cox Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 12:54:16 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.619) X-ELNK-Trace: 3507b2fe2d9b3ca5cc16ce54e02836f04107784947cbbdd52f25d6ac78fa407c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 199.174.117.121 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sep 8, 2004, at 9:37 AM, Andrew Newton wrote: > It is also the opinion of the co-chairs that many in the working group > are willing to deploy MAIL FROM checking as specified in > draft-mengwong-spf. Therefore, we ask for consideration of the > following proposal: > > The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > ver-minor = 1*DIGIT > ver-scope = "pra" / "mailfrom" / name > name = alpha *( alpha / digit / "-" / "_" / "." ) I agree with decoupling scope from the base record format. If we're going to modify -protocol, I suggest we further decouple the version string from the base record format. To wit: version = "spf/" ver-major "." ver-minor "/" ver-scope *( "," ver-scope ) ver-major = 1*DIGIT ver-minor = 1*DIGIT ver-scope = "pra" / "mailfrom" / name name = alpha *( alpha / digit / "-" / "_" / "." ) Doing this would help further delineate the static and variable parts of the version string. I also recommend that the RR type defined for -protocol be modified to drop the superfluous "2". Sample applied use: example.com. IN SPF "spf/2.0/pra,mailfrom mx a:smtp.example.com a:smtp.marketingco.com ?all" IN SPF "spf/2.0/mta mx a:smtp.example.com -a:192.0.2.0/24 ?all" IN TXT "spf/2.0/pra,mailfrom mx a:smtp.example.com a:smtp.marketingco.com ?all" IN TXT "spf/2.0/mta mx a:smtp.example.com -a:192.0.2.0/24 ?all" In future versions, perhaps: example.com IN SPF "spf/2.1/xmlstr " example.com IN SPF "spf/2.2/xmldoc http://example.com/spf/policy.xml" > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? I see no harm in taking this opportunity to allow for future versions of Sender-ID with additional scopes and different record formats. Tripp From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:18:40 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 NAA28748 for ; Wed, 8 Sep 2004 13:18: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 i88GuDU5077132; Wed, 8 Sep 2004 09:56:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88GuD7S077131; Wed, 8 Sep 2004 09:56:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vodka.at-once.com (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88GuCiO077115 for ; Wed, 8 Sep 2004 09:56:12 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vodka.at-once.com (8.12.11/8.12.11) with ESMTP id i88Gu96l020912; Wed, 8 Sep 2004 09:56:10 -0700 Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope From: Ryan Ordway To: Andrew Newton Cc: IETF MARID WG In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1094662569.20831.19.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 08 Sep 2004 09:56:09 -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 Wed, 2004-09-08 at 06:37, Andrew Newton wrote: > The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > ver-minor = 1*DIGIT > ver-scope = "pra" / "mailfrom" / name > name = alpha *( alpha / digit / "-" / "_" / "." ) > > And the following stipulations: > > 1) "mailfrom" checking will be defined in a new draft > 2) multiple records are allowed > 3) a scope (e.g. "pra") can only appear in one record of one type for > validity purposes > > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? I fully support the extraction of the patent encumbered PRA. I do have concerns about forwarding and compatibility with existing records, so I will reserve my judgement until the new drafts have been published. Ryan -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:21:51 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 NAA28944 for ; Wed, 8 Sep 2004 13:21: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 i88GvYkl077266; Wed, 8 Sep 2004 09:57:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88GvYXk077265; Wed, 8 Sep 2004 09:57:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp5.ActiveState.com (gw.activestate.com [209.17.183.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88GvYap077253 for ; Wed, 8 Sep 2004 09:57:34 -0700 (PDT) (envelope-from cliffordh@ActiveState.com) Received: from smtp3.ActiveState.com (latte.activestate.com [192.168.4.252]) by smtp5.ActiveState.com (8.12.11/8.12.11) with ESMTP id i88GvVm7011987 for ; Wed, 8 Sep 2004 09:57:32 -0700 (envelope-from cliffordh@ActiveState.com) Received: from [192.168.3.130] (bar.activestate.com [192.168.3.130]) by smtp3.ActiveState.com (8.12.9/8.12.9) with ESMTP id i88GvV2l015773 for ; Wed, 8 Sep 2004 09:57:31 -0700 Message-ID: <413F3A11.90204@activestate.com> Date: Wed, 08 Sep 2004 09:57:53 -0700 From: Clifford Hammerschmidt User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040813) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@mail.imc.org Subject: (no subject) X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; 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 unsubscribe From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:25: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 NAA29222 for ; Wed, 8 Sep 2004 13:25:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88GsUwv076970; Wed, 8 Sep 2004 09:54: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 i88GsU3k076969; Wed, 8 Sep 2004 09:54:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88GsTB9076962 for ; Wed, 8 Sep 2004 09:54:29 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C55go-0006yu-6I; Wed, 08 Sep 2004 12:52:58 -0400 Message-ID: <413F393E.4000400@solidmatrix.com> Date: Wed, 08 Sep 2004 12:54:22 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: David Woodhouse CC: Tony Finch , Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <1094659611.4083.512.camel@hades.cambridge.redhat.com> In-Reply-To: <1094659611.4083.512.camel@hades.cambridge.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Woodhouse wrote: > On Wed, 2004-09-08 at 15:37 +0100, Tony Finch wrote: > >>>The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) >>> >>> version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) >>> ver-minor = 1*DIGIT >>> ver-scope = "pra" / "mailfrom" / name >>> name = alpha *( alpha / digit / "-" / "_" / "." ) >> >>Will there also be a helo scope? >> >>We can't use either pra or mailfrom because they break forwarding. > > > A HELO scope would be useful. I could publish records for that, whereas > I could not publish records for either pra or mailfrom for much the same > reasons as Tony has already described. > I think that Andy's proposal would make Sender-ID extensible enough to allow for all kinds of scopes. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:42: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 NAA00475 for ; Wed, 8 Sep 2004 13:42:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88H4qZH077903; Wed, 8 Sep 2004 10:04: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 i88H4qYR077902; Wed, 8 Sep 2004 10:04:52 -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 i88H4pI7077888 for ; Wed, 8 Sep 2004 10:04:51 -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 1C55sG-0008NL-CY for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 12:04:54 -0500 To: "IETF MARID WG" References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> <1322218026.20040908084909@brandenburg.com> <413E5598.8030009@solidmatrix.com> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 08 Sep 2004 12:04:48 -0500 In-Reply-To: (Margaret Olson's message of "Wed, 8 Sep 2004 06:13:18 -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: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] 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.6 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 Margaret Olson writes: > In fairness, I'll point out that they have effectively > volunteered to pay for any patent defense that is necessary, and > perhaps can not be blamed too much for a zealous approach to > preventing litigation expense. No, MS has only volunteered to pay for any patent defense filed against them. Patent enforcement can be selective. If Patent Trolls Inc decides to start out small to strengthen their case, they could start by suing sourceforge or me. Nothing in the SenderID license says that MS would come to sourceforge's or my aid. > I suggest ignoring the patent. Also, in <413E3531.7010906@solidmatrix.com> Yakov Shafranovich writes: > Then according to RFC 3668 we can safely ignore the IPR claims is > irrelevant and frivilous like it has been done before with IDN and > IPSec. Or can we? Both Margaret and Yakov suggest that "we" can ignore the MS patent. There is clearly a risk involved for those who do, but apparently both feel that the risk is pretty small. Would those of you who suggest ignoring the patent please also volunteer to pay for any and all costs associated with a (potential) lawsuit from MS for not using their license? If the risks are really as small as you two suggest, surely this wouldn't be a problem for you to do. If you are not willing to pay such costs, why are you suggesting that people like me who write and distribute software that would violate the patent take that risk? -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:42: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 NAA00493 for ; Wed, 8 Sep 2004 13:42:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88HHiXJ078915; Wed, 8 Sep 2004 10:17: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 i88HHiZs078914; Wed, 8 Sep 2004 10:17:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88HHiaB078908 for ; Wed, 8 Sep 2004 10:17:44 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55508) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1C564h-0006mD-Dj (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 18:17:39 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C564h-0006XH-CX; Wed, 08 Sep 2004 18:17:39 +0100 Date: Wed, 8 Sep 2004 18:17:39 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <413F393E.4000400@solidmatrix.com> Message-ID: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <1094659611.4083.512.camel@hades.cambridge.redhat.com> <413F393E.4000400@solidmatrix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Another thing: the macro language should have a letter for interpolating the scope. Tony. -- f.a.n.finch http://dotat.at/ SOUTH UTSIRE: VARIABLE 3 OR 4. MAINLY FAIR. MODERATE OR GOOD. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:44: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 NAA00640 for ; Wed, 8 Sep 2004 13:44: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 i88HDmlS078608; Wed, 8 Sep 2004 10:13: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 i88HDmUY078607; Wed, 8 Sep 2004 10:13:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88HDi3n078556 for ; Wed, 8 Sep 2004 10:13:47 -0700 (PDT) (envelope-from pk@TechFak.Uni-Bielefeld.DE) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i88HDc7R013793 for ; Wed, 8 Sep 2004 19:13:38 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i88HDc310571 for ; Wed, 8 Sep 2004 19:13:38 +0200 (MEST) Message-Id: <200409081713.i88HDc310571@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-reply-to: Your message of "Wed, 08 Sep 2004 09:37:18 EDT." <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10569.1094663617.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 08 Sep 2004 19:13:37 +0200 From: Peter Koch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton wrote: > ver-scope = "pra" / "mailfrom" / name [...] > 2) multiple records are allowed > 3) a scope (e.g. "pra") can only appear in one record of one type for > validity purposes does this mean the mail receiver queries for the RR(s) and selects from what is there if that fits its own supported set of scopes or should at the time of the DNS query the receiving MTA already have made its choice? -Peter From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:46: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 NAA00849 for ; Wed, 8 Sep 2004 13:46:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88HKjHk079111; Wed, 8 Sep 2004 10:20: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 i88HKjwG079110; Wed, 8 Sep 2004 10:20:45 -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 i88HKiCj079104 for ; Wed, 8 Sep 2004 10:20:44 -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 1C567e-000089-Uv for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 12:20:47 -0500 To: "IETF MARID WG" References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 08 Sep 2004 12:20:42 -0500 In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> (Andrew Newton's message of "Wed, 8 Sep 2004 09:37:18 -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: consensus call on pra/mailfrom deployment and versioning/scope 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.6 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 <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Andrew Newton writes: > It is the opinion of the co-chairs at this time (before the end of > last call) that the MARID working group has no consensus regarding the > deployment of Sender ID. Sadly, I agree with this assessment. :-< > Since predicting deployment is > a subjective matter and not strictly a technical concern, we would > like to offer the working group a proposal for modifying Sender ID > that would take the issue of deployment out of the hands of the IETF > and place it in the hands of the ultimate decision-makers, the systems > and network administrators of the Internet. Are you saying that, by adding the mailfrom scope, you think that the marid-pra I-D can/should advance? If so, I strongly disagree with this position. > It is also the opinion of the co-chairs that many in the working group > are willing to deploy MAIL FROM checking as specified in > draft-mengwong-spf. Several comments: 1) I really doubt that we will be able to gain any sort of consensus on the support of 2821.MAILFROM in the time remaining in the current last call. 2) As others have pointed out, SPF-classic required 2821.HELO checking in some cases and allowed 2821.HELO checking in all cases. Therefore, I think that at least a 2821.HELO scope needs to be added. 3) I think that it is critical to also add the %{e} scope macro variable, as mentioned several times on this list. > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? I support work along this line. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:54: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 NAA01693 for ; Wed, 8 Sep 2004 13:54: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 i88HKJYV079058; Wed, 8 Sep 2004 10:20:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88HKJvT079057; Wed, 8 Sep 2004 10:20:19 -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 i88HKI37079051 for ; Wed, 8 Sep 2004 10:20:18 -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 6A88C4149B; Wed, 8 Sep 2004 10:20:22 -0700 (PDT) Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope From: Douglas Otis To: Andrew Newton Cc: IETF MARID WG In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1094664020.15739.62.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 08 Sep 2004 10:20:21 -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 Wed, 2004-09-08 at 06:37, Andrew Newton wrote: > It is the opinion of the co-chairs at this time (before the end of last > call) that the MARID working group has no consensus regarding the > deployment of Sender ID. This lack of consensus centers around the IPR > associated with the PRA algorithm. Since predicting deployment is a > subjective matter and not strictly a technical concern, we would like > to offer the working group a proposal for modifying Sender ID that > would take the issue of deployment out of the hands of the IETF and > place it in the hands of the ultimate decision-makers, the systems and > network administrators of the Internet. We feel that this is where > decisions of deployment should really be made. > > It is also the opinion of the co-chairs that many in the working group > are willing to deploy MAIL FROM checking as specified in > draft-mengwong-spf. Therefore, we ask for consideration of the > following proposal: > > The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > ver-minor = 1*DIGIT > ver-scope = "pra" / "mailfrom" / name > name = alpha *( alpha / digit / "-" / "_" / "." ) > > And the following stipulations: > > 1) "mailfrom" checking will be defined in a new draft > 2) multiple records are allowed > 3) a scope (e.g. "pra") can only appear in one record of one type for > validity purposes > > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? Checking RFC2821 MAIL FROM offers more value than did checking the PRA. The PRA allows spoofing the RFC2822 From anyway. The network overhead of this script is still a concern, especially as this draft allows extensions outside the standards process. Merging two mechanism will increase this overhead. There is also an issue when the list of the MTA addresses is marked as not comprehensive, which could cause this record to be exploited. This is related to the forwarding issue, also not properly addressed either. This is also where Jim Lyon expressed his opinion that anyone that employs this non-comprehensive option, perhaps in an effort to allow forwarding, will find themselves blacklisted. Both of these fundamental and serious shortcomings can be addressed by making a structural change. The mailbox domain obtained from either MAIL FROM or the PRA assumes the unverifiable integrity of the mail channel and thus are not suitable as a basis for a reputation assessment. The number of DNS lookups required to resolve the MTA to mailbox domain relationship can be confined to a single DNS lookup, if a name for the MTA is first authenticated. This resolves the network overhead issue and the problem of a non-comprehensive MTA to mailbox domain relationship, as the relationship and the MTA authentication become independent functions. An authenticated MTA name is suitable for reputation assessment, and removes the danger expressed by Jim Lyon. Those that wish to employ a restrictive relationship with their MTA and mailbox domains can easily do so without the need for the PRA algorithm. For some situations, such as for financial transactions, there may not be a desire to have messages forwarded or sent through a list server, when the message is restricted by either or both the MAIL FROM or From fields. There are also alternatives to SRS as well. Beyond the IPR, there are pressing technical issues that can be adequately rectified using this different two-step structural approach. The MTA and mailbox domain should normally be treated as a nominal relationship useful for coloring mail, where most of the compatibility issues then vanish. By declaring the MTA name as the only identity suitable for reputation assessment, this allows a lightweight scheme that can help combat Trojan proxies, and protect users from being falsely blacklisted. It also forms the basis for a simplistic means of expressing an MTA to mailbox domain relationship. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:56: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 NAA01806 for ; Wed, 8 Sep 2004 13:56: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 i88HOfs8079353; Wed, 8 Sep 2004 10:24: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 i88HOfhG079352; Wed, 8 Sep 2004 10:24: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 i88HOevE079345 for ; Wed, 8 Sep 2004 10:24:40 -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 i88HZH73024940; Wed, 8 Sep 2004 10:35:17 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i88HZGQE024936; Wed, 8 Sep 2004 10:35:16 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 8 Sep 2004 10:35:16 -0700 (PDT) From: "william(at)elan.net" To: Nate Leon cc: ietf-mxcomp@imc.org Subject: RE: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? In-Reply-To: <42FE9417C0B0374B9D4234DC867819AC0C37E7@mailserver.corp.mailfrontier.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 Wed, 8 Sep 2004, Nate Leon wrote: > Hmmm... so "64/8" would be valid ? > I'm not very comfortable with that. I'm not happy about it either and always used full cidr notaation (64.0.0.0/8) but 64/8 is unfortunetly a valid representation of cidr. I've had discussions about it before year ago in regards to ip whois and in the end a text was found from some old RFC which specified it. I'll try to find those old emails and then post to the list. I do note that since we do have classless cidr (RFC1519), old RFCs before that may not be correct. At the same time RFC1519 is not exactly great guide either as its using cisco-specific syntax. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 13:56:34 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 NAA01826 for ; Wed, 8 Sep 2004 13:56:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88HKa0c079098; Wed, 8 Sep 2004 10:20:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88HKash079097; Wed, 8 Sep 2004 10:20:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88HKZfd079081 for ; Wed, 8 Sep 2004 10:20:35 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Sep 2004 09:50:42 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i88GoZd1013271; Wed, 8 Sep 2004 09:50:35 -0700 (PDT) Received: from fenton-w2k01.cisco.com (dhcp-128-107-163-53.cisco.com [128.107.163.53]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i88GumfK006817; Wed, 8 Sep 2004 09:56:50 -0700 Message-Id: <4.3.2.7.2.20040908094911.03f57d20@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Sep 2004 09:50:29 -0700 To: Meng Weng Wong , Rand Wacker From: Jim Fenton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Cc: IETF MARID WG In-Reply-To: <20040908154529.GE23667@dumbo.pobox.com> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1094662610.767463"; x:"432000"; a:"rsa-sha1"; b:"0:584"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"bHgy5vj20A3PPkjLIp1/MnFo7EJbIHzY4tZc3zmyTM9AnQwTVjUW4CwKflOF9" "0SRUkb4tnR/cObErt5PUyxYuGUdFAnX8rDmJTvjkEcpup6H7dvWzh+r8Yff28" "odRwMApQrekn22Fr9GgDxWR9wlsUmpOmg5onwhuDA4pbkGpiA="; c:"Date: Wed, 08 Sep 2004 09:50:29 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: consensus call on pra/mailfrom deployment and=0A version" "ing/scope" IIM-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:45 AM 9/8/2004 -0400, Meng Weng Wong wrote: >Step 2: > HELO bob.mta > MAIL FROM: SUBMITTER= > RCPT TO: > DATA > Resent-From: > >At step 2, the receiver can apply spf/HELO tests (or SPF >Lite or CSV or even IP based whitelisting) to bob.mta, and >approve the forwarder based on that. > >The receiver can also apply spf/SUBMITTER tests to , >and approve the forwarder based on that. Wouldn't this require a PRA check to verify that SUBMITTER is consistent with the message headers, and wouldn't that be encumbered? -Jim From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 14:15:26 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 OAA03159 for ; Wed, 8 Sep 2004 14:15:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88HjQ7U081083; Wed, 8 Sep 2004 10:45:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88HjQG0081082; Wed, 8 Sep 2004 10:45:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88HjP7u081074 for ; Wed, 8 Sep 2004 10:45:25 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C56U8-0002yb-J5; Wed, 08 Sep 2004 13:43:56 -0400 Message-ID: <413F4530.7030606@solidmatrix.com> Date: Wed, 08 Sep 2004 13:45:20 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Tripp Cox CC: Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tripp Cox wrote: >> The question before the working group: assuming no technical errors >> with the above, is there anybody who vehemently objects with this >> proposal? > > > I see no harm in taking this opportunity to allow for future versions of > Sender-ID with additional scopes and different record formats. > I agree. Yakov P.S. Lets not forget an IANA registry for scope names. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 14:49:11 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 OAA05329 for ; Wed, 8 Sep 2004 14:49: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 i88IBf1x083199; Wed, 8 Sep 2004 11:11: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 i88IBfDg083198; Wed, 8 Sep 2004 11:11:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88IBeBk083189 for ; Wed, 8 Sep 2004 11:11:40 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C56tX-0004RP-GS for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 14:10:11 -0400 Message-ID: <413F4B57.7070108@solidmatrix.com> Date: Wed, 08 Sep 2004 14:11:35 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> <1322218026.20040908084909@brandenburg.com> <413E5598.8030009@solidmatrix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > Also, in <413E3531.7010906@solidmatrix.com> Yakov Shafranovich writes: > > >>Then according to RFC 3668 we can safely ignore the IPR claims is >>irrelevant and frivilous like it has been done before with IDN and >>IPSec. Or can we? > > > Both Margaret and Yakov suggest that "we" can ignore the MS patent. > There is clearly a risk involved for those who do, but apparently both > feel that the risk is pretty small. I specifically left it as an open question. I was purely speculating. > > Would those of you who suggest ignoring the patent please also > volunteer to pay for any and all costs associated with a (potential) > lawsuit from MS for not using their license? > > If the risks are really as small as you two suggest, surely this > wouldn't be a problem for you to do. If you are not willing to pay > such costs, why are you suggesting that people like me who write and > distribute software that would violate the patent take that risk? > I was suggesting no such thing. Rather, as IETF's history has shown it has been done before without detriment, and I was simply asking whether it is a viable option. In any case, given the chairs' statement on consensus this is irrelevant. We will not be able to reach consensus with the IPR issues anyway. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 14:53: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 OAA05621 for ; Wed, 8 Sep 2004 14:53:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88IITf2083945; Wed, 8 Sep 2004 11:18:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88IITZ4083944; Wed, 8 Sep 2004 11:18:29 -0700 (PDT) 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 i88IIRqj083933 for ; Wed, 8 Sep 2004 11:18:28 -0700 (PDT) (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 i88IIN9J065410; Wed, 8 Sep 2004 18:18:23 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 i88IINhT003838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Sep 2004 20:18:23 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i88IIM8G003837; Wed, 8 Sep 2004 20:18:22 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Wed, 8 Sep 2004 20:18:22 +0200 From: Koen Martens To: Rand Wacker Cc: Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040908181822.GD3614@metro.cx> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 08, 2004 at 08:13:20AM -0700, Rand Wacker wrote: > In particular, there is nothing in the current drafts that explain how to > modify messages or envelopes to allow forwarding/mail list/mx backup > operation...and I'm really hoping you're not suggesting we simply bring > SRS in to the fold. What is wrong with SRS? I think it's an ingenious solution that works. Ok, it mangles the MAIL FROM adresses, but these are not for users anyway but for the MTA. Furthermore, if as an administrator you can take the trouble to go through the headers and all, you can most certainly also 'unmangle' the srs address. Anyway, I've been doing srs for a while now, and I haven't got any complaints about it from those whom I forward to. Neither have I had any problems with it. Koen -- 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/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 14:55: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 OAA05736 for ; Wed, 8 Sep 2004 14:55: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 i88IKAjb084085; Wed, 8 Sep 2004 11:20:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88IKAlH084084; Wed, 8 Sep 2004 11:20:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88IK9tC084076 for ; Wed, 8 Sep 2004 11:20:10 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C571Z-00050i-Fu; Wed, 08 Sep 2004 14:18:29 -0400 Message-ID: <413F4D49.7050704@solidmatrix.com> Date: Wed, 08 Sep 2004 14:19:53 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Jim Fenton CC: Meng Weng Wong , Rand Wacker , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <4.3.2.7.2.20040908094911.03f57d20@mira-sjc5-1.cisco.com> In-Reply-To: <4.3.2.7.2.20040908094911.03f57d20@mira-sjc5-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jim Fenton wrote: > At 11:45 AM 9/8/2004 -0400, Meng Weng Wong wrote: > >> Step 2: HELO bob.mta MAIL FROM: SUBMITTER= RCPT >> TO: DATA Resent-From: >> >> At step 2, the receiver can apply spf/HELO tests (or SPF Lite or >> CSV or even IP based whitelisting) to bob.mta, and approve the >> forwarder based on that. >> >> The receiver can also apply spf/SUBMITTER tests to , and >> approve the forwarder based on that. > > > Wouldn't this require a PRA check to verify that SUBMITTER is > consistent with the message headers, and wouldn't that be encumbered? > No, SUBMITTER would be compared against the Sender-ID records directly without touching the headers. Ykaov From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 15:05: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 PAA06560 for ; Wed, 8 Sep 2004 15:05: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 i88IcTGB085941; Wed, 8 Sep 2004 11:38:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88IcT6B085940; Wed, 8 Sep 2004 11:38:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88IcSLq085934 for ; Wed, 8 Sep 2004 11:38:28 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [10.0.0.120] ([10.0.0.120]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for ietf-mxcomp@imc.org; Wed, 8 Sep 2004 11:38:32 -0700 Subject: Re: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] From: Max Kanat-Alexander To: IETF MARID WG In-Reply-To: References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> <1322218026.20040908084909@brandenburg.com> <413E5598.8030009@solidmatrix.com> Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094668711.4449.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 08 Sep 2004 11:38:31 -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 Wed, 2004-09-08 at 10:04, wayne wrote: > > In fairness, I'll point out that they have effectively > > volunteered to pay for any patent defense that is necessary, and > > perhaps can not be blamed too much for a zealous approach to > > preventing litigation expense. > > No, MS has only volunteered to pay for any patent defense filed > against them. Patent enforcement can be selective. If Patent Trolls > Inc decides to start out small to strengthen their case, they could > start by suing sourceforge or me. Nothing in the SenderID license says that > MS would come to sourceforge's or my aid. IANAL (but I was a Legal Studies major in college). However, I suspect that if anybody challenged Microsoft's patent anywhere, by suing anybody, they would be concerned as it could create precedent which invalidates their patent. Invalid patent then leaves the Exchange group open to a lawsuit from Patent Trolls Inc. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 15:36:51 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 PAA09871 for ; Wed, 8 Sep 2004 15:36:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88JCa4u090718; Wed, 8 Sep 2004 12:12:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88JCakh090717; Wed, 8 Sep 2004 12:12:36 -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 i88JCa11090711 for ; Wed, 8 Sep 2004 12:12:36 -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, 08 Sep 2004 15:12:37 -0400 id 0011B862.413F59A5.000015D8 In-Reply-To: <1094659611.4083.512.camel@hades.cambridge.redhat.com> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <1094659611.4083.512.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0A55FEF2-01CB-11D9-9A6B-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Tony Finch , IETF MARID WG From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 15:12:34 -0400 To: David Woodhouse 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 Sep 8, 2004, at 12:06 PM, David Woodhouse wrote: > A HELO scope would be useful. That is already being covered by the CSV proposals. -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 15:42:09 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 OAA05737 for ; Wed, 8 Sep 2004 14:55: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 i88ILA9w084153; Wed, 8 Sep 2004 11:21:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88ILAgc084152; Wed, 8 Sep 2004 11:21:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88IL9Lr084145 for ; Wed, 8 Sep 2004 11:21:09 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 20460 invoked from network); 8 Sep 2004 18:22:51 -0000 Received: from unknown (HELO ?192.168.254.140?) (208.198.98.24) by ns1.hoster907.com with SMTP; 8 Sep 2004 18:22:51 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <20040906193031.16757.qmail@tom.iecc.com> <16700.54574.131760.728158@giles.gnomon.org.uk> <626048219.20040907073928@brandenburg.com> <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> <1322218026.20040908084909@brandenburg.com> <413E5598.8030009@solidmatrix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Margaret Olson Subject: Re: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] Date: Wed, 8 Sep 2004 14:21:10 -0400 To: "IETF MARID WG" 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 Sep 8, 2004, at 1:04 PM, wayne wrote: > > In Margaret > Olson writes: > > >> In fairness, I'll point out that they have effectively >> volunteered to pay for any patent defense that is necessary, and >> perhaps can not be blamed too much for a zealous approach to >> preventing litigation expense. > > No, MS has only volunteered to pay for any patent defense filed > against them. Patent enforcement can be selective. If Patent Trolls > Inc decides to start out small to strengthen their case, they could > start by suing sourceforge or me. Nothing in the SenderID license > says that > MS would come to sourceforge's or my aid. This is an issue exists regardless of the IPR holder and the licensing terms, so you run the risk of a patent troll in any scenario. Spam prevention has a history of frivolous patent claims. > >> I suggest ignoring the patent. > > Also, in <413E3531.7010906@solidmatrix.com> Yakov Shafranovich > writes: > >> Then according to RFC 3668 we can safely ignore the IPR claims is >> irrelevant and frivilous like it has been done before with IDN and >> IPSec. Or can we? > > > Both Margaret and Yakov suggest that "we" can ignore the MS patent. > There is clearly a risk involved for those who do, but apparently both > feel that the risk is pretty small. > > Would those of you who suggest ignoring the patent please also > volunteer to pay for any and all costs associated with a (potential) > lawsuit from MS for not using their license? I can't speak for Yakov, but I'm suggesting that this working group ignore the IPR issue as irrelevant. You may or may not choose to ignore it for yourself. Margaret. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 15:42: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 PAA10249 for ; Wed, 8 Sep 2004 15: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 i88JK4Xg091432; Wed, 8 Sep 2004 12:20: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 i88JK48Y091431; Wed, 8 Sep 2004 12:20:04 -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 i88JK4iQ091425 for ; Wed, 8 Sep 2004 12:20:04 -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, 08 Sep 2004 15:20:07 -0400 id 0011B862.413F5B68.00001713 In-Reply-To: <200409081713.i88HDc310571@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200409081713.i88HDc310571@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <16666B20-01CC-11D9-9A6B-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 15:20:04 -0400 To: Peter Koch 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 Sep 8, 2004, at 1:13 PM, Peter Koch wrote: > does this mean the mail receiver queries for the RR(s) and selects > from what > is there if that fits its own supported set of scopes or should at the > time > of the DNS query the receiving MTA already have made its choice? If I understand your question, the intent is the former. Or to put it another way, there is one SPF/TXT query and not a scope targeted query. -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 15:59:49 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 PAA12198 for ; Wed, 8 Sep 2004 15:59:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88JLJYc091570; Wed, 8 Sep 2004 12:21:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88JLJ3b091569; Wed, 8 Sep 2004 12:21:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88JLHxA091541 for ; Wed, 8 Sep 2004 12:21:18 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C57yg-0000rF-Mj; Wed, 08 Sep 2004 15:19:35 -0400 Message-ID: <413F5B95.9070506@solidmatrix.com> Date: Wed, 08 Sep 2004 15:20:53 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Douglas Otis CC: Jim Fenton , Meng Weng Wong , Rand Wacker , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <4.3.2.7.2.20040908094911.03f57d20@mira-sjc5-1.cisco.com> <413F4D49.7050704@solidmatrix.com> <1094670923.15739.88.camel@ddev.mail-abuse.org> In-Reply-To: <1094670923.15739.88.camel@ddev.mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > On Wed, 2004-09-08 at 11:19, Yakov Shafranovich wrote: > >>Jim Fenton wrote: >> >>>At 11:45 AM 9/8/2004 -0400, Meng Weng Wong wrote: >>> >>> >>>>Step 2: HELO bob.mta MAIL FROM: SUBMITTER= RCPT >>>>TO: DATA Resent-From: >>>> >>>>At step 2, the receiver can apply spf/HELO tests (or SPF Lite or >>>>CSV or even IP based whitelisting) to bob.mta, and approve the >>>>forwarder based on that. >>>> >>>>The receiver can also apply spf/SUBMITTER tests to , and >>>>approve the forwarder based on that. >>> >>>Wouldn't this require a PRA check to verify that SUBMITTER is >>>consistent with the message headers, and wouldn't that be encumbered? >> >>No, SUBMITTER would be compared against the Sender-ID records directly >>without touching the headers. > > > This means there would be no record which identity was used to permit > the message. What an ideal way to spoof. > Let me rephrase that: SUBMITTER would be compared against the Sender-ID records directly without *examining* the headers. You can still record the result of that and the parameter in some header. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:01: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 QAA12470 for ; Wed, 8 Sep 2004 16:01:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88JFQ1k091082; Wed, 8 Sep 2004 12:15:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88JFQpk091081; Wed, 8 Sep 2004 12:15:26 -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 i88JFPSG091067 for ; Wed, 8 Sep 2004 12:15:25 -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 BA354414C4; Wed, 8 Sep 2004 12:15:23 -0700 (PDT) Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope From: Douglas Otis To: Yakov Shafranovich Cc: Jim Fenton , Meng Weng Wong , Rand Wacker , IETF MARID WG In-Reply-To: <413F4D49.7050704@solidmatrix.com> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <4.3.2.7.2.20040908094911.03f57d20@mira-sjc5-1.cisco.com> <413F4D49.7050704@solidmatrix.com> Content-Type: text/plain Message-Id: <1094670923.15739.88.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 08 Sep 2004 12:15:23 -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 Wed, 2004-09-08 at 11:19, Yakov Shafranovich wrote: > Jim Fenton wrote: > > At 11:45 AM 9/8/2004 -0400, Meng Weng Wong wrote: > > > >> Step 2: HELO bob.mta MAIL FROM: SUBMITTER= RCPT > >> TO: DATA Resent-From: > >> > >> At step 2, the receiver can apply spf/HELO tests (or SPF Lite or > >> CSV or even IP based whitelisting) to bob.mta, and approve the > >> forwarder based on that. > >> > >> The receiver can also apply spf/SUBMITTER tests to , and > >> approve the forwarder based on that. > > > > Wouldn't this require a PRA check to verify that SUBMITTER is > > consistent with the message headers, and wouldn't that be encumbered? > > No, SUBMITTER would be compared against the Sender-ID records directly > without touching the headers. This means there would be no record which identity was used to permit the message. What an ideal way to spoof. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:08:22 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 QAA13347 for ; Wed, 8 Sep 2004 16:08:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88JOuuO091778; Wed, 8 Sep 2004 12:24: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 i88JOuRu091777; Wed, 8 Sep 2004 12:24:56 -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 i88JOueR091771 for ; Wed, 8 Sep 2004 12:24:56 -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, 08 Sep 2004 15:24:59 -0400 id 0011B862.413F5C8C.000017A6 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 15:24:55 -0400 To: "IETF MARID WG" 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 Sep 8, 2004, at 1:20 PM, wayne wrote: > Are you saying that, by adding the mailfrom scope, you think that the > marid-pra I-D can/should advance? If so, I strongly disagree with > this position. Yes. And I'm confused as to why you would disagree, even if you do not intend to do PRA checking. There is no IPR issue with publishing both a PRA and MAIL FROM scope, just checking the PRA scope. So even though you have no intention to do it, why would you insist that other should not? -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:32:55 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 QAA16750 for ; Wed, 8 Sep 2004 16:32: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 i88JqmIn094256; Wed, 8 Sep 2004 12:52: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 i88Jqm9a094255; Wed, 8 Sep 2004 12:52:48 -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 i88JqmqY094249 for ; Wed, 8 Sep 2004 12:52:48 -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 019924149B; Wed, 8 Sep 2004 12:52:53 -0700 (PDT) Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope From: Douglas Otis To: Yakov Shafranovich Cc: Jim Fenton , Meng Weng Wong , Rand Wacker , IETF MARID WG In-Reply-To: <413F5B95.9070506@solidmatrix.com> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <4.3.2.7.2.20040908094911.03f57d20@mira-sjc5-1.cisco.com> <413F4D49.7050704@solidmatrix.com> <1094670923.15739.88.camel@ddev.mail-abuse.org> <413F5B95.9070506@solidmatrix.com> Content-Type: text/plain Message-Id: <1094673172.15739.107.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 08 Sep 2004 12:52:52 -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 Wed, 2004-09-08 at 12:20, Yakov Shafranovich wrote: > Douglas Otis wrote: > > On Wed, 2004-09-08 at 11:19, Yakov Shafranovich wrote: > >> Jim Fenton wrote: > >>> At 11:45 AM 9/8/2004 -0400, Meng Weng Wong wrote: > >>> > >>>> Step 2: HELO bob.mta MAIL FROM: SUBMITTER= RCPT > >>>> TO: DATA Resent-From: > >>>> > >>>> At step 2, the receiver can apply spf/HELO tests (or SPF Lite or > >>>> CSV or even IP based whitelisting) to bob.mta, and approve the > >>>> forwarder based on that. > >>>> > >>>> The receiver can also apply spf/SUBMITTER tests to , and > >>>> approve the forwarder based on that. > >>> > >>> Wouldn't this require a PRA check to verify that SUBMITTER is > >>> consistent with the message headers, and wouldn't that be encumbered? > >> > >> No, SUBMITTER would be compared against the Sender-ID records directly > >> without touching the headers. > > > > This means there would be no record which identity was used to permit > > the message. What an ideal way to spoof. > > Let me rephrase that: SUBMITTER would be compared against the Sender-ID > records directly without *examining* the headers. > > You can still record the result of that and the parameter in some header. This undefined header will also be spoofed. Are you suggesting removal of this header, if present, and insertion of a "X-Assumed PRA" header depending upon whether the check has been made and whether the PRA selection was assumed valid? This becomes irrelevant should the MTA/Mailbox domain relationships be viewed as nominal assertions against MAIL FROM and From mailbox domains and the MTA authentication is an independent operation. Where PRA plays a role is equally accommodated by the EHLO name anyway. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:33: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 QAA16822 for ; Wed, 8 Sep 2004 16:33:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88JpCmK094142; Wed, 8 Sep 2004 12:51: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 i88JpCPq094141; Wed, 8 Sep 2004 12:51:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88JpBxj094135 for ; Wed, 8 Sep 2004 12:51:11 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-18.tower-48.messagelabs.com!1094673072!0 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 18727 invoked from network); 8 Sep 2004 19:51:13 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-18.tower-48.messagelabs.com with SMTP; 8 Sep 2004 19:51:13 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Sep 2004 20:51:13 +0100 Received: (qmail 12556 invoked from network); 7 Sep 2004 19:48:17 -0000 Received: from unknown (HELO ?10.191.100.31?) (10.191.100.31) by matt?dev.int.star.co.uk with SMTP; 7 Sep 2004 19:48:17 -0000 Date: Wed, 8 Sep 2004 20:51:12 +0100 (BST) From: Matt Sergeant X-X-Sender: matt@localhost.localdomain To: Andrew Newton cc: David Woodhouse , Tony Finch , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <0A55FEF2-01CB-11D9-9A6B-000A95B3BA44@hxr.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 Sep 2004 19:51:13.0063 (UTC) FILETIME=[31E52B70:01C495DD] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Sep 2004, Andrew Newton wrote: > On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote: > > > A HELO scope would be useful. > > That is already being covered by the CSV proposals. Right, but with a different syntax and storage. If we could move forwards now with a unified syntax and storage that would be useful. Matt.x ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:38: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 QAA17818 for ; Wed, 8 Sep 2004 16:38:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88K24Zu094989; Wed, 8 Sep 2004 13:02: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 i88K24C0094988; Wed, 8 Sep 2004 13:02:04 -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 i88K23HA094982 for ; Wed, 8 Sep 2004 13:02:04 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 9AEF426C090; Wed, 8 Sep 2004 22:02:07 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 171AC26C070; Wed, 8 Sep 2004 22:01:57 +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 i88K1um7972499; Wed, 8 Sep 2004 22:01:57 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id E4CA0FACC; Wed, 8 Sep 2004 22:01:56 +0200 (CEST) Date: Wed, 8 Sep 2004 22:01:56 +0200 From: Stephane Bortzmeyer To: Tony Finch Cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040908200156.GB25754@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Sep 08, 2004 at 03:37:52PM +0100, Tony Finch wrote a message of 26 lines which said: > We can't use either pra or mailfrom because they break forwarding. Forwarding can be "repaired" with things like SUBMITTER or SRS (I prefer SUBMITTER). SPF-classic breaks forwarding but SenderID may be changed to repair it. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:40: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 QAA18242 for ; Wed, 8 Sep 2004 16:40: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 i88K2eS9095017; Wed, 8 Sep 2004 13:02:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88K2e0M095016; Wed, 8 Sep 2004 13:02:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88K2eia095009 for ; Wed, 8 Sep 2004 13:02:40 -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, 08 Sep 2004 16:02:42 -0400 id 0011B863.413F6563.00001DFA In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0819304F-01D2-11D9-9A6B-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 16:02:37 -0400 To: Matt Sergeant 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 Sep 8, 2004, at 3:51 PM, Matt Sergeant wrote: > Right, but with a different syntax and storage. If we could move > forwards > now with a unified syntax and storage that would be useful. This working group has already been through this and concluded that CSV was sufficiently different enough in its intentions and tact that it should not share the same DNS mechanism. -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:41:04 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 QAA18416 for ; Wed, 8 Sep 2004 16:41: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 i88K10F9094891; Wed, 8 Sep 2004 13:01:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88K10ro094890; Wed, 8 Sep 2004 13:01:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88K0xDo094874 for ; Wed, 8 Sep 2004 13:01:00 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C58bN-0003j5-9p; Wed, 08 Sep 2004 15:59:33 -0400 Message-ID: <413F64F8.9060804@solidmatrix.com> Date: Wed, 08 Sep 2004 16:00:56 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Douglas Otis CC: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <4.3.2.7.2.20040908094911.03f57d20@mira-sjc5-1.cisco.com> <413F4D49.7050704@solidmatrix.com> <1094670923.15739.88.camel@ddev.mail-abuse.org> <413F5B95.9070506@solidmatrix.com> <1094673172.15739.107.camel@ddev.mail-abuse.org> In-Reply-To: <1094673172.15739.107.camel@ddev.mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > This becomes irrelevant should the MTA/Mailbox domain relationships be > viewed as nominal assertions against MAIL FROM and From mailbox domains > and the MTA authentication is an independent operation. Where PRA plays > a role is equally accommodated by the EHLO name anyway. > Hmm. The original intent of all of these before phishing and 2822 headers got thrown in was to verify the parameters of the SMTP transaction. With the variant scopes we can still do that with ability to check MAIL FROM via mailfrom scope, and EHLO if CSV is intergrated into the main record format. As for PRA, I think I finally understand your point. The PRA and SUBMITTER invent a new identity, that of the original agent that submitted the message, akin to the "Sender" header in 2822. I think what you are trying to say is that there is no need to resort to those methods, which are less reliable, when 2821 information is available. Is that correct? If so, does that mean that this entire set of proposals is not useful for stopping phishing in any way? Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:43: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 QAA18854 for ; Wed, 8 Sep 2004 16:43:45 -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 i88K4Cwl095163; Wed, 8 Sep 2004 13:04: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 i88K4CFQ095162; Wed, 8 Sep 2004 13:04:12 -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 i88K4BCx095155 for ; Wed, 8 Sep 2004 13:04:12 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id E5A9B26C070; Wed, 8 Sep 2004 22:04:15 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 4AA5626C080; Wed, 8 Sep 2004 22:04:14 +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 i88K4Em7973729; Wed, 8 Sep 2004 22:04:14 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 1E82CFACC; Wed, 8 Sep 2004 22:04:14 +0200 (CEST) Date: Wed, 8 Sep 2004 22:04:14 +0200 From: Stephane Bortzmeyer To: Andrew Newton Cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040908200414.GC25754@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <1094659611.4083.512.camel@hades.cambridge.redhat.com> <0A55FEF2-01CB-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A55FEF2-01CB-11D9-9A6B-000A95B3BA44@hxr.us> 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, Sep 08, 2004 at 03:12:34PM -0400, Andrew Newton wrote a message of 9 lines which said: > >A HELO scope would be useful. > > That is already being covered by the CSV proposals. The CSV proposal is a completely separated one, with a different set of concepts and a different vocabulary. I would accept HELO checking if it were done in the same framework ("Unified SPF") and with the same record format so I support the idea of adding one more scope. -- Three identities to check for One record format to bind them all From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:45: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 QAA19074 for ; Wed, 8 Sep 2004 16:45:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88K0k2Z094859; Wed, 8 Sep 2004 13:00: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 i88K0kWi094858; Wed, 8 Sep 2004 13:00:46 -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 i88K0jsu094852 for ; Wed, 8 Sep 2004 13:00:46 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id AF8C226C08E; Wed, 8 Sep 2004 22:00:49 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 1BC2A26C080; Wed, 8 Sep 2004 22:00:39 +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 i88K0dm7975285; Wed, 8 Sep 2004 22:00:39 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id E9D06FACC; Wed, 8 Sep 2004 22:00:38 +0200 (CEST) Date: Wed, 8 Sep 2004 22:00:38 +0200 From: Stephane Bortzmeyer To: Andrew Newton Cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040908200038.GA25754@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> 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, Sep 08, 2004 at 09:37:18AM -0400, Andrew Newton wrote a message of 36 lines which said: > ver-scope = "pra" / "mailfrom" / name ... > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? Basically, you suggest to move to "Unified SPF" where the same record format is used for testing the various identities. I fully agree, and it pushes asides the IPR problem since PRA would become optional. But: 1) It cannot be done by a small patch in the drafts. It changes seveal things in -submitter and in -core. To me, your proposal (which I find perfect) requires dropping the current drafts and starting again with new drafts. 2) There are other scopes than mailfrom and pra (helo is an obvious one) and we should either mention them or allow for additional scopes. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:52: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 QAA19889 for ; Wed, 8 Sep 2004 16:52:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88K8NCX095562; Wed, 8 Sep 2004 13:08:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88K8Nl3095561; Wed, 8 Sep 2004 13:08:23 -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 i88K8MGE095543 for ; Wed, 8 Sep 2004 13:08:23 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 697B026C080 for ; Wed, 8 Sep 2004 22:08:26 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id BC5A226C070 for ; Wed, 8 Sep 2004 22:08:24 +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 i88K8Om7980057 for ; Wed, 8 Sep 2004 22:08:24 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 9B201FACC; Wed, 8 Sep 2004 22:08:24 +0200 (CEST) Date: Wed, 8 Sep 2004 22:08:24 +0200 From: Stephane Bortzmeyer To: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040908200824.GD25754@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Sep 08, 2004 at 12:20:42PM -0500, wayne wrote a message of 54 lines which said: > Are you saying that, by adding the mailfrom scope, you think that the > marid-pra I-D can/should advance? If so, I strongly disagree with > this position. It can advance at a different pace. For instance, -core, -protocol and -mailfrom may be published on the Standards Track while -pra is published as Experimental and may be "upgraded" later if the frivolous Microsoft patent is invalidated. As long as it is reasonably easy to drop -pra support, I agree with the proposal. Crypto software use a similar technique when some algorithms are patented. They can even be implemented in a separate shared library, may be published in a different archive ("non-free" for Debian). > 1) I really doubt that we will be able to gain any sort of consensus > on the support of 2821.MAILFROM in the time remaining in the > current last call. I agree. We should restart the process. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 16:54: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 QAA20057 for ; Wed, 8 Sep 2004 16:54: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 i88KCRqT095886; Wed, 8 Sep 2004 13:12:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88KCRlh095885; Wed, 8 Sep 2004 13:12:27 -0700 (PDT) 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 i88KCQ2u095878 for ; Wed, 8 Sep 2004 13:12:26 -0700 (PDT) (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 i88KCPFk070125 for ; Wed, 8 Sep 2004 20:12:25 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 i88KCPhT004338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Sep 2004 22:12:25 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i88KCPod004337 for ietf-mxcomp@imc.org; Wed, 8 Sep 2004 22:12:25 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Wed, 8 Sep 2004 22:12:25 +0200 From: gmc@metro.cx To: IETF MARID WG Subject: Re: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] Message-ID: <20040908201225.GN3614@metro.cx> References: <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> <1322218026.20040908084909@brandenburg.com> <413E5598.8030009@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 08, 2004 at 12:04:48PM -0500, wayne wrote: > > Then according to RFC 3668 we can safely ignore the IPR claims is > > irrelevant and frivilous like it has been done before with IDN and > > IPSec. Or can we? > > > Both Margaret and Yakov suggest that "we" can ignore the MS patent. > There is clearly a risk involved for those who do, but apparently both > feel that the risk is pretty small. > > > Would those of you who suggest ignoring the patent please also > volunteer to pay for any and all costs associated with a (potential) > lawsuit from MS for not using their license? > > If the risks are really as small as you two suggest, surely this > wouldn't be a problem for you to do. If you are not willing to pay > such costs, why are you suggesting that people like me who write and > distribute software that would violate the patent take that risk? I, for one, am not prepared to ignore the patent claim. Doing so would be naive and irrational. It would be irrational to ignore microsoft's past and go on like nothing ever happened. The patent claim is potentially dangerous, and ignoring it will not make it any less so. Koen Martens -- 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/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 17:01: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 RAA20707 for ; Wed, 8 Sep 2004 17:01: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 i88KCuUw095949; Wed, 8 Sep 2004 13:12: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 i88KCuQH095948; Wed, 8 Sep 2004 13:12:56 -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 i88KCt5f095933 for ; Wed, 8 Sep 2004 13:12:55 -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 1C58oK-0002Ix-Eo for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 15:12:59 -0500 To: "IETF MARID WG" References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <1094659611.4083.512.camel@hades.cambridge.redhat.com> <0A55FEF2-01CB-11D9-9A6B-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 08 Sep 2004 15:12:56 -0500 In-Reply-To: <0A55FEF2-01CB-11D9-9A6B-000A95B3BA44@hxr.us> (Andrew Newton's message of "Wed, 8 Sep 2004 15:12:34 -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: consensus call on pra/mailfrom deployment and versioning/scope 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.6 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 <0A55FEF2-01CB-11D9-9A6B-000A95B3BA44@hxr.us> Andrew Newton writes: > On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote: > >> A HELO scope would be useful. > > That is already being covered by the CSV proposals. I'm confident that Doug Otis and/or Dave Crocker will be quite willing to explain in elaborate detail how CSV differs from SPF/HELO. I do not see any reason not to support both and let the market decide. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 17:08: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 RAA21232 for ; Wed, 8 Sep 2004 17:08: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 i88KLowr096690; Wed, 8 Sep 2004 13:21:50 -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 i88KLoIF096689; Wed, 8 Sep 2004 13:21:50 -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 i88KLoxK096677 for ; Wed, 8 Sep 2004 13:21:50 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id CD79440D8 for ; Wed, 8 Sep 2004 13:21:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200409062234.25224.davidb@verisignlabs.com> References: <200409051824.i85IOOg02258@grimsvotn.TechFak.Uni-Bielefeld.DE> <200409062234.25224.davidb@verisignlabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: consensus call of RR prefix Date: Wed, 8 Sep 2004 13:21:49 -0700 To: IETF MARID WG 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 Sunday 05 September 2004 5:01 pm, Mark Lentczner wrote: > Usually, the use of the wild-card record is to say "-all" for anything > in a subdomain, and hence this record is would not be the same as the > domain's record: > > with prefix: > _prefix.example.com IN SPF2 "spf2.0/pra +mx +a -all" > *.example.com IN SPF2 "spf2.0/pra -all" > > without prefix: > example.com IN SPF2 "spf2.0/pra +mx +a -all" > *.example.com IN SPF2 "spf2.0/pra -all" On Sep 6, 2004, at 7:34 PM, David Blacka wrote: > This is not a valid use of DNS wildcards, assuming I understand the > problem > you are trying to solve. I'm not sure what you mean by 'valid' here -- certainly the domain file is legal and works. > In your example, "*.example.com IN SPF2 "spf2.0/pra -all", would only > match > names in example.com that do not exist (actually, the matching > behavior is a > bit more subtle that that). But, as has been pointed out on this list > more > than once, saying "-all" for non-existent names is unnecessary. The use of the wildcard with -all is an attempt to catch all e-mail which someone might send with forged malicious intermediate names: joe@random-host.example.com It has been claimed that MTA software is generally configured to reject e-mail that comes from a domain that doesn't exist. While this is true at my site, I have seen no stats to back the claim up. Unless the numbers were very high (>95%), I'm not sure relying on other people's MTAs to catch this for one's domain is a good idea. Nonetheless, many sites have wildcard MX records so that they can catch mail sent to any address. This means that they want to receive mail, not matter how it is addressed within their domain, but they don't authorize sending with such addresses. In theses cases, all domains exist (due to the wildcard MX record), and so other people's MTAs won't reject based on domain non-existance. > What I think you are really after is to put a "-all" SPF2 record for > every > (other) existing A, AAAA, and MX record. There is no convenient DNS > construct for this behavior. One needs to do this as well. - Mark From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 17:14: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 RAA21919 for ; Wed, 8 Sep 2004 17:14: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 i88KXT1C097607; Wed, 8 Sep 2004 13:33:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88KXTt0097606; Wed, 8 Sep 2004 13:33:29 -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 i88KXTxe097594 for ; Wed, 8 Sep 2004 13:33:29 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 7143140D8 for ; Wed, 8 Sep 2004 13:33:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <56E4ED0E-01D6-11D9-BB96-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: TECH-OMISSION (-protocol): Partial IPs with CIDRs allowed? Date: Wed, 8 Sep 2004 13:33:27 -0700 To: IETF MARID WG 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 For the record, I don't think 1.2.3/24 is or should be legal. Thanks to the reference to RFC 3513, Section 2.2, this sort of thing is clearly not legal for ip6 networks (see the ABNF production for ip6-network in the protocol draft.) If someone can supply me an equivalent reference for the ip4 notation, I'd be happy to include it. I also don't think "ipv4:" should be a synonym for "ip4:". Note, that since the standard is built on RFC 2234 for syntax definitions, all keywords are case independent: "IP4:" is a synonym for "ip4:". In general, I subscribe to the philosophy that the spec should be clear as to what is legal, and implementations should be ruthless in rejecting things that are malformed, misspelt, or otherwise broken. Just because the underlying representation is text doesn't mean that it isn't a protocol. I also don't believe that the spec has to constantly say "We really mean it here, in this case you MUST MUST MUST follow the syntax." That sort of thing should be implicit for the whole spec and if you start putting them in, then people feel free to play loosey-goosey with the rest. That said, Wayne, if there are areas of protocol that are actually too liberal in what they accept, I would be happy to tighten them up. - Mark From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 17:16:55 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 RAA22115 for ; Wed, 8 Sep 2004 17:16:54 -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 i88KXgSw097632; Wed, 8 Sep 2004 13:33:42 -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 i88KXgSm097631; Wed, 8 Sep 2004 13:33:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88KXftP097625 for ; Wed, 8 Sep 2004 13:33:41 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 16:38:45 -0400 Received: from ([65.10.113.247]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 846323578; Wed, 08 Sep 2004 16:38:44 -0400 Message-ID: <020e01c495e2$c0195650$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MARID WG" , "Andrew Newton" References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 16:30:38 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Hi, If I understand all this, I would agree this is the right approach. This will allow for the separation, breakdown, usage and implementation of one or more EPV (End Point Validation) techniques open, patented or otherwise. I would recommend the following to help faciliate your proposal: 1) Refine RFC 2821 to eliminate conflicts and ambiguities. 1a) What are required and enforcable entities? 2) Refine RFC 2822 to eliminate conflicts and ambiguities. 1a) What are required and enforceable entities? More so with #1, I don't believe good progress will be made until RFC 2821 is cleaned up. This could be in the same vain as it was done with RFC2476 for SMTP of applying a more strict transaction process , but it need not go that far. With #2, clearing up the ambiguities, like with the Resent-To, etc. However, I don't see this a major part since it is not an established requirement unlike the issues in 2821 with HELO and MAIL FROM. In short, the new draft need to improves upon the hosting requirements and once this is done, I believe MARID will become more stronger as a plausible technology to implement. It will also open the door for new possibilities as well. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Andrew Newton" To: "IETF MARID WG" Sent: Wednesday, September 08, 2004 9:37 AM Subject: consensus call on pra/mailfrom deployment and versioning/scope > > It is the opinion of the co-chairs at this time (before the end of last > call) that the MARID working group has no consensus regarding the > deployment of Sender ID. This lack of consensus centers around the IPR > associated with the PRA algorithm. Since predicting deployment is a > subjective matter and not strictly a technical concern, we would like > to offer the working group a proposal for modifying Sender ID that > would take the issue of deployment out of the hands of the IETF and > place it in the hands of the ultimate decision-makers, the systems and > network administrators of the Internet. We feel that this is where > decisions of deployment should really be made. > > It is also the opinion of the co-chairs that many in the working group > are willing to deploy MAIL FROM checking as specified in > draft-mengwong-spf. Therefore, we ask for consideration of the > following proposal: > > The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > ver-minor = 1*DIGIT > ver-scope = "pra" / "mailfrom" / name > name = alpha *( alpha / digit / "-" / "_" / "." ) > > And the following stipulations: > > 1) "mailfrom" checking will be defined in a new draft > 2) multiple records are allowed > 3) a scope (e.g. "pra") can only appear in one record of one type for > validity purposes > > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? > > -andy > > From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 17:41: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 RAA24030 for ; Wed, 8 Sep 2004 17:41:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Kte1a099734; Wed, 8 Sep 2004 13:55:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88KteKq099733; Wed, 8 Sep 2004 13:55:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88KtdSv099727 for ; Wed, 8 Sep 2004 13:55:39 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C59SI-0006tF-4J; Wed, 08 Sep 2004 16:54:14 -0400 Message-ID: <413F71C9.4020700@solidmatrix.com> Date: Wed, 08 Sep 2004 16:55:37 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <20040908200038.GA25754@nic.fr> In-Reply-To: <20040908200038.GA25754@nic.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > On Wed, Sep 08, 2004 at 09:37:18AM -0400, > Andrew Newton wrote > a message of 36 lines which said: > > >> ver-scope = "pra" / "mailfrom" / name > > ... > >>The question before the working group: assuming no technical errors >>with the above, is there anybody who vehemently objects with this >>proposal? > > > Basically, you suggest to move to "Unified SPF" where the same record > format is used for testing the various identities. I fully agree, and > it pushes asides the IPR problem since PRA would become optional. But: > > 1) It cannot be done by a small patch in the drafts. It changes seveal > things in -submitter and in -core. To me, your proposal (which I find > perfect) requires dropping the current drafts and starting again with > new drafts. > > 2) There are other scopes than mailfrom and pra (helo is an obvious > one) and we should either mention them or allow for additional scopes. > Sounds like the last call might have to be extended or canceled. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 17:43: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 RAA24327 for ; Wed, 8 Sep 2004 17:43:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88L0txr000232; Wed, 8 Sep 2004 14:00:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88L0t9G000231; Wed, 8 Sep 2004 14:00:55 -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 i88L0sFn000225 for ; Wed, 8 Sep 2004 14:00:55 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id BE52C26C070; Wed, 8 Sep 2004 23:00:58 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 5BE8926C080; Wed, 8 Sep 2004 23:00:48 +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 i88L0mm7986440; Wed, 8 Sep 2004 23:00:48 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 3C471FACC; Wed, 8 Sep 2004 23:00:48 +0200 (CEST) Date: Wed, 8 Sep 2004 23:00:48 +0200 From: Stephane Bortzmeyer To: Yakov Shafranovich Cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040908210048.GA31115@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <20040908200038.GA25754@nic.fr> <413F71C9.4020700@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413F71C9.4020700@solidmatrix.com> 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, Sep 08, 2004 at 04:55:37PM -0400, Yakov Shafranovich wrote a message of 32 lines which said: > Sounds like the last call might have to be extended or canceled. Certainly yes. Work for IETF 61 in Washington. Moving to an unified model also allows to reexamine previous decisions (such as the one against CSV, which could be reintegrated with a HELO scope). From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 17:50: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 RAA25052 for ; Wed, 8 Sep 2004 17:50: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 i88L72fZ000688; Wed, 8 Sep 2004 14:07: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 i88L720M000687; Wed, 8 Sep 2004 14:07:02 -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 i88L71pj000680 for ; Wed, 8 Sep 2004 14:07:01 -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 1C59ea-0002zs-Ss for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 16:07:05 -0500 To: "IETF MARID WG" References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 08 Sep 2004 16:06:56 -0500 In-Reply-To: (Andrew Newton's message of "Wed, 8 Sep 2004 15:24:55 -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: consensus call on pra/mailfrom deployment and versioning/scope 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.6 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 Andrew Newton writes: > On Sep 8, 2004, at 1:20 PM, wayne wrote: > >> Are you saying that, by adding the mailfrom scope, you think that the >> marid-pra I-D can/should advance? If so, I strongly disagree with >> this position. > > Yes. And I'm confused as to why you would disagree, even if you do > not intend to do PRA checking. There is no IPR issue with publishing > both a PRA and MAIL FROM scope, just checking the PRA scope. So even > though you have no intention to do it, why would you insist that other > should not? Publishing SPF records with PRA information has never been a problem for me (and I think for most others). The problem is the PRA can not be implemented in most F/OSS MTAs and spam filters. The PRA is an 2822 identity, which does not cover the same problem space as the 2821.MAILFROM. The suggestion of using 2821.MAILFROM to get around the SenderID patent mess is like suggesting using DES to get around the RSA patent mess. Yeah, they vaguely cover the same general area, but really, they are quite different. If you could come up with a proposal that has broad consensus that covers the 2822 identities, I could see letting both that proposal and the PRA going forward. However, I don't see any such proposal. The only two proposals besides the PRA in the area of 2822 that I can recall are the fetchmail algorithm and and my marid-schlitt-spf-fromhdr. The fetchmail algorithm use the Return-Path: header as its primary choice, so it really isn't any more of a 2822 identity than the PRA is a 2821 identity due to SUBMITTER. The SPF/FROMHDR proposal has not been discussed much at all, due largely to respect the wishes of the co-chairs not to muddle the current set of I-Ds. I can see advancing marid-core and marid-protocol. I can also see continuing work on the 2821 identities. I can even see taking another stab at the 2822 identities. I can't see advancing marid-pra. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 17:51: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 RAA25115 for ; Wed, 8 Sep 2004 17:51: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 i88LACVs000966; Wed, 8 Sep 2004 14:10: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 i88LACYC000965; Wed, 8 Sep 2004 14:10:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88LAANp000952 for ; Wed, 8 Sep 2004 14:10:11 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-9.tower-48.messagelabs.com!1094677810!4858429 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 26087 invoked from network); 8 Sep 2004 21:10:11 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-9.tower-48.messagelabs.com with SMTP; 8 Sep 2004 21:10:11 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Sep 2004 22:10:09 +0100 Received: (qmail 12652 invoked from network); 7 Sep 2004 21:07:13 -0000 Received: from unknown (HELO ?10.191.100.31?) (10.191.100.31) by matt?dev.int.star.co.uk with SMTP; 7 Sep 2004 21:07:13 -0000 Date: Wed, 8 Sep 2004 22:10:09 +0100 (BST) From: Matt Sergeant X-X-Sender: matt@localhost.localdomain To: Yakov Shafranovich cc: Douglas Otis , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <413F64F8.9060804@solidmatrix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 Sep 2004 21:10:09.0779 (UTC) FILETIME=[3932AC30:01C495E8] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Sep 2004, Yakov Shafranovich wrote: > If so, does that mean that this entire set of proposals is not useful > for stopping phishing in any way? None of these proposals will "stop" phishing in any way. No more so than "Are you sure you want to open executables" dialog boxes will stop viruses. And yes, I include the future time when we have working "reputation" services. Though I can say, if you want to reduce phishing, don't try and base it on updated MUAs. Focus on the MTA. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 17:53:09 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 RAA25262 for ; Wed, 8 Sep 2004 17:53: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 i88LCgom001222; Wed, 8 Sep 2004 14:12:42 -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 i88LCgPK001221; Wed, 8 Sep 2004 14:12:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88LCSXr001196 for ; Wed, 8 Sep 2004 14:12:29 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-18.tower-48.messagelabs.com!1094677950!0 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 26331 invoked from network); 8 Sep 2004 21:12:31 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-18.tower-48.messagelabs.com with SMTP; 8 Sep 2004 21:12:31 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Sep 2004 22:12:31 +0100 Received: (qmail 12662 invoked from network); 7 Sep 2004 21:09:35 -0000 Received: from unknown (HELO ?10.191.100.31?) (10.191.100.31) by matt?dev.int.star.co.uk with SMTP; 7 Sep 2004 21:09:35 -0000 Date: Wed, 8 Sep 2004 22:12:31 +0100 (BST) From: Matt Sergeant X-X-Sender: matt@localhost.localdomain To: Stephane Bortzmeyer cc: Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <20040908200038.GA25754@nic.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 Sep 2004 21:12:31.0125 (UTC) FILETIME=[8D725C50:01C495E8] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Sep 2004, Stephane Bortzmeyer wrote: > 1) It cannot be done by a small patch in the drafts. It changes seveal > things in -submitter and in -core. To me, your proposal (which I find > perfect) requires dropping the current drafts and starting again with > new drafts. I hope you're kidding. We can change the current drafts without scrapping how far we've come. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 18:03: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 SAA25731 for ; Wed, 8 Sep 2004 18:03: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 i88LM9dJ001911; Wed, 8 Sep 2004 14:22: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 i88LM99j001910; Wed, 8 Sep 2004 14:22:09 -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 i88LM8tt001902 for ; Wed, 8 Sep 2004 14:22:08 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 8646B26C089; Wed, 8 Sep 2004 23:22:12 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 2992526C070; Wed, 8 Sep 2004 23:22:02 +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 i88LM1m7995226; Wed, 8 Sep 2004 23:22:01 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id D4451FACC; Wed, 8 Sep 2004 23:22:01 +0200 (CEST) Date: Wed, 8 Sep 2004 23:22:01 +0200 From: Stephane Bortzmeyer To: Matt Sergeant Cc: Stephane Bortzmeyer , Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040908212201.GB910@nic.fr> References: <20040908200038.GA25754@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Sep 08, 2004 at 10:12:31PM +0100, Matt Sergeant wrote a message of 17 lines which said: > I hope you're kidding. No. > We can change the current drafts without scrapping how far we've > come. I did not suggest to start from zero. I just said that the new scheme cannot be considered a minor patch so we have to cancel the last call, to write new drafts (try to edit everything about PRA from -submitter, it is not as obvious as it may seems) and to discuss them, all of this before Washington. From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 18:06: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 SAA26120 for ; Wed, 8 Sep 2004 18:06: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 i88LPV0t002142; Wed, 8 Sep 2004 14:25:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88LPVR0002141; Wed, 8 Sep 2004 14:25:31 -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 i88LPUse002128 for ; Wed, 8 Sep 2004 14:25:30 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 6719140D8 for ; Wed, 8 Sep 2004 14:25:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9BC4046C-01DD-11D9-BB96-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 14:25:29 -0700 To: IETF MARID WG 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 Several items: -= 1 =- Someone asked for an example of a single record that works for both scopes: spf2.0/pra,mailfrom +mx -all -= 2 =- Yes, scopes would need an IANA registry. I would suggest that it needs to be limited in the greatest possible way (like amended only by a working group draft - anyone know language for this? an existing example of such a registry? -- e-mail me off-list.) -= 3 =- Please note that the Classic SPF's use of the HELO/EHLO domain when the reverse-path is null does not constitute a check of the HELO scope (such as done by SPF/HELO or CSV.) It is constructing what the return path should be even though the sending MTA has omitted it ("Mail From <>") to break possible mail loops. It is still checking the envelope concept of "Mail From". It is not making any assertions about the HELO/EHLO domain as used by a SMTP client. -= 4 =- I would not support a HELO scope for the same reasons mentioned by others. In particular, 1) CSV is this group's next agenda item, 2) The full syntax of SPF records is totally unwarranted for HELO checks (you only need "+a -all" and "-all".) 3) One generally never publishes records about HELO at the same domain name as MAIL FROM or PRA. Hence they'd never share a record. -= 5 =- As per my discussion in prior messages, the scope macro doesn't buy much. I am not in favor of it, though not strongly. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 18:30: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 SAA28796 for ; Wed, 8 Sep 2004 18:30:32 -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 i88Ll5fh004527; Wed, 8 Sep 2004 14:47: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 i88Ll5jT004526; Wed, 8 Sep 2004 14:47:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Ll5cK004513 for ; Wed, 8 Sep 2004 14:47:05 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 08 Sep 2004 17:47:02 -0400 id 0039C9EB.413F7DD6.000017CD From: David Blacka Organization: VeriSign, Inc. To: Mark Lentczner Subject: Re: consensus call of RR prefix Date: Wed, 8 Sep 2004 17:46:22 -0400 User-Agent: KMail/1.7 References: <200409051824.i85IOOg02258@grimsvotn.TechFak.Uni-Bielefeld.DE> <200409062234.25224.davidb@verisignlabs.com> In-Reply-To: Cc: IETF MARID WG MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409081746.22236.davidb@verisignlabs.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday 08 September 2004 4:21 pm, Mark Lentczner wrote: > On Sunday 05 September 2004 5:01 pm, Mark Lentczner wrote: > > Usually, the use of the wild-card record is to say "-all" for anything > > in a subdomain, and hence this record is would not be the same as the > > domain's record: > > > > with prefix: > > _prefix.example.com IN SPF2 "spf2.0/pra +mx +a -all" > > *.example.com IN SPF2 "spf2.0/pra -all" > > > > without prefix: > > example.com IN SPF2 "spf2.0/pra +mx +a -all" > > *.example.com IN SPF2 "spf2.0/pra -all" > > On Sep 6, 2004, at 7:34 PM, David Blacka wrote: > > This is not a valid use of DNS wildcards, assuming I understand the > > problem > > you are trying to solve. > > I'm not sure what you mean by 'valid' here -- certainly the domain file > is legal and works. I meant that it wouldn't work as I thought you were describing it, not that it wouldn't load. > > In your example, "*.example.com IN SPF2 "spf2.0/pra -all", would only > > match > > names in example.com that do not exist (actually, the matching > > behavior is a > > bit more subtle that that). But, as has been pointed out on this list > > more > > than once, saying "-all" for non-existent names is unnecessary. > > The use of the wildcard with -all is an attempt to catch all e-mail > which someone might send with forged malicious intermediate names: > > joe@random-host.example.com > > It has been claimed that MTA software is generally configured to reject > e-mail that comes from a domain that doesn't exist. While this is true > at my site, I have seen no stats to back the claim up. Unless the > numbers were very high (>95%), I'm not sure relying on other people's > MTAs to catch this for one's domain is a good idea. Well, you are relying on them to do the Sender-ID check, right? > Nonetheless, many sites have wildcard MX records so that they can catch > mail sent to any address. This means that they want to receive mail, > not matter how it is addressed within their domain, but they don't > authorize sending with such addresses. In theses cases, all domains > exist (due to the wildcard MX record), and so other people's MTAs won't > reject based on domain non-existance. This wasn't the case that you were describing (as I read it, anyway). This is a case where a wildcard SPF2 or TXT record *would* work. > > What I think you are really after is to put a "-all" SPF2 record for > > every > > (other) existing A, AAAA, and MX record. There is no convenient DNS > > construct for this behavior. > > One needs to do this as well. You would need to put a wildcard "-all" record below each existing name in your zone as well (except delegations). Again, if I understand your problem correctly. For the record, I think that RECOMMENDING that people publish wildcard "-all" records (in the absence of a wildcard MX) is not a good idea at all. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 19:16: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 TAA01703 for ; Wed, 8 Sep 2004 19:16: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 i88MoK6Y009751; Wed, 8 Sep 2004 15:50:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88MoKxF009750; Wed, 8 Sep 2004 15:50:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88MoJxN009744 for ; Wed, 8 Sep 2004 15:50:20 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i88MoAb28148; Wed, 8 Sep 2004 15:50:11 -0700 Date: Thu, 9 Sep 2004 05:44:04 +0900 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <888421820.20040909054404@brandenburg.com> To: Tony Finch CC: Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony, TF> Will there also be a helo scope? TF> We can't use either pra or mailfrom because they break forwarding. Taking andrew's proposal as an effort to process SPF "classic" through the IETF, I suggest not trying to expand the scope or redirect it. The issue of forwarding for author-based path registration schemes, like SPF and Sender-ID, has been discussed at length. At a minimum, we need to document these impacts on usage. However there is already a deployed base of some size, for SPF, so we know that there are usage scenarios that the community find helpful. I suggest we make sure we document all this, rather than re-targeting the technical focus. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 19:24:49 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 TAA02108 for ; Wed, 8 Sep 2004 19:24:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88MtE1I009977; Wed, 8 Sep 2004 15:55: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 i88MtERs009976; Wed, 8 Sep 2004 15:55:14 -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 i88MtEGI009970 for ; Wed, 8 Sep 2004 15:55:14 -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 D40A8414C4; Wed, 8 Sep 2004 15:55:18 -0700 (PDT) Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope From: Douglas Otis To: Yakov Shafranovich Cc: IETF MARID WG In-Reply-To: <413F64F8.9060804@solidmatrix.com> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <4.3.2.7.2.20040908094911.03f57d20@mira-sjc5-1.cisco.com> <413F4D49.7050704@solidmatrix.com> <1094670923.15739.88.camel@ddev.mail-abuse.org> <413F5B95.9070506@solidmatrix.com> <1094673172.15739.107.camel@ddev.mail-abuse.org> <413F64F8.9060804@solidmatrix.com> Content-Type: text/plain Message-Id: <1094684118.15949.77.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 08 Sep 2004 15:55:18 -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 Wed, 2004-09-08 at 13:00, Yakov Shafranovich wrote: > Douglas Otis wrote: > > This becomes irrelevant should the MTA/Mailbox domain relationships be > > viewed as nominal assertions against MAIL FROM and From mailbox domains > > and the MTA authentication is an independent operation. Where PRA plays > > a role is equally accommodated by the EHLO name anyway. > > Hmm. The original intent of all of these before phishing and 2822 > headers got thrown in was to verify the parameters of the SMTP > transaction. With the variant scopes we can still do that with ability > to check MAIL FROM via mailfrom scope, and EHLO if CSV is intergrated > into the main record format. There are a few advantages this seems to miss. By using CSV as a first step, the format for describing any mailbox-domain relationship with sending MTAs requires little more than a name list. Something like: _spf._mailfrom.my-domain.com. PTR my-isp.com. _spf._mailfrom.my-domain.com. PTR my-other-isp.com. _spf._mailfrom.my-domain.com. PTR my-support.com. -or- _spf._from.my-domain.com. PTR my-isp.com. _spf._from.my-domain.com. PTR my-other-isp.com. _spf._from.my-domain.com. PTR my-support.com. I had proposed: _mp._smtp.my-domain.com. PTR my-isp.com. _mp._smtp.my-domain.com. PTR my-other-isp.com. _mp._smtp.my-domain.com. PTR my-support.com. Where an A record flags whether the list is "comprehensive" for either the MAIL FROM or the From fields. If the associated flag is not set, then the list becomes nominal information to color mail. PTR should allow name compression and fit within a single DNS lookup. This would not require any subsequent lookups to resolve whether mx001.soup.my-isp.com was a nominal source for my-domain.com as example. > As for PRA, I think I finally understand your point. The PRA and > SUBMITTER invent a new identity, that of the original agent that > submitted the message, akin to the "Sender" header in 2822. I think what > you are trying to say is that there is no need to resort to those > methods, which are less reliable, when 2821 information is available. Is > that correct? The EHLO name offers virtually the same information obtained by roving through RFC2822 headers using the PRA algorithm where the From is being over-ridden, but the certainty of this EHLO name is suitable for asserting reputation. Reputation services are not without risk and being asked to trust the integrity of the mail channel is untenable for this purpose. Having an authenticated name lowers the cost establishing a history of use, but neither SPF nor Sender-ID offers a reasonable level of assurance for the domain identified. > If so, does that mean that this entire set of proposals is not useful > for stopping phishing in any way? Sender-ID does not stop phishing any better than simply asserting the nominal source of mail and making the authenticated EHLO name visible. This two step process would obtain better consumer protections with less information exchanged by DNS and less risk with respect to compliance. CSV does not add to the SMTP overhead, nor would a name list require subsequent lookups. A sequence of lookups could comprise a sizable burden for the receiving SMTP server needed with the collapsed functions of Sender-ID and SPF, and simply invoking a timeout is not a suitable solution. A nominal mailbox-domain sending MTA list is a lightweight approach that quickly brings results closer to the goal without breaking SMTP. Don't underestimate the importance of authenticating a name suitable reputation assertions or the role EHLO can play in this effort. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 19:55: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 TAA03722 for ; Wed, 8 Sep 2004 19:55: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 i88NSlCx013112; Wed, 8 Sep 2004 16:28:47 -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 i88NSlkj013111; Wed, 8 Sep 2004 16:28:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88NSkZZ013103 for ; Wed, 8 Sep 2004 16:28:46 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C5Brr-00031f-00; Wed, 08 Sep 2004 16:28:47 -0700 To: Andrew Newton Cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> From: Daniel Quinlan Date: 08 Sep 2004 16:28:47 -0700 In-Reply-To: Andrew Newton's message of "Wed, 8 Sep 2004 09:37:18 -0400" Message-ID: Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > [...] > ver-scope = "pra" / "mailfrom" / name > [...] > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? If patent-encumbered stuff (PRA) is any part of the specification (and I see it mentioned in your proposal), then the ASF (including the SpamAssassin and JAMES projects) vehemently objects. Given that there is a lack of consensus on PRA, it seems like the best course is drop PRA entirely and allow the specification authors to revise things a bit more freely again. Daniel Quinlan V.P., Apache SpamAssassin -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 20:02: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 TAA01719 for ; Wed, 8 Sep 2004 19:16: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 i88MoJY3009742; Wed, 8 Sep 2004 15:50:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88MoJxH009741; Wed, 8 Sep 2004 15:50:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88MoJ0C009735 for ; Wed, 8 Sep 2004 15:50:19 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i88MoLb28174; Wed, 8 Sep 2004 15:50:21 -0700 Date: Thu, 9 Sep 2004 05:52:54 +0900 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <728466010.20040909055254@brandenburg.com> To: Andrew Newton CC: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew, AN> The question before the working group: assuming no technical errors AN> with the above, is there anybody who vehemently objects with this AN> proposal? once upon a time, it was suggested that proposals need to have security and operations review. all of the proposals under discussion for this space have very significant ties and sensitivities to both security and OA&M. we really do need to get those reviews, before any proposal should reasonably be run through any sort of working group last call. and the broader IETF discussions on cross-area review have stressed the need for getting such reviews long before that. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 21:02:23 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 VAA08494 for ; Wed, 8 Sep 2004 21:02:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i890L5mi016846; Wed, 8 Sep 2004 17:21: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 i890L5V3016845; Wed, 8 Sep 2004 17:21:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i890L2Cb016838 for ; Wed, 8 Sep 2004 17:21:04 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 54988 invoked from network); 9 Sep 2004 00:21:06 -0000 Received: from unknown (HELO vaio) (203.115.130.7) by relay.pair.com with SMTP; 9 Sep 2004 00:21:06 -0000 X-pair-Authenticated: 203.115.130.7 Message-Id: <4.1.20040909080331.016367f0(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 09 Sep 2004 08:32:46 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i890L4Cb016840 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I vehemently object to standardizing fragmentation of e-mail via scope, especially when one scope is proprietary one from an entity who in the past has used monopoly leverage to "embrace and extend" as a means to convert de facto standards into proprietary standards. We will end up with a fragmented internet e-mail system separated into proprietary (pra) and free software (mailfrom). I will never vote to give ammunition to any attempt to fragment the fundamental protocols of the internet into proprietary and free software camps. That is entirely against the spirit of what has made the internet successful worldwide. Do we really need another "browser wars" in e-mail? Instead I support a single DNS record which can be used by either proprietary (pra) or free software (mailfrom). If Microsoft wants to use their leverage to popularize a DNS record which can they can use in their proprietary software, which can also be used by free software, then I would fully support that. This is quite different from giving a vote of approval for Microsoft to use their leverage to "embrace and extend" the core internet. Microsoft can freely use their leverage to create a separate DNS scope without the endorsement of the community concensus, but we must not encourage that by endorsing fragmentation as a standard. Also there is no compelling technical advantage to a fragmented scope. The fact is that per-domain anti-forgery will not stop all forms of phishing or e-mail forgery, nor will it stop spam. For example, in pra, the Resent-Sender could be not forged, but the From: header could be forged. In mailfrom, the MAIL FROM: envelope could be not forged, but the From: header could be forged. These proposals can help anti-spam as an added input data regarding the source of an e-mail to feed into probability anti-spam analysis, as well perhaps others will explore different UI approaches to presenting the datum. It will require experimentation and new innovations in using this new data, so the larger risk is on fragmenting who can use which data. IMO either proposal might be quite effective at stopping phishing in some scenarios. But in no case does this potential success justify fragmenting the core internet i the process of trying to achieve some marginal improvement in e-mail so! urce authentication. Additionally there are technical advantages to not polluting the DNS with proliferation of "extend and embrace" wars on e-mail. I completely agree that getting Microsoft and other corporate players on board is very helpful, but not at the cost of the other future billions of internet users who will probably use free software (third world countries for example, such as the UN's recent efforts to increase penetration in Africa using free software). -Shelby Moore http://AccuSpam.com From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 21:10: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 VAA08822 for ; Wed, 8 Sep 2004 21:10: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 i890jiBn018453; Wed, 8 Sep 2004 17:45: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 i890jilY018452; Wed, 8 Sep 2004 17:45:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i890jhsS018446 for ; Wed, 8 Sep 2004 17:45:44 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so22250rnk for ; Wed, 08 Sep 2004 17:45:49 -0700 (PDT) Received: by 10.38.79.69 with SMTP id c69mr135663rnb; Wed, 08 Sep 2004 17:45:49 -0700 (PDT) Received: by 10.38.164.60 with HTTP; Wed, 8 Sep 2004 17:45:49 -0700 (PDT) Message-ID: <94df60cf0409081745611293e0@mail.gmail.com> Date: Wed, 8 Sep 2004 20:45:49 -0400 From: Reply-To: To: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Cc: IETF MARID WG In-Reply-To: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit As a frequent joe job and virus victim, I would be very pleased to see a proposal go forward that would allow mail-from checking. However, I have two concerns. First, it would need to be clear how multiple checks should interact when receiving sites perform multiple checks. In particular, it must be the case that a site checking both mailfrom and pra should always reject mail when mailfrom fails (even if pra passes). This might be as simple as saying if any test fails, the message is considered to have failed. Second, if we just go forward and do this with the minimum amount of change necessary to the documents, I fear we may lose an opportunity to do something better. In particular, if the idea is that sites may wish to do multiple kinds of checking, it would probably be very useful to have access to the envelope sender from within the PRA check. For example, bank.com may wish to say that if the PRA is bank.com, the envelope sender should be bank.com or outsource.com (which could then be enforced with mailfrom). This would require a new macro for the mailfrom domain (%{m}?), and would also benefit greatly from some kind of string comparison mechanism--maybe eq:string1:string2. You'd want to be able to say something like: +eq:%{d}:%{m} +eq:outsource.com:%{m} in your /pra record. It's possible to achieve something similar with the exists: mechanism, but it requires more DNS traffic. That said, since since both technical and legal concerns make the PRA not useful to me, I guess I don't really care very much about this. I'm basically happy with SPF-classic, and view your proposal as a way to continue using SPF-classic while just changing "v=spf1" to "spf2.0/mailfrom". Perhaps the point is I'd be sympathetic to anyone who asked for a little more time to explore the possibility of cross-scope mechanisms. David From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 21:17: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 VAA09151 for ; Wed, 8 Sep 2004 21:17: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 i890jnqC018462; Wed, 8 Sep 2004 17:45: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 i890jnh8018461; Wed, 8 Sep 2004 17:45:49 -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 i890jmGD018455 for ; Wed, 8 Sep 2004 17:45:48 -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 i890uP2Y029570; Wed, 8 Sep 2004 17:56:25 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i890uPQ6029567; Wed, 8 Sep 2004 17:56:25 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 8 Sep 2004 17:56:25 -0700 (PDT) From: "william(at)elan.net" To: Mark Lentczner cc: IETF MARID WG Subject: Re: consensus call of RR prefix 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, 8 Sep 2004, Mark Lentczner wrote: > The use of the wildcard with -all is an attempt to catch all e-mail > which someone might send with forged malicious intermediate names: > > joe@random-host.example.com > > It has been claimed that MTA software is generally configured to reject > e-mail that comes from a domain that doesn't exist. While this is true > at my site, I have seen no stats to back the claim up. Unless the > numbers were very high (>95%), I'm not sure relying on other people's > MTAs to catch this for one's domain is a good idea. > > Nonetheless, many sites have wildcard MX records so that they can catch > mail sent to any address. This means that they want to receive mail, > not matter how it is addressed within their domain, but they don't > authorize sending with such addresses. In theses cases, all domains > exist (due to the wildcard MX record), and so other people's MTAs won't > reject based on domain non-existance. You're making an assumption that to check if domain exist one would make an "A" or "AAAA" query on that domain and if no record is received assume that domain is invalid, that is not correct. There is important difference that should be made by implementors about dns error codes. If domain does not exist the correct error code is RCODE3 (NXDOMAIN) and in that case you can safely assume there is no such domain and reject the email. However if subdomain is defined by wildcard MX record (or any other wildcard record for that matter), the query for "A" on that domain would return RCODE 0 (NO ERROR), but there would not be an an ip address available for query in the ANSWER section, which would cause normal dns resolver to answer with its own error code (NODATA for bind-based resolver). (Actually to be more precise NODATA should be given if answer section is empty, but dns resolvers can't make this assumption because of other problems; for example if direct name does not exist but there is a CNAME or DNAME record for the same name, the answer section given by dns server should contain that - unfortunetly I sometimes see CNAMEs listed in Additional section. At the same time query for A when there is an AAAA on some servers would cause an AAAA to be addded to additional section, or possible that is the other way around...) P.S. I recently wrote my own dns resolver, so these things had to be looked up in RFCs and sometimes found just by direct testing. Also I'm of the opinion that DNS RFCs are inconsistant with some of the existing implementations (bind, djbdns, etc), the responses are different for example between various versions of bind if domain is not deligated (and when its deligated authoritive NS servers appear in different sections depending on bind dns server version). Its still amazes me that dns works so well with so much difference in responses; the credit goes to dns resolvers, that try to account for all these differences and always use Postel's principal to be very liberal in what you accept. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 21:44: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 VAA10354 for ; Wed, 8 Sep 2004 21:44: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 i891GQd1021371; Wed, 8 Sep 2004 18:16:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i891GQmX021370; Wed, 8 Sep 2004 18:16:26 -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 i891GP7i021360 for ; Wed, 8 Sep 2004 18:16:26 -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, 08 Sep 2004 21:16:28 -0400 id 0011B864.413FAEEC.00003BEC In-Reply-To: <4.1.20040909080331.016367f0(null)> References: <4.1.20040909080331.016367f0(null)> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@vpnc.org From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 21:16:23 -0400 To: AccuSpam 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 Sep 8, 2004, at 8:32 PM, AccuSpam wrote: > Instead I support a single DNS record which can be used by either > proprietary (pra) or free software (mailfrom). By this, I assume you mean a record that does not describe a scope (since what I proposed did allow one record to describe both scopes). And if so, do you actually think it is better for the receiver to have to guess the intended scope of the sender? -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 22:00: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 WAA11399 for ; Wed, 8 Sep 2004 22:00:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i891YtkM023184; Wed, 8 Sep 2004 18:34:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i891Yt4I023183; Wed, 8 Sep 2004 18:34:55 -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 i891Ysg0023177 for ; Wed, 8 Sep 2004 18:34:55 -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, 08 Sep 2004 21:34:58 -0400 id 0011B864.413FB343.00003D0B Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <724F9981-0200-11D9-9A6B-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Wed, 8 Sep 2004 21:34:52 -0400 To: "IETF MARID WG" 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 Sep 8, 2004, at 5:06 PM, wayne wrote: > Publishing SPF records with PRA information has never been a problem > for me (and I think for most others). > > The problem is the PRA can not be implemented in most F/OSS MTAs and > spam filters. Is this a double standard? You do not wish to be restricted by the encumbrances of another's license yet you wish to restrict others to the encumbrances of your software license. This compromise gives those unwilling to accept the license for PRA the ability to check MAIL FROM while allowing those willing to accept the license for PRA the ability to check the PRA. However, everybody can publish both. > The PRA is an 2822 identity, which does not cover the > same problem space as the 2821.MAILFROM. The suggestion of using > 2821.MAILFROM to get around the SenderID patent mess is like > suggesting using DES to get around the RSA patent mess. Yeah, they > vaguely cover the same general area, but really, they are quite > different. Just because an identity appears in the same RFC does not mean it has any better relationship for sender authentication. Certainly 2821.MAILFROM and 2822.From are more closely correlated than 2822.From and 2822.Cc. > If you could come up with a proposal that has broad consensus that > covers the 2822 identities, I could see letting both that proposal and > the PRA going forward. However, I don't see any such proposal. The syntax does account for future scopes. However, if we cannot advance the two scopes the people on this list have said they would be willing to deploy and instead wait around for the definition of a third scope then where do we stop, on the tenth defined scope? -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 22:41:22 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 WAA24828 for ; Wed, 8 Sep 2004 22:41:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i891soHu024768; Wed, 8 Sep 2004 18:54:50 -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 i891sokC024767; Wed, 8 Sep 2004 18:54:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i891soJ3024761 for ; Wed, 8 Sep 2004 18:54:50 -0700 (PDT) (envelope-from csm@moongroup.com) Received: from [192.168.0.10] (rdu74-170-067.nc.rr.com [24.74.170.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1.moongroup.com (Postfix) with ESMTP id 457DF1182400F; Wed, 8 Sep 2004 21:54:56 -0400 (EDT) Message-ID: <413FB7EF.3050503@moongroup.com> Date: Wed, 08 Sep 2004 21:54:55 -0400 From: Chuck Mead Organization: MoonGroup.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG , quinlan@pathname.com Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Quinlan wrote: | Andrew Newton writes: | | |>[...] |> ver-scope = "pra" / "mailfrom" / name |>[...] |>The question before the working group: assuming no technical errors |>with the above, is there anybody who vehemently objects with this |>proposal? | | | If patent-encumbered stuff (PRA) is any part of the specification (and I | see it mentioned in your proposal), then the ASF (including the | SpamAssassin and JAMES projects) vehemently objects. | | Given that there is a lack of consensus on PRA, it seems like the best | course is drop PRA entirely and allow the specification authors to | revise things a bit more freely again. | | Daniel Quinlan | V.P., Apache SpamAssassin Dan, ~ Did you see the message linked below from Stephane Bortzmeyer? It appears to me that he is suggesting that we effectively "un-link" the encumbered PRA and move ahead with -core, -protocol and -mailfrom leaving PRA in an experimental state. As Andy has made a suggestion about where we should focus since we cannot agree to use the PRA for deployment reasons it seems to me that this might be considered a reasonable suggestion. What would ASF say to this? http://www.imc.org/ietf-mxcomp/mail-archive/msg04519.html - -- csm@moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBP7fvv6Gjsf2pQ0oRAqsXAKCW5qk9nBLWVt5i58Mew4hgLHXCOwCeLYrG 4Lby2PDKqUvyAf8OoaJ4m5Q= =XHLl -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 22:51:59 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 WAA25423 for ; Wed, 8 Sep 2004 22:51: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 i892AxEU025639; Wed, 8 Sep 2004 19:10: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 i892AxND025638; Wed, 8 Sep 2004 19:10: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 i892Aw87025632 for ; Wed, 8 Sep 2004 19:10: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 i892Lbgp003002; Wed, 8 Sep 2004 19:21:37 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i892LbBG002999; Wed, 8 Sep 2004 19:21:37 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 8 Sep 2004 19:21:37 -0700 (PDT) From: "william(at)elan.net" To: Stephane Bortzmeyer cc: Matt Sergeant , Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <20040908212201.GB910@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 Wed, 8 Sep 2004, Stephane Bortzmeyer wrote: > I did not suggest to start from zero. I just said that the new scheme > cannot be considered a minor patch so we have to cancel the last call, > to write new drafts (try to edit everything about PRA from -submitter, > it is not as obvious as it may seems) and to discuss them, all of this > before Washington. I entirely agree. As soon as last call is over, I'll post the proposal (which will include modified version of some of current draft documents) that does exactly that - consistant with ideas of callerid but does not base it on requirement to use PRA algorithm and instead focuses on Submitter as appropriate identity all by itself. I'd have posted all this already but group chair is of the opinion that such proposal would distract us and parallel the proposal itself would also not receive appopriate review because of distraction of last call on other documents. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Sep 8 23:55: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 XAA28506 for ; Wed, 8 Sep 2004 23: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 i8933Dx4029877; Wed, 8 Sep 2004 20:03:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8933DOt029876; Wed, 8 Sep 2004 20:03:13 -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 i8933CBC029865 for ; Wed, 8 Sep 2004 20:03:12 -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 1C5FDG-000773-Ii for ietf-mxcomp@imc.org; Wed, 08 Sep 2004 22:03:18 -0500 To: "IETF MARID WG" References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <724F9981-0200-11D9-9A6B-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 08 Sep 2004 22:03:06 -0500 In-Reply-To: <724F9981-0200-11D9-9A6B-000A95B3BA44@hxr.us> (Andrew Newton's message of "Wed, 8 Sep 2004 21:34:52 -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: consensus call on pra/mailfrom deployment and versioning/scope 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.6 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 <724F9981-0200-11D9-9A6B-000A95B3BA44@hxr.us> Andrew Newton writes: > On Sep 8, 2004, at 5:06 PM, wayne wrote: > >> Publishing SPF records with PRA information has never been a problem >> for me (and I think for most others). >> >> The problem is the PRA can not be implemented in most F/OSS MTAs and >> spam filters. > > Is this a double standard? You do not wish to be restricted by the > encumbrances of another's license yet you wish to restrict others to > the encumbrances of your software license. I'm sorry Andy, but for the life of me, I can't figure out where this line of reasoning comes from. You made similar comments in your last point of you "on the topic of IPR" post: http://www.imc.org/ietf-mxcomp/mail-archive/msg03751.html I was going to reply/rebut this line of reasoning, but I saw that several people said basically what I was going to say. Yakov Shafranovich's reply: http://www.imc.org/ietf-mxcomp/mail-archive/msg03759.html Paul Iadonisi's reply: http://www.imc.org/ietf-mxcomp/mail-archive/msg03773.html I think we have a failure to communicate here. ;-) Even back in my original "Obstacles between us and the finish line" post ( http://www.imc.org/ietf-mxcomp/mail-archive/msg02476.html ) I said: : 4) IP licensing: I'm not dogmatic about the GPL or commercial : licenses, but there are significant MTAs and mail filters that fall : under both kinds of licenses, and several others to boot. I think : that any proposal that has incompatible IP licensing needs to be : dropped. If there was a patent holder who covered some part of the SenderID proposal and their patent license required using the GPL, I would be just as bothered. The issue isn't what individual implementers choose to license their code under, the issue is whether we should advance a standard that is incompatible with a very large percentage of current the email infrastructure. The patent license on the standard covers everyone. (For what it is worth, the vast majority of software I have written is under commercial/proprietary licenses far more restrictive than any F/OSS licence that I know of.) >> The PRA is an 2822 identity, which does not cover the >> same problem space as the 2821.MAILFROM. The suggestion of using >> 2821.MAILFROM to get around the SenderID patent mess is like >> suggesting using DES to get around the RSA patent mess. Yeah, they >> vaguely cover the same general area, but really, they are quite >> different. > > Just because an identity appears in the same RFC does not mean it has > any better relationship for sender authentication. Certainly > 2821.MAILFROM and 2822.From are more closely correlated than 2822.From > and 2822.Cc. Yes, true, I'm being far to vague when I say "2822 identities". For the most part, what people discussed as identities back in April(?) were the HELO domain, the 2821.MAILFROM, the 2822.From:, and the PTR identity (MTAmark, SS, etc.). The PRA was presented as protecting "what users see", e.g., the 2822.From:. It was correctly pointed out that users generally don't see the 2821.MAILFROM. I think there are valid reasons to consider all four of those identities because I think they all address different parts of an overall forgery problem. >> If you could come up with a proposal that has broad consensus that >> covers the 2822 identities, I could see letting both that proposal and >> the PRA going forward. However, I don't see any such proposal. > > The syntax does account for future scopes. However, if we cannot > advance the two scopes the people on this list have said they would be > willing to deploy and instead wait around for the definition of a > third scope then where do we stop, on the tenth defined scope? Well, I haven't seen many people suggest more than four identities/scopes. I've seen people advance different proposals for most of these identities. I think we can reasonably stop at one good standard for each identity. That doesn't mean that I think that the 2821.MAILFROM identity is a good subsitute for the 2822.From: identity, or vice versa. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 00:26: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 AAA00362 for ; Thu, 9 Sep 2004 00:26:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8942l8w034500; Wed, 8 Sep 2004 21:02:47 -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 i8942ldU034499; Wed, 8 Sep 2004 21:02:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8942l4N034489 for ; Wed, 8 Sep 2004 21:02:47 -0700 (PDT) (envelope-from csm@moongroup.com) Received: from [192.168.0.10] (rdu74-170-067.nc.rr.com [24.74.170.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1.moongroup.com (Postfix) with ESMTP id D0DBA1182400F for ; Thu, 9 Sep 2004 00:02:53 -0400 (EDT) Message-ID: <413FD5EC.1070804@moongroup.com> Date: Thu, 09 Sep 2004 00:02:52 -0400 From: Chuck Mead Organization: MoonGroup.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <724F9981-0200-11D9-9A6B-000A95B3BA44@hxr.us> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 wayne wrote: | If there was a patent holder who covered some part of the SenderID | proposal and their patent license required using the GPL, I would be | just as bothered. | | The issue isn't what individual implementers choose to license their | code under, the issue is whether we should advance a standard that is | incompatible with a very large percentage of current the email | infrastructure. The patent license on the standard covers everyone. This is exactly why I asked Dan Quinlan about the ASF position on this. - -- csm@moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBP9Xsv6Gjsf2pQ0oRAjs/AKCqAYDkOsrWCnYcxImQAaAmWLU+NACeJNn/ 0PqQueHHlm4CkXLfo80wvjs= =l8XN -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 02:10: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 CAA16614 for ; Thu, 9 Sep 2004 02:10:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i895iEXZ058624; Wed, 8 Sep 2004 22:44: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 i895iEXt058623; Wed, 8 Sep 2004 22:44:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i895iCjp058598 for ; Wed, 8 Sep 2004 22:44:13 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 80715 invoked from network); 9 Sep 2004 05:44:08 -0000 Received: from unknown (HELO vaio) (203.115.130.65) by relay.pair.com with SMTP; 9 Sep 2004 05:44:08 -0000 X-pair-Authenticated: 203.115.130.65 Message-Id: <4.1.20040909130446.016721f0(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 09 Sep 2004 13:55:42 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: References: <4.1.20040909080331.016367f0(null)> <4.1.20040909080331.016367f0(null)> 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: At 09:16 PM 9/8/2004 -0400, Andrew Newton wrote: > >On Sep 8, 2004, at 8:32 PM, AccuSpam wrote: >> Instead I support a single DNS record which can be used by either >> proprietary (pra) or free software (mailfrom). > >By this, I assume you mean a record that does not describe a scope >(since what I proposed did allow one record to describe both scopes). Minimally yes. IMO, the scope should be implicit from the specification. I will elaborate below. BTW, I appreciated your proposal to try to build concensus, and I hope you will consider my reasoning below. >And if so, do you actually think it is better for the receiver to have >to guess the intended scope of the sender? Yes because inherent in the design of the specification should be acknowledged the *REALITY* that the sender can not control the receiver (verifier). Even today without this standard, senders have no control over how their e-mail is filtered by receivers. IMO, that will never change, because the market will always decide that receiver has control over his/her Inbox and never give that control to the sender. Would you give control of your Inbox to your senders? A robust specification that will stand the test of time (e.g. SMTP) will acknowledge that it only specifies what the syntax data means, it can not reasonably specify all the ways that companies will try to "embrace and extend" to their competitive advantage. There is fundamental disconnect between what we think/want to happen and what we can actually insure will happen. I urge people here to think about all the ways a specification can be "misused" (...for example if only the original writers of SMTP could have predicted "misuse"...). I do not think we correct "misuse" by throwing everything we can think of into the specification. Instead, a wiser approach is to analyze priorities of what is sufficiently general and germane to the cause so as to both easily accepted into concensus and also robust to stand the test of time. For example, since we know that pra and mailfrom can still suffer from forged From: (as explained in my previous post), i.e. we do not provide a final "end all" solution, then verifiers are going to be adding value by interpreting the data provided by the specification (e.g. incorporating when the From and PRA or MAIL FROM: are different as another data in probability analysis). I think it would be folly and brittle for us to attempt to specify *ALL* the ways that the data in the DNS record can be used and interpreted, as the result set will be numerous and continually changing (improving). We might never reach concensus (even if get all tthe people here to agree but as you deploy other needs will be discovered and specification will continually be under revisement). Using this same logic, I am against a brittle and complex specification that attempts to cover too much. If we could start with something simple and core, such as specifying the approved mail servers for sending from a domain, and then we can later build new specifications on top of that basic core specification. I could ramble on about technical reasons. We need to keep this simple for the millions of owners of domains, as most senders are not forged and thus have very little incentive to deploy. Why complicate when we are not even sure what benefits we will get from the additional complexity? Is it cost effective to prioritize the needs of a few and pass the cost on to the many? Instead I support letting others build experimental complexity on top of a core unencumbered centralized standard, and then let them petition for their extensions to become part of the standard, but always only if those extensions can be used by free software also. For example, if Microsoft proposes some extension to the syntax, then they should justify how that extension can be used by all software, not just their licensees, else it should not be incorporated into an endorsed standard. It would be different if Microsoft had some proven technology that had no other alternative, but that is far from the case today. In fact, I am arguing that choosing the winning technology from unproven and incomplete set, is not the role of the standards body. And I argue that instead standardizing fragmentation is worse (or same as) no standard at all. What is wrong with reaching concensus on a DNS record that specifies the approved mail servers for sending email for a domain, then allow SPF and SenderID (and others) to go forward as experimental uses of that specification? Then we have more time to hash out real experience in the market. Since issues such as SUBMITTER for forwarding are (minimally and I would argue preferably) not part of the DNS record, then we can proceed with that resolution as an experiment and debate such orthogonal issues forward. Also we should try to form orthogonal approach to specification, so that we can accomplish highest priority goals most efficiently and so that esoteric and/or experimental features do not encumber the entire internet useage nor encumber future improvements and experience we will learn. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 02:18: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 CAA20988 for ; Thu, 9 Sep 2004 02:18:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i895uFbH064415; Wed, 8 Sep 2004 22:56:15 -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 i895uF1e064414; Wed, 8 Sep 2004 22:56:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i895uEhY064304 for ; Wed, 8 Sep 2004 22:56:14 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id C32D028A75 for ; Thu, 9 Sep 2004 07:56:12 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16366-06-2 for ; Thu, 9 Sep 2004 07:56:09 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 46811283DD; Thu, 9 Sep 2004 07:56:09 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Thu, 9 Sep 2004 07:56:09 +0200 (CEST) Message-ID: <57099.127.0.0.1.1094709369.squirrel@127.0.0.1> In-Reply-To: <20040908200824.GD25754@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <20040908200824.GD25754@nic.fr> Date: Thu, 9 Sep 2004 07:56:09 +0200 (CEST) Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Stephane Bortzmeyer a écrit : > >> 1) I really doubt that we will be able to gain any sort of consensus >> on the support of 2821.MAILFROM in the time remaining in the >> current last call. > > I agree. We should restart the process. Agreed. The remaining timeframe is much too short to figure out all these proposed changes, discuss it and reach consensus. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 02:49: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 CAA23077 for ; Thu, 9 Sep 2004 02:49: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 i896ScIp077655; Wed, 8 Sep 2004 23:28: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 i896ScGg077654; Wed, 8 Sep 2004 23:28:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i896SbOn077642 for ; Wed, 8 Sep 2004 23:28:37 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 94905 invoked from network); 9 Sep 2004 06:28:34 -0000 Received: from unknown (HELO vaio) (203.115.130.65) by relay.pair.com with SMTP; 9 Sep 2004 06:28:34 -0000 X-pair-Authenticated: 203.115.130.65 Message-Id: <4.1.20040909142901.0160d100(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 09 Sep 2004 14:40:16 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <724F9981-0200-11D9-9A6B-000A95B3BA44@hxr.us> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> 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 Sep 8, 2004, at 5:06 PM, wayne wrote: > >> Publishing SPF records with PRA information has never been a problem >> for me (and I think for most others). >> >> The problem is the PRA can not be implemented in most F/OSS MTAs and >> spam filters. > >Is this a double standard? You do not wish to be restricted by the >encumbrances of another's license yet you wish to restrict others to >the encumbrances of your software license. I fail to see what crucial information is needed in the DNS record to implement PRA that is also not needed by SPF check? Thus I fail to see why the DNS record has to specify the algorithm that will be used on the approved mail servers specified in the DNS? Do we think by inserting "pra" or "spf" we will really control what all receivers do? The main point is that the standard of what goes into the DNS record should not be supporting a proprietary standard. >This compromise gives those unwilling to accept the license for PRA the >ability to check MAIL FROM while allowing those willing to accept the >license for PRA the ability to check the PRA. However, everybody can >publish both. The compromise adds fuel to fire fragmented syntax for DNS records. In future, I envision large corporate senders only specifying "pra", because they do not have time to test with "spf", just as the situation we have now with many writing web sites for IE and not for other browsers. >> The PRA is an 2822 identity, which does not cover the >> same problem space as the 2821.MAILFROM. The suggestion of using >> 2821.MAILFROM to get around the SenderID patent mess is like >> suggesting using DES to get around the RSA patent mess. Yeah, they >> vaguely cover the same general area, but really, they are quite >> different. > >Just because an identity appears in the same RFC does not mean it has >any better relationship for sender authentication. Certainly >2821.MAILFROM and 2822.From are more closely correlated than 2822.From >and 2822.Cc. The only thing we are doing is specifying the approved mail servers. Everything else is our attempt to pick a winning technology for interpreting the data of approved mail servers. > >> If you could come up with a proposal that has broad consensus that >> covers the 2822 identities, I could see letting both that proposal and >> the PRA going forward. However, I don't see any such proposal. > >The syntax does account for future scopes. Inherently. No need to limit the scope, since you can not limit it. Once you publish the data of approved mail servers, it is open game to use the data. There will be many competing technologies and implementations, just as there are now in anti-spam, unless possibly if we hand a "silver bullet" to a monopoly to stifle that experimentation. I realize you do not want speculation on the future, and only on the merits as of today. So I will state as fact that no one can prove today that any of the methods for interpreting the approved mail servers will be better than the other. -Shelby Moore http://AccuSpam.com From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 03:19: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 DAA24508 for ; Thu, 9 Sep 2004 03:19: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 i896mb0L085553; Wed, 8 Sep 2004 23:48:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i896mbXZ085552; Wed, 8 Sep 2004 23:48:37 -0700 (PDT) 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 i896mTxP085465 for ; Wed, 8 Sep 2004 23:48:36 -0700 (PDT) (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 i896mN16005910 for ; Thu, 9 Sep 2004 06:48:24 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 i896mN8j002431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Sep 2004 08:48:23 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i896mNSK002430 for ietf-mxcomp@imc.org; Thu, 9 Sep 2004 08:48:23 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Thu, 9 Sep 2004 08:48:23 +0200 From: Koen Martens To: IETF MARID WG Subject: DEPLOY: microsoft SenderID wizard seriously flawed, unusable Message-ID: <20040909064823.GA2369@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, Microsoft has sponsored a 'wizard' to create SPF records, it's online here: http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx However, the wizard is seriously flawed. For example, it suggests you to enter ip adresses to be used with the a mechanism, producing for example: v=spf2.0/pra a:1.2.3.4 ~all this obviously should be v=spf2.0/pra ip4:1.2.3.4 ~all There are further flaws in the programming. Surely, microsoft programmers are not _this_ stupid, so I cannot understand otherwise than this is a deliberate stalling move to frustrate development of SenderID. This wizard should be taken off-line immediatelly! It should not come back online until after all the bugs have been fixed. This wizard is bad for deployment, making people publish bad records. Koen Martens -- 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/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 03:45: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 DAA25677 for ; Thu, 9 Sep 2004 03:45:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i897J4xV099771; Thu, 9 Sep 2004 00:19: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 i897J4pw099770; Thu, 9 Sep 2004 00:19:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i897J3qk099754 for ; Thu, 9 Sep 2004 00:19:03 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 11846 invoked from network); 9 Sep 2004 07:19:01 -0000 Received: from 210.5.90.74.pldt.net (HELO vaio) (210.5.90.74) by relay.pair.com with SMTP; 9 Sep 2004 07:19:01 -0000 X-pair-Authenticated: 210.5.90.74 Message-Id: <4.1.20040909152359.014ddf00(null)> Message-Id: <4.1.20040909152359.014ddf00(null)> Message-Id: <4.1.20040909152359.014ddf00(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 09 Sep 2004 15:29:10 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: DEPLOY: microsoft SenderID wizard seriously flawed, unusable In-Reply-To: <20040909064823.GA2369@metro.cx> 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: Is this perhaps the first example of "embrace and extend"?, as I have warned: http://www.imc.org/ietf-mxcomp/mail-archive/msg04536.html As I have written twice already today in spf-discuss, IMHO we need structural validation feedback written into the spec to prevent other de facto standards from monopolies: AccuSpam wrote: >Again I want to re-iterate my opinion that there needs to be some structural >enforcement/incentive for validation in the spec, else spf syntax errors >have no incentive to be fixed. (unlike for a web page) If the e-mail still gets through, and since >we know that most senders are not currently experiencing problems from >forgery, and since recipients have no incentive to notify the sender of >error, (then sender is not aware and thus) I see structural incentive is currently to encourage proliferation of >errors (or de facto extensions). For example, possibly the spec could ask errors to be reported to "postmaster@domain". At 08:48 AM 9/9/2004 +0200, you wrote: > >All, > >Microsoft has sponsored a 'wizard' to create SPF records, it's online >here: > >http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx > >However, the wizard is seriously flawed. For example, it suggests you to >enter ip adresses to be used with the a mechanism, producing for example: > >v=spf2.0/pra a:1.2.3.4 ~all > >this obviously should be > >v=spf2.0/pra ip4:1.2.3.4 ~all > >There are further flaws in the programming. Surely, microsoft >programmers are not _this_ stupid, so I cannot understand otherwise than >this is a deliberate stalling move to frustrate development of SenderID. > >This wizard should be taken off-line immediatelly! It should not come >back online until after all the bugs have been fixed. This wizard is bad >for deployment, making people publish bad records. > >Koen Martens > >-- >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/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 04:18:41 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 EAA27073 for ; Thu, 9 Sep 2004 04:18:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i897m8Ga013859; Thu, 9 Sep 2004 00:48: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 i897m8Ax013858; Thu, 9 Sep 2004 00:48: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 i897m7cu013846 for ; Thu, 9 Sep 2004 00:48: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 i897wn3g017522; Thu, 9 Sep 2004 00:58:49 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i897wnpH017519; Thu, 9 Sep 2004 00:58:49 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 9 Sep 2004 00:58:49 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <33F089AA-019C-11D9-9A6B-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 Wed, 8 Sep 2004, Andrew Newton wrote: > It is the opinion of the co-chairs at this time (before the end of last > call) that the MARID working group has no consensus regarding the > deployment of Sender ID. This lack of consensus centers around the IPR > associated with the PRA algorithm. I'm not surprised you draw this conclusion, considering posts on the list for last couple weeks.... (in fact I would have been very surprised if it was not the conclusion). > Since predicting deployment is a subjective matter and not strictly a > technical concern, we would like to offer the working group a proposal > for modifying Sender ID that would take the issue of deployment out of > the hands of the IETF IETF had real problem is that it did not wish to deal with how their protocols would be deployed. This is the main reason of failures of number of protocols that have been created and why others are less used then they could be. Certain conclusion must (and have) been drawn out of this and it would be unfortunete if we choose to go the same road again. > and place it in the hands of the ultimate decision-makers, the systems and > network administrators of the Internet. We feel that this is where > decisions of deployment should really be made. The same people are also looking for IETF for guidence. There is a reasson why we have a BCP series and why exactly is it that we have entire section of IETF is listed as "Operations and Management Area"? While I think that if the drafts are to be published as EXPERIMENTAL your statements that it would be up to the administrative to try it out, (as an experiment to see if it works and later come to IETF and tell how it is going and if more work is needed to make it standard), my understanding is that this WG is expecting to publish documents in STANDARD track. But it would not be a "Standard" if we don't expect entire worldwide community to be able to implement it. > It is also the opinion of the co-chairs that many in the working group > are willing to deploy MAIL FROM checking as specified in > draft-mengwong-spf. This is not unexpected conclusion either. However, I note that MAIL FROM is different identity which is used entirely inside SMTP stream and not usually seen by end-users. The problem here is not as much "phishing" as it is a DoS that happens when your domain is used without your permission and you get all the bounces. This group should to solve both problems, but we should not say that you are going to be able to solve either one problem or the other depending on if you're part of the open-source community or commercial product developer willing to get a supposedely "free" license. > Therefore, we ask for consideration of the following proposal: > The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne) > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > ver-minor = 1*DIGIT > ver-scope = "pra" / "mailfrom" / name > name = alpha *( alpha / digit / "-" / "_" / "." ) > > And the following stipulations: > > 1) "mailfrom" checking will be defined in a new draft > 2) multiple records are allowed > 3) a scope (e.g. "pra") can only appear in one record of one type for > validity purposes I'm going to comment in separate post on the scoping since issue now officially came up. > The question before the working group: assuming no technical errors > with the above, is there anybody who vehemently objects with this > proposal? Yes, I do. Not on technical reasons that doing scoping is bad - I would have expected scoping to be worked out by the group sooner or later anyway. But as I indicated above, I'm concerned that the IPR issue with SenderID/PRA are still unresolved and if we standartize PRA as chair is suggesting, only some be able to do this type of verification and on the other hand only some would do mail-from checking, etc. This separatism is a dangerous road to take for IETF work, we want to have one unified internet-wide standard not a standard for you and standard for me! I think we should decide on SenderID/PRA all by itself. Either we find an acceptable solution that will allow everybody to implement it or we find a replacement for it or we drop the entire concept all together and work on different identities and scopes, including envelope mail-from as is done with classic SPF. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 04:32: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 EAA27785 for ; Thu, 9 Sep 2004 04:32: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 i89858uJ020989; Thu, 9 Sep 2004 01:05: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 i89858lC020988; Thu, 9 Sep 2004 01:05:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i89857F4020962 for ; Thu, 9 Sep 2004 01:05:07 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 24317 invoked from network); 9 Sep 2004 08:05:03 -0000 Received: from 210.5.90.74.pldt.net (HELO vaio) (210.5.90.74) by relay.pair.com with SMTP; 9 Sep 2004 08:05:03 -0000 X-pair-Authenticated: 210.5.90.74 Message-Id: <4.1.20040909160745.0160e540(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 09 Sep 2004 16:16:37 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> 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: >IETF had real problem is that it did not wish to deal with how their >protocols would be deployed. This is the main reason of failures of number >of protocols that have been created and why others are less used then >they could be. Certain conclusion must (and have) been drawn out of this >and it would be unfortunete if we choose to go the same road again. IMHO, the largest deployment hurdle will be to get 63 million of domain owners (growing at 1.5 million per month) to publish and maintain a DNS record. (See my post at spf-discuss for source). Presenting these non-technical people with the complexity of choosing which scope their approved mail servers will be used and other complex options we might provide them, seems to run counter to the 80/20 rule for deployment. I simply do not see why we need scope in order to get people to publish which mail servers they approve for sending email? >This is not unexpected conclusion either. However, I note that MAIL FROM >is different identity which is used entirely inside SMTP stream and not >usually seen by end-users. The problem here is not as much "phishing" as >it is a DoS that happens when your domain is used without your permission >and you get all the bounces. Disagree. There are many possible ways verifiers might use the spf data and specification. You can not preordain those uses unless you have a crystal ball. >This group should to solve both problems, I do not think this group will solve "these problems". I think this group will define a standard for publishing the approved mail servers and then let the internet and marketplace work towards solving "these problems" and other related problems (e.g. spam). > but we should not say that you >are going to be able to solve either one problem or the other depending >on if you're part of the open-source community or commercial product >developer willing to get a supposedely "free" license. Agreed. And I think the most efficient way to reach that concensus and to not inhibit the use of the standard, is to not try to specify the scope of the algorithm (since it can be ignored any way). >But as I indicated above, I'm concerned that the IPR issue with SenderID/PRA >are still unresolved and if we standartize PRA as chair is suggesting, only >some be able to do this type of verification and on the other hand only >some would do mail-from checking, etc. This separatism is a dangerous road >to take for IETF work, we want to have one unified internet-wide standard >not a standard for you and standard for me! Agreed. >I think we should decide on SenderID/PRA all by itself. Agreed, but I would prefer to find a "win-win" common denominator approach. > Either we find >an acceptable solution that will allow everybody to implement it Publishing the approved mail servers is something everybody can agree to do I think? From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 04:38: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 EAA28039 for ; Thu, 9 Sep 2004 04:38: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 i897BkAf096171; Thu, 9 Sep 2004 00:11: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 i897Bk76096170; Thu, 9 Sep 2004 00:11:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i897BiUb096159 for ; Thu, 9 Sep 2004 00:11:45 -0700 (PDT) (envelope-from SRS0=43/R+TEm=L6=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i897BiJx049384 for ; Thu, 9 Sep 2004 09:11:44 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409090711.I897BHFX049374@asarian-host.net> Date: Thu, 09 Sep 2004 07:11:44 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: microsoft SenderID wizard seriously flawed, unusable X-Trace: vxKv0ELwypjNM9kcv1++X1A0d5L4acZEjjauw8TPfzwS23DhKioYRDZfyo1WNwGAMecbK+O3Ubn03CebH2g8Pw== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <20040909064823.GA2369@metro.cx> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUACMDFqW1BleBN9AQH0FQf+PweNbtNpHpkcKz95Ue+fr9LVjeBYdoEo IKnqpjJ+Zj0bgEe+AU+hKMQ4TUHVOSFmmLzSIgTfL7r4oMFw2cbog2DybDV0+5RL 08ObAKbr0N+MFxlf9r5f5yj65PCnMoWh/FO6CemLFLwmAdOqcVMo9DefMBVbwvfx y0fhVPzqMdggwf78LpV765PEn5EdO/cRm0Y98EI+TJ29FXe6lOczfDvNqX+fpkIy 9lGC5jjoUanlb+BuDB6oaj0U0Jyo4kbDr/TwtCTuhGoUezIOvyUEGdqk1FaDEBxg iuaLfvuECqAD3mbwo91PMliDT9llDjoPsHFciB+nP/XlOdHkeRkLtg== =pYo7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Koen Martens wrote: > All, > > Microsoft has sponsored a 'wizard' to create SPF records, it's online > here: > > http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx > > However, the wizard is seriously flawed. For example, it suggests you > to enter ip adresses to be used with the a mechanism, producing for > example: > > v=spf2.0/pra a:1.2.3.4 ~all > > this obviously should be > > v=spf2.0/pra ip4:1.2.3.4 ~all > > There are further flaws in the programming. Here is another: http://archives.listbox.com/spf-discuss@v2.listbox.com/200409/0263.html - Mark From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 04:46: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 EAA28386 for ; Thu, 9 Sep 2004 04:46: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 i898JXrD027634; Thu, 9 Sep 2004 01:19:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i898JXXH027633; Thu, 9 Sep 2004 01:19:33 -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 i898JWW9027622 for ; Thu, 9 Sep 2004 01:19:32 -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 i898UEDN019092; Thu, 9 Sep 2004 01:30:14 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i898UETu019089; Thu, 9 Sep 2004 01:30:14 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 9 Sep 2004 01:30:14 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: Matt Sergeant , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <0819304F-01D2-11D9-9A6B-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 Wed, 8 Sep 2004, Andrew Newton wrote: > > > Right, but with a different syntax and storage. If we could move > > forwards > > now with a unified syntax and storage that would be useful. > > This working group has already been through this and concluded that CSV > was sufficiently different enough in its intentions and tact that it > should not share the same DNS mechanism. This working group has not made such a conclusion. The working group made a conclusion that the HELO identity is different and should be pursued separately from work being done on "from" identities represented by CallerID and SPF, RMX and other proposals and it was decised that mechanics offered by SPF offer best choice for futher standartization. We have not made any conclusion about DNS mechanism that should be used for HELO identity but agreed to let Dave Crocker and Douglas Otis work further on their promising proposal and evaluate it in detail after SenderID work is dealt with. If the above is incorrect understanding about conclusions from interim meeting in May and list discussions prior to that, then please correct me and show at which point in the WG dicussions did we reach consensus on dns mechanisms for HELO identity checking. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 05:34:49 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 FAA01170 for ; Thu, 9 Sep 2004 05:34:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89994Eq048946; Thu, 9 Sep 2004 02:09: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 i89994wj048945; Thu, 9 Sep 2004 02:09: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 i89993JP048934 for ; Thu, 9 Sep 2004 02:09:04 -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 i899JjZ6020752; Thu, 9 Sep 2004 02:19:45 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i899JjAk020749; Thu, 9 Sep 2004 02:19:45 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 9 Sep 2004 02:19:45 -0700 (PDT) From: "william(at)elan.net" To: Yakov Shafranovich cc: Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <413F71C9.4020700@solidmatrix.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 Wed, 8 Sep 2004, Yakov Shafranovich wrote: > Sounds like the last call might have to be extended or canceled. The idea that WG would come to consensus and produce complete set of documents within 4 months of its beginning was unrealistic to begin with. (and many have said that in the beginning). The last call is appropriate for documents that have undergone serious review and all major problems have been eliminated. It is not a way to find all the problems in the documents that need fixing (did you notice how many real tech-errors, doc-bugs, etc have been reported?) - this should have been done as part of normal process of this WG's work. Even if we did not have such serious IPR issues, I would be surprised if documents in their current form were able to progress further - a new revision and new review of all the drafts are needed. It is however unfortunete that this WG did not seriously gone through each document in such a detail until we were formally called upon with this last-call, I however attribute this to the rush put with our initial schedule. I do not think its realistic to be able to progress to standard before next meeting. In fact it might be unrealistic that we're able to progress even at that time, but hopefully we'll be more ready and somewhere by the end of the year we really can do this. And even if it happens this way, the WG that has done its work in less then one year, would still probably be the shortest successfull WG of IETF. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 05:56:34 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 FAA02651 for ; Thu, 9 Sep 2004 05:56:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i899WKxZ057606; Thu, 9 Sep 2004 02:32:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i899WK3d057605; Thu, 9 Sep 2004 02:32:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i899WJZR057587 for ; Thu, 9 Sep 2004 02:32:19 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 21120 invoked from network); 9 Sep 2004 09:33:52 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 9 Sep 2004 09:33:52 -0000 In-Reply-To: <4.1.20040909160745.0160e540(null)> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <4.1.20040909160745.0160e540(null)> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <214504A2-0243-11D9-AFEC-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@vpnc.org From: Margaret Olson Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Thu, 9 Sep 2004 05:32:12 -0400 To: AccuSpam 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 Sep 9, 2004, at 4:16 AM, AccuSpam wrote: > > >> IETF had real problem is that it did not wish to deal with how their >> protocols would be deployed. This is the main reason of failures of >> number >> of protocols that have been created and why others are less used then >> they could be. Certain conclusion must (and have) been drawn out of >> this >> and it would be unfortunete if we choose to go the same road again. > > > IMHO, the largest deployment hurdle will be to get 63 million of > domain owners (growing at 1.5 million per month) to publish and > maintain a DNS record. (See my post at spf-discuss for source). > > Presenting these non-technical people with the complexity of choosing > which scope their approved mail servers will be used and other complex > options we might provide them, seems to run counter to the 80/20 rule > for deployment. A very small minority of those domains will do the actual publishing themselves. They will rely on their vendors to publish for them and to exchange the necessary information. The average domain owner does not know what DNS is and if they do, they have no idea who manages DNS for them. The record update problem is serious and needs to be addressed within the industry, but the end user education needs to take the form of telling people that (a) this exists and (b) who to call. Small business domains, of which there are literally millions, generally outsource everything. If they are business to consumer they may have an outsourced online shopping cart sending transaction notices. They almost certainly have an ISP for business person to person mail. And any email marketing will be a third provider. The assumption that small domains all have simple configurations is just not valid. It's probably true for small personal domains, and small technical domains, but those are not the majority. Failure to scope will make it harder, not easier, for small domains, if for no other reason than figuring out what a rational receiver is likely to do with the record will be that much harder for whoever is doing the domain administration. This is currently a very low cost service - do we want to make it expensive? Margaret. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 06:18:34 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 GAA04141 for ; Thu, 9 Sep 2004 06:18:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i899m5Vb063542; Thu, 9 Sep 2004 02:48: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 i899m5r4063541; Thu, 9 Sep 2004 02:48:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i899m4Pw063529 for ; Thu, 9 Sep 2004 02:48:05 -0700 (PDT) (envelope-from SRS0=43/R+TEm=L6=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i899m4Xe053096 for ; Thu, 9 Sep 2004 11:48:04 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409090948.I899M4O2053086@asarian-host.net> Date: Thu, 09 Sep 2004 09:48:04 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] X-Trace: BMKx9bwCuZJzS8hX9Ey4481ZpBkaaEABHYvRhqPhzYatCY0+eavBxNsIMY85fdQASlgmqn3BsTuvbZ9femKGIQ== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUAm1DFqW1BleBN9AQH3fwf8DMrvQpFYdb7eumOPkxtFilXmBxvUBtqX kqZD9ji+jQ3HOQCJpEN9uGxgIwA9a22GV/BK4uDYvP892kutfM/sIIoMaUDYXYPp 2kZ+r1idf3AUBuJwQux2mMLSl7xVZUX2p/YEeqHa3nyrOAaGLrrcfIay+w8KiZkL 5x4fJ0X75G13o7WevvXCGEQ/Gcmu6URjpbEG2iBdhcYGnrUsbsGNsjKCZXTKi4E0 U3tPI/m/NHzi6UsydnaOm2lvNjViLU15XRE394079953NR7yzC6WMC6NJ3md8JW7 +lfQLvdsrcjAupsfnAREkdNvD14CZnAZzDOUV07+R+P7aW4wogODbQ== =eaq5 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Margaret Olson wrote: >> Would those of you who suggest ignoring the patent please also >> volunteer to pay for any and all costs associated with a (potential) >> lawsuit from MS for not using their license? > > I can't speak for Yakov, but I'm suggesting that this working group > ignore the IPR issue as irrelevant. You may or may not choose to > ignore it for yourself. I chose not to. The question, to me, is not whether Microsoft's IPR claims are valid, but whether I can afford to be wrong. Heck, with all the legal cost involved with a lawsuit, I cannot even afford to be right. :) - Mark From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 06:34: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 GAA05234 for ; Thu, 9 Sep 2004 06:34: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 i89A7leM072029; Thu, 9 Sep 2004 03:07:47 -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 i89A7luN072028; Thu, 9 Sep 2004 03:07:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89A7kVi072015 for ; Thu, 9 Sep 2004 03:07:47 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45435) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1C5LqD-0007oM-Lc (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Thu, 09 Sep 2004 11:07:45 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C5LqD-0007x3-GG; Thu, 09 Sep 2004 11:07:45 +0100 Date: Thu, 9 Sep 2004 11:07:45 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Crocker cc: Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <888421820.20040909054404@brandenburg.com> Message-ID: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <888421820.20040909054404@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 9 Sep 2004, Dave Crocker wrote: > > The issue of forwarding for author-based path registration schemes, > like SPF and Sender-ID, has been discussed at length. At a minimum, > we need to document these impacts on usage. Perhaps my DEPLOY submission will serve as a starting point. I can generalise it into an "Interoperability Considerations" section that covers both /pra and /mailfrom if you think this would be useful. Tony. -- f.a.n.finch http://dotat.at/ MULL OF KINTYRE TO ARDNAMURCHAN POINT: SOUTHEAST 4 OR 5, OCCASIONALLY 3 LATER. FAIR. GOOD. SLIGHT. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 08:40:44 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 IAA14521 for ; Thu, 9 Sep 2004 08: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 i89CEWjB014169; Thu, 9 Sep 2004 05:14:32 -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 i89CEWvr014168; Thu, 9 Sep 2004 05:14:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89CEVuh014132 for ; Thu, 9 Sep 2004 05:14:32 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42471) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C5Nos-00001Y-Ib (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Thu, 09 Sep 2004 13:14:30 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C5Nos-0007jx-CC; Thu, 09 Sep 2004 13:14:30 +0100 Date: Thu, 9 Sep 2004 13:14:30 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Stephane Bortzmeyer cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <20040908200156.GB25754@nic.fr> Message-ID: References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <20040908200156.GB25754@nic.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Sep 2004, Stephane Bortzmeyer wrote: > > Forwarding can be "repaired" with things like SUBMITTER or SRS (I > prefer SUBMITTER). SPF-classic breaks forwarding but SenderID may be > changed to repair it. SUBMITTER is just an optimisation: it has no effect on semantics and it does nothing to fix the interoperability problems. Most of the problems arise in a mixed environment with some sites that implement Sender-ID and some that do not. They are a result of trying to authenticate a message with respect to an MTA, which is the fundamental error of all designated sender schemes. See http://www.imc.org/ietf-mxcomp/mail-archive/msg04462.html for a more thorough analysis of problems caused by Sender-ID. Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: WEST OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST, BECOMING VARIABLE 3 OR 4. RAIN DYING OUT. MODERATE OR POOR BECOMING GOOD &NBSP;. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 09:35: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 JAA18779 for ; Thu, 9 Sep 2004 09:35:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89D6vP1027556; Thu, 9 Sep 2004 06:06: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 i89D6vYU027555; Thu, 9 Sep 2004 06:06:57 -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 i89D6rN7027512 for ; Thu, 9 Sep 2004 06:06:57 -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 8A85516CD2 for ; Thu, 9 Sep 2004 09:15:53 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: Your message of "Thu, 09 Sep 2004 13:55:42 +0800." <4.1.20040909130446.016721f0(null)> Date: Thu, 09 Sep 2004 09:15:53 -0400 Message-Id: <20040909131553.8A85516CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: AccuSpam wrote: > IMO, the scope should be implicit from the specification. "Implicit" instructions in specifications have historically meant inter-operability problems, and security flaws. The specifications exist to make scope/intent explicit. Adding a few more sentences to clarify the scope would be a good idea for any specification. > >And if so, do you actually think it is better for the receiver to have > >to guess the intended scope of the sender? > > Yes because inherent in the design of the specification should be > acknowledged the *REALITY* that the sender can not control the > receiver (verifier). Control is different from intent. MX records in DNS are intended to be used as destination IP's for SMTP traffic to a domain, and that intent is explicit in the specifications. Yet nothing stops anyone from doing: $ ping `host -t mx example.com` For MARID issues, the intent of the publisher of the records should be made explicit in the specifications, if not the protocol. For the vast majority of recipients who use the records as expected, having that intent explicit makes their jobs easier. For the recipients who don't follow the publishers intent, it makes no difference to have that intent explicit, because they won't follow it. > I think it would be folly and brittle for us to attempt to specify > *ALL* the ways that the data in the DNS record can be used and > interpreted, ... Similarly, it would be follow to specify *no* standard way for the data to be used and interpreted. There is a happy medium. We should find it, and use it. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 09:45:26 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 JAA19289 for ; Thu, 9 Sep 2004 09:45:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89DLDen030963; Thu, 9 Sep 2004 06:21:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89DLDX3030962; Thu, 9 Sep 2004 06:21:13 -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 i89DLCVM030955 for ; Thu, 9 Sep 2004 06:21:13 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 5CCBF26C07F; Thu, 9 Sep 2004 15:21:14 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id BFCD626C06C; Thu, 9 Sep 2004 15:21:12 +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 i89DLCm7656795; Thu, 9 Sep 2004 15:21:12 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 47D46FACE; Thu, 9 Sep 2004 15:21:12 +0200 (CEST) Date: Thu, 9 Sep 2004 15:21:12 +0200 From: Stephane Bortzmeyer To: Daniel Quinlan Cc: Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040909132112.GB28026@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Sep 08, 2004 at 04:28:47PM -0700, Daniel Quinlan wrote a message of 23 lines which said: > If patent-encumbered stuff (PRA) is any part of the specification > (and I see it mentioned in your proposal), then the ASF (including > the SpamAssassin and JAMES projects) vehemently objects. Even if, while mentioned in the specification, it is optional and can be ommitted at will? > Given that there is a lack of consensus on PRA, it seems like the > best course is drop PRA entirely and allow the specification authors > to revise things a bit more freely again. Crypto-related standards (a field crippled with patents) often use the very same method to allow interesting (but potentially infringing) algorithms. See RFC 2246 for instance. You do not object against it because it mentions the patented IDEA? From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 09:48: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 JAA19513 for ; Thu, 9 Sep 2004 09:48: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 i89DInWR030370; Thu, 9 Sep 2004 06:18: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 i89DIn9v030369; Thu, 9 Sep 2004 06:18:49 -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 i89DIlX4030327 for ; Thu, 9 Sep 2004 06:18:48 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 858 invoked by uid 1013); 9 Sep 2004 13:18:42 -0000 Date: Thu, 9 Sep 2004 15:18:42 +0200 From: Markus Stumpf To: ietf-mxcomp@vpnc.org Subject: SPF abused by spammers Message-ID: <20040909131842.GV44802@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Justin Murdock posted this link on the qmail list: http://news.bbc.co.uk/1/hi/technology/3631350.stm "CipherTrust [...] found that 34% more spam is passing SPF checks than legitimate e-mail." \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 Thu Sep 9 09:48: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 JAA19536 for ; Thu, 9 Sep 2004 09:48: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 i89DGhF3029822; Thu, 9 Sep 2004 06:16: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 i89DGh2H029821; Thu, 9 Sep 2004 06:16:43 -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 i89DGUWB029767 for ; Thu, 9 Sep 2004 06:16:43 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 01D2426C091; Thu, 9 Sep 2004 15:16:32 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 7D48D26C06C; Thu, 9 Sep 2004 15:16:21 +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 i89DGLm7655594; Thu, 9 Sep 2004 15:16:21 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 287B3FACE; Thu, 9 Sep 2004 15:16:21 +0200 (CEST) Date: Thu, 9 Sep 2004 15:16:21 +0200 From: Stephane Bortzmeyer To: Mark Lentczner Cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040909131621.GA28026@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <9BC4046C-01DD-11D9-BB96-000393A56BB6@glyphic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BC4046C-01DD-11D9-BB96-000393A56BB6@glyphic.com> 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, Sep 08, 2004 at 02:25:29PM -0700, Mark Lentczner wrote a message of 41 lines which said: > Yes, scopes would need an IANA registry. Unless we decide to hardwire the list of possible scopes in the RFC, I presume? > 3) One generally never publishes records about HELO at the same > domain name as MAIL FROM or PRA. Hence they'd never share a record. That's strange. If you publish a SPF record for example.com, surely mail.example.com (the name you announce in HELO) has a SPF record, too? (Otherwise, it is trivial to defeat your SPF record, the method is left as an exercice.) From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 10:17: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 KAA22268 for ; Thu, 9 Sep 2004 10:17:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89DhIdP036680; Thu, 9 Sep 2004 06:43: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 i89DhIK8036679; Thu, 9 Sep 2004 06:43:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from medrad.com ([205.166.66.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id i89DhGAI036642 for ; Thu, 9 Sep 2004 06:43:17 -0700 (PDT) (envelope-from MHolm@medrad.com) Received: by hq.medrad.com id <119065>; Thu, 9 Sep 2004 09:42:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: DEPLOY: microsoft SenderID wizard seriously flawed, unusable, Date: Thu, 9 Sep 2004 09:34:25 -0400 Message-Id: <04Sep9.094218edt.119065@hq.medrad.com> Thread-Topic: Re: DEPLOY: microsoft SenderID wizard seriously flawed, unusable, Thread-Index: AcSWcbkPIu62qM3IT8iwQruszc7EOw== From: "Holm, Mark" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i89DhHAI036672 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I'm the one who pointed out over on spf-discuss that the Microsoft Sender ID record wizard appears to be broken. Unlike some others, I don't see it as a sign of conspiricy. Just a screwed up piece of programming. Probably the result of a rush job based on incomplete or bad information. The things I noted: 1. The plain a mechanism doesn't work. If you click the box to get it, it never appears in the final record. 2. Both the a and mx mechanism's encourage the user to put ipv4 or ipv6 addresses as arguments to the mechanisms. I understand this, though not specifically forbidden by the spec., is not good practice. 3. The wizard prefixes the records with v=spf2.0/pra I understand that this syntax is still very much under debate and can not yet be considered part of the specification. I'm not an expert. I may have missed things or misunderstood things, but I think there is evidence that the wizard needs some healing magic :) Mark Holm From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 10:19:23 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 KAA22524 for ; Thu, 9 Sep 2004 10:19:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89DbiIR035314; Thu, 9 Sep 2004 06:37: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 i89DbiPL035313; Thu, 9 Sep 2004 06:37:44 -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 i89Dbh59035304 for ; Thu, 9 Sep 2004 06:37:44 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 3893A26C06C; Thu, 9 Sep 2004 15:37:45 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 923AC26C080; Thu, 9 Sep 2004 15:37:43 +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 i89Dbhm7649523; Thu, 9 Sep 2004 15:37:43 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 1FF58FACE; Thu, 9 Sep 2004 15:37:43 +0200 (CEST) Date: Thu, 9 Sep 2004 15:37:43 +0200 From: Stephane Bortzmeyer To: AccuSpam Cc: ietf-mxcomp@vpnc.org Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040909133743.GA29668@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Thu, Sep 09, 2004 at 04:16:37PM +0800, AccuSpam wrote a message of 63 lines which said: > Presenting these non-technical people with the complexity of > choosing which scope their approved mail servers will be used and > other complex options we might provide them, seems to run counter to > the 80/20 rule for deployment. In most cases, all the scopes (or at least PRA and 2821 MAIL FROM) are the same. So, the default scope will probably be fine for them. "Unified SPF" (http://spf.pobox.com/unified/1-unified.txt) discusses this issue. See 2.2.1 and 2.2.2. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 10: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 KAA23530 for ; Thu, 9 Sep 2004 10:34:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Du2E3039642; Thu, 9 Sep 2004 06:56: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 i89Du2cc039641; Thu, 9 Sep 2004 06:56:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Du1gB039618 for ; Thu, 9 Sep 2004 06:56:02 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with esmtpa (Exim 4.42) id 1C5PNh-0007Qn-67; Thu, 09 Sep 2004 09:54:33 -0400 Message-ID: <414060EB.5070400@solidmatrix.com> Date: Thu, 09 Sep 2004 09:55:55 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Koen Martens CC: IETF MARID WG Subject: Re: DEPLOY: microsoft SenderID wizard seriously flawed, unusable References: <20040909064823.GA2369@metro.cx> In-Reply-To: <20040909064823.GA2369@metro.cx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Koen Martens wrote: > All, > > Microsoft has sponsored a 'wizard' to create SPF records, it's online > here: > > http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx > > However, the wizard is seriously flawed. For example, it suggests you to > enter ip adresses to be used with the a mechanism, producing for example: > > v=spf2.0/pra a:1.2.3.4 ~all > > this obviously should be > > v=spf2.0/pra ip4:1.2.3.4 ~all > > There are further flaws in the programming. Surely, microsoft > programmers are not _this_ stupid, so I cannot understand otherwise than > this is a deliberate stalling move to frustrate development of SenderID. > > This wizard should be taken off-line immediatelly! It should not come > back online until after all the bugs have been fixed. This wizard is bad > for deployment, making people publish bad records. A quick WHOIS check determines that the domain belongs to "Aditi Technologies" which is an outsourcing company in India. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 10:45:49 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 KAA24199 for ; Thu, 9 Sep 2004 10:45:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Duits039809; Thu, 9 Sep 2004 06:56: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 i89Dui4L039808; Thu, 9 Sep 2004 06:56:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89DuXJ3039763 for ; Thu, 9 Sep 2004 06:56:44 -0700 (PDT) (envelope-from SRS0+ba578818d45572b67121+382+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C5PPe-0000UH-Jg; Thu, 09 Sep 2004 14:56:35 +0100 Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope From: David Woodhouse To: Stephane Bortzmeyer Cc: Mark Lentczner , IETF MARID WG In-Reply-To: <20040909131621.GA28026@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <9BC4046C-01DD-11D9-BB96-000393A56BB6@glyphic.com> <20040909131621.GA28026@nic.fr> Content-Type: text/plain Message-Id: <1094738193.4083.1603.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Thu, 09 Sep 2004 14:56:33 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-09-09 at 15:16 +0200, Stephane Bortzmeyer wrote: > On Wed, Sep 08, 2004 at 02:25:29PM -0700, > Mark Lentczner wrote: > > 3) One generally never publishes records about HELO at the same > > domain name as MAIL FROM or PRA. Hence they'd never share a record. > > That's strange. If you publish a SPF record for example.com, surely > mail.example.com (the name you announce in HELO) has a SPF record, > too? strcmp("example.com", "mail.example.com"); As Mark said, they don't _share_ a record. They each have their own. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 10:47:55 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 KAA24309 for ; Thu, 9 Sep 2004 10:47: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 i89E6YCW042316; Thu, 9 Sep 2004 07:06:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89E6Y7F042315; Thu, 9 Sep 2004 07:06:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89E6YBY042306 for ; Thu, 9 Sep 2004 07:06:34 -0700 (PDT) (envelope-from csm@moongroup.com) Received: by server1.moongroup.com (Postfix, from userid 48) id 035D11182400F; Thu, 9 Sep 2004 10:06:35 -0400 (EDT) Received: from 63.148.163.200 (SquirrelMail authenticated user csm); by www.moongroup.com with HTTP; Thu, 9 Sep 2004 10:06:35 -0400 (EDT) Message-ID: <34251.63.148.163.200.1094738795.squirrel@63.148.163.200> In-Reply-To: <20040909131842.GV44802@Space.Net> References: <20040909131842.GV44802@Space.Net> Date: Thu, 9 Sep 2004 10:06:35 -0400 (EDT) Subject: Re: SPF abused by spammers From: "Chuck Mead" To: ietf-mxcomp@vpnc.org User-Agent: SquirrelMail/1.4.3a-0.e3.1 X-Mailer: SquirrelMail/1.4.3a-0.e3.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Markus Stumpf said: > > Justin Murdock posted this link on the qmail list: > http://news.bbc.co.uk/1/hi/technology/3631350.stm > "CipherTrust [...] found that 34% more spam is passing SPF checks than > legitimate e-mail." This is good news! Personally I hope it hits 100% as that will make it sooooooo much easier to whack the moles! -- csm@moongroup.com Chief Tech and Bottle Washer From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 10:59: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 KAA24893 for ; Thu, 9 Sep 2004 10:59:58 -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 i89EKc31046079; Thu, 9 Sep 2004 07:20: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 i89EKcHV046078; Thu, 9 Sep 2004 07:20:38 -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 i89EKcSm046061 for ; Thu, 9 Sep 2004 07:20:38 -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; Thu, 09 Sep 2004 10:20:37 -0400 id 0011B862.414066B5.00000F91 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <69B5E674-026B-11D9-9A6B-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Thu, 9 Sep 2004 10:20:34 -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: Content-Transfer-Encoding: 7bit On Sep 9, 2004, at 4:30 AM, william(at)elan.net wrote: > If the above is incorrect understanding about conclusions from interim > meeting in May and list discussions prior to that, then please correct > me > and show at which point in the WG dicussions did we reach consensus > on dns mechanisms for HELO identity checking. The conclusion was that CSV semantics should not put into Sender ID, which uses a particular syntax known as SPF syntax and the TXT & SPF records. http://www.imc.org/ietf-mxcomp/mail-archive/msg02527.html -andy From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 11:23: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 LAA26440 for ; Thu, 9 Sep 2004 11:23:04 -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 i89EtZCj054445; Thu, 9 Sep 2004 07:55: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 i89EtZWS054444; Thu, 9 Sep 2004 07:55:35 -0700 (PDT) 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 i89EtYr2054418 for ; Thu, 9 Sep 2004 07:55:34 -0700 (PDT) (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 i89EtV51022090; Thu, 9 Sep 2004 14:55:31 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 i89EtV8j003293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2004 16:55:31 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i89EtVCW003292; Thu, 9 Sep 2004 16:55:31 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Thu, 9 Sep 2004 16:55:31 +0200 From: Koen Martens To: Yakov Shafranovich Cc: IETF MARID WG Subject: Re: DEPLOY: microsoft SenderID wizard seriously flawed, unusable Message-ID: <20040909145530.GC3151@metro.cx> References: <20040909064823.GA2369@metro.cx> <414060EB.5070400@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414060EB.5070400@solidmatrix.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 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 09, 2004 at 09:55:55AM -0400, Yakov Shafranovich wrote: > Koen Martens wrote: > >Microsoft has sponsored a 'wizard' to create SPF records, it's online > >here: > > > >http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx > > > >However, the wizard is seriously flawed. For example, it suggests you to > >enter ip adresses to be used with the a mechanism, producing for example: > > [....] > > A quick WHOIS check determines that the domain belongs to "Aditi > Technologies" which is an outsourcing company in India. A quick glance at the web-site determines that the site is sponsored by microsoft. Why is microsoft sponsoring a wizard that creates invalid spf records? If microsoft is not indeed sponsoring this site, why has the 'sponsored by microsoft' banner up there for months now? Koen -- 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/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 11:24:59 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 LAA26576 for ; Thu, 9 Sep 2004 11:24:58 -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 i89Ewnhd055274; Thu, 9 Sep 2004 07:58: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 i89EwnKr055273; Thu, 9 Sep 2004 07:58:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Ewm7M055227 for ; Thu, 9 Sep 2004 07:58:48 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i89EwYuW015470 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Sep 2004 10:58:37 -0400 Date: Thu, 9 Sep 2004 10:58:34 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Markus Stumpf cc: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040909131842.GV44802@Space.Net> 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: Isn't that what I said would happen? --Dean On Thu, 9 Sep 2004, Markus Stumpf wrote: > > Justin Murdock posted this link on the qmail list: > http://news.bbc.co.uk/1/hi/technology/3631350.stm > "CipherTrust [...] found that 34% more spam is passing SPF checks than > legitimate e-mail." > > \Maex > > Date: Tue, 10 Aug 2004 19:55:57 -0400 (EDT) From: Dean Anderson To: 'IETF MARID WG' Subject: Analysis of SPF benefits for reduced filtering It has been reported that AOL is already using SPF to give reduced filtering to SPF-using domains. Is this a good idea? IF you use SPF to provide less stringent anti-spam processing, then you are MORE vulnerable than you were before. You have shot yourself in the foot. Suppose for example that AOL subjects MSN users to less stringent anti-spam filtering because MSN uses SPF. MSN is still vulnerable to viruses as it was before it used SPF, and it is just as vulnerable to disposable account creation as it was before. Using SPF will __attract__ abusers to MSN, because they can get more spam through to AOL, because it is subject to less processing. Since AOL is doing less processing on the same spam, AOL users get more spam. SPF is bad for both companies. And of course, anyone who sets up a disposable domain can also get spam through to AOL by creating an SPF record for the domain. Disposable domains along with disposable or stolen accounts is a major problem now, and it remains a major problem under SPF. Anything that reduces spam filtering without reducing the number of abusers will be harmful. Basically, SPF gives abusers the opportunity to whitelist themselves, or the opportunity to identify ISPs that may be whitelisted. Any kind of whitelist that is under the control of the sender, rather than the recipient is also going to be ineffective and harmful. Dean Anderson Av8 Internet, Inc From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 11:25:50 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 LAA26635 for ; Thu, 9 Sep 2004 11:25:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89F05FK055638; Thu, 9 Sep 2004 08:00: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 i89F05VM055637; Thu, 9 Sep 2004 08:00:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89F04v4055627 for ; Thu, 9 Sep 2004 08:00:04 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with esmtpa (Exim 4.42) id 1C5QNi-0002tN-11; Thu, 09 Sep 2004 10:58:38 -0400 Message-ID: <41406FF0.9050801@solidmatrix.com> Date: Thu, 09 Sep 2004 11:00:00 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Koen Martens CC: IETF MARID WG Subject: Re: DEPLOY: microsoft SenderID wizard seriously flawed, unusable References: <20040909064823.GA2369@metro.cx> <414060EB.5070400@solidmatrix.com> <20040909145530.GC3151@metro.cx> In-Reply-To: <20040909145530.GC3151@metro.cx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Koen Martens wrote: > On Thu, Sep 09, 2004 at 09:55:55AM -0400, Yakov Shafranovich wrote: > >> Koen Martens wrote: >> >>> Microsoft has sponsored a 'wizard' to create SPF records, it's >>> online here: >>> >>> http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx >>> >>> >>> However, the wizard is seriously flawed. For example, it suggests >>> you to enter ip adresses to be used with the a mechanism, >>> producing for example: >> >> >> [....] >> >> A quick WHOIS check determines that the domain belongs to "Aditi >> Technologies" which is an outsourcing company in India. > > > A quick glance at the web-site determines that the site is sponsored > by microsoft. Why is microsoft sponsoring a wizard that creates > invalid spf records? If microsoft is not indeed sponsoring this site, > why has the 'sponsored by microsoft' banner up there for months now? It sounds like they outsourced the work to India and the outsources botched it up. I don't see any malicious intent here, simply lack of foresight. But we can always ask Jim and Harry... Yakov From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 11:37: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 LAA27354 for ; Thu, 9 Sep 2004 11:37:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89F9k0h058210; Thu, 9 Sep 2004 08:09: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 i89F9kEi058209; Thu, 9 Sep 2004 08:09:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp3g.bellsouth.com (aismtp3g.bellsouth.com [139.76.165.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89F9knG058163 for ; Thu, 9 Sep 2004 08:09:46 -0700 (PDT) (envelope-from Damon.Sauer@BellSouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp3g.bellsouth.com with ESMTP; Thu, 9 Sep 2004 11:08:09 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: SPF abused by spammers X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Thu, 9 Sep 2004 10:07:21 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB904F97563@bremocog-55> Thread-Topic: SPF abused by spammers Thread-Index: AcSWfgA+Woa0+h8uQn6cO5RAXuRsoQAABREQ From: "Sauer, Damon" To: "Dean Anderson" , "Markus Stumpf" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i89F9knG058204 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dean, You are missing where this is a GOOD thing. We WANT spammers to use SPF. This will allow us to identify, publish, process, shred, pillage, burn, destroy the IP addresses that this stuff is coming from. Nobody is doing less stringent processing of the email that passes an SPF check. It just makes it easier to block when identified. The checks that I DON'T have to do are against the received from: headers. I already know. If you want to call this 'reducing filtering' so be it. But it is a reduction because the check that you used to have to run is no longer necessary. Regards, Damon Sauer -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Dean Anderson Sent: Thursday, September 09, 2004 10:59 AM To: Markus Stumpf Cc: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers Isn't that what I said would happen? --Dean On Thu, 9 Sep 2004, Markus Stumpf wrote: > > Justin Murdock posted this link on the qmail list: > http://news.bbc.co.uk/1/hi/technology/3631350.stm > "CipherTrust [...] found that 34% more spam is passing SPF checks than > legitimate e-mail." > > \Maex > > Date: Tue, 10 Aug 2004 19:55:57 -0400 (EDT) From: Dean Anderson To: 'IETF MARID WG' Subject: Analysis of SPF benefits for reduced filtering It has been reported that AOL is already using SPF to give reduced filtering to SPF-using domains. Is this a good idea? IF you use SPF to provide less stringent anti-spam processing, then you are MORE vulnerable than you were before. You have shot yourself in the foot. Suppose for example that AOL subjects MSN users to less stringent anti-spam filtering because MSN uses SPF. MSN is still vulnerable to viruses as it was before it used SPF, and it is just as vulnerable to disposable account creation as it was before. Using SPF will __attract__ abusers to MSN, because they can get more spam through to AOL, because it is subject to less processing. Since AOL is doing less processing on the same spam, AOL users get more spam. SPF is bad for both companies. And of course, anyone who sets up a disposable domain can also get spam through to AOL by creating an SPF record for the domain. Disposable domains along with disposable or stolen accounts is a major problem now, and it remains a major problem under SPF. Anything that reduces spam filtering without reducing the number of abusers will be harmful. Basically, SPF gives abusers the opportunity to whitelist themselves, or the opportunity to identify ISPs that may be whitelisted. Any kind of whitelist that is under the control of the sender, rather than the recipient is also going to be ineffective and harmful. Dean Anderson Av8 Internet, Inc ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 11:37:40 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 LAA27377 for ; Thu, 9 Sep 2004 11:37:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89FB3C6058583; Thu, 9 Sep 2004 08:11:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89FB3AZ058582; Thu, 9 Sep 2004 08:11:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89FB1rC058536 for ; Thu, 9 Sep 2004 08:11:02 -0700 (PDT) (envelope-from peeebeee@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so363894rnk for ; Thu, 09 Sep 2004 08:10:49 -0700 (PDT) Received: by 10.38.59.69 with SMTP id h69mr3555505rna; Thu, 09 Sep 2004 08:10:49 -0700 (PDT) Received: by 10.38.72.24 with HTTP; Thu, 9 Sep 2004 08:10:49 -0700 (PDT) Message-ID: <56152ae9040909081013f4e72c@mail.gmail.com> Date: Thu, 9 Sep 2004 16:10:49 +0100 From: Peter Bowyer Reply-To: peter@bowyer.org To: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040909131842.GV44802@Space.Net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > From: Dean Anderson (Sorry if I got the attribution wrong - confusing bad quoting and top-posting going on) > It has been reported that AOL is already using SPF to give reduced > filtering to SPF-using domains. Is this a good idea? On its own - no. Fortunately, it's not what they're doing - they're using SPF for exactly what it was intended - as part of their reputation system. They use SPF to confirm that a mail purporting to come from an organisation on their whitelist is not forged. Domain on whitelist + SPF Pass = less filtering. Peter From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 11:43:40 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 LAA27644 for ; Thu, 9 Sep 2004 11:43: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 i89FEHe5059552; Thu, 9 Sep 2004 08:14:17 -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 i89FEH8B059551; Thu, 9 Sep 2004 08:14:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89FEGRW059529 for ; Thu, 9 Sep 2004 08:14:16 -0700 (PDT) (envelope-from craigspi@microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Thu, 9 Sep 2004 08:13:43 -0700 Received: from RED-MSG-50.redmond.corp.microsoft.com ([157.54.12.10]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 08:14:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4967F.A1816BE8" Subject: Beta Tool RE: DEPLOY: Microsoft SenderID wizard seriously flawed, unusable, Date: Thu, 9 Sep 2004 08:14:09 -0700 Message-ID: <22DDEC51216B404E8C056F8F5198E92702133534@RED-MSG-50.redmond.corp.microsoft.com> Thread-Topic: Beta Tool RE: DEPLOY: Microsoft SenderID wizard seriously flawed, unusable, Thread-Index: AcSWcbkPIu62qM3IT8iwQruszc7EOwADMsVA From: "Craig Spiezle" To: "Holm, Mark" , X-OriginalArrivalTime: 09 Sep 2004 15:14:28.0518 (UTC) FILETIME=[B33A6C60:01C4967F] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4967F.A1816BE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The tool is in beta, incorporating use case feedback prior to being finalized, both on usability as well as creating accurate records. In its current state It is intended to demonstrate the ease of creating a text record and to assist in implementation and deployment once the spec moves from the draft to proposed state. On the home page www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx this is called out as below; =20 Note: This wizard is in beta and is intended to illustrate what SPF records will look like and the ease of creating them. We anticipate possible changes to the final format by the IETF. As such, records are subject to change until the standard has been finalized and approved.=20 If you have other suggestions, including usability please forward your comments directly to senderid@microsoft.com. =20 Craig Spiezle Director Industry & Partner Relations Safety Technology Strategy Group Microsoft Corporation -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Holm, Mark Sent: Thursday, September 09, 2004 6:34 AM To: ietf-mxcomp@vpnc.org Subject: Re: DEPLOY: microsoft SenderID wizard seriously flawed, unusable, I'm the one who pointed out over on spf-discuss that the Microsoft Sender ID record wizard appears to be broken. Unlike some others, I don't see it as a sign of conspiricy. Just a screwed up piece of programming. Probably the result of a rush job based on incomplete or bad information. The things I noted: 1. The plain a mechanism doesn't work. If you click the box to get it, it never appears in the final record. 2. Both the a and mx mechanism's encourage the user to put ipv4 or ipv6 addresses as arguments to the mechanisms. I understand this, though not specifically forbidden by the spec., is not good practice. 3. The wizard prefixes the records with v=3Dspf2.0/pra I understand that this syntax is still very much under debate and can not yet be considered part of the specification. I'm not an expert. I may have missed things or misunderstood things, but I think there is evidence that the wizard needs some healing magic :) Mark Holm ------_=_NextPart_001_01C4967F.A1816BE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Beta Tool RE: DEPLOY: Microsoft SenderID wizard seriously flawed, = unusable,

The = tool is = in beta, = incorporating use case feedback prior to being = finalized, both on usability as well = as creating accurate records.  In its current = state = It is intended to demonstrate the ease of = creating a text record and to assist in implementation and deployment = once the spec moves from the draft to proposed state.

On = the home page www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.asp= x  this is called out as below; 

Note: This wizard is in beta and is intended to = illustrate what SPF records will look like and the ease of creating = them. We anticipate possible changes to the final format by the IETF. As = such, records are subject to change until the standard has been = finalized and approved.

If = you have other suggestions, including usability please = forward your comments directly to senderid@microsoft.com. 




Craig = Spiezle

Director Industry & Partner = Relations

Safety Technology Strategy Group

Microsoft Corporation

-----Original Message-----
From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@m= ail.imc.org] On Behalf Of Holm, Mark
Sent: Thursday, September 09, 2004 6:34 AM
To: ietf-mxcomp@vpnc.org
Subject: Re: DEPLOY: microsoft SenderID wizard seriously flawed, = unusable,


I'm the one who pointed out over on spf-discuss that the Microsoft = Sender ID record wizard appears to be broken.

Unlike some others, I don't see it as a sign of conspiricy.  = Just a screwed up piece of programming.  Probably the result of a = rush job based on incomplete or bad information.

The things I noted:

1. The  plain  a  mechanism doesn't work.  If = you click the box to get it, it never appears in the final = record.

2.  Both the  a  and  mx  mechanism's = encourage the user to put ipv4 or ipv6 addresses as arguments to the = mechanisms.  I understand this, though not specifically forbidden = by the spec., is not good practice.

3.  The wizard prefixes the records with = v=3Dspf2.0/pra   I understand that this syntax is still very = much under debate and can not yet be considered part of the = specification.

I'm not an expert.  I may have missed things or misunderstood = things, but I think there is evidence that the wizard needs some healing = magic :)

Mark Holm


------_=_NextPart_001_01C4967F.A1816BE8-- From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 11:54:48 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 LAA29240 for ; Thu, 9 Sep 2004 11:54:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89FOjN1062253; Thu, 9 Sep 2004 08:24: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 i89FOjwT062252; Thu, 9 Sep 2004 08:24:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from drsneaky.slc.co.uk (mail1.slc.co.uk [195.99.121.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89FOhdf062223 for ; Thu, 9 Sep 2004 08:24:44 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) Received: from emerald.slc.co.uk (emerald.slc.co.uk) by drsneaky.slc.co.uk (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Thu, 9 Sep 2004 16:24:40 +0100 Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope To: IETF MARID WG Cc: Stephane Bortzmeyer X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Danny Angus Date: Thu, 9 Sep 2004 16:25:30 +0100 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 09/09/2004 16:24:40 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: All, > Crypto-related standards (a field crippled with patents) often use the > very same method to allow interesting (but potentially infringing) > algorithms. See RFC 2246 for instance. You do not object against it > because it mentions the patented IDEA? To be honest from what I can see there doesn't really need to be a specification for PRA at all as it merely formalises the correct interpretation of RFC2822 compliant headers. "This document describes an algorithm that allows one to determine who appears to have most recently caused an e-mail message to be delivered. It does this by inspecting the headers in the message. [RFC2822]" PRA could just as easily be replaced by a requirement to interpret headers in accordance with RFC2822, Marid core 4: "Determining the Purported Responsible Address The purported responsible address (PRA) of a message MUST be determined using the algorithm described in [PRA]. If the Sender ID check is being performed by an MTA as part of receiving an e-mail message, and the PRA algorithm cannot determine a PRA, then the message SHOULD be rejected with error "550 5.1.7 Missing purported Responsible Address"" This could be redrafted as "Determining the domain responsible for introduction of the message into the messaging system MUST be in accordance with RFC2822." and "ver-scope" could be redefined to refer to a definition of the senders domain written in refrence to rfc2822 alone. It would then be the responsibility of the implementor to deal with their own IPR issues, though what a can of worms would be opened if a patent could be taken out on any algorythm implied but not explicitly stated by any RFC. It strikes me that crypto algorithms are the product of much commercial effort and the ends of ineroperability are better served by incuding them in an interoperability framework than omitting them. This case is different in that a party to an interoperability standard seems to have indicated that they intend to seek patents based upon work done by the group and which will probably affect implementations but will not be granted or revealed until after the standard has been published. d. (p.s. I'm an Apache James PMC member) *************************************************************************** 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 Thu Sep 9 11:56:24 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 LAA29366 for ; Thu, 9 Sep 2004 11:56:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89FSGxF063144; Thu, 9 Sep 2004 08:28: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 i89FSGAE063143; Thu, 9 Sep 2004 08:28:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89FSGpc063136 for ; Thu, 9 Sep 2004 08:28:16 -0700 (PDT) (envelope-from dotzero@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so315930rnb for ; Thu, 09 Sep 2004 08:28:12 -0700 (PDT) Received: by 10.38.98.1 with SMTP id v1mr416415rnb; Thu, 09 Sep 2004 08:28:12 -0700 (PDT) Received: by 10.38.8.12 with HTTP; Thu, 9 Sep 2004 08:28:12 -0700 (PDT) Message-ID: <7ae58c2204090908286db44d4@mail.gmail.com> Date: Thu, 9 Sep 2004 11:28:12 -0400 From: Michael Hammer Reply-To: Michael Hammer To: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040909131842.GV44802@Space.Net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It might be useful if people checked their facts before using rumor or secondhand reports as the basis of posting to the lsit. On Thu, 9 Sep 2004 10:58:34 -0400 (EDT), Dean Anderson wrote: > > Isn't that what I said would happen? > > --Dean > > It has been reported that AOL is already using SPF to give reduced > filtering to SPF-using domains. Is this a good idea? > Please visit: http://postmaster.aol.com/spf/ AOL has NOT said they will do less stringent checking if you publish an SPF record. What they have said is that in order to remain on their whitelist (assuming you meet all of the other requirements) you must publish SPF records. I think their website is pretty clear. Mike From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 11:57:24 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 LAA29490 for ; Thu, 9 Sep 2004 11:57:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89FNO49061911; Thu, 9 Sep 2004 08:23: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 i89FNOfv061910; Thu, 9 Sep 2004 08:23:24 -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 i89FNNvO061889 for ; Thu, 9 Sep 2004 08:23:23 -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 i89FY46k001989; Thu, 9 Sep 2004 08:34:04 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i89FY4GS001986; Thu, 9 Sep 2004 08:34:04 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 9 Sep 2004 08:34:04 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <69B5E674-026B-11D9-9A6B-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 Thu, 9 Sep 2004, Andrew Newton wrote: > > If the above is incorrect understanding about conclusions from interim > > meeting in May and list discussions prior to that, then please correct > > me > > and show at which point in the WG dicussions did we reach consensus > > on dns mechanisms for HELO identity checking. > > The conclusion was that CSV semantics should not put into Sender ID, > which uses a particular syntax known as SPF syntax and the TXT & SPF > records. > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02527.html There appears to be problems with above statement. The problem has to do with interpretation of how names "SenderID" and "CSV" are used. It appears based on yesterday's statement that you imply that you were using both in more general sense and assuming SenderID to mean anything that working group comes up with that is using SPF syntax and CSV to mean HELO identity checking in general. But that is not how I or many others understand this. For me SenderID is particular proposal made when attempting to merge SPF with CallerID and that means its particular to the PRA identity (that is why until now SenderID was always distinguished from SPF classic and it was understood that SenderID does not include SPF classic but that MARID may at later time standarding SPF classic envelope mail-from checks on its own after conclusion of SenderID identity work. Similarly CSV is also particular proposal made by Dave Crocker on the HELO identity checking. In that sense merging these two completely different and particular proposals or even discussing it would not have been productive for the group so I agree with what you said in that post. I understood it to mean that we should focus on SenderID identity at the time and discuss other identities and specific CSV proposal later. I do not see the above to imply that we agreed (or disagreed) that we can not include checking other identities by means of SPF syntax, again it was understood that discussions of that will take place later on. And since we agreed not discuss CSV or HELO identity checking until SenderID is worked on, it means there was no discussion and thus no consensus about what dns symantics should be used with that identity... -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 12: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 MAA00856 for ; Thu, 9 Sep 2004 12: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 i89FkV4Q065952; Thu, 9 Sep 2004 08:46:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89FkVQL065951; Thu, 9 Sep 2004 08:46:31 -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 i89FkVEh065944 for ; Thu, 9 Sep 2004 08:46:31 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i89FkMjO010253; Thu, 9 Sep 2004 08:46:24 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Sep 2004 08:46:21 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , Markus Stumpf Cc: ietf-mxcomp@vpnc.org Subject: RE: SPF abused by spammers Date: Thu, 9 Sep 2004 08:46:13 -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: What percentage of the SPF authenticated spam is being trapped by the spam filters? The big advantage of authentication is that you are no longer forced to analyse at the message level. Even if you have zero third party data available you can arrive at general conclusions such as 'all mail from example.com is spam' or the opposite. Authentication alone is not a security solution. You also need authorization. This is what I was saying 18 months ago in my 'Plan for No Spam'. Phill > -----Original Message----- > From: Dean Anderson [mailto:dean@av8.com] > Sent: Thursday, September 09, 2004 10:59 AM > To: Markus Stumpf > Cc: ietf-mxcomp@vpnc.org > Subject: Re: SPF abused by spammers > > > > Isn't that what I said would happen? > > --Dean > > On Thu, 9 Sep 2004, Markus Stumpf wrote: > > > > > Justin Murdock posted this link on the qmail list: > > http://news.bbc.co.uk/1/hi/technology/3631350.stm > > "CipherTrust [...] found that 34% more spam is passing > SPF checks than > > legitimate e-mail." > > > > \Maex > > > > > > Date: Tue, 10 Aug 2004 19:55:57 -0400 (EDT) > From: Dean Anderson > To: 'IETF MARID WG' > Subject: Analysis of SPF benefits for reduced filtering > > > It has been reported that AOL is already using SPF to give reduced > filtering to SPF-using domains. Is this a good idea? > > IF you use SPF to provide less stringent anti-spam > processing, then you > are MORE vulnerable than you were before. You have shot > yourself in the > foot. Suppose for example that AOL subjects MSN users to > less stringent > anti-spam filtering because MSN uses SPF. MSN is still vulnerable to > viruses as it was before it used SPF, and it is just as vulnerable to > disposable account creation as it was before. Using SPF will > __attract__ > abusers to MSN, because they can get more spam through to > AOL, because it > is subject to less processing. Since AOL is doing less > processing on the > same spam, AOL users get more spam. SPF is bad for both companies. > > And of course, anyone who sets up a disposable domain can > also get spam > through to AOL by creating an SPF record for the domain. Disposable > domains along with disposable or stolen accounts is a major > problem now, > and it remains a major problem under SPF. > > Anything that reduces spam filtering without reducing the number of > abusers will be harmful. > > Basically, SPF gives abusers the opportunity to whitelist > themselves, or > the opportunity to identify ISPs that may be whitelisted. Any kind of > whitelist that is under the control of the sender, rather than the > recipient is also going to be ineffective and harmful. > > > Dean Anderson > Av8 Internet, Inc > > From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 12:30:40 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 MAA01527 for ; Thu, 9 Sep 2004 12:30: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 i89G0Y5O067708; Thu, 9 Sep 2004 09:00:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89G0Ygx067707; Thu, 9 Sep 2004 09:00:34 -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 i89G0XBF067700 for ; Thu, 9 Sep 2004 09:00:33 -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 i89GB5Kn003347; Thu, 9 Sep 2004 09:11:05 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i89GB59i003344; Thu, 9 Sep 2004 09:11:05 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 9 Sep 2004 09:11:05 -0700 (PDT) From: "william(at)elan.net" To: Michael Hammer cc: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers In-Reply-To: <7ae58c2204090908286db44d4@mail.gmail.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 Thu, 9 Sep 2004, Michael Hammer wrote: > AOL has NOT said they will do less stringent checking if you publish > an SPF record. What they have said is that in order to remain on their > whitelist (assuming you meet all of the other requirements) you must > publish SPF records. "A requires B" does not mean "B implies A" i.e. A; Thu, 9 Sep 2004 12:52: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 i89GFwaD069917; Thu, 9 Sep 2004 09:15: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 i89GFwAt069916; Thu, 9 Sep 2004 09:15:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89GFvMX069900 for ; Thu, 9 Sep 2004 09:15:58 -0700 (PDT) (envelope-from paf@cisco.com) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 09 Sep 2004 18:22:28 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i89GEi33029163; Thu, 9 Sep 2004 18:15:51 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 18:15:44 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 18:15:43 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> Cc: ietf-mxcomp@vpnc.org, Michael Hammer From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: SPF abused by spammers Date: Thu, 9 Sep 2004 18:15:40 +0200 To: "william(at)elan.net" X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 09 Sep 2004 16:15:44.0025 (UTC) FILETIME=[42004890:01C49688] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i89GFwMX069910 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sep 9, 2004, at 18:11, william(at)elan.net wrote: > On Thu, 9 Sep 2004, Michael Hammer wrote: > >> AOL has NOT said they will do less stringent checking if you publish >> an SPF record. What they have said is that in order to remain on their >> whitelist (assuming you meet all of the other requirements) you must >> publish SPF records. > > "A requires B" does not mean "B implies A" i.e. A B=A > > So in order to be on their whitelist AOL will require to have published > SPF records. However those that published SPF records don't automaticly > get to be on the AOL whitelist! It's pretty sad that people like the author of this article we got a link to still see 1:1 mapping between "remove spam" and "minimize the number of fake sender addresses". I thought "we" as a collective had educated enough people to not get articles like this. Sigh... More education needed, else any mechanism which try to stop fake sender addresses will fall in the same trap -- and be useless. We need ability to track spammers (i.e. more correct data about the sender), someone tracking and a legal system which penalizes the originator to show that "spam is not ok". All three things. One piece in the puzzle is not enough. paf Patrik Fältström Cisco Systems Consulting Engineer Corporate Consulting Engineering PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 13:10: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 NAA04754 for ; Thu, 9 Sep 2004 13:10:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89GcLk3071925; Thu, 9 Sep 2004 09:38:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89GcLhF071924; Thu, 9 Sep 2004 09:38:21 -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 i89GcIee071916 for ; Thu, 9 Sep 2004 09:38:19 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i89Gc8uL014162; Thu, 9 Sep 2004 09:38:09 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Sep 2004 09:38:08 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Tony Finch'" , ietf-mxcomp@imc.org Cc: Tony Finch Subject: RE: DEPLOY: not at the University of Cambridge Date: Thu, 9 Sep 2004 09:38:04 -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 Tony Finch > Most of these > reasons apply to all designated sender schemes, so we won't be > implementing SPF either. > As well as the alumni forwarding service, about 7% of our > message store > users forward their email off-site. These users are likely to lose > legitimate email because of Sender-ID checks at the > destination sites. Looks to me as if you can still deploy an SPF record that says that A, B & C are authentic university of Cambridge mail servers. What you are saying you cannot do is to add a final -all to exclude the universe of all other mail servers. This is supported by the spec. > We do not know how many of our users forward email to > Cambridge from other > sites, and it is very difficult to find out. We can only implement > Sender-ID checks if we also whitelist sites that forward to > Cambridge, in > order to avoid erroneously rejecting legitimate email. It will be > extremely difficult to create and maintain the whitelist, That is why most people who are going to use a whitelist are going to outsource the process. VeriSign has started making the Verified Domains List available to qualified anti-spam companies and we plan to make it available to everyone via a DNS publication mechanism in the near future. Both services are free. > The University is a federal organization with a strongly delegated > management structure. The Computing Service does not have a > monopoly over > the provision of email services, so the colleges and > departments use the > central email services to a greater or lesser extent at their > choice. We > would have to perform a much more detailed liaison exercise > than usual to > work out what the implications of implementing Sender-ID would be for > email travelling between the various parts of the University. What this says to me is that even though the central IT dept at Cambridge is not going to support Sender ID, the same is not necessarily true of the colleges. The more progressive colleges such as Porterhouse can choose to issue SenderID records for their domains even if central IT services do not. The ancient universities have barely come to terms with the consequences of the industrial revolution. If we consider the suitability of specifications on the basis of their ability to deploy we are not going to get very far. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 13:10:17 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 NAA04774 for ; Thu, 9 Sep 2004 13:10:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89GdNHU072002; Thu, 9 Sep 2004 09:39:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89GdNuk072001; Thu, 9 Sep 2004 09:39:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp2g.bellsouth.com (aismtp2g.bellsouth.com [139.76.165.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89GdMFd071973 for ; Thu, 9 Sep 2004 09:39:22 -0700 (PDT) (envelope-from Damon.Sauer@bellsouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp2g.bellsouth.com with ESMTP; Thu, 9 Sep 2004 12:39:15 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: SPF abused by spammers X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Thu, 9 Sep 2004 11:39:05 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB904F97647@bremocog-55> Thread-Topic: SPF abused by spammers Thread-Index: AcSWiW82lIglWcwVRGumiJbMVpk0MwAAdFKg From: "Sauer, Damon" To: "Hallam-Baker, Phillip" , "Dean Anderson" , "Markus Stumpf" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i89GdMFd071996 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Also by me. Please see my post dated: Wed, 5 Mar 2003. With particular attention to example. http://www1.ietf.org/mail-archive/web/asrg/current/msg00334.html Regards, Damon Sauer -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Thursday, September 09, 2004 11:46 AM To: 'Dean Anderson'; Markus Stumpf Cc: ietf-mxcomp@vpnc.org Subject: RE: SPF abused by spammers What percentage of the SPF authenticated spam is being trapped by the spam filters? The big advantage of authentication is that you are no longer forced to analyse at the message level. Even if you have zero third party data available you can arrive at general conclusions such as 'all mail from example.com is spam' or the opposite. Authentication alone is not a security solution. You also need authorization. This is what I was saying 18 months ago in my 'Plan for No Spam'. Phill > -----Original Message----- > From: Dean Anderson [mailto:dean@av8.com] > Sent: Thursday, September 09, 2004 10:59 AM > To: Markus Stumpf > Cc: ietf-mxcomp@vpnc.org > Subject: Re: SPF abused by spammers > > > > Isn't that what I said would happen? > > --Dean > > On Thu, 9 Sep 2004, Markus Stumpf wrote: > > > > > Justin Murdock posted this link on the qmail list: > > http://news.bbc.co.uk/1/hi/technology/3631350.stm > > "CipherTrust [...] found that 34% more spam is passing > SPF checks than > > legitimate e-mail." > > > > \Maex > > > > > > Date: Tue, 10 Aug 2004 19:55:57 -0400 (EDT) > From: Dean Anderson > To: 'IETF MARID WG' > Subject: Analysis of SPF benefits for reduced filtering > > > It has been reported that AOL is already using SPF to give reduced > filtering to SPF-using domains. Is this a good idea? > > IF you use SPF to provide less stringent anti-spam > processing, then you > are MORE vulnerable than you were before. You have shot > yourself in the > foot. Suppose for example that AOL subjects MSN users to > less stringent > anti-spam filtering because MSN uses SPF. MSN is still vulnerable to > viruses as it was before it used SPF, and it is just as vulnerable to > disposable account creation as it was before. Using SPF will > __attract__ > abusers to MSN, because they can get more spam through to > AOL, because it > is subject to less processing. Since AOL is doing less > processing on the > same spam, AOL users get more spam. SPF is bad for both companies. > > And of course, anyone who sets up a disposable domain can > also get spam > through to AOL by creating an SPF record for the domain. Disposable > domains along with disposable or stolen accounts is a major > problem now, > and it remains a major problem under SPF. > > Anything that reduces spam filtering without reducing the number of > abusers will be harmful. > > Basically, SPF gives abusers the opportunity to whitelist > themselves, or > the opportunity to identify ISPs that may be whitelisted. Any kind of > whitelist that is under the control of the sender, rather than the > recipient is also going to be ineffective and harmful. > > > Dean Anderson > Av8 Internet, Inc > > ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 13:17: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 NAA05318 for ; Thu, 9 Sep 2004 13:17:32 -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 i89GorMQ073200; Thu, 9 Sep 2004 09:50: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 i89GorqP073199; Thu, 9 Sep 2004 09:50:53 -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 i89Gor4I073193 for ; Thu, 9 Sep 2004 09:50:53 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i89GokSL015071; Thu, 9 Sep 2004 09:50:46 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Sep 2004 09:50:46 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Sauer, Damon'" , "Hallam-Baker, Phillip" , Dean Anderson , Markus Stumpf Cc: ietf-mxcomp@vpnc.org Subject: RE: SPF abused by spammers Date: Thu, 9 Sep 2004 09:50:39 -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: I claim absolutely no originality here. Butler Lampson was talking about Authentication/Authorization in the design of the MULTICS security system thirty years ago before email was invented. The only originality here might be here is changing the term authorization to accreditation due to the possible use of third party data. What I suspect has happened here is that the spammers have asked their arms providers for a SenderID work arround and this is what they have come up with. It does not have to work for the arms providers to get paid. I suspect that spammers are also adding SPF records in the hope that they can slow the adoption of SenderID by falsely claiming it is not going to work. If SenderID was not going to work they would not be as concerned as they clearly are. We have a reactive system here, we said all along that this would happen. disposable domains are a clear weakness in any authentication only solution. That is why we have to go further to accreditation - which I hope we will get to as soon as last call finishes. SenderID is the chasis, engine and wheels. We know that we also need bodywork before we have a complete car. Phill > -----Original Message----- > From: Sauer, Damon [mailto:Damon.Sauer@bellsouth.com] > Sent: Thursday, September 09, 2004 12:39 PM > To: Hallam-Baker, Phillip; Dean Anderson; Markus Stumpf > Cc: ietf-mxcomp@vpnc.org > Subject: RE: SPF abused by spammers > > > Also by me. Please see my post dated: Wed, 5 Mar 2003. With particular > attention to example. > > http://www1.ietf.org/mail-archive/web/asrg/current/msg00334.html > > Regards, > Damon Sauer > > > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Hallam-Baker, > Phillip > Sent: Thursday, September 09, 2004 11:46 AM > To: 'Dean Anderson'; Markus Stumpf > Cc: ietf-mxcomp@vpnc.org > Subject: RE: SPF abused by spammers > > > > What percentage of the SPF authenticated spam is being trapped by the > spam filters? > > The big advantage of authentication is that you are no longer > forced to > analyse at the message level. Even if you have zero third party > data available you can arrive at general conclusions such as > 'all mail from example.com is spam' or the opposite. > > Authentication alone is not a security solution. You also need > authorization. This is what I was saying 18 months ago in my > 'Plan for No Spam'. > > Phill > > > -----Original Message----- > > From: Dean Anderson [mailto:dean@av8.com] > > Sent: Thursday, September 09, 2004 10:59 AM > > To: Markus Stumpf > > Cc: ietf-mxcomp@vpnc.org > > Subject: Re: SPF abused by spammers > > > > > > > > Isn't that what I said would happen? > > > > --Dean > > > > On Thu, 9 Sep 2004, Markus Stumpf wrote: > > > > > > > > Justin Murdock posted this link on the qmail list: > > > http://news.bbc.co.uk/1/hi/technology/3631350.stm > > > "CipherTrust [...] found that 34% more spam is passing > > SPF checks than > > > legitimate e-mail." > > > > > > \Maex > > > > > > > > > > Date: Tue, 10 Aug 2004 19:55:57 -0400 (EDT) > > From: Dean Anderson > > To: 'IETF MARID WG' > > Subject: Analysis of SPF benefits for reduced filtering > > > > > > It has been reported that AOL is already using SPF to give reduced > > filtering to SPF-using domains. Is this a good idea? > > > > IF you use SPF to provide less stringent anti-spam > > processing, then you > > are MORE vulnerable than you were before. You have shot > > yourself in the > > foot. Suppose for example that AOL subjects MSN users to > > less stringent > > anti-spam filtering because MSN uses SPF. MSN is still > vulnerable to > > viruses as it was before it used SPF, and it is just as > vulnerable to > > disposable account creation as it was before. Using SPF will > > __attract__ > > abusers to MSN, because they can get more spam through to > > AOL, because it > > is subject to less processing. Since AOL is doing less > > processing on the > > same spam, AOL users get more spam. SPF is bad for both companies. > > > > And of course, anyone who sets up a disposable domain can > > also get spam > > through to AOL by creating an SPF record for the domain. Disposable > > domains along with disposable or stolen accounts is a major > > problem now, > > and it remains a major problem under SPF. > > > > Anything that reduces spam filtering without reducing the number of > > abusers will be harmful. > > > > Basically, SPF gives abusers the opportunity to whitelist > > themselves, or > > the opportunity to identify ISPs that may be whitelisted. > Any kind of > > whitelist that is under the control of the sender, rather than the > > recipient is also going to be ineffective and harmful. > > > > > > Dean Anderson > > Av8 Internet, Inc > > > > > > > ***** > The information transmitted is intended only for the person > or entity to which it is addressed and may contain > confidential, proprietary, and/or privileged material. Any > review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by > persons or entities other than the intended recipient is > prohibited. If you received this in error, please contact > the sender and delete the material from all computers. 113 > From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 14:55:14 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 OAA12017 for ; Thu, 9 Sep 2004 14:55: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 i89IL6AW081132; Thu, 9 Sep 2004 11:21: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 i89IL6tF081131; Thu, 9 Sep 2004 11:21:06 -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 i89IL3vN081122 for ; Thu, 9 Sep 2004 11:21:06 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 09 Sep 2004 14:21:04 -0400 id 0011B863.41409F11.0000264D Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: clarification on consensus call for compromise Date: Thu, 9 Sep 2004 14:21:03 -0400 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 There seems to be some confusion on the proposal on table and on the next steps which it implies. To clarify that, it seems important to step back a bit. The co-chairs have judged that there is no consensus to move forward with the documents as they entered last call. Since the issues with documents do not relate to the syntax of the record, the DNS-based mechanism, or the fundamental architecture (e.g. application of these tests by an MTA), the co-chairs have focused the next steps on how to retain the work which has garnered consensus and move forward. To do that, the co-chairs suggest that the existing documents be modified so that the group creates a standard that: describes the DNS-based mechanism, the MTA's application of tests, and a modified syntax which is explicitly scoped. In order to ensure that there are scopes for which there is no known IPR encumbrance, the co-chairs propose a new document describing a mail_from scope. The PRA scope would also be one of the scopes initially described, as there is clearly sufficient interest in checking pra to allow it to move forward as one among several scopes (interest being judged both on public statements and deployed code). An IANA registry for additional scopes created by Standards Track RFCs would be created. Under such a system, it would be up to the zone maintainer to determine which scopes to provide data on. It would be up to the MTA running the check to determine which checks to run. No single scope would be mandatory to provide or check; it would simply be mandatory that someone populating a record use a valid, registered scope. The existence of scopes which an MTA does not choose to check take up packet space in the DNS response, but have no other effect. While the existence of at least one mandatory to implement scope would be beneficial, the co-chairs do not see consensus emerging around any single scope during the lifetime of this group. In order not to abandon this work completely, the appropriate thing to do is to allow the fundamental mechanism move forward with the options that have emerged. Over time, deployment will tell us whether either of these scopes is successful. For a real consensus call on this proposal, new documents must be produced which describe it in full. Those would be based on the existing documents and the co-chairs anticipate that they would be closely related to the existing proposals, at least in regards to the elements of the system for which we already have consensus. The document authors have agreed to take on the work required to undertake the additional work to make this new attempt to reach overall consensus. This is not a call for alternate suggestions, nor is it a consensus call on the documents which have not yet been produced. It is the chairs' work plan for meeting this chartered goal of this working group: Aug 04 Submit working group document on MTA Authorization Record in DNS to PS Once the documents have been produced, working group discussion of the protocol engineering and deployment will proceed using the same subject line headers as before, and we will move through that discussion to a second last call. -andy, co-chair of MARID From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 15:16: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 PAA14125 for ; Thu, 9 Sep 2004 15:16: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 i89Ic5t2083507; Thu, 9 Sep 2004 11:38: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 i89Ic5Zi083506; Thu, 9 Sep 2004 11:38:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Ic4gp083500 for ; Thu, 9 Sep 2004 11:38:05 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C5To2-00059T-00; Thu, 09 Sep 2004 11:38:02 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16704.41738.510079.625670@proton.pathname.com> Date: Thu, 9 Sep 2004 11:38:02 -0700 To: Stephane Bortzmeyer Cc: Daniel Quinlan , Andrew Newton , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <20040909132112.GB28026@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <20040909132112.GB28026@nic.fr> X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel Quinlan wrote: >> If patent-encumbered stuff (PRA) is any part of the specification >> (and I see it mentioned in your proposal), then the ASF (including >> the SpamAssassin and JAMES projects) vehemently objects. Stephane Bortzmeyer writes: > Even if, while mentioned in the specification, it is optional and can > be ommitted at will? Yes, I think so. I understand the fine distinction you are trying to make with this proposal, but it appears to be a back door (and I don't think you are trying to be deliberately harmful to open source) for the IETF to standardize a patent-encumbered technology in order to push Sender ID out the door as soon as possible. In the end, it would become a de-facto requirement as the proposal stands. Also, it is not certain that the patent will be invalidated or that anyone will have the resources to invalidate it, so relying on that strategy as part of the reasoning for this proposal is not a valid argument. Still, it's possible the license will be fixed and this will become a moot point. (I still would like to see the scope become modular as I noted in one of my earlier technical last call comments.) We want some method to parse RFC 2822 headers to be part of the standard. However, PRA is off limits to us due to how the license is currently designed. An unencumbered method to authenticate RFC 2822 messages that is permitted and encouraged is needed. I believe that the "experimental" PRA standard will end up an effective requirement, especially given the intense campaign of the last few weeks to get companies behind the encumbered standard. >> Given that there is a lack of consensus on PRA, it seems like the >> best course is drop PRA entirely and allow the specification authors >> to revise things a bit more freely again. > Crypto-related standards (a field crippled with patents) often use the > very same method to allow interesting (but potentially infringing) > algorithms. If the field of crypto is crippled with patents, are you keen on doing the same to email? > See RFC 2246 for instance. You do not object against it because it > mentions the patented IDEA? False analogy. There are many alternatives to IDEA that do basically the same thing and a bunch of them are mentioned in RFC 2246. In addition, nobody needs IDEA to authenticate email as best possible. If PRA is implicitly the way you connect RFC 2822 with Sender ID, then email systems will be required to support it: - at send time, to conform with systems that use PRA at receive time (even when not desired) - at receive time, to conform with sites that only send with the PRA scope It seems likely it will become a requirement by virtue of how it is used and because there is no alternative being pursued by the IETF. I think we can find a way to resolve this (either replacing PRA with an unencumbered alternative or an open license on the PRA patent(s)), but relying on the patent going away is wishful thinking. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 15:18:44 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 PAA14544 for ; Thu, 9 Sep 2004 15:18: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 i89IpeGE084748; Thu, 9 Sep 2004 11:51:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89Ipdhf084747; Thu, 9 Sep 2004 11:51:39 -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 i89Ipc6r084737 for ; Thu, 9 Sep 2004 11:51:39 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 21892 invoked by uid 1013); 9 Sep 2004 18:51:41 -0000 Date: Thu, 9 Sep 2004 20:51:41 +0200 From: Markus Stumpf To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers Message-ID: <20040909185141.GE44802@Space.Net> References: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.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: Content-Transfer-Encoding: 8bit On Thu, Sep 09, 2004 at 06:15:40PM +0200, Patrik Fältström wrote: > More education needed, else any mechanism which try to stop fake sender > addresses will fall in the same trap -- and be useless. We need ability > to track spammers (i.e. more correct data about the sender), someone > tracking and a legal system which penalizes the originator to show that > "spam is not ok". All three things. One piece in the puzzle is not > enough. IMHO we need something different first. If in real life you throw 100,000 letters on the street no postman will collect and deliver them to the recipients. You have to carry them somewhere like a post office to get them distributed and delivered. A postman will only accept letters and put them in his bag if they are from a "official" post office. The disadvantage of the SMTProtocol is that there is no way for a MTA (as opposed to MSA and MDA) whether the party putting letters in his mailbag is a "official" post office or just some random user. So what we really need is a method for a MTA to tell the difference. DE has 6.9 millions registered domains and according to a survey of Peter Koch (it is in the archives of this list) there are about 150,000 unique IP addresses of MX hosts for that domains. With each TLD added the percentage will decrease, as a lot of MX hosts act for domain pools like example.{com,net,org,ccTLD,...} In DE the ratio domains to MXhosts is 2.1% and with all existing domains on the Internet it may drop to 1.5%. I think it is not an assumption with a large error ration (at least it is in the same order of magnitude) to assume that the number of sending IP addresses ~ number of IP addresses of MX hosts. IMHO that is a data set that is more workable with, even more as the control is with people that tend to know what they are doing (i.e. managing a MTA). So IMHO Mta Authorization Records In Dns (MARID) should have dealt foremost with the fact to provide the information in DNS if an IP is a mailserver at all. That way we would have received the number of "mailservers" (or lookalikes) from 4,000,000,000 to about 600,000? Yeah I know all the gossip about "marking in rev DNS is bad as rev DNS is poorly maintained". Now, how much "legitimate" mailservers have broken revDNS records? And this is all that is important, if the revDNS for "legitimate" mailservers is also "poorly maintained". But industry and the big money are all for anti spoofing of domain names to protect their customers. But as long as the software industry, on which this solutions depend, produces software like described in http://weblog.infoworld.com/udell/2004/03/23.html this authorization thingy will reduce the success of spoofers and phishers by exactly 0 percent. Sure - as someone has written in this thread - spammers (ab)using SPF help to block their IP addresses, but with spammers running botnets of 100,000s of infected hosts I don't think they really care about that fact at all. Rather they sit there having a good time and laughing about all those heated discussions about patents and methods of authorization they do not at all care about. At least not for another 5-10 years. The spam problem is more then 10 years old (Cantor and Siegel was 1994) and now look how far we have already come in the last 10 years. Currently my maillog show that the spam problem is worse than ever. \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 Thu Sep 9 16:01: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 QAA19290 for ; Thu, 9 Sep 2004 16:01: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 i89JVntZ087930; Thu, 9 Sep 2004 12:31: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 i89JVnOM087929; Thu, 9 Sep 2004 12:31:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts20-srv.bellnexxia.net (tomts20-srv.bellnexxia.net [209.226.175.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89JVm80087923 for ; Thu, 9 Sep 2004 12:31:48 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.196]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040909193151.LZQA19123.tomts20-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 9 Sep 2004 15:31:51 -0400 From: "John Glube" To: "'Dave Crocker'" , "'Andrew Newton'" Cc: "'IETF MARID WG'" Subject: RE: consensus call on pra/mailfrom deployment and versioning/scope Date: Thu, 9 Sep 2004 15:29:37 -0400 Message-ID: <009601c496a3$58ab6640$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <728466010.20040909055254@brandenburg.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i89JVm80087924 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Andy, You asked: The question before the working group: assuming no technical errors with the above, is there anybody who vehemently objects with this proposal? My comment is not a vehement objection, but rather a strong suggestion. Having strongly supported Dave Crocker's earlier suggestion of a security and operations review of Sender-ID by graybeards, I second Dave's suggestion, adopt his reasoning and strongly support the request that the co-chairs have a security and operations review carried out by graybeards on any proposal for pra/mailfrom checks before the draft specifications go through last call. As a secondary matter, I simply note the draft patent license contains the following restriction: Microsoft ... hereby grant You a perpetual ...worldwide license under Microsoft’s Necessary Claims to use ... object code versions of Licensed Implementations only as incorporated into Licensed Products and solely for the purpose of conforming with the Sender ID Specification. (See section 2.1 of the draft Patent License.) My read of the last restriction ... "and solely for the purpose of conforming with the Sender ID Specification" precludes "object code versions of Licensed Implementations only as incorporated into Licensed Products" being used for any other purpose except to "conform with the Sender ID Specification." (The Sender ID Specification being defined as the combination of draft-marid-pra with draft-marid-core.) I presume a proposal which includes both pra and mailfrom checks would involve elements of draft-marid-pra and draft-marid-core, so giving rise to Microsoft's IPR claim and the draft patent license with the noted restriction. As such, the restriction contained in the draft patent Sender-ID license would preclude network administrators from incorporating both mailfrom and pra checks without obtaining separate permission from Microsoft. On this point, please note the following Q & A from Microsoft's FAQ: Q8: What if I want to use the Sender ID technology in some other context, still related to email but perhaps not related to Sender ID? Will Microsoft sue me? A8: Microsoft is committed to working with companies in a collaborative way to license our Intellectual Property (see http://www.microsoft.com/mscorp/ip/). If Microsoft is granted patent rights that cover the Sender ID specification (currently pending) it will make those rights available at no cost for anyone to implement and use the Sender ID specification. Microsoft will need to see what patent rights are granted by the US Patent and Trademark Office to even know for sure what rights it has to offer. Since it is impossible to contemplate every possible use of it Sender ID patent rights we cannot make a commitment up front to specific license terms. We invite anyone interested in using Microsoft’s IP to innovate and compete in the marketplace to come talk to us. In the circumstances, should the WG wish to proceed with a protocol which incorporates both pra/mailfrom checking based on one version with multiple scopes, I urge the WG co-chairs to seek clarification from Microsoft on this point. Why? Because if my understanding is correct, it means software developers cannot access the Microsoft Necessary Claims under the draft Sender-ID patent license to develop object code which allows for pra/mailfrom checking without getting a further license from Microsoft, which may or may not be forthcoming. In turn as matters now stand, without clarification from Microsoft, this would seem to be a further impediment to widespread implementation of this proposal. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.752 / Virus Database: 503 - Release Date: 03/09/2004 From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 16:03:14 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 QAA19429 for ; Thu, 9 Sep 2004 16:03:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89JVNDG087890; Thu, 9 Sep 2004 12:31:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89JVNII087889; Thu, 9 Sep 2004 12:31:23 -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 i89JVKgD087869 for ; Thu, 9 Sep 2004 12:31:20 -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 D5E57414C4; Thu, 9 Sep 2004 12:31:20 -0700 (PDT) Subject: RE: SPF abused by spammers From: Douglas Otis To: "Sauer, Damon" Cc: Dean Anderson , Markus Stumpf , MARID In-Reply-To: <38363D9940D92A458010AAE24D162EB904F97563@bremocog-55> References: <38363D9940D92A458010AAE24D162EB904F97563@bremocog-55> Content-Type: text/plain Message-Id: <1094758280.16741.169.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 09 Sep 2004 12:31:20 -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-09-09 at 08:07, Sauer, Damon wrote: > Dean, > > You are missing where this is a GOOD thing. We WANT spammers to use > SPF. This will allow us to identify, publish, process, shred, pillage, burn, > destroy the IP addresses that this stuff is coming from. Nobody is doing > less stringent processing of the email that passes an SPF check. It just > makes it easier to block when identified. How do you know the spammer has not bothered to include addresses of legitimate MTAs? The obvious adaptive strategy would be to disrupt this presumptive use of spammer's information as-if it were trustworthy. > The checks that I DON'T have to do are against the received from: > headers. I already know. If you want to call this 'reducing filtering' > so be it. But it is a reduction because the check that you used to have > to run is no longer necessary. The value of SPF is clear when white-listing as a means for reducing false negative assessments. SPF will never serve as a tool for blacklisting for what should be obvious reasons. There is a risk presuming the domain identified using SPF has not been spoofed somewhere in the mail channel. SPF does not allow the IP address to be trusted to allow address blacklisting beyond the current connection, nor does SPF really allow the MAIL FROM mailbox domain be trusted to a degree that would allow name blacklisting, as it fails to accurately identify the entity introducing the message. The mail channel is often shared and there is no means to verify the channel is being checked at either end of the administrative realms. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 16:43: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 QAA27370 for ; Thu, 9 Sep 2004 16:43:32 -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 i89KGMOE092121; Thu, 9 Sep 2004 13:16:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89KGMao092120; Thu, 9 Sep 2004 13:16:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp2g.bellsouth.com (aismtp2g.bellsouth.com [139.76.165.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89KGM0D092099 for ; Thu, 9 Sep 2004 13:16:22 -0700 (PDT) (envelope-from Damon.Sauer@bellsouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp2g.bellsouth.com with ESMTP; Thu, 9 Sep 2004 16:16:17 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: SPF abused by spammers X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Thu, 9 Sep 2004 15:16:05 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB90521CF31@bremocog-55> Thread-Topic: SPF abused by spammers Thread-Index: AcSWo6WRzU+NmCfhT7eMgepCQHry0gABZq5Q From: "Sauer, Damon" To: "Douglas Otis" Cc: "Dean Anderson" , "Markus Stumpf" , "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i89KGM0D092115 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > You are missing where this is a GOOD thing. We WANT spammers to use > > SPF. This will allow us to identify, publish, process, > shred, pillage, > > burn, destroy the IP addresses that this stuff is coming > from. Nobody > > is doing less stringent processing of the email that passes an SPF > > check. It just makes it easier to block when identified. > > How do you know the spammer has not bothered to include addresses of > legitimate MTAs? The obvious adaptive strategy would be to > disrupt this presumptive use of spammer's information as-if > it were trustworthy. I am not looking at the SPF record at this point. I am looking at the IP address they connected from. Am I misunderstanding your question? This just seems too obvious to me. > > > The checks that I DON'T have to do are against the received from: > > headers. I already know. If you want to call this 'reducing > filtering' > > so be it. But it is a reduction because the check that you used to > > have to run is no longer necessary. > > The value of SPF is clear when white-listing as a means for > reducing false negative assessments. > > SPF will never serve as a tool for blacklisting for what > should be obvious reasons. There is a risk presuming the > domain identified using SPF has not been spoofed somewhere in > the mail channel. SPF does not allow the IP address to be > trusted to allow address blacklisting beyond the current > connection, nor does SPF really allow the MAIL FROM mailbox > domain be trusted to a degree that would allow name > blacklisting, as it fails to accurately identify the entity > introducing the message. The mail channel is often shared > and there is no means to verify the channel is being checked > at either end of the administrative realms. > Please provide an example of how this would happen. I am completely missing your chain of thought. Regards, Damon Sauer ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 17:08: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 RAA00417 for ; Thu, 9 Sep 2004 17:08:45 -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 i89Kh49P094952; Thu, 9 Sep 2004 13:43: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 i89Kh49g094951; Thu, 9 Sep 2004 13:43:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Kh3gg094924 for ; Thu, 9 Sep 2004 13:43:03 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 20:43:01 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" , Subject: RE: SPF abused by spammers Date: Thu, 9 Sep 2004 14:43:23 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040909131842.GV44802@Space.Net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-OriginalArrivalTime: 09 Sep 2004 20:43:01.0712 (UTC) FILETIME=[99351D00:01C496AD] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Markus Stumpf wrote: >Justin Murdock posted this link on the qmail list: > http://news.bbc.co.uk/1/hi/technology/3631350.stm > "CipherTrust [...] found that 34% more spam is passing SPF checks > than legitimate e-mail." I suggest everyone else do what I did. I clicked on the "Feedback" link up at the top and filled out the form as follows. YOUR COMMENT IS ABOUT: Factual Errors URL: http://news.bbc.co.uk/1/hi/technology/3631350.stm YOUR COMMENT: In your article "Spammers exploit anti-spam trap", you completely missed the point of SPF. Instead of reporting the use of SPF as a positive, you portrayed it as a negative. We WANT spammers to use SPF, because then they are easy to identify. If 100% of spammers used SPF, I could easily blacklist all e-mail coming from their domains, and then I'd receive no spam. Please make a better effort to consult technical experts before making a report. Several others in the media got the story right (or came close), and it is very disheartening to see that the BBC (which I rely on for unbiased reporting) got it completely wrong. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 17:10: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 RAA00783 for ; Thu, 9 Sep 2004 17:10: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 i89KiI8L095075; Thu, 9 Sep 2004 13:44: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 i89KiIru095074; Thu, 9 Sep 2004 13:44:18 -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 i89KiHYB095067 for ; Thu, 9 Sep 2004 13:44:18 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id A169826C07F; Thu, 9 Sep 2004 22:44:21 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id CCF9B26C070; Thu, 9 Sep 2004 22:44:19 +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 i89KiJm7737758; Thu, 9 Sep 2004 22:44:19 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 6BEA4FACE; Thu, 9 Sep 2004 22:44:19 +0200 (CEST) Date: Thu, 9 Sep 2004 22:44:19 +0200 From: Stephane Bortzmeyer To: David Woodhouse Cc: Stephane Bortzmeyer , Mark Lentczner , IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040909204419.GA30390@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <9BC4046C-01DD-11D9-BB96-000393A56BB6@glyphic.com> <20040909131621.GA28026@nic.fr> <1094738193.4083.1603.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094738193.4083.1603.camel@hades.cambridge.redhat.com> 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 Thu, Sep 09, 2004 at 02:56:33PM +0100, David Woodhouse wrote a message of 16 lines which said: > > That's strange. If you publish a SPF record for example.com, surely > > mail.example.com (the name you announce in HELO) has a SPF record, > > too? > > strcmp("example.com", "mail.example.com"); > > As Mark said, they don't _share_ a record. They each have their own. Well apparently, my english was not good enough to make me clear. 1) When you publish a SPF (I said SPF, not SenderID) record for example.com, if your mail server is mail.example.com, you *also* publish a SPF record for mail.example.com. Always. Otherwise, there is a trivial way of spoofing you. 2) Since you already have a SPF record for both names, adding the HELO check in SenderID changes nothing. You already had the two records. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 17:58: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 RAA05892 for ; Thu, 9 Sep 2004 17:58: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 i89LVBT9001615; Thu, 9 Sep 2004 14:31: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 i89LVBSE001614; Thu, 9 Sep 2004 14:31:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89LUpKM001536 for ; Thu, 9 Sep 2004 14:31:10 -0700 (PDT) (envelope-from SRS0+f886827e478a41955cdc+382+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C5WVD-0004rV-SM; Thu, 09 Sep 2004 22:30:47 +0100 Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope From: David Woodhouse To: Stephane Bortzmeyer Cc: Mark Lentczner , IETF MARID WG In-Reply-To: <20040909204419.GA30390@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <9BC4046C-01DD-11D9-BB96-000393A56BB6@glyphic.com> <20040909131621.GA28026@nic.fr> <1094738193.4083.1603.camel@hades.cambridge.redhat.com> <20040909204419.GA30390@nic.fr> Content-Type: text/plain Message-Id: <1094765447.9144.14.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Thu, 09 Sep 2004 22:30:47 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-09-09 at 22:44 +0200, Stephane Bortzmeyer wrote: > 2) Since you already have a SPF record for both names, adding the HELO > check in SenderID changes nothing. You already had the two records. I suspect we're in agreement. The point is they should be separate. SPF 'classic' didn't get this right. Recipients should not infer anything about HELO from the RFC2821 record, and vice versa. The latter being the more important to me -- I'm happy enough to publish records stating who may HELO with my hostnames but until/unless the whole world (including those who haven't even discovered ESMTP yet) upgrades to the Brave New World neither the RFC2821 nor RFC2822 records are workable. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 18:02: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 SAA06163 for ; Thu, 9 Sep 2004 18:02: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 i89LXU1o001879; Thu, 9 Sep 2004 14:33: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 i89LXUMO001878; Thu, 9 Sep 2004 14:33:30 -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 i89LXUVP001872 for ; Thu, 9 Sep 2004 14:33:30 -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 ECDF14149B; Thu, 9 Sep 2004 14:33:34 -0700 (PDT) Subject: RE: SPF abused by spammers From: Douglas Otis To: "Sauer, Damon" Cc: Dean Anderson , Markus Stumpf , MARID In-Reply-To: <38363D9940D92A458010AAE24D162EB90521CF31@bremocog-55> References: <38363D9940D92A458010AAE24D162EB90521CF31@bremocog-55> Content-Type: text/plain Message-Id: <1094765614.16741.225.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 09 Sep 2004 14:33: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 Thu, 2004-09-09 at 13:16, Sauer, Damon wrote: > > > You are missing where this is a GOOD thing. We WANT spammers to use > > > SPF. This will allow us to identify, publish, process, shred, > > > pillage, burn, destroy the IP addresses that this stuff is coming > > > from. Nobody is doing less stringent processing of the email that > > > passes an SPF check. It just makes it easier to block when > > > identified. > > > > How do you know the spammer has not bothered to include addresses of > > legitimate MTAs? The obvious adaptive strategy would be to > > disrupt this presumptive use of spammer's information as-if > > it were trustworthy. > > I am not looking at the SPF record at this point. I am looking at the > IP address they connected from. If the mailbox domain has been safely blacklisted, then no confirmation with respect to the IP address from the SPF records is needed. Should abusive mail be discovered, it would be unsafe to conclude the SPF mailbox-domain/IP address confirmation is tenable for establishing a name blacklist. Only the IP address has received sufficient authentication for such a listing, but then this has not improved upon current IP address blacklisting. > Am I misunderstanding your question? This just seems too obvious to me. If you are only looking at the address, then there is no advantage obtained using SPF records. > > > The checks that I DON'T have to do are against the received from: > > > headers. I already know. If you want to call this 'reducing > > > filtering' so be it. But it is a reduction because the check that > > > you used to have to run is no longer necessary. This would seem to imply you are checking the mailbox domains? > > The value of SPF is clear when white-listing as a means for > > reducing false negative assessments. > > > > SPF will never serve as a tool for blacklisting for what > > should be obvious reasons. There is a risk presuming the > > domain identified using SPF has not been spoofed somewhere in > > the mail channel. SPF does not allow the IP address to be > > trusted to allow address blacklisting beyond the current > > connection, nor does SPF really allow the MAIL FROM mailbox > > domain be trusted to a degree that would allow name > > blacklisting, as it fails to accurately identify the entity > > introducing the message. The mail channel is often shared > > and there is no means to verify the channel is being checked > > at either end of the administrative realms. > > Please provide an example of how this would happen. I am completely > missing your chain of thought. There are many cases where an MTA is shared. This may be due to transparent interception, virtual hosting, ports blocked by providers, where many of these configurations ARE effective at curtailing abuse. If one of these MTAs is not checking against the SPF record, or the SPF record is open, then there is no assurance a mailbox-domain appears on account of the entity that published the SPF record. There is no indication a check has been made, nor that the MTA is being shared. A breach in the mail channel integrity can happen within either the receiving or sending realm. An SPF blacklisting fails to locate the accountable entity. Beyond white-listing, SPF may even be viewed as dangerous, when there are expectations more can be obtained using this mechanism than is safe. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 18:23: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 SAA09611 for ; Thu, 9 Sep 2004 18:23: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 i89LuwgY004312; Thu, 9 Sep 2004 14:56: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 i89LuwPO004311; Thu, 9 Sep 2004 14:56:58 -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 i89LuvR4004303 for ; Thu, 9 Sep 2004 14:56:57 -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 i89M7mYE018872; Thu, 9 Sep 2004 15:07:48 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i89M7m7k018869; Thu, 9 Sep 2004 15:07:48 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 9 Sep 2004 15:07:48 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: clarification on consensus call for compromise In-Reply-To: <01F77AC2-028D-11D9-BE4C-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: I don't know if there was any confusion, but it appears I understood you perfectly and answered with negative exactly based on that correct understanding that group is going to standartize scopes without any hope that they will be able to be used worldwide - this is not a a way to create a "standard". Your calls for letting market decide if any "scope" is sucessfull also suggests that we'll not have a standard for a while (until the market made the decision...) As such the working group documents for each scope should be listed as EXPERIMENTAL while only the protocol should be listed as STANDARD when they are submitted to RFC editor for publication. That means that IANA registry should be maintained not only for STANDARD track RFCs related to scope but for EXPERIMENTAL ones as well - and it is probably best that IANA registry is setup to make such distinction, i.e. SPF Scope Status and description ------------------------------------------------- MAILFROM Authorization to use RFC2821 Mail From by SMTP clients as desribed by EXPERIMENTAL RFCxxxx On Thu, 9 Sep 2004, Andrew Newton wrote: > There seems to be some confusion on the proposal on table and on > the next steps which it implies. To clarify that, it seems important > to step back a bit. The co-chairs have judged that there is no > consensus > to move forward with the documents as they entered last call. Since > the issues with documents do not relate to the syntax of the record, > the DNS-based mechanism, or the fundamental architecture (e.g. > application of these tests by an MTA), the co-chairs have focused the > next steps on how to retain the work which has garnered consensus > and move forward. To do that, the co-chairs suggest that the existing > documents be modified so that the group creates a standard that: > describes the DNS-based mechanism, the MTA's application > of tests, and a modified syntax which is explicitly scoped. > > In order to ensure that there are scopes for which there is no known > IPR encumbrance, the co-chairs propose a new document describing > a mail_from scope. The PRA scope would also be one of the scopes > initially > described, as there is clearly sufficient interest in checking pra to > allow it to move forward as one among several scopes (interest being > judged both on public statements and deployed code). An IANA registry > for additional scopes created by Standards Track RFCs would be created. > > Under such a system, it would be up to the zone maintainer to determine > which scopes to provide data on. It would be up to the MTA running > the check to determine which checks to run. No single scope would > be mandatory to provide or check; it would simply be mandatory that > someone populating a record use a valid, registered scope. The > existence of scopes which an MTA does not choose to check take up > packet space in the DNS response, but have no other effect. While > the existence of at least one mandatory to implement scope would > be beneficial, the co-chairs do not see consensus emerging around > any single scope during the lifetime of this group. In order not > to abandon this work completely, the appropriate thing to do is > to allow the fundamental mechanism move forward with the options > that have emerged. Over time, deployment will tell us whether either > of these scopes is successful. > > For a real consensus call on this proposal, new documents must > be produced which describe it in full. Those would be based on > the existing documents and the co-chairs anticipate that they would > be closely related to the existing proposals, at least in regards to > the elements of the system for which we already have consensus. > The document authors have agreed to take on the work required to > undertake the additional work to make this new attempt to reach > overall consensus. > > This is not a call for alternate suggestions, nor is it a consensus call > on the documents which have not yet been produced. It is the > chairs' work plan for meeting this chartered goal of this working > group: > > Aug 04 Submit working group document on MTA Authorization Record in DNS > to PS > > Once the documents have been produced, working group discussion of the > protocol engineering and deployment will proceed using the same subject > line headers as before, and we will move through that discussion to a > second > last call. > > -andy, co-chair of MARID From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 18:26: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 SAA09971 for ; Thu, 9 Sep 2004 18:26: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 i89LvtWS004390; Thu, 9 Sep 2004 14:57:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89Lvtuu004389; Thu, 9 Sep 2004 14:57:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.kerio.com (adsl-67-127-65-201.dsl.snfc21.pacbell.net [67.127.65.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89LvtUt004379 for ; Thu, 9 Sep 2004 14:57:55 -0700 (PDT) (envelope-from mkanat@kerio.com) Received: from [10.0.0.120] ([10.0.0.120]) (authenticated user mkanat@us.kerio.com) by mail.kerio.com (Kerio MailServer 6.0.1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Thu, 9 Sep 2004 14:57:57 -0700 Subject: Re: clarification on consensus call for compromise From: Max Kanat-Alexander To: IETF MARID WG Cc: Andrew Newton In-Reply-To: <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> References: <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> Content-Type: text/plain Organization: Kerio Technologies, Inc. Message-Id: <1094767077.5605.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 09 Sep 2004 14:57:57 -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-09-09 at 11:21, Andrew Newton wrote: > Under such a system, it would be up to the zone maintainer to determine > which scopes to provide data on. It would be up to the MTA running > the check to determine which checks to run. Does the IPR really cover the syntax of the published record? I thought the only significant IPR was the PRA algorithm itself, on the MTA side. Why not just leave the IPR question only in the hands of the MTA folks, and just let people publish their records unscoped? Would there be specific examples in which this would cause a terrible problem? I think that would make deployment much easier. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 19:01: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 TAA14100 for ; Thu, 9 Sep 2004 19:00: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 i89Mc2km008321; Thu, 9 Sep 2004 15:38: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 i89Mc26n008320; Thu, 9 Sep 2004 15:38:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Mc1ha008313 for ; Thu, 9 Sep 2004 15:38:01 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i89Mbv57006221; Thu, 9 Sep 2004 15:37:57 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i89Mbr1I004655; Thu, 9 Sep 2004 15:37:55 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <1094767077.5605.5.camel@localhost.localdomain> References: <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> <1094767077.5605.5.camel@localhost.localdomain> Date: Thu, 9 Sep 2004 15:37:52 -0700 To: Max Kanat-Alexander , IETF MARID WG From: Ted Hardie Subject: Re: clarification on consensus call for compromise Cc: Andrew Newton Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:57 PM -0700 9/9/04, Max Kanat-Alexander wrote: >On Thu, 2004-09-09 at 11:21, Andrew Newton wrote: >> Under such a system, it would be up to the zone maintainer to determine >> which scopes to provide data on. It would be up to the MTA running >> the check to determine which checks to run. > > Does the IPR really cover the syntax of the published record? I thought >the only significant IPR was the PRA algorithm itself, on the MTA side. >Why not just leave the IPR question only in the hands of the MTA folks, >and just let people publish their records unscoped? An unscoped record would be meaningless, as the MTA checking the record would not know which identity was at issue. This has been covered before; please read the archives. regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 19:32: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 TAA16700 for ; Thu, 9 Sep 2004 19:32: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 i89MxtZV011378; Thu, 9 Sep 2004 15:59:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89MxtZ2011377; Thu, 9 Sep 2004 15:59:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Mxs57011371 for ; Thu, 9 Sep 2004 15:59:55 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i89Mxkgj024142 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Sep 2004 18:59:47 -0400 Date: Thu, 9 Sep 2004 18:59:46 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Sauer, Damon" cc: Markus Stumpf , Subject: RE: SPF abused by spammers In-Reply-To: <38363D9940D92A458010AAE24D162EB904F97563@bremocog-55> 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, 9 Sep 2004, Sauer, Damon wrote: > Dean, > > You are missing where this is a GOOD thing. We WANT spammers to use > SPF. > This will allow us to identify, publish, process, shred, pillage, burn, > destroy the IP addresses that this stuff is coming from. Nobody is doing > less stringent processing of the email that passes an SPF check. It just > makes it easier to block when identified. SPF doesn't make it easier to identify spammers. > The checks that I DON'T have to do are against the received from: > headers. I already know. If you want to call this 'reducing filtering' > so be it. But it is a reduction because the check that you used to have > to run is no longer necessary. > > Regards, > Damon Sauer > > > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Dean Anderson > Sent: Thursday, September 09, 2004 10:59 AM > To: Markus Stumpf > Cc: ietf-mxcomp@vpnc.org > Subject: Re: SPF abused by spammers > > > > Isn't that what I said would happen? > > --Dean > > On Thu, 9 Sep 2004, Markus Stumpf wrote: > > > > > Justin Murdock posted this link on the qmail list: > > http://news.bbc.co.uk/1/hi/technology/3631350.stm > > "CipherTrust [...] found that 34% more spam is passing SPF checks > than > > legitimate e-mail." > > > > \Maex > > > > > > Date: Tue, 10 Aug 2004 19:55:57 -0400 (EDT) > From: Dean Anderson > To: 'IETF MARID WG' > Subject: Analysis of SPF benefits for reduced filtering > > > It has been reported that AOL is already using SPF to give reduced > filtering to SPF-using domains. Is this a good idea? > > IF you use SPF to provide less stringent anti-spam processing, then you > are MORE vulnerable than you were before. You have shot yourself in the > foot. Suppose for example that AOL subjects MSN users to less stringent > anti-spam filtering because MSN uses SPF. MSN is still vulnerable to > viruses as it was before it used SPF, and it is just as vulnerable to > disposable account creation as it was before. Using SPF will > __attract__ abusers to MSN, because they can get more spam through to > AOL, because it is subject to less processing. Since AOL is doing less > processing on the same spam, AOL users get more spam. SPF is bad for > both companies. > > And of course, anyone who sets up a disposable domain can also get spam > through to AOL by creating an SPF record for the domain. Disposable > domains along with disposable or stolen accounts is a major problem now, > and it remains a major problem under SPF. > > Anything that reduces spam filtering without reducing the number of > abusers will be harmful. > > Basically, SPF gives abusers the opportunity to whitelist themselves, or > the opportunity to identify ISPs that may be whitelisted. Any kind of > whitelist that is under the control of the sender, rather than the > recipient is also going to be ineffective and harmful. > > > Dean Anderson > Av8 Internet, Inc > > > > ***** > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 > > > From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 19:38: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 TAA17086 for ; Thu, 9 Sep 2004 19:38:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89NE8cZ012775; Thu, 9 Sep 2004 16:14: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 i89NE8oN012774; Thu, 9 Sep 2004 16:14:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89NE7uP012766 for ; Thu, 9 Sep 2004 16:14:08 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i89NEBqs024420 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Sep 2004 19:14:12 -0400 Date: Thu, 9 Sep 2004 19:14:11 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Douglas Otis cc: "Sauer, Damon" , Markus Stumpf , MARID Subject: RE: SPF abused by spammers In-Reply-To: <1094758280.16741.169.camel@ddev.mail-abuse.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 9 Sep 2004, Douglas Otis wrote: > On Thu, 2004-09-09 at 08:07, Sauer, Damon wrote: > > Dean, > > > > You are missing where this is a GOOD thing. We WANT spammers to use > > SPF. This will allow us to identify, publish, process, shred, pillage, burn, > > destroy the IP addresses that this stuff is coming from. Nobody is doing > > less stringent processing of the email that passes an SPF check. It just > > makes it easier to block when identified. > > How do you know the spammer has not bothered to include addresses of > legitimate MTAs? The obvious adaptive strategy would be to disrupt this > presumptive use of spammer's information as-if it were trustworthy. Yep. Suppose you have a piece of spam. You look at the from address. Can you check the SPF record for that domain? No. Its probably changed between the time the message was sent and the time you looked at it. You can check the original IP address that your MTA logged in the received header. But YOU COULD DO THAT BEFORE. I don't think I'm the only one thinking "duh!" just about now. You might as well go back to domain name blocking. But YOU COULD DO THAT BEFORE, too. (another big "duh!". We don't do that because spammers send from big ISPs that we can't block, or use viruses to steal resources from innocent domains. Or use disposable accounts. --Dean > The value of SPF is clear when white-listing as a means for reducing > false negative assessments. There is already a two line rule for sendmail and other MTAs to do IP based whitelisting, and great software, called rbldns. I don't see a benefit in replacing something that works with something that offers benefits to spammers and abusers. > SPF will never serve as a tool for blacklisting for what should be > obvious reasons. There is a risk presuming the domain identified using > SPF has not been spoofed somewhere in the mail channel. SPF does not > allow the IP address to be trusted to allow address blacklisting beyond > the current connection, nor does SPF really allow the MAIL FROM mailbox > domain be trusted to a degree that would allow name blacklisting, as it > fails to accurately identify the entity introducing the message. The > mail channel is often shared and there is no means to verify the channel > is being checked at either end of the administrative realms. What he said. > > -Doug > > > From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 20:04: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 UAA18391 for ; Thu, 9 Sep 2004 20:04: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 i89NgnKr014893; Thu, 9 Sep 2004 16:42: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 i89NgnnK014892; Thu, 9 Sep 2004 16:42:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i89NgmmF014886 for ; Thu, 9 Sep 2004 16:42:48 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 30450 invoked from network); 9 Sep 2004 23:42:51 -0000 Received: from unknown (HELO vaio) (203.115.130.129) by relay.pair.com with SMTP; 9 Sep 2004 23:42:51 -0000 X-pair-Authenticated: 203.115.130.129 Message-Id: <4.1.20040910073717.00a67990(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Sep 2004 07:53:17 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <214504A2-0243-11D9-AFEC-000A95BC6A7E@margaretolson.com> References: <4.1.20040909160745.0160e540(null)> <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <4.1.20040909160745.0160e540(null)> 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: >>> IETF had real problem is that it did not wish to deal with how their >>> protocols would be deployed. This is the main reason of failures of >>> number >>> of protocols that have been created and why others are less used then >>> they could be. Certain conclusion must (and have) been drawn out of >>> this >>> and it would be unfortunete if we choose to go the same road again. >> >> >> IMHO, the largest deployment hurdle will be to get 63 million of >> domain owners (growing at 1.5 million per month) to publish and >> maintain a DNS record. (See my post at spf-discuss for source). >> >> Presenting these non-technical people with the complexity of choosing >> which scope their approved mail servers will be used and other complex >> options we might provide them, seems to run counter to the 80/20 rule >> for deployment. > >A very small minority of those domains will do the actual publishing >themselves. They will rely on their vendors to publish for them and to >exchange the necessary information. Yes and no. Agreed for the majority of domains that do publish, and this is precisely what worries me. Then you have 3rd parties (not the ones sending the e-mail) making decisions and assumptions for the actual users, and thus: 1. More likelihood of a war on scope where some camps refuse to declare "mailfrom" or "spf", because they have a vested interest to declare only "pra" or vice versa. 2. More likelihood that the actual users voilate the rules in the DNS record, because the user has no concept they exist or what they mean. 3. Thus because of the two scenarios above and because recipients could care less about the sender's woes, you will have adhoc algorithms sprouting about to deal with the fragmented reality that results. And no, disagree, that the majority of domains will publish records, especially if there is no concensus, much complexity and confusion about scoping, useage, confusing press statements (lack of concensus and simplicity), etc.. >The average domain owner does not know what DNS is and if they do, they >have no idea who manages DNS for them. The record update problem is >serious and needs to be addressed within the industry, but the end user >education needs to take the form of telling people that (a) this exists >and (b) who to call. What exists? How do we explain it to them if the underlying standard is confused and fragmented? We are already seeing confusing press statements about SPF that say spammers are using it. We are much better off to get a simple concensus, than a complex fragmented mess. In the latter scenario, Microsoft will "save the day" by being the unified, de facto choice. Just observe history. [...] >The assumption that small domains all have simple configurations is >just not valid. It's probably true for small personal domains, and >small technical domains, but those are not the majority. What is your point of saying this? You mean we can not provide a simple way to specify the approved mail servers? You mean that we can never make it simple enough to explain to users? >Failure to scope will make it harder, not easier, for small domains, if >for no other reason than figuring out what a rational receiver is >likely to do with the record will be that much harder for whoever is >doing the domain administration. Can you tell me today the differences between the way AccuSpam, SpamAssassin, CloudMark, and a zillion other anti-spam are going to interpret the SPF or SenderID DNS record?? I assert that specifying scope is nothing more than a hopeful hint. In reality, the only the scope is specified by what data you are actually exposing. > This is currently a very low cost >service - do we want to make it expensive? How does not specifying scope make it more expensive? I think specifying scope and having multiple records is going to make it much more expensive for both maintainers, receivers (verifiers), and also in terms of fragmentation and proprietary wars. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 20:36:49 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 UAA20694 for ; Thu, 9 Sep 2004 20:36:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8A08Y8m016821; Thu, 9 Sep 2004 17:08:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8A08YaW016820; Thu, 9 Sep 2004 17:08:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8A08XKp016814 for ; Thu, 9 Sep 2004 17:08:33 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 41127 invoked from network); 10 Sep 2004 00:08:36 -0000 Received: from unknown (HELO vaio) (203.115.130.129) by relay.pair.com with SMTP; 10 Sep 2004 00:08:36 -0000 X-pair-Authenticated: 203.115.130.129 Message-Id: <4.1.20040910080152.00aacf00(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Sep 2004 08:20:16 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope In-Reply-To: <20040909131553.8A85516CD2@mail.nitros9.org> References: 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: >> IMO, the scope should be implicit from the specification. > > "Implicit" instructions in specifications have historically meant >inter-operability problems, and security flaws. > > The specifications exist to make scope/intent explicit. Adding a >few more sentences to clarify the scope would be a good idea for any >specification. Of course and I my suggestion is completely consistent. Read on below to the end... The point I am making is not against specifying the scope of the data being exposed, but against specifying multiple scopes in multiple records, because this will lead to confusion, fragmentation, etc.. Some examples of possible confusion: 1. "Why are there two different ways to specify the approved mail servers for my domain?" 2. "Which is better?" 3. "Which is required?" etc.. You create a proliferation of issues, proliferation of debate, proliferation of DNS records, proliferation of competitive issues, ... in short, you do not create a useful standard. If there is a compelling technical reason to need multiple scopes on the DNS record, then you can consider the tradeoffs. There is no compelling technical reason. >> >And if so, do you actually think it is better for the receiver to have >> >to guess the intended scope of the sender? >> >> Yes because inherent in the design of the specification should be >> acknowledged the *REALITY* that the sender can not control the >> receiver (verifier). > > Control is different from intent. MX records in DNS are intended to >be used as destination IP's for SMTP traffic to a domain, and that >intent is explicit in the specifications. Yet nothing stops anyone >from doing: > >$ ping `host -t mx example.com` Your analogy is comparing apples to oranges. In the case of MX records, the scope specified is a 100% solution to the need that it is for. In the case of per-domain anti-forgery authentication, all the current algorithms for processing the approved mail servers DNS record do not give a 100% result. Thus it is impossible to declare the *FINAL* scope. No one knows today what the *FINAL* scope will be. Instead the best we can do is declare what the data that is being exposed means and what it is intended to be used for. In short, with MX there is no compelling need to use the data in any other way than the exact scope specified. Whereas in our case, the data is going to be used in creative ways to accomplish the goals of the receiver. And I assert that by fragmenting the scope into multiple DNS records, you will actually have the reverse of the intended effect. Instead of limiting scope, you will cause all sorts of adhoc algorithms to try to give the anti-forgery results desired by recipient based on multiple records. It seems your logic above assumes that recipient will only deal with one DNS record orthogonally. So what does recipient do with multiple scopes? What does recipient do when the result from scope(s) is neutral or error or inconclusive? > For MARID issues, the intent of the publisher of the records should >be made explicit in the specifications, if not the protocol. For the >vast majority of recipients who use the records as expected, having >that intent explicit makes their jobs easier. For the recipients who >don't follow the publishers intent, it makes no difference to have >that intent explicit, because they won't follow it. Make explicit how I can deal with the case with PRA where the Resent-Sender: is not forged but the From: header is forged? Ditto for MAILFROM: and From: in SPF? Make explicit how I can use the the results from either scope algorithm to help fight spam? Make explicit how I can combine multiple results from multiple scopes? >> I think it would be folly and brittle for us to attempt to specify >> *ALL* the ways that the data in the DNS record can be used and >> interpreted, ... > > Similarly, it would be follow to specify *no* standard way for the >data to be used and interpreted. We should specify what we can specify. But adding uncompelling scopes when it is the same underlying data is not useful. > > There is a happy medium. We should find it, and use it. Agreed. I think that happy consensus medium would be to specify the approved mail servers for a domain, and then specify some of the possible algorithms that might be applied by receivers. From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 21:12: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 VAA23516 for ; Thu, 9 Sep 2004 21:12: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 i8A0m88j019594; Thu, 9 Sep 2004 17:48: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 i8A0m8us019593; Thu, 9 Sep 2004 17:48:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8A0m7du019585 for ; Thu, 9 Sep 2004 17:48:07 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 55182 invoked from network); 10 Sep 2004 00:48:08 -0000 Received: from unknown (HELO vaio) (203.115.130.129) by relay.pair.com with SMTP; 10 Sep 2004 00:48:08 -0000 X-pair-Authenticated: 203.115.130.129 Message-Id: <4.1.20040910085057.018455d0(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Sep 2004 08:59:54 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: clarification on consensus call for compromise In-Reply-To: References: <1094767077.5605.5.camel@localhost.localdomain> <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> <1094767077.5605.5.camel@localhost.localdomain> 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: \ >>> Under such a system, it would be up to the zone maintainer to determine >>> which scopes to provide data on. It would be up to the MTA running >>> the check to determine which checks to run. >> >> Does the IPR really cover the syntax of the published record? I thought >>the only significant IPR was the PRA algorithm itself, on the MTA side. >>Why not just leave the IPR question only in the hands of the MTA folks, >>and just let people publish their records unscoped? I support scoping what the published data means "these are the approved mail servers for this domain" but not scoping which experimental and incomplete algorithm the data is intended for. >An unscoped record would be meaningless, as the MTA checking the >record would not know which identity was at issue. This has been >covered before; please read the archives. Apologies if I am not aware of the specific posts you are referring to. Nevertheless, I fail to see how publishing "the approved mail servers for sending e-mail from a domain" is an amibiguous "identity" without algorithm scope? Seems to me that your implication that someone would need to publish different mail servers depending on whether the Return-Path or PRA header is being evaluated is not mainstream. And I have asserted that once you publish the data in the DNS, you have no control over how receivers are going to evaluate that data any way. Since none of the scoped algorithms give a 100% final result, it is obvious that receivers are going to experiment with many algorithm scopes. Please enlighten me on the past discussion about "identity" as an algorithm instead of as "approved mail servers"? Also do you think the average users can ever be educated on the nuances of their use of e-mail relative to some complex permutations of algorithm scopes and multiple DNS records? From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 22:20:24 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 WAA27589 for ; Thu, 9 Sep 2004 22:20: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 i8A1o7iL024832; Thu, 9 Sep 2004 18:50: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 i8A1o77g024831; Thu, 9 Sep 2004 18:50:07 -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 i8A1o6VR024823 for ; Thu, 9 Sep 2004 18:50:06 -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 1C5aYA-0003bb-Ty for ietf-mxcomp@imc.org; Thu, 09 Sep 2004 20:50:11 -0500 To: "IETF MARID WG" References: <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 09 Sep 2004 20:50:06 -0500 In-Reply-To: <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> (Andrew Newton's message of "Thu, 9 Sep 2004 14:21:03 -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: clarification on consensus call for compromise 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.6 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 <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> Andrew Newton writes: > In order to ensure that there are scopes for which there is no known > IPR encumbrance, the co-chairs propose a new document describing > a mail_from scope. The PRA scope would also be one of the scopes > initially > described, as there is clearly sufficient interest in checking pra to > allow it to move forward as one among several scopes (interest being > judged both on public statements and deployed code). An IANA registry > for additional scopes created by Standards Track RFCs would be created. Andy, I just don't understand this. While there is clearly sufficient interest in using the PRA by some people, there are also many who object to such a patent encumbered RFC advancing. I can't see how you think you will get consensus for the PRA advancing later. If you intend to ignore the objections, why don't you just advance it now? Since before this working group was founded, there was clearly sufficient interest in using the MAIL FROM in the form of SPF-classic. If "sufficient interest" is an adequate reason for pushing an RFC, why was SPF-classic put on the back burner? > This is not a call for alternate suggestions, nor is it a consensus call > on the documents which have not yet been produced. It is the > chairs' work plan for meeting this chartered goal of this working > group: Ok, let me understand this. We can't put forth alternatives to the PRA, but you can pull a incompatible version of SPF-classic out of your hat? The case of patent encumbered crypto has been mentioned several times. As has been repeatedly pointed out, RFCs that allow patent encumbered crypto almost(?) always include options for unencumbered crypto that can be used in the same problem space. I vehemently object to advancing marid-pra unless there is at least one unencumbered proposal that covers the 2822.From: identity. (marid-pra becoming unencumbered is obviously one way of erasing my objection.) -wayne From owner-ietf-mxcomp@mail.imc.org Thu Sep 9 22:37: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 WAA28406 for ; Thu, 9 Sep 2004 22:37:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8A29lu4026753; Thu, 9 Sep 2004 19:09:47 -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 i8A29l4R026752; Thu, 9 Sep 2004 19:09:47 -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 i8A29kHo026744 for ; Thu, 9 Sep 2004 19:09:46 -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 1C5arD-0003mh-LD for ietf-mxcomp@imc.org; Thu, 09 Sep 2004 21:09:52 -0500 To: "IETF MARID WG" From: wayne Reply-To: "IETF MARID WG" Date: Thu, 09 Sep 2004 21:09:47 -0500 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: problems with patents: the IDN example from RFC3669 Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 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) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8A29kHo026746 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The International Domain Name (IDN) working group is cited as an example in RFC3669. Yesterday, I was poking around a little bit and I read some of the discussion on the IDN mailing list about the patent issue. Boy, things sure are different between the IDN WG and the MARID WG. Check out the following messages: http://www.mail-archive.com/idn-data@psg.com/msg00659.html http://www.mail-archive.com/idn-data@psg.com/msg00764.html http://www.mail-archive.com/idn-data@psg.com/msg00758.html Some choice quotes: "The IETF has always strongly favored completely unencumbered technology over any technology for which there are even mild licensing restrictions." -- Paul Hoffman "The WALID patent does not exist in a vacuum. The IDN Working Group has options that would not infringe on the WALID patent. The fact that all of these options are worse than the one currently favored does not affect the IETF's views on the patent. As long as there is any option that is unencumbered, a protocol that would infringe on the WALID patent will probably not be considered unless WALID signs an IPR statement giving full, free, and unencumbered access to the technology. This would involve a significant change to the WALID IPR statement on file with the IETF Secretariat." -- Paul Hooffman "Any solution which is possible to implement might be better than one which is not possible to implement for various reasons, and licensing being one of them." -- Patrik Fältström The co-chairs publicly pushed for closure on the "Walid patent mess": "As you know, time is the essence. We do feel an urgent need to have another statement from Walid that it either: - keeps with the current IP statement, which is unsatisfactory for the working group - have a new IP statement that the working group will find acceptable to promote the documents to the RFC level." -- Marc Blanchet, co-chair of IETF idn wg. -- James Seng, co-chair of IETF idn wg. Now, I didn't read the whole IDN archive. I mostly read stuff that popped up in my google searches. Still, this some of these quotes a *VERY* different than anything expressed by the people running this working group. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 03:03:22 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 DAA28667 for ; Fri, 10 Sep 2004 03:03: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 i8A6TBei083864; Thu, 9 Sep 2004 23:29:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8A6TBV5083862; Thu, 9 Sep 2004 23:29:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8A6TBcd083853 for ; Thu, 9 Sep 2004 23:29:11 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C5euE-0001FB-00; Thu, 09 Sep 2004 23:29:10 -0700 From: Daniel Quinlan To: Andrew Newton Cc: IETF MARID WG Subject: Re: clarification on consensus call for compromise References: <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> Message-Id: Date: Thu, 09 Sep 2004 23:29:10 -0700 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > In order to ensure that there are scopes for which there is no known > IPR encumbrance, the co-chairs propose a new document describing a > mail_from scope. The PRA scope would also be one of the scopes > initially described, as there is clearly sufficient interest in > checking pra to allow it to move forward as one among several scopes > (interest being judged both on public statements and deployed code). I believe there has been a lot more interest in not using the patented approach and replacing it with an unencumbered technique. In addition, I believe most of the statements of support have been for Sender ID itself, not specifically for leaving PRA in as an option. A good number of the statements of support for Sender ID also suggested removing PRA, finding a way to adopt Sender ID without PRA, etc. > This is not a call for alternate suggestions, nor is it a consensus call > on the documents which have not yet been produced. It is the > chairs' work plan for meeting this chartered goal of this working > group: If the chairs feel it is necessary to actively advocate patented material when we have barely explored unencumbered alternatives, barely consider interoperability, and fix the specification in stone before it is ready -- all in order to meet our time goals, perhaps we should request changes to the charter. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 04:47:41 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 EAA04894 for ; Fri, 10 Sep 2004 04:47:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8A8LOx8023839; Fri, 10 Sep 2004 01:21: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 i8A8LO1E023838; Fri, 10 Sep 2004 01:21:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from drsneaky.slc.co.uk (mail1.slc.co.uk [195.99.121.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8A8LN4V023793 for ; Fri, 10 Sep 2004 01:21:24 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) 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, 10 Sep 2004 09:21:18 +0100 Subject: Re: clarification on consensus call for compromise To: IETF MARID WG Cc: Andrew Newton X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Danny Angus Date: Fri, 10 Sep 2004 09:21:17 +0100 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 10/09/2004 09:21:18 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: > Under such a system, it would be up to the zone maintainer to determine > which scopes to provide data on. > It would be up to the MTA running > the check to determine which checks to run. Sadly this doesn't promote interoperability in any practical way, it is only half a proposal. If everyone can participate in a basic mandatory scope then life-in-the-wild can evolve new scopes. > No single scope would > be mandatory to provide or check; I think that one unencumbered scope should be mandatory. 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 Sep 10 06:17: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 GAA09789 for ; Fri, 10 Sep 2004 06:17: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 i8A9eASX050899; Fri, 10 Sep 2004 02:40:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8A9eANY050898; Fri, 10 Sep 2004 02:40:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8A9e32S050855 for ; Fri, 10 Sep 2004 02:40:04 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C5hsy-0003yJ-00 for ; Fri, 10 Sep 2004 11:40:04 +0200 Received: from host217-40-185-225.in-addr.btopenworld.com ([217.40.185.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Sep 2004 11:40:03 +0200 Received: from J.deBoynePollard by host217-40-185-225.in-addr.btopenworld.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Sep 2004 11:40:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: All members of "we" please raise your hands. Date: Thu, 09 Sep 2004 18:48:03 +0100 Organization: Wacks Wicks Works Lines: 29 Message-ID: References: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: host217-40-185-225.in-addr.btopenworld.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit PF> It's pretty sad that people like the author of this article we PF> got a link to still see 1:1 mapping between "remove spam" and PF> "minimize the number of fake sender addresses". I thought "we" PF> as a collective had educated enough people to not get articles PF> like this. Does this "we" include those who are, right now, educating people with the following? "SPF reduces inbound spam." -- "If the message fails SPF tests, it's a forgery. That's how you can tell it's probably a spammer." -- (That first sentence is a lie, of course.) "Eventually, as SMTP improves its immunity to spam, we hope spammers will get discouraged." -- "'Why should SPF succeed when similar proposals have failed in the past?' The spam problem was never as bad in the past as it is now." -- "Saving the world from spam is an expensive duty." -- From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 08:04: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 IAA18091 for ; Fri, 10 Sep 2004 08:04: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 i8ABYXN4080759; Fri, 10 Sep 2004 04:34:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ABYXip080758; Fri, 10 Sep 2004 04:34:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ABYJFd080747 for ; Fri, 10 Sep 2004 04:34:33 -0700 (PDT) (envelope-from SRS0+d1e260bf94796c5167e3+383+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C5jfV-000696-HF; Fri, 10 Sep 2004 12:34:17 +0100 Subject: RE: DEPLOY: not at the University of Cambridge From: David Woodhouse To: "Hallam-Baker, Phillip" Cc: "'Tony Finch'" , ietf-mxcomp@imc.org, Tony Finch In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1094816056.9144.103.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 10 Sep 2004 12:34:16 +0100 Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 2004-09-09 at 09:38 -0700, Hallam-Baker, Phillip wrote: > What this says to me is that even though the central IT dept > at Cambridge is not going to support Sender ID, the same is not necessarily > true of the colleges. The more progressive colleges > such as Porterhouse can choose to issue SenderID records for > their domains even if central IT services do not. :) > The ancient universities have barely come to terms with the > consequences of the industrial revolution. If we consider > the suitability of specifications on the basis of their > ability to deploy we are not going to get very far. I don't think an ad hominem attack is really an appropriate response to a concise and technical report such as the one to which you were responding¹. Especially in this particular case -- are we to assume that you've never heard the term 'Silicon Fen', and you have little knowledge of the history of computer science? Perhaps you've never even heard of Alan Turing? Maybe a quote from Microsoft's web site might help... "The city of Cambridge, England, was the clear choice for the location of the facilities because of its world-renowned reputation and its rich history as a center of learning. Cambridge has been the origin of fundamental advances in nuclear physics, molecular biology and computer science. Furthermore, Cambridge has become a center for technological excellence in recent years. More than 300 companies and commercial laboratories specializing in computing and advanced technology are concentrated in the Cambridge area." The reasons which were presented for non-deployment of Sender-ID within Cambridge were quite clearly applicable to many other sites -- my own inconsequential domains included. This is not an example of Luddism from a entity which has 'barely come to terms with the consequences of the industrial revolution' and I find it astonishing that you are willing to say such a thing in an email which bears your employer's name. -- dwmw2 ¹ Although your mail client doesn't make it very clear which mail you were replying to, as it ignores the recommendations of RFC2822. Please use a non-broken mail client if you wish to participate in public fora. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 08:57:34 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 IAA22120 for ; Fri, 10 Sep 2004 08:57:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ACXYmK086025; Fri, 10 Sep 2004 05:33:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ACXYxu086024; Fri, 10 Sep 2004 05:33:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ACXXef086018 for ; Fri, 10 Sep 2004 05:33:34 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51276) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C5kaq-00070n-91 (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Fri, 10 Sep 2004 13:33:32 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C5kan-0000Rh-CQ; Fri, 10 Sep 2004 13:33:29 +0100 Date: Fri, 10 Sep 2004 13:33:29 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: David Woodhouse cc: "Hallam-Baker, Phillip" , "'Tony Finch'" , ietf-mxcomp@imc.org Subject: RE: DEPLOY: not at the University of Cambridge In-Reply-To: <1094816056.9144.103.camel@imladris.demon.co.uk> Message-ID: References: <1094816056.9144.103.camel@imladris.demon.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 10 Sep 2004, David Woodhouse wrote: > > I don't think an ad hominem attack is really an appropriate response to > a concise and technical report such as the one to which you were > responding. I shouldn't worry about Phillip's silliness. After all he is an Oxonian and so should be familiar with institutions that are more concerned with the number of angels that can dance on the head of a pin than, say, nuclear physics. Tony. -- f.a.n.finch http://dotat.at/ SOUTH UTSIRE: SOUTHWEST BACKING SOUTHEAST 3 OR 4, INCREASING 5. FAIR. GOOD. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:24:55 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 JAA24326 for ; Fri, 10 Sep 2004 09:24: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 i8ACtuZ8088152; Fri, 10 Sep 2004 05:55: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 i8ACtunP088151; Fri, 10 Sep 2004 05:55:56 -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 i8ACtlE9088134 for ; Fri, 10 Sep 2004 05:55:56 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7CDA126C092; Fri, 10 Sep 2004 14:55:42 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 1BE0526C093; Fri, 10 Sep 2004 14:55:41 +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 i8ACtZm7910978; Fri, 10 Sep 2004 14:55:35 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 97A6EFACC; Fri, 10 Sep 2004 14:55:35 +0200 (CEST) Date: Fri, 10 Sep 2004 14:55:35 +0200 From: Stephane Bortzmeyer To: AccuSpam Cc: ietf-mxcomp@vpnc.org Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040910125535.GC23050@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Thu, Sep 09, 2004 at 08:32:46AM +0800, AccuSpam wrote a message of 19 lines which said: > We will end up with a fragmented internet e-mail system separated > into proprietary (pra) and free software (mailfrom). Some people like Paul Vixie believe that it is unavoidable because there is no consensus on the "best" identity (scope) to check. Reading MARID archives again and again, I believe they are right. Even without the patent issue, there is no consensus on PRA (or on MAIL FROM). So, "Unified SPF" is the only solution. Not perfect but reasonable. May be in the future, the "proper" scope will be obvious and all the others will become deprecated. But we are far from it. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:24:57 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 JAA24343 for ; Fri, 10 Sep 2004 09:24: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 i8AD02bQ088474; Fri, 10 Sep 2004 06:00: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 i8AD02Yx088473; Fri, 10 Sep 2004 06:00:02 -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 i8AD01AY088467 for ; Fri, 10 Sep 2004 06:00:01 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id BCDE326C091; Fri, 10 Sep 2004 15:00:02 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 5C0CA26C08E; Fri, 10 Sep 2004 15:00:01 +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 i8ACxxm7751780; Fri, 10 Sep 2004 14:59:59 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 370C7FACC; Fri, 10 Sep 2004 14:59:59 +0200 (CEST) Date: Fri, 10 Sep 2004 14:59:59 +0200 From: Stephane Bortzmeyer To: mazieres@gmail.com Cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040910125959.GD23050@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <94df60cf0409081745611293e0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94df60cf0409081745611293e0@mail.gmail.com> 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, Sep 08, 2004 at 08:45:49PM -0400, mazieres@gmail.com wrote a message of 43 lines which said: > First, it would need to be clear how multiple checks should interact > when receiving sites perform multiple checks. Please read http://spf.pobox.com/unified/2-best.txt for a start. > In particular, it must be the case that a site checking both > mailfrom and pra should always reject mail when mailfrom fails (even > if pra passes). This might be as simple as saying if any test > fails, the message is considered to have failed. I'm not sure this should be mandated. We should standardize protocols, not policies. It is important that pass(SPF_record,identity) always return the same value, whoever the tester is, but not so important to decide what to do when it fails or succeeds. > This would require a new macro for the mailfrom domain (%{m}?), and > would also benefit greatly from some kind of string comparison > mechanism--maybe eq:string1:string2. You'd want to be able to say > something like: Nice but it would mean a non-trivial change to SPF implementations (which, at the present time, are almost ready to implement -protocol). From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:26:44 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 JAA24466 for ; Fri, 10 Sep 2004 09:26:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ACxHej088410; Fri, 10 Sep 2004 05:59:17 -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 i8ACxHFZ088407; Fri, 10 Sep 2004 05:59:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ACxGVK088399 for ; Fri, 10 Sep 2004 05:59:16 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55250) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1C5kza-0007zP-Oj (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@vpnc.org; Fri, 10 Sep 2004 13:59:06 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C5kza-0004nA-Fl; Fri, 10 Sep 2004 13:59:06 +0100 Date: Fri, 10 Sep 2004 13:59:06 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Markus Stumpf cc: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040909185141.GE44802@Space.Net> Message-ID: References: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> <20040909185141.GE44802@Space.Net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 9 Sep 2004, Markus Stumpf wrote: > > So IMHO Mta Authorization Records In Dns (MARID) should have dealt foremost > with the fact to provide the information in DNS if an IP is a mailserver > at all. That is what CSV does. Tony. -- f.a.n.finch http://dotat.at/ LOUGH FOYLE TO CARLINGFORD LOUGH: EAST OR SOUTHEAST BECOMING SOUTH OR SOUTHEAST 4 OR 5, OCCASIONALLY 3 AROUND THE SHORE. SHOWERS LATER. MODERATE OR GOOD. SLIGHT TO MODERATE. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:28: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 JAA24547 for ; Fri, 10 Sep 2004 09:28: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 i8AD60PX088861; Fri, 10 Sep 2004 06:06:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AD601c088860; Fri, 10 Sep 2004 06:06:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AD5xpZ088854 for ; Fri, 10 Sep 2004 06:06:00 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56427) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1C5l6E-0004rL-07 (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Fri, 10 Sep 2004 14:05:58 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C5l6C-0005zY-QS; Fri, 10 Sep 2004 14:05:57 +0100 Date: Fri, 10 Sep 2004 14:05:56 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "Hallam-Baker, Phillip" cc: "'Tony Finch'" , ietf-mxcomp@imc.org Subject: RE: DEPLOY: not at the University of Cambridge In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 9 Sep 2004, Hallam-Baker, Phillip wrote: > > Looks to me as if you can still deploy an SPF record that says > that A, B & C are authentic university of Cambridge mail servers. > What you are saying you cannot do is to add a final -all to > exclude the universe of all other mail servers. That's pretty worthless. What we need is a method of identifying forgeries, not a method of identifying legitimate email. > That is why most people who are going to use a whitelist are > going to outsource the process. > > VeriSign has started making the Verified Domains List available > to qualified anti-spam companies and we plan to make it available > to everyone via a DNS publication mechanism in the near future. > Both services are free. I can't find any information about the VDL on the web. It sounds like a list of domains whereas what we need is a list of MTA IP addresses. Tony. -- f.a.n.finch http://dotat.at/ ROCKALL: EAST 4 OR 5 BECOMING CYCLONIC, THEN NORTHWEST 5 TO 7, PERHAPS GALE 8 LATER. RAIN LATER. MODERATE OR GOOD. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:31:24 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 JAA24879 for ; Fri, 10 Sep 2004 09:31:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AD7RZ2088980; Fri, 10 Sep 2004 06:07:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AD7RY7088979; Fri, 10 Sep 2004 06:07:27 -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 i8AD7Qme088973 for ; Fri, 10 Sep 2004 06:07:26 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id EB30626C08E for ; Fri, 10 Sep 2004 15:07:27 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 67EC726C091 for ; Fri, 10 Sep 2004 15:07:26 +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 i8AD7Qm7925355 for ; Fri, 10 Sep 2004 15:07:26 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 45A0DFACC; Fri, 10 Sep 2004 15:07:26 +0200 (CEST) Date: Fri, 10 Sep 2004 15:07:26 +0200 From: Stephane Bortzmeyer To: IETF MARID WG Subject: Re: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] Message-ID: <20040910130726.GF23050@nic.fr> References: <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> <1322218026.20040908084909@brandenburg.com> <413E5598.8030009@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Sep 08, 2004 at 12:04:48PM -0500, wayne wrote a message of 42 lines which said: > Would those of you who suggest ignoring the patent please also > volunteer to pay for any and all costs associated with a (potential) > lawsuit from MS for not using their license? This is asking too much! I suggest instead, for those who claim that the risk for the patent is quite low, to ask the IESG or the ISOC to issue a clear statement that the patent is ignorable, thus providing no money for legal fees but a strong support for future infringers. I know, it contradicts RFC 2026 "10.3.2. Standards Track Documents", "[The IESG] will take no position on the validity or scope of any such rights." but it is better than asking for money. (And I believe, like the Apache Software Foundation, that the IETF should change its patent policy.) From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:31: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 JAA24902 for ; Fri, 10 Sep 2004 09:31: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 i8AD7P0p088970; Fri, 10 Sep 2004 06:07: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 i8AD7PIC088969; Fri, 10 Sep 2004 06:07:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AD7O9R088961 for ; Fri, 10 Sep 2004 06:07:24 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 49948 invoked from network); 10 Sep 2004 13:07:22 -0000 Received: from 210.5.92.24.pldt.net (HELO vaio) (210.5.92.24) by relay.pair.com with SMTP; 10 Sep 2004 13:07:22 -0000 X-pair-Authenticated: 210.5.92.24 Message-Id: <4.1.20040910205740.03a2e980(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Sep 2004 21:18:42 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: clarification on consensus call for compromise 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: Some compelling reasons for a single DNS record which does not specify algorithm scope: 1. It allows all algorithms to play equally. 2. If we do not reach concensus, Microsoft might just go create their own non-interoperable (with other algorithms technically or legally) standard for DNS records. 3. The hardest thing to get done, undone (if we choose wrong or act too late), and maintain, are the publishing of the DNS records on wide scale. We better not get the DNS record wrong, be too late to be relevant, proliferate fragmentation, or exclude parties which can promote it to success. 4. The anti-forgery algorithms we are considering now may ultimately have the least relevance in the end game of anti-spam. For example, I expect the PASS case to be much more important to a viable anti-spam algorithm than the other result cases. Thus in the anti-spam algorithms I envision, the more algorithms that can generate a PASS case, the better the final performance. 5. If we design a DNS record that can interopt with known algorithm proposals, then it will have a better chance of interopting with all algorithms, than if we design separate records that go off in proprietary directions. 6. Simplicity breeds success. Other engineers know this as "KISS" (Keep It Simple Stupid). Also known as 80/20 rule. 7. We can not force an algorithm in reality (because we haven't provided a 100% solution with proposed algorithms), thus #5 is needed. 8. Waiting until we have a "end all" algorithm means we may be too late. There are important cases that can be solved today with the current proposed algorithms. I could probably think of more. Can anyone think of compelling reasons to convince ourselves we can force an algorithm on the DNS record (even though IMO we can not in reality)? -Shelby Moore From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:33: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 JAA25002 for ; Fri, 10 Sep 2004 09:33: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 i8AD92Y7089083; Fri, 10 Sep 2004 06:09: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 i8AD921O089082; Fri, 10 Sep 2004 06:09:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AD92Ex089072 for ; Fri, 10 Sep 2004 06:09:02 -0700 (PDT) (envelope-from graham.finlayson@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (Email Firewall v6.0.0)); Fri, 10 Sep 2004 06:09:35 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Fri, 10 Sep 2004 06:08:46 -0700 Message-ID: From: "Graham Finlayson" To: "'ietf-mxcomp@imc.org'" Subject: Request for MARID-PRA-Examples document Date: Fri, 10 Sep 2004 06:08:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D5F78052ZG266063-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49737.4D236ACF" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C49737.4D236ACF Content-Type: text/plain Content-Transfer-Encoding: 7bit To save a lot of people the bother to have to create the same test cases for testing their PRA implementations, I think it would be a good idea to create a document which solely consists of Messages that exercise the different test cases for the PRA algorithm. As someone, somewhere probably already has these available, this may just be an exercise in collating these into a central document. Graham Finlayson Tumbleweed Communications ------_=_NextPart_001_01C49737.4D236ACF Content-Type: text/html Content-Transfer-Encoding: quoted-printable Request for MARID-PRA-Examples document

To save a lot of people the bother to have to create = the same test cases for testing their PRA implementations, I think it = would be a good idea to create a document which solely consists of = Messages that exercise the different test cases for the PRA algorithm. = As someone, somewhere probably already has these available, this may = just be an exercise in collating these into a central = document.

Graham Finlayson
Tumbleweed Communications

------_=_NextPart_001_01C49737.4D236ACF-- From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:37: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 JAA25343 for ; Fri, 10 Sep 2004 09:37: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 i8ADEFcF089535; Fri, 10 Sep 2004 06:14:15 -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 i8ADEFki089534; Fri, 10 Sep 2004 06:14:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8ADEEWC089526 for ; Fri, 10 Sep 2004 06:14:14 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 54818 invoked from network); 10 Sep 2004 13:14:15 -0000 Received: from 210.5.92.24.pldt.net (HELO vaio) (210.5.92.24) by relay.pair.com with SMTP; 10 Sep 2004 13:14:15 -0000 X-pair-Authenticated: 210.5.92.24 Message-Id: <4.1.20040910212300.03a2f220(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Sep 2004 21:25:30 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: RE: DEPLOY: not at the University of Cambridge In-Reply-To: References: 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: >> Looks to me as if you can still deploy an SPF record that says >> that A, B & C are authentic university of Cambridge mail servers. >> What you are saying you cannot do is to add a final -all to >> exclude the universe of all other mail servers. > >That's pretty worthless. What we need is a method of identifying >forgeries, not a method of identifying legitimate email. Disagree. I think the PASS case will end up being much more important for anti-spam end game, than the other result cases. For anti-forgery, maybe you need the binary answer, and those corporations who have a serious problem with forgery (phishing) will be sure to declare "-all" if they need to solve their problem. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:43:44 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 JAA25756 for ; Fri, 10 Sep 2004 09:43:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ADGnc7089779; Fri, 10 Sep 2004 06:16: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 i8ADGnF2089778; Fri, 10 Sep 2004 06:16:49 -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 i8ADGmtL089772 for ; Fri, 10 Sep 2004 06:16:48 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 0179B26C08E; Fri, 10 Sep 2004 15:16:50 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 73B7D26C093; Fri, 10 Sep 2004 15:16:48 +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 i8ADGmm7925773; Fri, 10 Sep 2004 15:16:48 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id F3164FACC; Fri, 10 Sep 2004 15:16:47 +0200 (CEST) Date: Fri, 10 Sep 2004 15:16:47 +0200 From: Stephane Bortzmeyer To: Daniel Quinlan Cc: IETF MARID WG Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Message-ID: <20040910131647.GA24748@nic.fr> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <20040909132112.GB28026@nic.fr> <16704.41738.510079.625670@proton.pathname.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16704.41738.510079.625670@proton.pathname.com> 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 Thu, Sep 09, 2004 at 11:38:02AM -0700, Daniel Quinlan wrote a message of 68 lines which said: > We want some method to parse RFC 2822 headers to be part of the > standard. However, PRA is off limits to us due to how the license is > currently designed. An unencumbered method to authenticate RFC 2822 > messages that is permitted and encouraged is needed. OK, I agree with the idea of having two more scopes: 1) "from", pure and simple plain old 2822 From 2) "fetchmail", meaning the algorithm explained in http://www.imc.org/ietf-mxcomp/mail-archive/msg04356.html Note that I take no position on the usefulness of these scopes. I simply believe that, given the current state of the art about email identities, it is better to have choice. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 09:51: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 JAA26348 for ; Fri, 10 Sep 2004 09:51:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ADQWSd090943; Fri, 10 Sep 2004 06:26:32 -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 i8ADQWNe090942; Fri, 10 Sep 2004 06:26:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8ADQVdK090935 for ; Fri, 10 Sep 2004 06:26:31 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 63958 invoked from network); 10 Sep 2004 13:26:31 -0000 Received: from 210.5.92.24.pldt.net (HELO vaio) (210.5.92.24) by relay.pair.com with SMTP; 10 Sep 2004 13:26:31 -0000 X-pair-Authenticated: 210.5.92.24 Message-Id: <4.1.20040910213758.0393df00(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Sep 2004 21:38:00 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope 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: >Note that I take no position on the usefulness of these scopes. I >simply believe that, given the current state of the art about email >identities, it is better to have choice. So why declare algorithm scope? I could support algorithm scopes, if all applicable scopes were in a single record. 2nd to the Nth records would be ignored. Thus the intent would be for a single record to interopt with all current and future scopes (updated by version number), and the sender can hint the limitation of intended scopes. This would be more in touch with reality IMO, and also appease the desire to give sender some input into algorithm scope, while also preventing fragmentation and proprietary directions (wars) on DNS records. - Shelby Moore From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:02:44 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 KAA27480 for ; Fri, 10 Sep 2004 10:02: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 i8ADXkdG091449; Fri, 10 Sep 2004 06:33: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 i8ADXkOe091448; Fri, 10 Sep 2004 06:33:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8ADXjSl091441 for ; Fri, 10 Sep 2004 06:33:45 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 69241 invoked from network); 10 Sep 2004 13:33:45 -0000 Received: from 210.5.92.24.pldt.net (HELO vaio) (210.5.92.24) by relay.pair.com with SMTP; 10 Sep 2004 13:33:45 -0000 X-pair-Authenticated: 210.5.92.24 Message-Id: <4.1.20040910214314.03a353f0(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Sep 2004 21:45:09 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: DEPLOY: not at the University of Cambridge In-Reply-To: References: 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: >> What we need is a method of identifying forgeries, not a method of >> identifying legitimate email. > >I share that desire. However, as a practical matter it may be easier to >get legitimate senders to cooperate than would-be forgers. Exacto! For anti-spam, the future reality is that any successful anti-forgery will eliminate the forgery case as useful input. Spammers will morph. The PASS case is going to be much more useful in long run. We have a proprietary algorithm in mind, which I can not detail in public. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:04: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 KAA27694 for ; Fri, 10 Sep 2004 10:04:32 -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 i8ADOWRw090786; Fri, 10 Sep 2004 06:24:32 -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 i8ADOWvs090785; Fri, 10 Sep 2004 06:24:32 -0700 (PDT) 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 i8ADOTUe090766 for ; Fri, 10 Sep 2004 06:24:32 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 230651A6C2; Fri, 10 Sep 2004 15:24:26 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 0EA6E1A6B8 for ; Fri, 10 Sep 2004 15:24:24 +0200 (CEST) Message-Id: Date: Fri, 10 Sep 2004 15:24:34 +0200 From: Arnt Gulbrandsen To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: not at the University of Cambridge References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tony Finch writes: > What we need is a method of identifying forgeries, not a method of > identifying legitimate email. I share that desire. However, as a practical matter it may be easier to get legitimate senders to cooperate than would-be forgers. Arnt From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:11:40 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 KAA28702 for ; Fri, 10 Sep 2004 10:11: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 i8ADlCpT092354; Fri, 10 Sep 2004 06:47: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 i8ADlCAH092353; Fri, 10 Sep 2004 06:47:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from high-mountain.nihongo.org (high-mountain.nihongo.org [209.76.104.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ADlCBL092346 for ; Fri, 10 Sep 2004 06:47:12 -0700 (PDT) (envelope-from snowhare@nihongo.org) Received: from high-mountain.nihongo.org (localhost.localdomain [127.0.0.1]) by high-mountain.nihongo.org (8.12.11/8.12.11) with ESMTP id i8ADl6aZ004290 for ; Fri, 10 Sep 2004 06:47:06 -0700 Received: from localhost (snowhare@localhost) by high-mountain.nihongo.org (8.12.11/8.12.11/Submit) with ESMTP id i8ADl6Pl004286 for ; Fri, 10 Sep 2004 06:47:06 -0700 X-Authentication-Warning: high-mountain.nihongo.org: snowhare owned process doing -bs Date: Fri, 10 Sep 2004 06:47:06 -0700 (PDT) From: Benjamin Franz To: IETF MARID WG Subject: Re: clarification on consensus call for compromise In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 10 Sep 2004, Danny Angus wrote: > Andrew Newton wrote: > > > > No single scope would be mandatory to provide or check; > > I think that one unencumbered scope should be mandatory. I concur. Trying to slide PRA around the non-consensus wall by making it one of several optional scopes is not a good answer. There needs to be at least one unencumbered mandatory scope so that deployment does not degenerate into non-interoperable closed source 'PRA supporters' and F/OSS based 'SPF supporters' camps. Which is precisely what will happen if passed along in this form. -- Benjamin Franz From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:11: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 KAA28747 for ; Fri, 10 Sep 2004 10:11: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 i8ADjvOj092264; Fri, 10 Sep 2004 06:45: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 i8ADjvO8092263; Fri, 10 Sep 2004 06:45:57 -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 i8ADjveK092255 for ; Fri, 10 Sep 2004 06:45:57 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i8ADjssN008183; Fri, 10 Sep 2004 06:45:54 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Sep 2004 06:45:54 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Tony Finch'" , David Woodhouse Cc: "Hallam-Baker, Phillip" , ietf-mxcomp@imc.org Subject: RE: DEPLOY: not at the University of Cambridge Date: Fri, 10 Sep 2004 06:45:53 -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: Tony Finch [mailto:dot@dotat.at] > That's pretty worthless. What we need is a method of identifying > forgeries, not a method of identifying legitimate email. That is what Sender-ID is, a means of identifying legitimate mail. That is the objective. > On Fri, 10 Sep 2004, David Woodhouse wrote: > > > > I don't think an ad hominem attack is really an appropriate > response to > > a concise and technical report such as the one to which you were > > responding. > > I shouldn't worry about Phillip's silliness. After all he is > an Oxonian > and so should be familiar with institutions that are more > concerned with > the number of angels that can dance on the head of a pin than, say, > nuclear physics. Actually I was in the Nuclear Physics department. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:12:22 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 KAA28869 for ; Fri, 10 Sep 2004 10:12:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ADj0IZ092179; Fri, 10 Sep 2004 06:45:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ADj0qb092178; Fri, 10 Sep 2004 06:45:00 -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 i8ADixDU092171 for ; Fri, 10 Sep 2004 06:44:59 -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 1C5lhw-0000tH-TA for ietf-mxcomp@imc.org; Fri, 10 Sep 2004 08:45:01 -0500 To: "IETF MARID WG" References: <4.1.20040910205740.03a2e980(null)> From: wayne Reply-To: "IETF MARID WG" Date: Fri, 10 Sep 2004 08:44:56 -0500 In-Reply-To: <4.1.20040910205740.03a2e980(null)> (AccuSpam's message of "Fri, 10 Sep 2004 21:18:42 +0800") 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: clarification on consensus call for compromise 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.6 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 <4.1.20040910205740.03a2e980(null)> AccuSpam writes: > Some compelling reasons for a single DNS record which does not specify > algorithm scope: > [snip] This is all well covered stuff that was decided months ago. I don't think it is a productive use of this working group's time to re-raise issues that have already been decided just because someone new has joined the working group. Reading the complete archive will help you understand why the decisions were made. You may not agree with those decisions, but so be it. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:21:50 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 KAA00145 for ; Fri, 10 Sep 2004 10:21:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ADsnXt092863; Fri, 10 Sep 2004 06:54: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 i8ADsnaf092862; Fri, 10 Sep 2004 06:54:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp4g.bellsouth.com (aismtp4g.bellsouth.com [139.76.165.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ADsmC7092846 for ; Fri, 10 Sep 2004 06:54:48 -0700 (PDT) (envelope-from Damon.Sauer@BellSouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp4g.bellsouth.com with ESMTP; Fri, 10 Sep 2004 09:54:39 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: SPF abused by spammers X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Fri, 10 Sep 2004 08:54:26 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB90521D090@bremocog-55> Thread-Topic: SPF abused by spammers Thread-Index: AcSWwL1MNvxj3WCUTOiMuze9/S4B1gAdyPgA From: "Sauer, Damon" To: "Dean Anderson" Cc: "Markus Stumpf" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8ADsmC7092857 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Dean, > > > > You are missing where this is a GOOD thing. We WANT > spammers to use > > SPF. This will allow us to identify, publish, process, > shred, pillage, > > burn, destroy the IP addresses that this stuff is coming > from. Nobody > > is doing less stringent processing of the email that passes an SPF > > check. It just makes it easier to block when identified. > > SPF doesn't make it easier to identify spammers. > I didn't say it did. How I identify the IP as a spammer is up to my other processes. What it DOES do is allow me to make a informed decision on whether or not to block that IP. (I am not sure how many different ways I can try to explain this fact but here is another one) Only people that don't understand what SPF actually does say that SPF blocks spam. Now I do know that pobox has said something to this effect, but it is my belief that they were writing that statement with the end-user in mind. Basically, never mind HOW it blocks spam, just that it will. It is up to the system admins and programmers to determine the HOW. If someone of intellect higher than your average bumblebee can't see where being able to prevent domain forgery is a good thing and being able to put an IP address to a real domain is a great thing.... Then bumblebees may eventually rule the world. Regards, Damon ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:39: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 KAA02150 for ; Fri, 10 Sep 2004 10:39:04 -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 i8AE4aNn093615; Fri, 10 Sep 2004 07:04:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AE4aW1093614; Fri, 10 Sep 2004 07:04:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp1g.bellsouth.com (aismtp1g.bellsouth.com [139.76.165.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AE4ZH2093605 for ; Fri, 10 Sep 2004 07:04:35 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp1g.bellsouth.com with ESMTP; Fri, 10 Sep 2004 10:04:32 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: DEPLOY: not at the University of Cambridge X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Fri, 10 Sep 2004 09:04:22 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB90521D0AF@bremocog-55> Thread-Topic: DEPLOY: not at the University of Cambridge Thread-Index: AcSXN2f/voU6nGmGTLqDFmLlLmsTsAABpRHg From: "Sauer, Damon" To: "Tony Finch" , "Hallam-Baker, Phillip" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8AE4ZH2093609 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > On Thu, 9 Sep 2004, Hallam-Baker, Phillip wrote: > > > > Looks to me as if you can still deploy an SPF record that > says that A, > > B & C are authentic university of Cambridge mail servers. > What you are > > saying you cannot do is to add a final -all to exclude the > universe of > > all other mail servers. > > That's pretty worthless. What we need is a method of > identifying forgeries, not a method of identifying legitimate email. > The glass is half full. 1) When SPF is deployed and used the line between forgeries and legitimate will be much sharper. 2) In the corporate world, I am actually going to be able to deploy SPF based on the argument that my MAIL FROM: will not be able to be forged. 3) Which in turn makes all MY email legitimate. This means if anyone sends with my domain from a source outside of my defined range, you can identify as a forgery. (I am going to start talking in circles, so I am going to stop here) > -- > f.a.n.finch http://dotat.at/ > ROCKALL: EAST 4 OR 5 BECOMING CYCLONIC, THEN NORTHWEST 5 TO > 7, PERHAPS GALE 8 LATER. RAIN LATER. MODERATE OR GOOD. > > Regards, Damon Sauer ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:39: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 KAA02168 for ; Fri, 10 Sep 2004 10:39: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 i8AE7Dbt093849; Fri, 10 Sep 2004 07:07:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AE7D0L093848; Fri, 10 Sep 2004 07:07:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AE7099093833 for ; Fri, 10 Sep 2004 07:07:12 -0700 (PDT) (envelope-from SRS0+81b18495ec4da8345ff4+383+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C5m3I-00067K-Ru; Fri, 10 Sep 2004 15:07:01 +0100 Subject: RE: DEPLOY: not at the University of Cambridge From: David Woodhouse To: AccuSpam Cc: ietf-mxcomp@vpnc.org In-Reply-To: <4.1.20040910212300.03a2f220(null)> References: <4.1.20040910212300.03a2f220(null)> Content-Type: text/plain Message-Id: <1094825219.22505.26.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 10 Sep 2004 15:07:00 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ Please make sure your attributions are present and correct, and that you limit your lines to a sane number of characters. For a mailing list used to discuss technical matters relating to email, I'm amazed at the lack of consideration shown by the posters. Is it September again already? ] On Fri, 2004-09-10 at 21:25 +0800, AccuSpam wrote: > <...fanf2 wrote:...> > >That's pretty worthless. What we need is a method of identifying > >forgeries, not a method of identifying legitimate email. > > Disagree. I think the PASS case will end up being much more important > for anti-spam end game, than the other result cases. I think both are correct. I think the PASS result will end up being much more widely used in practice than the FAIL result, as Shelby claims. For example, I would consider bypassing SMTP verification callouts for sender addresses when there is an SPF/Sender-ID 'PASS' result, yet I would never consider actually rejecting mail due to a 'FAIL' result. However I agree with Tony that this renders the whole thing pretty worthless. We already have ways to rate the trustworthiness of IP addresses. We're introducing all this breakage, requiring hosts to 'upgrade' to join the Brave New World by performing SRS or some abuse of Resent-* headers which is inconsistent with RFC2822, and what do we achieve at the end of it? We get spammers publishing their own records quicker than legitimate users do, proving that the only thing we've achieved at the end of it all is to 'reduce' it to... almost precisely the same problem -- only now we get to rate the trustworthiness of _domains_ rather than IP addresses. If we really want to check domains instead of IP addresses, and to limit the 'permitted' mail servers for outgoing mail, surely we'd just do better to mandate the use of TLS and check the sender's certificate against our 'trust' database? Oh yeah... the world hasn't actually noticed ESMTP yet, and there are still mail hosts out there which aren't TLS-capable.... and yet you think they're going to notice whatever changes SPF/Sender-ID require of them? You're living in a dream world. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:44: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 KAA02777 for ; Fri, 10 Sep 2004 10:44:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AEMI38095707; Fri, 10 Sep 2004 07:22: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 i8AEMIuL095706; Fri, 10 Sep 2004 07:22:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AEMCLL095690 for ; Fri, 10 Sep 2004 07:22:17 -0700 (PDT) (envelope-from graham.finlayson@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (Email Firewall v6.0.0)); Fri, 10 Sep 2004 07:22:39 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Fri, 10 Sep 2004 07:21:50 -0700 Message-ID: From: "Graham Finlayson" To: "'ietf-mxcomp@imc.org'" Subject: DOC-BUG: Determining the Purported Responsible Address Date: Fri, 10 Sep 2004 07:21:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D5F67252ZG266692-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49741.069C4255" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C49741.069C4255 Content-Type: text/plain Content-Transfer-Encoding: 7bit In marid-core, section 4 on "Determining the Purported Responsible Address", specifies the error "550 5.1.7 Missing purported Responsible Address". Is this meant to be "550 5.7.1 Missing Purported Responsible Address"? Note, the capitalization on Purported as well. Graham Finlayson Tumbleweed Communications ------_=_NextPart_001_01C49741.069C4255 Content-Type: text/html Content-Transfer-Encoding: 7bit DOC-BUG: Determining the Purported Responsible Address

In marid-core, section 4 on "Determining the Purported Responsible Address", specifies the error

"550 5.1.7 Missing purported Responsible Address".

Is this meant to be

"550 5.7.1 Missing Purported Responsible Address"?

Note, the capitalization on Purported as well.

Graham Finlayson
Tumbleweed Communications

------_=_NextPart_001_01C49741.069C4255-- From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:45: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 KAA02871 for ; Fri, 10 Sep 2004 10:45: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 i8AELOeu095274; Fri, 10 Sep 2004 07:21: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 i8AELNOP095269; Fri, 10 Sep 2004 07:21:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AELLuV095157 for ; Fri, 10 Sep 2004 07:21:22 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C5mFq-0006qL-2L; Fri, 10 Sep 2004 10:19:58 -0400 Message-ID: <4141B85C.2050507@solidmatrix.com> Date: Fri, 10 Sep 2004 10:21:16 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Stephane Bortzmeyer CC: IETF MARID WG Subject: Re: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify] References: <16700.61568.149508.266801@giles.gnomon.org.uk> <413D087F.7090505@solidmatrix.com> <16701.2722.149695.20569@giles.gnomon.org.uk> <413D0FB7.9080903@solidmatrix.com> <16702.13483.861326.183032@giles.gnomon.org.uk> <413E3531.7010906@solidmatrix.com> <1322218026.20040908084909@brandenburg.com> <413E5598.8030009@solidmatrix.com> <20040910130726.GF23050@nic.fr> In-Reply-To: <20040910130726.GF23050@nic.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > On Wed, Sep 08, 2004 at 12:04:48PM -0500, > wayne wrote > a message of 42 lines which said: > > >>Would those of you who suggest ignoring the patent please also >>volunteer to pay for any and all costs associated with a (potential) >>lawsuit from MS for not using their license? > > > This is asking too much! I suggest instead, for those who claim that > the risk for the patent is quite low, to ask the IESG or the ISOC to > issue a clear statement that the patent is ignorable, thus providing > no money for legal fees but a strong support for future infringers. > > I know, it contradicts RFC 2026 "10.3.2. Standards Track Documents", > "[The IESG] will take no position on the validity or scope of any such > rights." but it is better than asking for money. (And I believe, like > the Apache Software Foundation, that the IETF should change its patent > policy.) > And RFC 3667, 3668 and 3669. Rules aren't going to change in such short time. As of now, the IETF cannot take a stand on the validity of any patent. Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:46: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 KAA03024 for ; Fri, 10 Sep 2004 10:46:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AEOsZZ095886; Fri, 10 Sep 2004 07:24:54 -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 i8AEOsPw095885; Fri, 10 Sep 2004 07:24:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AEOr4X095879 for ; Fri, 10 Sep 2004 07:24:53 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 6737 invoked from network); 10 Sep 2004 14:24:55 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 10 Sep 2004 14:24:55 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "IETF MARID WG" Subject: RE: clarification on consensus call for compromise Date: Fri, 10 Sep 2004 10:24:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Andrew Newton > Sent: Thursday, September 09, 2004 2:21 PM > To: IETF MARID WG > Subject: clarification on consensus call for compromise > > In order to ensure that there are scopes for which there is no known > IPR encumbrance, the co-chairs propose a new document describing > a mail_from scope. The PRA scope would also be one of the scopes > initially > described, as there is clearly sufficient interest in checking pra to > allow it to move forward as one among several scopes (interest being > judged both on public statements and deployed code). An IANA registry > for additional scopes created by Standards Track RFCs would be created. > PRA isn't what I would think of when I think of the word scope. The scope within which PRA operates is the 2822 message header. Within this scope there is more than one way to determine which header field is appropriate to use. PRA is one way. There are others. If scope were defined by the type of data used to make a determination vice the method, then I believe there is a limited, bounded set of potential scopes that can be defined now. Pick different names if you want, but I think they are: 1. Envelope [2821] ~ mail_from 2. Header [2822] (I would include SUBMITTER here since it's an early look at this scope) 3. HELO (separate from Envelope because it relates to the MTA and not the message) If defined in this manner, then PRA is one potential method to evaluate the Header scope, but there are others. This would let work on the documents upon which there is some agreement move forward while preserving the possibility of eventually reaching rough consensus on an approach for the Header scope. I put this forward in the hopes that this will meet the objections of those that strongly object to any standard going forward that includes PRA as currently licensed. Done this way, I don't think there's a need for an IANA registry of scopes. What there will be is an eventual set of RFCs that describe appropriate methods for evaluating each scope. There may even be more than one per scope if they are demonstrated to be interoperable. There is also a need to define the inter-relationship of the different scopes, but once defined that would be static and dependable. The variable remaining for future drafts is how to evaluate the individual scopes in isolation. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 10:54:40 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 KAA03598 for ; Fri, 10 Sep 2004 10:54: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 i8AESZN0096279; Fri, 10 Sep 2004 07:28: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 i8AESZie096278; Fri, 10 Sep 2004 07:28:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AESY5m096224 for ; Fri, 10 Sep 2004 07:28:34 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 9712C28E4B for ; Fri, 10 Sep 2004 16:28:31 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02625-05-2 for ; Fri, 10 Sep 2004 16:28:28 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 50F2828E4A; Fri, 10 Sep 2004 16:28:28 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Fri, 10 Sep 2004 16:28:28 +0200 (CEST) Message-ID: <37503.127.0.0.1.1094826508.squirrel@127.0.0.1> In-Reply-To: References: Date: Fri, 10 Sep 2004 16:28:28 +0200 (CEST) Subject: Re: clarification on consensus call for compromise From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Benjamin Franz a écrit : > > On Fri, 10 Sep 2004, Danny Angus wrote: >> Andrew Newton wrote: >> > >> > No single scope would be mandatory to provide or check; >> >> I think that one unencumbered scope should be mandatory. > > I concur. Trying to slide PRA around the non-consensus wall by making it > one of several optional scopes is not a good answer. There needs to be at > least one unencumbered mandatory scope so that deployment does not > degenerate into non-interoperable closed source 'PRA supporters' and F/OSS > based 'SPF supporters' camps. Which is precisely what will happen if > passed along in this form. I agree with this. For the time being, only non-encumbered scopes/algorithms should be considered for validation by MARID, and the modular structure that allows adding future scopes/algorithm is good for we can later consider adding currently encumbered algorithms/scopes in the event that they become non-encumbered. But the "modular" approach must not serve as an excuse for approving "among other possibilities" a scope/algorithm for which a massive number of WG participants (read : a clear majority) have expressed that they disapprove of because of the IPR encumbrance issue. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 11:11: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 LAA05085 for ; Fri, 10 Sep 2004 11:11:45 -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 i8AEjEdV097509; Fri, 10 Sep 2004 07: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 i8AEjES1097508; Fri, 10 Sep 2004 07:45:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AEjDBx097482 for ; Fri, 10 Sep 2004 07:45:13 -0700 (PDT) (envelope-from SRS0=dEkfAAFe=L7=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8AEjCxA007314 for ; Fri, 10 Sep 2004 16:45:12 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409101445.I8AEJBLH007304@asarian-host.net> Date: Fri, 10 Sep 2004 14:45:12 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: not at the University of Cambridge X-Trace: HKrYZwZj6p4EdyL7UNZRMjTG4YwACbX3alXO19dEaF6xeYddLHDINcr+qcYHFG1YIg9CdMC0om/SZsOuCkRITg== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: References: <4.1.20040910212300.03a2f220(null)> <1094825219.22505.26.camel@hades.cambridge.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUG9+DFqW1BleBN9AQFpXgf/U9lFlHnxqHn4tluga4wQ25LPe6ZxPqJB jCvGCslYaaL8pt+8fk89Ku4CJxz3QofhMvTAbm0WSdq+TM5XtOzeztWU6fiogKzf nwkEC0u/dQ8SkKVkaLsveB86cVbXeVHl7F3qnceyoYNneCMRsbBiLmRT1zCpShGY DkYc1yT3/Gy+C1DR76jMsw+99C3XJIiUOYY4Uq1TjYr4qURD3SvPCMO65Q0oh0zg APAzB8dBTn1aNgSbj2sL76c5C4+cdBa68LbMVoPkoHBu7bfi0EAjna8zqN069QoS bXkXrNlnVGaMbu+iSiH3RPyh6jo9SSgWDhivj5g9jVSHE5sySI4Weg== =W/V4 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Woodhouse wrote: > I would consider bypassing SMTP verification > callouts for sender addresses when there is an SPF/Sender-ID 'PASS' > result, yet I would never consider actually rejecting mail due to a > 'FAIL' result. You would never? I do; on SPF "classic" FAIL, that is. And with no qualms about it either. "Be-FAIL ist be-FAIL", as a German would say. :) I mean, seriously, I do so on the grounds that I am not even executing MY local policy, but that of the remote domain owner. Worried about losing legitimate mail? Why, that is a consideration made by the domain owner who published the "-all" SPF record. He apparently felt comfortable with that. And I just respect his wishes. Furthermore, I attach the greater legal risk at accepting mail, in case where FAIL was prescribed. Not perhaps with your average vanity domain (Lord, I hate that term); but if a large financial institution says "FAIL this fake email, pretending to be from me, coming from a relay I have not authorized to send mail on my behalf," you can bet I will err on the side of caution, and REJECT according to their policy. > We get spammers publishing their own records quicker > than legitimate users do, proving that the only thing we've achieved > at the end of it all is to 'reduce' it to... almost precisely the > same problem -- only now we get to rate the trustworthiness of > _domains_ rather than IP addresses. Which is a hundred times more easy than managing individual, ever changing IP addresses/ranges. Blocklists based on domain names were pretty useless before SPF. But now they are hopefully coming back in fashion. And will make the New World perhaps not Braver, but easier, I hope. :) Regards, - Mark From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 11:32:34 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 LAA06613 for ; Fri, 10 Sep 2004 11:32:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AF6oGC099721; Fri, 10 Sep 2004 08:06:50 -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 i8AF6oM5099720; Fri, 10 Sep 2004 08:06:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AF6oY3099713 for ; Fri, 10 Sep 2004 08:06:50 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C5mxq-0000kV-Ow; Fri, 10 Sep 2004 11:05:27 -0400 Message-ID: <4141C305.4000901@solidmatrix.com> Date: Fri, 10 Sep 2004 11:06:45 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Michel Bouissou CC: ietf-mxcomp@imc.org Subject: Re: clarification on consensus call for compromise References: <37503.127.0.0.1.1094826508.squirrel@127.0.0.1> In-Reply-To: <37503.127.0.0.1.1094826508.squirrel@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Michel Bouissou wrote: > Benjamin Franz a écrit : > >>On Fri, 10 Sep 2004, Danny Angus wrote: >> >>>Andrew Newton wrote: >>> >>>>No single scope would be mandatory to provide or check; >>> >>>I think that one unencumbered scope should be mandatory. >> >>I concur. Trying to slide PRA around the non-consensus wall by making it >>one of several optional scopes is not a good answer. There needs to be at >>least one unencumbered mandatory scope so that deployment does not >>degenerate into non-interoperable closed source 'PRA supporters' and F/OSS >>based 'SPF supporters' camps. Which is precisely what will happen if >>passed along in this form. > > > I agree with this. For the time being, only non-encumbered > scopes/algorithms should be considered for validation by MARID, and the > modular structure that allows adding future scopes/algorithm is good for > we can later consider adding currently encumbered algorithms/scopes in the > event that they become non-encumbered. > > But the "modular" approach must not serve as an excuse for approving > "among other possibilities" a scope/algorithm for which a massive number > of WG participants (read : a clear majority) have expressed that they > disapprove of because of the IPR encumbrance issue. > What about the scope idea itself? Do you agree with it? Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 11:32:40 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 KAA02776 for ; Fri, 10 Sep 2004 10:44:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AELZl4095562; Fri, 10 Sep 2004 07:21: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 i8AELZIG095560; Fri, 10 Sep 2004 07:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AELY0P095523 for ; Fri, 10 Sep 2004 07:21:34 -0700 (PDT) (envelope-from SRS0+81b18495ec4da8345ff4+383+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C5mHP-0006BO-L4; Fri, 10 Sep 2004 15:21:36 +0100 Subject: Re: clarification on consensus call for compromise From: David Woodhouse To: AccuSpam Cc: ietf-mxcomp@vpnc.org In-Reply-To: <4.1.20040910205740.03a2e980(null)> References: <4.1.20040910205740.03a2e980(null)> Content-Type: text/plain Message-Id: <1094826073.22505.34.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 10 Sep 2004 15:21:13 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-09-10 at 21:18 +0800, AccuSpam wrote: > I could probably think of more. Can anyone think of compelling > reasons to convince ourselves we can force an algorithm on the DNS > record (even though IMO we can not in reality)? I can think of reasons why we should ensure that there is a clear distinction between those addresses which are considered to be an acceptable RFC2821 reverse-path, and those addresses which are considered to be acceptable in RFC2822 headers. 220-ZenIV.linux.org.uk ESMTP Exim 4.41 Fri, 10 Sep 2004 15:16:59 +0100 220 Be gentle with me helo me 250 ZenIV.linux.org.uk Hello me [2002:c35c:f9fc::1] mail from: 250 OK rcpt to: 550-Verification failed for 550-Called: 2002:c1ed:8229:10:2c0:f0ff:fe31:e18 550-Sent: RCPT TO: 550-Response: 550-This address never sends messages directly, and should not accept bounces. 550-550-Please see http://www.infradead.org/rpr.html or contact 550-550 postmaster@infradead.org for further information. 550 Sender verify failed 220-canuck.infradead.org ESMTP Exim 4.42 Fri, 10 Sep 2004 10:15:52 -0400 220 Be gentle with me helo me 250 canuck.infradead.org Hello me [2002:c35c:fd02::1] mail from: 250 OK rcpt to: 250 Accepted rset 250 Reset OK mail from:<> 250 OK rcpt to: 550-This address never sends messages directly, and should not accept bounces. 550-Please see http://www.infradead.org/rpr.html or contact 550 postmaster@infradead.org for further information. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 11:39: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 LAA07215 for ; Fri, 10 Sep 2004 11:39: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 i8AF4sIU099586; Fri, 10 Sep 2004 08:04:54 -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 i8AF4s9A099585; Fri, 10 Sep 2004 08:04:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AF4r3B099578 for ; Fri, 10 Sep 2004 08:04:53 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C5mvz-0000f8-Er; Fri, 10 Sep 2004 11:03:31 -0400 Message-ID: <4141C291.1010907@solidmatrix.com> Date: Fri, 10 Sep 2004 11:04:49 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Andrew Newton , "IETF MXCOMP (E-mail)" Subject: Conclusion of Last Call? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andy, Today is the conclusion for the last call. What's the bottom line if any? Yakov From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 11:46: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 LAA07890 for ; Fri, 10 Sep 2004 11:46: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 i8AFJuGx001258; Fri, 10 Sep 2004 08:19: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 i8AFJu3R001257; Fri, 10 Sep 2004 08:19:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AFJttX001249 for ; Fri, 10 Sep 2004 08:19:55 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 47288 invoked from network); 10 Sep 2004 15:19:54 -0000 Received: from unknown (HELO vaio) (203.115.130.72) by relay.pair.com with SMTP; 10 Sep 2004 15:19:54 -0000 X-pair-Authenticated: 203.115.130.72 Message-Id: <4.1.20040910233017.018906f0(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Sep 2004 23:31:35 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: clarification on consensus call for compromise 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: >I concur. Trying to slide PRA around the non-consensus wall by making it >one of several optional scopes is not a good answer. Doesn't making it a hinted scope of a single record solve the concensus problem, or am I correct to sense the SPF camp is unwilling to try for a concensus with the SenderID camp? > There needs to be at >least one unencumbered mandatory scope so that deployment does not >degenerate into non-interoperable closed source 'PRA supporters' and F/OSS >based 'SPF supporters' camps. Which is precisely what will happen if >passed along in this form. Is there is only one record format, with scope as a hint only, then how can the specification of the DNS record degenerate into multiple camps? >I think both are correct. I think the PASS result will end up being much >more widely used in practice than the FAIL result, as Shelby claims. For >example, I would consider bypassing SMTP verification callouts for >sender addresses when there is an SPF/Sender-ID 'PASS' result, yet I >would never consider actually rejecting mail due to a 'FAIL' result. > >However I agree with Tony that this renders the whole thing pretty >worthless. > >We already have ways to rate the trustworthiness of IP addresses. > >We're introducing all this breakage, requiring hosts to 'upgrade' to >join the Brave New World by performing SRS or some abuse of Resent-* >headers which is inconsistent with RFC2822, and what do we achieve at >the end of it? Agree that the forwarding breakage is a big factor, but remember for the PASS case you do not care about this breakage. There are other ways in anti-spam to use the data that an email came from a domain as PASS. Also the proposals could help stop phishing for corporations that publish "-all" (HARD FAIL) (but within the scope of forwarding breakage). >I can think of reasons why we should ensure that there is a clear >distinction between those addresses which are considered to be an >acceptable RFC2821 reverse-path, and those addresses which are >considered to be acceptable in RFC2822 headers. If I understood your example correctly, I am suggesting 1 record per domain, and I have agreed that a hint on applicable scopes is acceptable as long as we do not end up with different record formats and multiple records, so if you need to specify different hinted scopes on different domains then I agree you should be able to. >PRA isn't what I would think of when I think of the word scope. The scope >within which PRA operates is the 2822 message header. Within this scope >there is more than one way to determine which header field is appropriate to >use. PRA is one way. There are others. > >If scope were defined by the type of data used to make a determination vice >the method, then I believe there is a limited, bounded set of potential >scopes that can be defined now. Pick different names if you want, but I >think they are: > >1. Envelope [2821] ~ mail_from >2. Header [2822] (I would include SUBMITTER here since it's an early look at >this scope) >3. HELO (separate from Envelope because it relates to the MTA and not the >message) I am not against this if either: 1. A common DNS record is used for all scopes. 2. Or there is a compelling reason a common record can not be used that overrides the compelling desire to not get fragmentation and proliferation of DNS records for per-domain anti-forgery. >But the "modular" approach must not serve as an excuse for approving >"among other possibilities" a scope/algorithm for which a massive number >of WG participants (read : a clear majority) have expressed that they >disapprove of because of the IPR encumbrance issue. What is wrong with approving SenderID/PRA as an optional algorithm scope in "modular" (common or single or unified) DNS record format? I am worried about: 1. People being induced to only publish SenderID or SPF records but not both. 2. Endorsing SenderID first or as the only algorithm scope. I am not so paranoid to think we have to ry to kill SenderID. We can not kill it. We would be much better off to embrace it carefully (force it into a common DNS record so other algorithms do not get locked out). >> Some compelling reasons for a single DNS record which does not specify >> algorithm scope: >> [snip] > > >This is all well covered stuff that was decided months ago. >I don't think it is a productive use of this working group's time to >re-raise issues that have already been decided just because someone >new has joined the working group. If you and everyone else is sure that all my points were covered from the same perspective as I am suggesting, then so be it. Then again, such a generalization could be a way to mask some points which were not covered. I think you have written here that you are not against PRA using SPF records, and I have written that I am not against a single DNS record that specifies all intended scopes, so I hope you are writing about the same history that I am. I see basically two camps in this list. One camp wants SPF as the mandatory standard. The other wants SenderID to be approved. Rather I am interested in getting a concensus. >Reading the complete archive will help you understand why the >decisions were made. You may not agree with those decisions, but so >be it. I have an extremely large archive of discussions I have made over the past several years. Reading that might help you understand my perspective. You may not agree with my perspective, nor have a month of time to read all my historical perspective, but nevertheless I think we are both entitled to express our opinion, especially about an important decision that affects all e-mail. That is to say do not assume your history is more important than my history (or perspective). Okay I made my opinions clear and will be a bystander for next 2 days or so... Thanks, Shelby Moore From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 11:46: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 LAA07915 for ; Fri, 10 Sep 2004 11:46: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 i8AFKBsa001282; Fri, 10 Sep 2004 08:20: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 i8AFKBce001281; Fri, 10 Sep 2004 08:20:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AFKAxS001272 for ; Fri, 10 Sep 2004 08:20:10 -0700 (PDT) (envelope-from SRS0+81b18495ec4da8345ff4+383+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C5nBr-0006Mq-As; Fri, 10 Sep 2004 16:19:58 +0100 Subject: RE: DEPLOY: not at the University of Cambridge From: David Woodhouse To: "Sauer, Damon" Cc: Tony Finch , "Hallam-Baker, Phillip" , ietf-mxcomp@imc.org In-Reply-To: <38363D9940D92A458010AAE24D162EB90521D0AF@bremocog-55> References: <38363D9940D92A458010AAE24D162EB90521D0AF@bremocog-55> Content-Type: text/plain Message-Id: <1094829593.22505.89.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 10 Sep 2004 16:19:54 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-09-10 at 09:04 -0500, Sauer, Damon wrote: > 1) When SPF is deployed and used the line between forgeries and > legitimate will be much sharper. > 2) In the corporate world, I am actually going to be able to deploy SPF > based on the argument that my MAIL FROM: will not be able to be forged. > 3) Which in turn makes all MY email legitimate. This means if anyone > sends with my domain from a source outside of my defined range, you can > identify as a forgery. The point is that you _cannot_ reliably identify it as a forgery unless you're willing to redefine your meaning of 'forgery' for the purpose; in particular you'd have to redefine your meaning of 'forgery' to include a lot of mail which a lot of people consider perfectly valid and normal. Consider the case where you send mail a user at one of my virtual domains, and my mail hosts forward it on to the final recipient. Some definitions of 'forgery' may include the mail which my mail host sends on... but my definition does not. We know how slow the world is to upgrade even when the upgrade is useful and well-designed, like ESMTP and TLS. For things like SRS or the Resent-* header abuse, I'd predict that the take-up will be a _lot_ slower. If it were just an addition to a Received: header perhaps it would be quicker to catch on though. That could be enabled by default in MTAs. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 11:48: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 LAA08119 for ; Fri, 10 Sep 2004 11:48: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 i8AFG4XQ001023; Fri, 10 Sep 2004 08:16: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 i8AFG430001022; Fri, 10 Sep 2004 08:16:04 -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 i8AFG3tI001014 for ; Fri, 10 Sep 2004 08:16:03 -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 9101816CD2 for ; Fri, 10 Sep 2004 11:25:15 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Thu, 09 Sep 2004 14:33:34 PDT." <1094765614.16741.225.camel@ddev.mail-abuse.org> Date: Fri, 10 Sep 2004 11:25:15 -0400 Message-Id: <20040910152515.9101816CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > If the mailbox domain has been safely blacklisted, then no confirmation > with respect to the IP address from the SPF records is needed. RFC 2821 header checking against authentication records in DNS enables recipients to safely blacklist mailbox domains. i.e. 100% of messages from a domain pass RFC 2821 DNS checks, and are spam: the recipient may choose to blacklist the domain. In the absence of those checks, the recipient can still blacklist the domain, but has no way of knowing for sure if the messages are forged, and thus an attack by a malicious third party, who wishes to disrupt communications between the alleged originator and the recipient. > Should abusive mail be discovered, it would be unsafe to conclude > the SPF mailbox-domain/IP address confirmation is tenable for > establishing a name blacklist. Are there reasons why this is true? > Only the IP address has received sufficient authentication for such > a listing, but then this has not improved upon current IP address > blacklisting. You are stating that your position is that your position is correct. > There are many cases where an MTA is shared. ... > A breach in the mail channel integrity can happen within either the > receiving or sending realm. An SPF blacklisting fails to locate the > accountable entity. Shared services means shared accountability. If the recipient is unable to distinguish between a "good" party on a shared MTA and a "bad" party, then by definition, both parties fall into the same classification. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 11:55:24 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 LAA08649 for ; Fri, 10 Sep 2004 11:55:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AFX3xL002191; Fri, 10 Sep 2004 08:33:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AFX3qW002190; Fri, 10 Sep 2004 08:33:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AFX1cD002183 for ; Fri, 10 Sep 2004 08:33:02 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 2AC5F28E4B for ; Fri, 10 Sep 2004 17:33:04 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04213-04-2 for ; Fri, 10 Sep 2004 17:33:00 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 60F6A28E4A; Fri, 10 Sep 2004 17:33:00 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Fri, 10 Sep 2004 17:33:00 +0200 (CEST) Message-ID: <37746.127.0.0.1.1094830380.squirrel@127.0.0.1> In-Reply-To: <4141C305.4000901@solidmatrix.com> References: <37503.127.0.0.1.1094826508.squirrel@127.0.0.1> <4141C305.4000901@solidmatrix.com> Date: Fri, 10 Sep 2004 17:33:00 +0200 (CEST) Subject: Re: clarification on consensus call for compromise From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Yakov Shafranovich a écrit : > > What about the scope idea itself? Do you agree with it? Well, I must admit that I haven't have much time to spend thinking of this issue since it has been raised, but there are a number of reasons that make me feel quite uncomfortable with it : It seems to me to be in contradiction with the "keep it simple, stupid" paradigm. We have to take into consideration that these protocols are being discussed and designed by e-mail experts, but will have to be used by "average-skill" sysadmins, and the procotol should avoid to create unnecessary complexities that would cause one to wonder what can be the differences between a 2821 or a 2822 scope on a practical standpoint, what differences it may cause in the system behaviour depending upon which kind of scope they want to publish in their records, or check in their MTA. The current SPF system record syntax is "a bit" complex, but yet straightforward enough to allow easy understanding. I'm afraid that if we have to add different scopes, and possibly different DNS records for a domain depending on the scopes, it may create complexity beyond the average sysadmin's understanding (or will to spend the necessary time for understanding and testing different possibilities). I'm also not sure that possibly multiplying DNS records for different scopes would be such a good idea, as it will, again, add complexity in DNS maintenance (and possibly multiply queries, cause TCP answers and add to DNS load). Lats but not least, I'm afraid that this could result in a mess, with the sender publishing records for one given scope, where the recipient MTA would be configured to check only for another scope, which would result in no checks being performed. The more complex we make it, the more chances we have to find ourselves in situations that may product "unpredictable results" between unrelated sending and receiving domains. Since the beginning, I feel that the "good" solution IMHO for the first MARID protocol, especially if we want to get something usable and deployed in the shortest possible timeframe, would be to go for SPF-Classic accompanied with SRS. And stick to it. Simple, that already has running implementations and a wide real-world deployment. I have also expressed here in the past that I feel that MARID should limit itself to checking existing 2821-stage fields (which means MAIL FROM: and HELO:) and leave alone the emails contents (2822 headers being "content"). Anyway this is just my personal opinion, regardless of other IPR issues. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E Qui peut m'expliquer comment fonctionne le fusible thermique sur les processeurs. Est ce que cela peut se configurer ? -+- DA in : : Neuneu pète un plomb -+- From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 11:56:09 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 LAA08770 for ; Fri, 10 Sep 2004 11:56: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 i8AFSs0O001867; Fri, 10 Sep 2004 08:28:54 -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 i8AFSsFU001866; Fri, 10 Sep 2004 08:28:54 -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 i8AFSscb001855 for ; Fri, 10 Sep 2004 08:28:54 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 10 Sep 2004 11:28:55 -0400 id 000A0290.4141C837.00001E6B In-Reply-To: <4141C291.1010907@solidmatrix.com> References: <4141C291.1010907@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1F7B5041-033E-11D9-B751-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: "IETF MXCOMP (E-mail)" From: Andrew Newton Subject: Re: Conclusion of Last Call? Date: Fri, 10 Sep 2004 11:28:53 -0400 To: Yakov Shafranovich 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 Sep 10, 2004, at 11:04 AM, Yakov Shafranovich wrote: > What's the bottom line if any? Please be patient. Marshall and I must spend some time rereading many of the threads and then compare notes. -andy From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 12:06: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 MAA09559 for ; Fri, 10 Sep 2004 12:06:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AFgJ95002843; Fri, 10 Sep 2004 08:42:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AFgJT5002842; Fri, 10 Sep 2004 08:42:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp2g.bellsouth.com (aismtp2g.bellsouth.com [139.76.165.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AFgIX7002833 for ; Fri, 10 Sep 2004 08:42:18 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp2g.bellsouth.com with ESMTP; Fri, 10 Sep 2004 11:42:10 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: DEPLOY: not at the University of Cambridge X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Fri, 10 Sep 2004 10:42:00 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB90521D18A@bremocog-55> Thread-Topic: DEPLOY: not at the University of Cambridge Thread-Index: AcSXScoDdSA0ZJDCQgGwOUZE1OWNOgAAeZZg From: "Sauer, Damon" To: "David Woodhouse" Cc: "Tony Finch" , "Hallam-Baker, Phillip" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8AFgJX7002837 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > 1) When SPF is deployed and used the line between forgeries and > > legitimate will be much sharper. > > 2) In the corporate world, I am actually going to be able to deploy > > SPF based on the argument that my MAIL FROM: will not be able to be > > forged. > > 3) Which in turn makes all MY email legitimate. This means if anyone > > sends with my domain from a source outside of my defined > range, you can > > identify as a forgery. > > The point is that you _cannot_ reliably identify it as a > forgery unless you're willing to redefine your meaning of > 'forgery' for the purpose; in particular you'd have to > redefine your meaning of 'forgery' to include a lot of mail > which a lot of people consider perfectly valid and normal. > > Consider the case where you send mail a user at one of my > virtual domains, and my mail hosts forward it on to the final > recipient. Some definitions of 'forgery' may include the mail > which my mail host sends on... but my definition does not. In this case it is not my MTA or your MTA that has an issue but one on the MTA's that you forward to. At this point it has less to do with an issue of my SPF record as it is your issue between your MTA's. If the receiving MTA does an SPF check, then the MTA that the message is forwarded to should trust the originating MTA shouldn't it? If the receiving MTA does not trust the sending MTA in your example, then why would you allow it to forward through it? Isn't this the same as an open-relay? My internal systems that my gateway systems forward to will not be doing SPF checks, that is what my gateways are for. Sounds like an administrative issue that can be resolved. Regards, Damon Sauer ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 12:41: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 MAA11989 for ; Fri, 10 Sep 2004 12:41:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGAVTj005985; Fri, 10 Sep 2004 09:10:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AGAVwi005984; Fri, 10 Sep 2004 09:10:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGAVNU005978 for ; Fri, 10 Sep 2004 09:10:31 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 10 Sep 2004 09:10:33 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 Sep 2004 09:10:31 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 10 Sep 2004 09:10:33 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Sep 2004 09:10:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: consensus call on pra/mailfrom deployment and versioning/scope Date: Fri, 10 Sep 2004 09:10:31 -0700 Message-ID: Thread-Topic: consensus call on pra/mailfrom deployment and versioning/scope thread-index: AcSWpjmXddSuFcx+RLGhrxM7y9d54wAqT4Qw From: "Harry Katz" To: "John Glube" , "Dave Crocker" , "Andrew Newton" , "IETF MARID WG" X-OriginalArrivalTime: 10 Sep 2004 16:10:31.0048 (UTC) FILETIME=[B1DD8880:01C49750] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8AGAVNU005979 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, September 09, 2004 12:30 PM John Glube wrote: [snip] > I presume a proposal which includes both pra and mailfrom > checks would involve elements of draft-marid-pra and > draft-marid-core, so giving rise to Microsoft's IPR claim and > the draft patent license with the noted restriction. Microsoft's IPR disclosure clearly states that our IPR claims relate to the maird-core and marid-pra specs used in combination. We are not aware of any IPR claims on marid-core used in combination with some other specification. > As such, the restriction contained in the draft patent > Sender-ID license would preclude network administrators from > incorporating both mailfrom and pra checks without obtaining > separate permission from Microsoft. Not true. Administrators or any other end users of licensed Sender ID implementations do not require a license from Microsoft. This is clearly stated in section 2.2 of the Sender ID license. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 12:48:23 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 MAA12374 for ; Fri, 10 Sep 2004 12:48:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGN8Ui006812; Fri, 10 Sep 2004 09:23: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 i8AGN8du006811; Fri, 10 Sep 2004 09:23:08 -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 i8AGN8xm006803 for ; Fri, 10 Sep 2004 09:23:08 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 10 Sep 2004 12:23:11 -0400 id 000A0295.4141D4EF.00002447 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: John Glube , IETF MARID WG From: Andrew Newton Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Fri, 10 Sep 2004 12:23:09 -0400 To: "Harry Katz" 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 Sep 10, 2004, at 12:10 PM, Harry Katz wrote: > On Thursday, September 09, 2004 12:30 PM John Glube wrote: > > [snip] >> I presume a proposal which includes both pra and mailfrom >> checks would involve elements of draft-marid-pra and >> draft-marid-core, so giving rise to Microsoft's IPR claim and >> the draft patent license with the noted restriction. > > Microsoft's IPR disclosure clearly states that our IPR claims relate to > the maird-core and marid-pra specs used in combination. We are not > aware of any IPR claims on marid-core used in combination with some > other specification. > >> As such, the restriction contained in the draft patent >> Sender-ID license would preclude network administrators from >> incorporating both mailfrom and pra checks without obtaining >> separate permission from Microsoft. > > Not true. Administrators or any other end users of licensed Sender ID > implementations do not require a license from Microsoft. This is > clearly stated in section 2.2 of the Sender ID license. Perhaps I misinterpreted the main question of John's email. I thought he was asking if the license allows for an implementation of both PRA and MAIL FROM. In other words, he was asking a question about certain language in the license that could be interpreted as disallowing any other scope. And I think the question arises from what is being considered the "Sender ID Specification". -andy From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 12:50: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 MAA12508 for ; Fri, 10 Sep 2004 12:50: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 i8AGR6eI007045; Fri, 10 Sep 2004 09:27: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 i8AGR6bW007044; Fri, 10 Sep 2004 09:27:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGR50L007037 for ; Fri, 10 Sep 2004 09:27:06 -0700 (PDT) (envelope-from SRS0=dEkfAAFe=L7=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8AGR8SV010589 for ; Fri, 10 Sep 2004 18:27:08 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409101627.I8AGR7FK010578@asarian-host.net> Date: Fri, 10 Sep 2004 16:27:08 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope X-Trace: P5zQ+GGzj/EtIaMq1NUFdK7EsmOZRRaBfk5VNzCmqQFMURNTb7omvZfx89pc3L30E/5OV409QvfsJSnmZBgN2w== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUHV3DFqW1BleBN9AQEfowf/frTmAtuts70d5TYBFFLoMyALvHfUdfZT 60N1mHA7DZHuKlmKe+kzMZbssxbXPmISiMfsWBkUAKiuStxhBFrxbS26yrz9Kwpf DqdATDjYjzzk8Eyd88rQsDH/nCYUBjEvxpiX1lZKVc85MbO68ylC7GDPSdpaPOjB 1ZvoqIdcbA8kDIdt4FOQXKkZrJd8zq/LIf5M7c7hG7hCQqIhaLuEJdvvylsZEr6x uFmP1Mg9Pax1J+/h/F/AQ5+pUeNtAarmIw4AoNiyB4almfC2UcZT66uaZXtLY4jS Y0UBKqoPqxg62LSvjW0fn094kWcEU42OLicKt7vVFmxfMZXggL52NA== =uml3 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Harry Katz wrote: >> As such, the restriction contained in the draft patent >> Sender-ID license would preclude network administrators from >> incorporating both mailfrom and pra checks without obtaining >> separate permission from Microsoft. > > Not true. Administrators or any other end users of licensed Sender ID > implementations do not require a license from Microsoft. This is > clearly stated in section 2.2 of the Sender ID license. IANAL, but when you say, "Administrators ... of LICENSEd Sender ID implementations do not require a LICENSE," then does not the former preclude the latter? Or are you saying I, as Administrator, do not need a license when I use an already exsting, licensed Sender-ID product (licensed to the company, for instance), but DO require one if I use PRA checks in a program of my own? Regards, - Mark From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 13:03:14 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 NAA13939 for ; Fri, 10 Sep 2004 13:03:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AGSOZX007124; Fri, 10 Sep 2004 09:28: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 i8AGSOqB007123; Fri, 10 Sep 2004 09:28:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8AGSNWs007115 for ; Fri, 10 Sep 2004 09:28:24 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 20896 invoked from network); 10 Sep 2004 16:29:59 -0000 Received: from unknown (HELO ?192.168.254.140?) (208.198.98.24) by ns1.hoster907.com with SMTP; 10 Sep 2004 16:29:59 -0000 In-Reply-To: <4.1.20040910233017.018906f0(null)> References: <4.1.20040910233017.018906f0(null)> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6EDFD584-0346-11D9-AFEC-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@vpnc.org From: Margaret Olson Subject: Re: clarification on consensus call for compromise Date: Fri, 10 Sep 2004 12:28:22 -0400 To: AccuSpam 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 Sep 10, 2004, at 11:31 AM, AccuSpam wrote: > >> Reading the complete archive will help you understand why the >> decisions were made. You may not agree with those decisions, but so >> be it. > > > I have an extremely large archive of discussions I have made over the > past several years. Reading that might help you understand my > perspective. You may not agree with my perspective, nor have a month > of time to read all my historical perspective, but nevertheless I > think we are both entitled to express our opinion, especially about an > important decision that affects all e-mail. > > That is to say do not assume your history is more important than my > history (or perspective). The issue is not that your perspective isn't potentially valuable, the point is that all of these issues have been discussed, at great length, on *this* list. We can not reopen all the issues every time someone new joins. All of us have studied the problems discussed here at great length, many of us over a number of years. Repetition of points already thoroughly explored do not contribute to the discussion. Please study the archives before posting further. If you do not have time to catch up with the list, I suggest that you do not have time to participate. Speaking entirely for myself. Margaret. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 13:42: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 NAA16493 for ; Fri, 10 Sep 2004 13:42: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 i8AHDkMx010599; Fri, 10 Sep 2004 10:13: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 i8AHDklh010598; Fri, 10 Sep 2004 10:13:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AHDjsN010584 for ; Fri, 10 Sep 2004 10:13:45 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from p67-39.acedsl.com ([66.114.67.39] helo=[192.168.2.33]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C5owh-0008P9-BQ; Fri, 10 Sep 2004 13:12:24 -0400 Message-ID: <4141E0BD.7000906@solidmatrix.com> Date: Fri, 10 Sep 2004 13:13:33 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Margaret Olson CC: AccuSpam , ietf-mxcomp@vpnc.org Subject: Re: clarification on consensus call for compromise References: <4.1.20040910233017.018906f0(null)> <6EDFD584-0346-11D9-AFEC-000A95BC6A7E@margaretolson.com> In-Reply-To: <6EDFD584-0346-11D9-AFEC-000A95BC6A7E@margaretolson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - vpnc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Margaret Olson wrote: > > > On Sep 10, 2004, at 11:31 AM, AccuSpam wrote: > >> >>> Reading the complete archive will help you understand why the >>> decisions were made. You may not agree with those decisions, but so >>> be it. >> >> >> >> I have an extremely large archive of discussions I have made over the >> past several years. Reading that might help you understand my >> perspective. You may not agree with my perspective, nor have a month >> of time to read all my historical perspective, but nevertheless I >> think we are both entitled to express our opinion, especially about an >> important decision that affects all e-mail. >> >> That is to say do not assume your history is more important than my >> history (or perspective). > > > The issue is not that your perspective isn't potentially valuable, the > point is that all of these issues have been discussed, at great length, > on *this* list. We can not reopen all the issues every time someone new > joins. All of us have studied the problems discussed here at great > length, many of us over a number of years. Repetition of points already > thoroughly explored do not contribute to the discussion. Please study > the archives before posting further. If you do not have time to catch up > with the list, I suggest that you do not have time to participate. > > Speaking entirely for myself. > And I would add to that that the WG has made consensus decisions at certain points, which is what Andy was trying to address. IETF WGs work by consensus, and certain decisions of this WG have already been made before. Ykaov From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 14:31:17 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 OAA19172 for ; Fri, 10 Sep 2004 14:31:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AI4HfH014239; Fri, 10 Sep 2004 11:04:17 -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 i8AI4HOi014238; Fri, 10 Sep 2004 11:04:17 -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 i8AI4HqL014230 for ; Fri, 10 Sep 2004 11:04:17 -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 48BD616CD2 for ; Fri, 10 Sep 2004 14:13:29 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: not at the University of Cambridge In-Reply-To: Your message of "Fri, 10 Sep 2004 16:19:54 BST." <1094829593.22505.89.camel@hades.cambridge.redhat.com> Date: Fri, 10 Sep 2004 14:13:29 -0400 Message-Id: <20040910181329.48BD616CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse wrote: > Consider the case where you send mail a user at one of my virtual > domains, and my mail hosts forward it on to the final recipient. Some > definitions of 'forgery' may include the mail which my mail host sends > on... but my definition does not. Your definition is irrelevant. What matters is the definitions published by the owners of the domains used in SMTP fields, and the application of those definitions by the recipient MTA. The whole purpose of MARID is to define how those definitions are published and interpreted, so that their application can be automated. Phrased another way, my MTA doesn't read this list, so it doesn't know what your definition of forgery is, and it therefore cannot apply it to incoming messages. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 15:00:22 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 PAA21694 for ; Fri, 10 Sep 2004 15:00: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 i8AIXbKE016347; Fri, 10 Sep 2004 11:33:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AIXbfL016346; Fri, 10 Sep 2004 11:33:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AIXbuX016340 for ; Fri, 10 Sep 2004 11:33:37 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59686) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1C5qDF-0008Qu-17 (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Fri, 10 Sep 2004 19:33:33 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C5qDE-0002R5-Ot; Fri, 10 Sep 2004 19:33:32 +0100 Date: Fri, 10 Sep 2004 19:33:32 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: not at the University of Cambridge In-Reply-To: <20040910181329.48BD616CD2@mail.nitros9.org> Message-ID: References: <20040910181329.48BD616CD2@mail.nitros9.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 10 Sep 2004, Alan DeKok wrote: > > What matters is the definitions published by the owners of the domains > used in SMTP fields, and the application of those definitions by the > recipient MTA. The whole purpose of MARID is to define how those > definitions are published and interpreted, so that their application can > be automated. Unfortunately MARID encourages sites to define bogus policies, because they can only describe the first part of a message's journey (up to the border of the originating organization), and it is very difficult for a recipient site to implement checks that accommodate all the possibilities in the rest of the message's journey. Tony. -- f.a.n.finch http://dotat.at/ COLWYN BAY TO THE MULL OF GALLOWAY INCLUDING THE ISLE OF MAN: SOUTH 3 OR 4, VEERING SOUTHWEST TONIGHT AND INCREASING 5 OR 6, AND LOCALLY 7 AROUND THE ISLES OF MAN, VEERING WEST 5 OR 6 LATER TOMORROW. SHOWERS. MODERATE OR GOOD. SLIGHT, BECOMING MODERATE, LOCALLY ROUGH LATER TONIGHT AND TOMORROW. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 16:21: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 QAA00457 for ; Fri, 10 Sep 2004 16:21: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 i8AJr1eJ022693; Fri, 10 Sep 2004 12:53: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 i8AJr1Vb022692; Fri, 10 Sep 2004 12:53:01 -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 i8AJr1Pf022684 for ; Fri, 10 Sep 2004 12:53:01 -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 33F054149B; Fri, 10 Sep 2004 12:52:56 -0700 (PDT) Subject: Re: SPF abused by spammers From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040910152515.9101816CD2@mail.nitros9.org> References: <20040910152515.9101816CD2@mail.nitros9.org> Content-Type: text/plain Message-Id: <1094845976.17587.151.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Sep 2004 12:52:56 -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-09-10 at 08:25, Alan DeKok wrote: > Douglas Otis wrote: > > > > If the mailbox domain has been safely blacklisted, then no confirmation > > with respect to the IP address from the SPF records is needed. > > RFC 2821 header checking against authentication records in DNS > enables recipients to safely blacklist mailbox domains. > > i.e. 100% of messages from a domain pass RFC 2821 DNS checks, and > are spam: the recipient may choose to blacklist the domain. I would restrict this to the EHLO domain. Using the MAIL FROM is making an assumption of the integrity of the mail channel providing the message. There is nothing to substantiate such an assumption and defending a blacklist is not a trivial matter. There is naturally a reasonably strong authentication of the IP address through transport protocol interaction. The use of names MUST be held to at least the same level of authentication. A name, unlike an IP address, may disable mail and, effectively, how a business is identified! Those running blacklisting services MUST be prepared to defend negative name based assertions, especially with a name's broader impact. A point of view that the mail channel "should" be secure and publishing an SPF record represents an implicit agreement the mail channel shall be considered secure is not defensible. "Tough luck, find a better provider!" does not address a possibility the provider may not be at fault. There are at least two realms that must be secure. > In the absence of those checks, the recipient can still blacklist > the domain, but has no way of knowing for sure if the messages are > forged, and thus an attack by a malicious third party, who wishes to > disrupt communications between the alleged originator and the > recipient. Those checks with respect to MAIL FROM and even the more extreme From with Sender-ID, still assumes the mail channel is secure. In the case of "open" records, it is assumed the outbound mail channel is not being shared. Where the normal implementation may be to publish the "nominal" sources of a mailbox domain and leave the record "open" as a solution for the forwarding issues, allows messages to suffer "validation" promotion moving through the mail channel. > > Should abusive mail be discovered, it would be unsafe to conclude > > the SPF mailbox-domain/IP address confirmation is tenable for > > establishing a name blacklist. > > Are there reasons why this is true? In short, the mail channel can not be assumed to be secure and not shared. > > Only the IP address has received sufficient authentication for such > > a listing, but then this has not improved upon current IP address > > blacklisting. > > You are stating that your position is that your position is correct. I was responding to Damon's statement that he was not looking at the SPF record for making a decision. If only the IP address is being used, then this has not improved upon the current IP address blacklisting. The address space is becoming more dynamic, but there are still black-holes implemented in routers by some providers that tend to permanently disable address space due to bad policies of companies now long out of business. Reclaiming this space may take decades. Moving to a name based reputation system allows a long history to exist without the overhead needed to track this exchange of IP addresses. Trojan proxies are largely an outcome of the need to commandeer an address that a blacklist attempts to make scarce. While the number of names of the good actors should reflect real uses, the number of bad actors will explode should a name blacklist become effective. This will require taking advantage of the history that a name naturally provides. This may seem like a poor choice, as the IP address space is bounded and the name space is not. To deal with such a difficult problem may require: a) Retain good actors long term (proved worthy of the magnetic domains expended) b) Establish policy based affiliations (agrees to Opt-In only perhaps) c) Limit exposure from new domains (cap messages perhaps) d) Improve vetting of domain name applications (industry sponsored clearing house perhaps) > > There are many cases where an MTA is shared. > ... > > A breach in the mail channel integrity can happen within either the > > receiving or sending realm. An SPF blacklisting fails to locate the > > accountable entity. > > Shared services means shared accountability. If the recipient is > unable to distinguish between a "good" party on a shared MTA and a > "bad" party, then by definition, both parties fall into the same > classification. Sharing an MTA is a highly effective method used by ISPs to abate abuse. Reserve painting this technique with such a broad brush. This wide brush never uncovers an MTA that may be compromised or poorly administered. Holding those unable to take immediate corrective action accountable will cause a most unwelcome backlash. The party that must be held accountable is the entity administrating policies of the MTA. That party is only identified by an authenticated EHLO domain or the IP address. Having the MAIL FROM or From reference a name list of EHLO domains allows a simple and safe method of publishing either the typical, compatible, "nominal" record, or the atypical, breaks-everything, "restrictive" record for outbound MTA servers. Making the authenticated EHLO domain visible and used as a basis for establishing reputations, affords consumer protections superior to that of the PRA algorithm. This approach allows a policy that always restricts the From, as example. Establishing a name for the MTA allows a "single" DNS lookup to further establish the Mailbox-domain to MTA relationship in a non-exploitable manner, and not the few hundred lookups required by SPF. When SPF is used to express the nominal outbound mail channel, this invites the very exploitation SPF had promised to curtail! SPF is good for white-listing. For white-listing, I like the binary RR specified by RFC3123 by P. Koch, "A DNS RR Type for Lists of Address Prefixes", June 2001. There is a bit of a mess with CIDR notation in SPF. It would be better in the long run to keep this information concise and as part of the standard DNS reference library. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 16:34: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 QAA02137 for ; Fri, 10 Sep 2004 16:34: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 i8AK5e18023757; Fri, 10 Sep 2004 13:05:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AK5eR5023756; Fri, 10 Sep 2004 13:05:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AK5dkO023740 for ; Fri, 10 Sep 2004 13:05:39 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.196]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040910200542.WOXL29920.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 10 Sep 2004 16:05:42 -0400 From: "John Glube" To: "'Harry Katz'" , "'Dave Crocker'" , "'Andrew Newton'" , "'IETF MARID WG'" Subject: RE: consensus call on pra/mailfrom deployment and versioning/scope Date: Fri, 10 Sep 2004 16:03:25 -0400 Message-ID: <00d101c49771$3b8ecf10$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8AK5ekO023747 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Harry, I appreciate the point that: >Microsoft's IPR disclosure clearly states that our IPR >claims relate to the maird-core and marid-pra specs used in >combination. We are not aware of any IPR claims on >marid-core used in combination with some other >specification. I acknowledge that: >... Administrators or any other end users of licensed >Sender ID implementations do not require a license from >Microsoft. This is clearly stated in section 2.2 of the >Sender ID license. Perhaps I did not make my point clearly in my earlier note. So, let me give a specific example. Let's say I am a software developer. A protocol is adopted which allows MTA's to do mailfrom and/or pra checks. The specification includes draft-marid-core (modified to include reference to mailfrom checks as well as pra checks), draft-marid-pra and draft-marid-mailfrom. (This is somewhat speculative on my part, but we need a set of facts for the sake of discussion.) Microsoft has an IPR claim on using draft-marid-pra in combination with draft-marid-core. (I make this statement based on Microsoft's existing claims.) I want to write a program which allows an MTA to run mailfrom and/or pra checks using these specifications and then distribute this program to end users. The program will be a plug in, or filter which is designed to work with any of the existing MTA's on the market. The draft patent license contains the following: Microsoft ... hereby grant You a perpetual ...worldwide license under Microsoft’s Necessary Claims to use ... object code versions of Licensed Implementations only as incorporated into Licensed Products and solely for the purpose of conforming with the Sender ID Specification. (See section 2.1 of the draft Patent License.) I appreciate that as long as I include the requisite notice: You also have ... a ... license to distribute or otherwise disclose source code copies of such Licensed Implementation ... (See section 2.2 of the draft Patent License.) The question is whether I can incorporate mailfrom checks in my program, so that an end user can do both mailfrom and/or pra checks using my software program? My concern is with the last restriction in the draft patent license which reads: ... "and solely for the purpose of conforming with the Sender ID Specification." I take this to mean "object code versions of Licensed Implementations only as incorporated into Licensed Products" can only be used to "conform with the Sender ID Specification." (The Sender ID Specification being defined as the combination of draft-marid-pra with draft-marid-core.) On this point, please also note the following Q & A from Microsoft's FAQ: Q8: What if I want to use the Sender ID technology in some other context, still related to email but perhaps not related to Sender ID? Will Microsoft sue me? A8: Microsoft is committed to working with companies in a collaborative way to license our Intellectual Property (see http://www.microsoft.com/mscorp/ip/). If Microsoft is granted patent rights that cover the Sender ID specification (currently pending) it will make those rights available at no cost for anyone to implement and use the Sender ID specification. Microsoft will need to see what patent rights are granted by the US Patent and Trademark Office to even know for sure what rights it has to offer. Since it is impossible to contemplate every possible use of it Sender ID patent rights we cannot make a commitment up front to specific license terms. We invite anyone interested in using Microsoft’s IP to innovate and compete in the marketplace to come talk to us. I want to use the Sender ID technology in a software program which allows network administrators to run both mailfrom and/or pra checks on incoming email to the network, or outgoing email from the network she is administrating. Can I do this under the license terms, or do I as per Q8 and A8 need a separate license from Microsoft? If I need a separate license then as I note in my earlier email: As such, the restriction contained in the draft patent Sender-ID license would preclude network administrators from incorporating both mailfrom and pra checks without obtaining separate permission from Microsoft. To be totally clear, the concern should have read: As such, the restriction contained in the draft patent Sender-ID license would preclude network administrators from incorporating both mailfrom and pra checks without the distributor of any such Licensed Implementation obtaining separate permission from Microsoft. I trust this helps to clarify the issue raised in my earlier note. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.752 / Virus Database: 503 - Release Date: 03/09/2004 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 17:14: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 RAA09423 for ; Fri, 10 Sep 2004 17:14:45 -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 i8AKjgFf027101; Fri, 10 Sep 2004 13:45:42 -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 i8AKjgC4027100; Fri, 10 Sep 2004 13:45:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts25-srv.bellnexxia.net (tomts25.bellnexxia.net [209.226.175.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AKjfUN027090 for ; Fri, 10 Sep 2004 13:45:42 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.196]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040910204545.VIJV7925.tomts25-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 10 Sep 2004 16:45:45 -0400 From: "John Glube" To: "'Andrew Newton'" , "'Harry Katz'" Cc: "'IETF MARID WG'" Subject: RE: consensus call on pra/mailfrom deployment and versioning/scope Date: Fri, 10 Sep 2004 16:43:28 -0400 Message-ID: <00d201c49776$d38cc650$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8AKjgUN027094 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Andy, When you wrote: >Perhaps I misinterpreted the main question of John's email. >I thought he was asking if the license allows for an >implementation of both PRA and MAIL FROM. In other words, >he was asking a question about certain language in the >license that could be interpreted as disallowing any other >scope. And I think the question arises from what is being >considered the "Sender ID Specification." You have fairly stated my concern. My purpose in putting forward an example in response to Harry's message was to simply illustrate the underlying issue. I regret causing any inconvenience by responding directly to Harry via the mailing list. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.752 / Virus Database: 503 - Release Date: 03/09/2004 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 17:44: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 RAA11688 for ; Fri, 10 Sep 2004 17:44:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ALHrx0028992; Fri, 10 Sep 2004 14:17: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 i8ALHrkN028991; Fri, 10 Sep 2004 14:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ALHn7K028982 for ; Fri, 10 Sep 2004 14:17:50 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C5smH-0006xZ-00 for ; Fri, 10 Sep 2004 23:17:53 +0200 Received: from c-134-92-136.hh.dial.de.ignite.net ([62.134.92.136]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Sep 2004 23:17:53 +0200 Received: from nobody by c-134-92-136.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Sep 2004 23:17:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: consensus call of RR prefix Date: Fri, 10 Sep 2004 23:16:40 +0200 Organization: Lines: 12 Message-ID: <414219B8.7929@xyzzy.claranet.de> References: <200409051824.i85IOOg02258@grimsvotn.TechFak.Uni-Bielefeld.DE> <200409062234.25224.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-92-136.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > many sites have wildcard MX records so that they can catch > mail sent to any address. This means that they want to > receive mail, not matter how it is addressed within their > domain, but they don't authorize sending with such addresses. -all is not the only application of wildcards, for me it's a redirect=claranet.de doing the trick. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 17:44: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 RAA11714 for ; Fri, 10 Sep 2004 17:44: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 i8ALKiSF029161; Fri, 10 Sep 2004 14:20: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 i8ALKicY029160; Fri, 10 Sep 2004 14:20:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ALKiYS029149 for ; Fri, 10 Sep 2004 14:20:44 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Sep 2004 21:20:43 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "Michel Bouissou" Subject: RE: clarification on consensus call for compromise Date: Fri, 10 Sep 2004 15:21:09 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 V6.00.2900.2180 In-Reply-To: <37746.127.0.0.1.1094830380.squirrel@127.0.0.1> Importance: Normal X-OriginalArrivalTime: 10 Sep 2004 21:20:43.0479 (UTC) FILETIME=[07BD1E70:01C4977C] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I agree with everything said here by Michel Bouissou. He saved me a lot of typing by addressing every issue in the same way I would have. I can see the utility in allowing multiple scopes, but I would prefer that MARID define a "universal" scope which provides the foundation for additional scopes. -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Michel Bouissou Sent: Friday, September 10, 2004 09:33 AM To: ietf-mxcomp@imc.org Subject: Re: clarification on consensus call for compromise Yakov Shafranovich a écrit : > > What about the scope idea itself? Do you agree with it? Well, I must admit that I haven't have much time to spend thinking of this issue since it has been raised, but there are a number of reasons that make me feel quite uncomfortable with it : It seems to me to be in contradiction with the "keep it simple, stupid" paradigm. We have to take into consideration that these protocols are being discussed and designed by e-mail experts, but will have to be used by "average-skill" sysadmins, and the procotol should avoid to create unnecessary complexities that would cause one to wonder what can be the differences between a 2821 or a 2822 scope on a practical standpoint, what differences it may cause in the system behaviour depending upon which kind of scope they want to publish in their records, or check in their MTA. The current SPF system record syntax is "a bit" complex, but yet straightforward enough to allow easy understanding. I'm afraid that if we have to add different scopes, and possibly different DNS records for a domain depending on the scopes, it may create complexity beyond the average sysadmin's understanding (or will to spend the necessary time for understanding and testing different possibilities). I'm also not sure that possibly multiplying DNS records for different scopes would be such a good idea, as it will, again, add complexity in DNS maintenance (and possibly multiply queries, cause TCP answers and add to DNS load). Lats but not least, I'm afraid that this could result in a mess, with the sender publishing records for one given scope, where the recipient MTA would be configured to check only for another scope, which would result in no checks being performed. The more complex we make it, the more chances we have to find ourselves in situations that may product "unpredictable results" between unrelated sending and receiving domains. Since the beginning, I feel that the "good" solution IMHO for the first MARID protocol, especially if we want to get something usable and deployed in the shortest possible timeframe, would be to go for SPF-Classic accompanied with SRS. And stick to it. Simple, that already has running implementations and a wide real-world deployment. I have also expressed here in the past that I feel that MARID should limit itself to checking existing 2821-stage fields (which means MAIL FROM: and HELO:) and leave alone the emails contents (2822 headers being "content"). Anyway this is just my personal opinion, regardless of other IPR issues. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E Qui peut m'expliquer comment fonctionne le fusible thermique sur les processeurs. Est ce que cela peut se configurer ? -+- DA in : : Neuneu pète un plomb -+- From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 17:52:04 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 RAA12179 for ; Fri, 10 Sep 2004 17:52: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 i8ALUSth029743; Fri, 10 Sep 2004 14:30: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 i8ALUSr6029742; Fri, 10 Sep 2004 14:30:28 -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 i8ALURp1029736 for ; Fri, 10 Sep 2004 14:30:28 -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 i8ALfVjt012929 for ; Fri, 10 Sep 2004 14:41:31 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8ALfVSW012926 for ; Fri, 10 Sep 2004 14:41:31 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 10 Sep 2004 14:41:31 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID WG Subject: I-D ACTION:draft-kucherawy-sender-auth-header-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: This is very usefull draft for this WG. We should consider sponsoring it further. ---------- Forwarded message ---------- Date: Fri, 10 Sep 2004 15:55:32 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Message Header for Indicating Sender Authentication Status Author(s) : M. Kucherawy Filename : draft-kucherawy-sender-auth-header-00.txt Pages : 15 Date : 2004-9-10 This memo defines a new message header for use with [MAIL] messages to indicate the results of sender authentication efforts to mail user agents (MUAs) in order to equip them to relay that information in a convenient way to users. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-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-kucherawy-sender-auth-header-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-kucherawy-sender-auth-header-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-kucherawy-sender-auth-header-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 Fri Sep 10 18:19: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 SAA15074 for ; Fri, 10 Sep 2004 18:19: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 i8ALs1MD031366; Fri, 10 Sep 2004 14:54: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 i8ALs12p031365; Fri, 10 Sep 2004 14:54:01 -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 i8ALs0Zl031354 for ; Fri, 10 Sep 2004 14:54:00 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [66.80.0.14] (dhcp-14.danastreet.live.com [66.80.0.14]) by mail.glyphic.com (Postfix) with ESMTP id 75EF540C7 for ; Fri, 10 Sep 2004 14:53:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: clarification on consensus call for compromise Date: Fri, 10 Sep 2004 14:53:57 -0700 To: IETF MARID WG 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 There has been quite a bit of discussion here about either removing scopes or allowing some sort of universal or wildcard scope. I would not support such a concept because it lessens the strength of what a domain is saying by publishing records. In particular, if a domain were to publish (making up a syntax...): example.com. IN A SPF2 "spf2.0/* +mx +a -all" We have to wonder what this record says. It authorizes a set of hosts to use the domain "example.com" as part of which identities in mail? All of them? Including identities that we haven't named a scope for yet? I certainly wouldn't publish such a record for my domain, as I don't know what I'm making such an assertion about. While I might be willing to believe that the "+mx" and "+a" directives are going to be reasonable for any such identity (after all, the reference machines I presumably have control of), I can't make such a statement about "-all". I don't know that there might be some notion of identity, as yet undefined, for which I'd need to include other hosts. While other site owners might be willing to take such risks and publish such records, the ability to do so lesses the effectiveness for the whole scheme. If domains are able to make claims like "We didn't know about that identity check when we published "spf2.0/*" - you can't ding our reputation based on that check." or " - you can't reject mail that doesn't pass", it means that the whole scheme is diminished. In short, when we say "domains authorized the use of identity X by publishing an SPF record" we do so because we are going to hold them accountable if the authorization passes, and reject if it fails. And for those actions to have any force, the declaration of authorization has to be incontestable. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 18:43:44 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 SAA17118 for ; Fri, 10 Sep 2004 18:43:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AMHMho034067; Fri, 10 Sep 2004 15:17:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AMHMcN034066; Fri, 10 Sep 2004 15:17:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AMHL3I034060 for ; Fri, 10 Sep 2004 15:17:21 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 10 Sep 2004 15:17:20 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 Sep 2004 15:17:21 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 10 Sep 2004 15:17:20 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Sep 2004 15:17:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: consensus call on pra/mailfrom deployment and versioning/scope Date: Fri, 10 Sep 2004 15:17:11 -0700 Message-ID: Thread-Topic: consensus call on pra/mailfrom deployment and versioning/scope thread-index: AcSXcY+IDKb7OL+QRWmlBMFv8FDaHgADHo/w From: "Harry Katz" To: "John Glube" , "Dave Crocker" , "Andrew Newton" , "IETF MARID WG" X-OriginalArrivalTime: 10 Sep 2004 22:17:19.0681 (UTC) FILETIME=[F0086B10:01C49783] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8AMHL3I034061 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On September 10, 2004 1:03 PM, John Glube [mailto:jbglube@sympatico.ca] wrote: > Harry, > > I appreciate the point that: > > >Microsoft's IPR disclosure clearly states that our IPR > claims relate to > >the maird-core and marid-pra specs used in combination. We are not > >aware of any IPR claims on marid-core used in combination with some > >other specification. > > I acknowledge that: > > >... Administrators or any other end users of licensed Sender ID > >implementations do not require a license from Microsoft. This is > >clearly stated in section 2.2 of the Sender ID license. > > Perhaps I did not make my point clearly in my earlier note. Perhaps I misunderstood. At any rate, thank you for taking the time to clarify. > So, let me give a specific example. > > Let's say I am a software developer. > > A protocol is adopted which allows MTA's to do mailfrom > and/or pra checks. The specification includes > draft-marid-core (modified to include reference to mailfrom > checks as well as pra checks), draft-marid-pra and > draft-marid-mailfrom. > > (This is somewhat speculative on my part, but we need a set > of facts for the sake of discussion.) This is my understanding of the co-chairs proposal too. > Microsoft has an IPR claim on using draft-marid-pra in > combination with draft-marid-core. > > (I make this statement based on Microsoft's existing > claims.) Correct. > I want to write a program which allows an MTA to run mailfrom > and/or pra checks using these specifications and then > distribute this program to end users. > > The program will be a plug in, or filter which is designed to > work with any of the existing MTA's on the market. > > The draft patent license contains the following: > > Microsoft ... hereby grant You a perpetual ...worldwide > license under Microsoft's Necessary Claims to use ... > object code versions of Licensed Implementations only as > incorporated into Licensed Products and solely for the > purpose of conforming with the Sender ID Specification. > > (See section 2.1 of the draft Patent License.) > > I appreciate that as long as I include the requisite notice: > > You also have ... a ... license to distribute or otherwise > disclose source code copies of such Licensed Implementation ... > > (See section 2.2 of the draft Patent License.) > > The question is whether I can incorporate mailfrom checks in > my program, so that an end user can do both mailfrom and/or > pra checks using my software program? Yes, you can. We are not aware of any Microsoft IPR claim related to spoof checking of MAIL FROM. Therefore, the Sender ID license is irrelevent for checking MAIL FROM. > My concern is with the last restriction in the draft patent > license which reads: > > ... "and solely for the purpose of conforming with the Sender > ID Specification." > > I take this to mean "object code versions of Licensed > Implementations only as incorporated into Licensed Products" > can only be used to "conform with the Sender ID Specification." > > (The Sender ID Specification being defined as the combination > of draft-marid-pra with draft-marid-core.) > > On this point, please also note the following Q & A from > Microsoft's FAQ: > > Q8: What if I want to use the Sender ID technology in some > other context, still related to email but perhaps not related > to Sender ID? Will Microsoft sue me? > > A8: Microsoft is committed to working with companies in a > collaborative way to license our Intellectual Property (see > http://www.microsoft.com/mscorp/ip/). If Microsoft is granted > patent rights that cover the Sender ID specification > (currently pending) it will make those rights available at no > cost for anyone to implement and use the Sender ID > specification. Microsoft will need to see what patent rights > are granted by the US Patent and Trademark Office to even > know for sure what rights it has to offer. > Since it is impossible to contemplate every possible use of > it Sender ID patent rights we cannot make a commitment up > front to specific license terms. We invite anyone interested > in using Microsoft's IP to innovate and compete in the > marketplace to come talk to us. > > I want to use the Sender ID technology in a software program > which allows network administrators to run both mailfrom > and/or pra checks on incoming email to the network, or > outgoing email from the network she is administrating. > > Can I do this under the license terms, or do I as per Q8 and > A8 need a separate license from Microsoft? As I stated above, we are not aware of any Microsoft IPR claims on MAIL FROM checking, so our license is not relevent. So, to be as clear as I can, if you're implementing spoof checks of both PRA and MAIL FROM under the framework described in Core (and our patent application is granted) then you would need a license for the PRA check but not the MAIL FROM check. If you are implementing spoof checking of MAIL FROM and _not_ PRA, we have no IPR claims, and no license to offer. > If I need a separate license then as I note in my earlier > email: > > As such, the restriction contained in the draft patent > Sender-ID license would preclude network administrators from > incorporating both mailfrom and pra checks without obtaining > separate permission from Microsoft. > > To be totally clear, the concern should have read: > > As such, the restriction contained in the draft patent > Sender-ID license would preclude network administrators from > incorporating both mailfrom and pra checks without the > distributor of any such Licensed Implementation obtaining > separate permission from Microsoft. > > I trust this helps to clarify the issue raised in my earlier note. Thanks. Likewise, I hope I've answered your question. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 19:23:51 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 TAA19437 for ; Fri, 10 Sep 2004 19:23:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AMruSi036286; Fri, 10 Sep 2004 15:53: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 i8AMru77036285; Fri, 10 Sep 2004 15:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AMrs6x036277 for ; Fri, 10 Sep 2004 15:53:55 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C5uHB-0000iL-00 for ; Sat, 11 Sep 2004 00:53:53 +0200 Received: from c-134-92-136.hh.dial.de.ignite.net ([62.134.92.136]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2004 00:53:53 +0200 Received: from nobody by c-134-92-136.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2004 00:53:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope Date: Sat, 11 Sep 2004 00:52:52 +0200 Organization: Lines: 23 Message-ID: <41423044.1E97@xyzzy.claranet.de> References: <33F089AA-019C-11D9-9A6B-000A95B3BA44@hxr.us> <20040909132112.GB28026@nic.fr> <16704.41738.510079.625670@proton.pathname.com> <20040910131647.GA24748@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-92-136.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > 2) "fetchmail", meaning the algorithm explained in > http://www.imc.org/ietf-mxcomp/mail-archive/msg04356.html Not very different from spf2.0/mailfrom if I got this right. The conclusion in RfC 3834 (4) is: | The Return-Path address is really the only one from the | message header that can be expected, as a matter of protocol, | to be suitable for automatic responses that were not | anticipated by the sender. > I simply believe that, given the current state of the art > about email identities, it is better to have choice. Yes. For an unmodified PRA to work RfC 2476 could be updated (8.1 MAY insert Sender => MUST insert Sender), but actually it would be simpler to fix the algorithm (pretend that a Sender matching the Return-Path is there if necessary). Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 19:25: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 TAA19529 for ; Fri, 10 Sep 2004 19:25: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 i8AN1NBh036542; Fri, 10 Sep 2004 16:01:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8AN1NPF036541; Fri, 10 Sep 2004 16:01:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8AN1L7w036504 for ; Fri, 10 Sep 2004 16:01:22 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Sep 2004 23:01:23 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Cc: "Mark Lentczner" Subject: RE: clarification on consensus call for compromise Date: Fri, 10 Sep 2004 17:01:47 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 10 Sep 2004 23:01:23.0025 (UTC) FILETIME=[1796B410:01C4978A] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > There has been quite a bit of discussion here about either removing > scopes or allowing some sort of universal or wildcard scope. I'd like to clarify the terminology a little, just to make sure we are talking about the same thing: - universal/mandatory scope: A scope which is mandatory, universally understood, and required for MARID compliant implementation. Basically, a foundation scope which all domains must publish and MTAs must evaluate under MARID. - wildcard scopes/no scopes: A way of saying the MARID record applies to all MARID scopes. (your made up example: "spf2.0/* +mx +a -all") From the rest of your message, I am guessing that you are against wildcard scopes, but not universal scopes? If so, I would agree: I am against wildcard scopes. I would also say that I'm for at least one universal/mandatory scope. -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Mark Lentczner Sent: Friday, September 10, 2004 03:54 PM To: IETF MARID WG Subject: Re: clarification on consensus call for compromise There has been quite a bit of discussion here about either removing scopes or allowing some sort of universal or wildcard scope. I would not support such a concept because it lessens the strength of what a domain is saying by publishing records. In particular, if a domain were to publish (making up a syntax...): example.com. IN A SPF2 "spf2.0/* +mx +a -all" We have to wonder what this record says. It authorizes a set of hosts to use the domain "example.com" as part of which identities in mail? All of them? Including identities that we haven't named a scope for yet? I certainly wouldn't publish such a record for my domain, as I don't know what I'm making such an assertion about. While I might be willing to believe that the "+mx" and "+a" directives are going to be reasonable for any such identity (after all, the reference machines I presumably have control of), I can't make such a statement about "-all". I don't know that there might be some notion of identity, as yet undefined, for which I'd need to include other hosts. While other site owners might be willing to take such risks and publish such records, the ability to do so lesses the effectiveness for the whole scheme. If domains are able to make claims like "We didn't know about that identity check when we published "spf2.0/*" - you can't ding our reputation based on that check." or " - you can't reject mail that doesn't pass", it means that the whole scheme is diminished. In short, when we say "domains authorized the use of identity X by publishing an SPF record" we do so because we are going to hold them accountable if the authorization passes, and reject if it fails. And for those actions to have any force, the declaration of authorization has to be incontestable. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 19:44: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 TAA20298 for ; Fri, 10 Sep 2004 19:44: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 i8ANKHv7037926; Fri, 10 Sep 2004 16:20:17 -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 i8ANKHdg037925; Fri, 10 Sep 2004 16:20:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ANK3ua037907 for ; Fri, 10 Sep 2004 16:20:16 -0700 (PDT) (envelope-from SRS0+d1e260bf94796c5167e3+383+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C5ugR-0005F1-UP; Sat, 11 Sep 2004 00:19:59 +0100 Subject: Re: clarification on consensus call for compromise From: David Woodhouse To: Mark Lentczner Cc: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1094858399.9144.111.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Sat, 11 Sep 2004 00:19:59 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-09-10 at 14:53 -0700, Mark Lentczner wrote: > I can't make such a statement about > "-all". I don't know that there might be some notion of identity, as > yet undefined, for which I'd need to include other hosts. To cite an example: in today's world, you need to include other hosts for both RFC2821 reverse-path and RFC2822 identities. > While other site owners might be willing to take such risks and publish > such records, the ability to do so lesses the effectiveness for the > whole scheme. Indeed they might be willing to do that, and indeed it does lessen the effectiveness of the whole scheme. > If domains are able to make claims like "We didn't know > about that identity check when we published "spf2.0/*" - you can't ding > our reputation based on that check." or " - you can't reject mail that > doesn't pass", it means that the whole scheme is diminished. It does indeed mean that the whole scheme is diminished. > In short, when we say "domains authorized the use of identity X by > publishing an SPF record" we do so because we are going to hold them > accountable if the authorization passes, and reject if it fails. And > for those actions to have any force, the declaration of authorization > has to be incontestable. I agree. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 19:56:44 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 TAA21236 for ; Fri, 10 Sep 2004 19:56: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 i8ANSp6a038267; Fri, 10 Sep 2004 16:28: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 i8ANSpCV038266; Fri, 10 Sep 2004 16:28:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8ANSosE038259 for ; Fri, 10 Sep 2004 16:28:51 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 39332 invoked from network); 10 Sep 2004 23:28:52 -0000 Received: from unknown (HELO vaio) (203.115.130.11) by relay.pair.com with SMTP; 10 Sep 2004 23:28:52 -0000 X-pair-Authenticated: 203.115.130.11 Message-Id: <4.1.20040911073016.03d75100(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 11 Sep 2004 07:40:31 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: clarification on consensus call for compromise In-Reply-To: <4141E0BD.7000906@solidmatrix.com> References: <6EDFD584-0346-11D9-AFEC-000A95BC6A7E@margaretolson.com> <4.1.20040910233017.018906f0(null)> <6EDFD584-0346-11D9-AFEC-000A95BC6A7E@margaretolson.com> 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: >> The issue is not that your perspective isn't potentially valuable, the >> point is that all of these issues have been discussed, at great length, >> on *this* list. We can not reopen all the issues every time someone new >> joins. [...] >And I would add to that that the WG has made consensus decisions at >certain points, which is what Andy was trying to address. IETF WGs work >by consensus, and certain decisions of this WG have already been made >before. Sorry to post again, because I already made my points clear, but I must address this black propoganda (or personalization of facts). Instead of making a general statement that all of my points are invalid due to some phantom concensus decisions, if you are so familiar with those concensus decisions (and the issues involved in them), why not just answer my post with specific links to those representative posts regarding those threads for each point I made? I am sure that would be more useful than some generalized propoganda. It might be instructive that when you start to refute my points point-by-point with links to past threads, then we might discover something or at least my points will be put to rest. I have seen other examples here (e.g. the Cambridge deploy thread) where others have taken the time to reference preference threads regarding important points, and I have thus seen new information (or perspectives) sprout because of that. The argument that you have been working on this for years seems to hold less weight when you do not have concensus on how to handle the current roadblock and you do not have an algorithm which can prevent forgery 100% for a domain that declares a forgery DNS record. Please stop the personalization of debate and go back to the facts. If you disagree with my position, then please present some relevant links to past posts. I have an open mind. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 20:21: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 UAA22755 for ; Fri, 10 Sep 2004 20:21:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ANwcdS040263; Fri, 10 Sep 2004 16:58: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 i8ANwbMh040262; Fri, 10 Sep 2004 16:58:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8ANwbPv040256 for ; Fri, 10 Sep 2004 16:58:37 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 52020 invoked from network); 10 Sep 2004 23:58:41 -0000 Received: from unknown (HELO vaio) (203.115.130.11) by relay.pair.com with SMTP; 10 Sep 2004 23:58:41 -0000 X-pair-Authenticated: 203.115.130.11 Message-Id: <4.1.20040911081007.00abfb00(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 11 Sep 2004 08:10:31 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: [spf-discuss] Unified SPF policy daemon and constructing apersonal whitelist 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: Apologies I sent this to wrong list, because of c+P. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 20:21:23 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 UAA22785 for ; Fri, 10 Sep 2004 20:21:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ANvcX1040207; Fri, 10 Sep 2004 16:57: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 i8ANvc1f040206; Fri, 10 Sep 2004 16:57:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8ANvbaG040199 for ; Fri, 10 Sep 2004 16:57:37 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 51370 invoked from network); 10 Sep 2004 23:57:40 -0000 Received: from unknown (HELO vaio) (203.115.130.11) by relay.pair.com with SMTP; 10 Sep 2004 23:57:40 -0000 X-pair-Authenticated: 203.115.130.11 Message-Id: <4.1.20040911080902.00abf5a0(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 11 Sep 2004 08:09:23 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: clarification on consensus call for compromise 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: The algorithm has to take that in account else the algorithm is not going to be popular. There seems to be a big disconnect here between reality. None of the proposals can specify with 100% certainty what will happen with the published data. For example, with the record below, what happens when a fowarder does not use SRS or SUBMITTER? All the algorithms used have to take this fuzziness into account. >If so, I would agree: I am against wildcard scopes. I would also say that >I'm for at least one universal/mandatory scope. This is impossible and/or unrealistic. For example, what are you going to mandate about the reality of incomplete adoption of a forwarding solution for MAILFROM? At 02:53 PM 9/10/2004 -0700, you wrote: > >There has been quite a bit of discussion here about either removing >scopes or allowing some sort of universal or wildcard scope. > >I would not support such a concept because it lessens the strength of >what a domain is saying by publishing records. In particular, if a >domain were to publish (making up a syntax...): > > example.com. IN A SPF2 "spf2.0/* +mx +a -all" > >We have to wonder what this record says. It authorizes a set of hosts >to use the domain "example.com" as part of which identities in mail? >All of them? Including identities that we haven't named a scope for >yet? > >I certainly wouldn't publish such a record for my domain, as I don't >know what I'm making such an assertion about. While I might be willing >to believe that the "+mx" and "+a" directives are going to be >reasonable for any such identity (after all, the reference machines I >presumably have control of), I can't make such a statement about >"-all". I don't know that there might be some notion of identity, as >yet undefined, for which I'd need to include other hosts. > >While other site owners might be willing to take such risks and publish >such records, the ability to do so lesses the effectiveness for the >whole scheme. If domains are able to make claims like "We didn't know >about that identity check when we published "spf2.0/*" - you can't ding >our reputation based on that check." or " - you can't reject mail that >doesn't pass", it means that the whole scheme is diminished. > >In short, when we say "domains authorized the use of identity X by >publishing an SPF record" we do so because we are going to hold them >accountable if the authorization passes, and reject if it fails. And >for those actions to have any force, the declaration of authorization >has to be incontestable. > > - Mark > >Mark Lentczner >http://www.ozonehouse.com/mark/ >markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 20:23:48 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 UAA22943 for ; Fri, 10 Sep 2004 20:23:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ANvZK2040195; Fri, 10 Sep 2004 16:57: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 i8ANvZqD040194; Fri, 10 Sep 2004 16:57:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8ANvYqY040188 for ; Fri, 10 Sep 2004 16:57:34 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 51337 invoked from network); 10 Sep 2004 23:57:37 -0000 Received: from unknown (HELO vaio) (203.115.130.11) by relay.pair.com with SMTP; 10 Sep 2004 23:57:37 -0000 X-pair-Authenticated: 203.115.130.11 Message-Id: <4.1.20040911080850.00a8df00(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 11 Sep 2004 08:08:52 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: [spf-discuss] Unified SPF policy daemon and constructing apersonal whitelist 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: At 02:29 PM 9/10/2004 -0400, you wrote: > >> My point was the semantic difference is useless for anti-spam unless >> you know that all "not known" implies a spammer domain. >> > >I think you missed Meng's point: > >not known <> known not > >He's implying that there was a check for the domain against a system >that lists the good guys, like cloudmark. Therefore it is 'known not to >be a spammer domain'. I got his point. Respectfully, you apparently still did not get mine. Please go back to my previous post in this thread. My basic point is that the inverse result does not imply a spammer, so the result is not that useful. Cloudmark can not PASS most non-spam domains. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 22:04:26 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 WAA28276 for ; Fri, 10 Sep 2004 22:04:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8B1VGjX044541; Fri, 10 Sep 2004 18:31: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 i8B1VGds044540; Fri, 10 Sep 2004 18:31:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8B1VFZb044534 for ; Fri, 10 Sep 2004 18:31:16 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C5wjY-0004JK-00 for ; Sat, 11 Sep 2004 03:31:20 +0200 Received: from c-134-92-136.hh.dial.de.ignite.net ([62.134.92.136]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2004 03:31:20 +0200 Received: from nobody by c-134-92-136.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2004 03:31:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: clarification on consensus call for compromise Date: Sat, 11 Sep 2004 03:30:10 +0200 Organization: Lines: 23 Message-ID: <41425522.128@xyzzy.claranet.de> References: <1094767077.5605.5.camel@localhost.localdomain> <01F77AC2-028D-11D9-BE4C-000A95B3BA44@hxr.us> <1094767077.5605.5.camel@localhost.localdomain> <22794.6032341153$1094778015@news.gmane.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-92-136.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit AccuSpam wrote: > Seems to me that your implication that someone would need to > publish different mail servers depending on whether the > Return-Path or PRA header is being evaluated is not > mainstream. It is. PRA does not work with legacy MUAs and MSAs, where the sending site doesn't insert a "Sender" matching the MAIL FROM (to overrule a 2822-From not matching the MAIL FROM). In other words I daily send mails with "my" 2822-From, which would FAIL in a PRA-Test, because "my" sender policy has scope MAIL FROM and not PRA. > none of the scoped algorithms give a 100% final result If "my" MAIL FROM results in a FAIL, then this is 100% final, and if it results in a PASS then that's also 100% final. And "my" 2822-From results in a 100% final NONE when it happens to be the PRA. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 22:06: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 WAA28315 for ; Fri, 10 Sep 2004 22:06: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 i8B1bU9N044996; Fri, 10 Sep 2004 18:37: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 i8B1bUg2044995; Fri, 10 Sep 2004 18:37:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8B1bTsU044988 for ; Fri, 10 Sep 2004 18:37:30 -0700 (PDT) (envelope-from SRS0=GwfodJAg=MA=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8B1bZGg028557 for ; Sat, 11 Sep 2004 03:37:35 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409110137.I8B1BY6B028547@asarian-host.net> Date: Sat, 11 Sep 2004 01:37:35 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: clarification on consensus call for compromise X-Trace: qji/YvuhWNAyATfn0fx+5ZvF8uGIkWOmayTvYlGD5giFWDdzlX+mHyDGR+9CGCLFhYb2zrvnSTnLQh/Q6gxefA== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <6EDFD584-0346-11D9-AFEC-000A95BC6A7E@margaretolson.com><4.1.20040910233017.018906f0(null)><6EDFD584-0346-11D9-AFEC-000A95BC6A7E@margaretolson.com> <4.1.20040911073016.03d75100(null)> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUJW3zFqW1BleBN9AQHlgAgAjX4tvAeXBE4BBN6xJ/GWWc8TQkiqgXOI 2E0BzWMBspdVMZD6hZiC3qqa3Fv+BB23QKV+tDaxdEv1vyaNVCZjpLo8EfUgLacU afOqrH3ZyDYifCYld2tiMCahbh3hxLy5A/R+Vb+7anxkXtgTSyguDgjd4Eb+WFGr tm77zNEj8IEb2HMxhPUZ0wDram2ry1WPP6VQli5OHxMC5mtadVI+fBL5BRgWKkn9 5Bd6btM9uUF6yCnN/Z/oIh0qNAR3uk0KQnDtIY88Ty5jWYCK4zlZrzdQLVwnrBaM 5n602q6oXgf0eqSIRXVruCxVIomrmt6jtpYCfa+lNFit9/wMw9nr4w== =1BsV Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit AccuSpam wrote: > Sorry to post again, because I already made my points clear, but I > must address this black propoganda (or personalization of facts). Please, do not follow the same, disasterous, path that you went on the SPF list. As a lawyer would say, "cease and desist". > Instead of making a general statement that all of my points are > invalid due to some phantom concensus decisions, if you are so > familiar with those concensus decisions (and the issues involved in > them), why not just answer my post with specific links to those > representative posts regarding those threads for each point I made? Because you are to do your own homework. :) Good-bye, - Mark P.S. Speaking entirely for myself. From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 22:31: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 WAA29335 for ; Fri, 10 Sep 2004 22:31: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 i8B26dLl046622; Fri, 10 Sep 2004 19:06: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 i8B26d0X046621; Fri, 10 Sep 2004 19:06:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8B26c4X046614 for ; Fri, 10 Sep 2004 19:06:39 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C5xHo-0005Ef-00 for ; Sat, 11 Sep 2004 04:06:44 +0200 Received: from c-134-92-136.hh.dial.de.ignite.net ([62.134.92.136]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2004 04:06:44 +0200 Received: from nobody by c-134-92-136.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Sep 2004 04:06:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd) Date: Sat, 11 Sep 2004 04:05:10 +0200 Organization: Lines: 12 Message-ID: <41425D56.6E83@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-92-136.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit william(at)elan.net wrote: > This is very usefull draft for this WG. > We should consider sponsoring it further. Yes, it could replace the "Received-SPF:" header in the SPF classic draft. I'm a bit lost with one of the examples (9.4), it has auth=, spf=, and sender-id=, but AUTH is done by the MSA, while spf resp. sender-id tests are done by the MX / MDA. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 23:48: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 XAA02908 for ; Fri, 10 Sep 2004 23:48: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 i8B3GFMb050297; Fri, 10 Sep 2004 20:16:15 -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 i8B3GFrB050296; Fri, 10 Sep 2004 20:16:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts36-srv.bellnexxia.net (tomts36-srv.bellnexxia.net [209.226.175.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8B3GErL050290 for ; Fri, 10 Sep 2004 20:16:15 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.196]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040911031620.SAHU25796.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 10 Sep 2004 23:16:20 -0400 From: "John Glube" To: "'Harry Katz'" , "'Dave Crocker'" , "'Andrew Newton'" , "'IETF MARID WG'" Subject: RE: consensus call on pra/mailfrom deployment and versioning/scope Date: Fri, 10 Sep 2004 23:14:01 -0400 Message-ID: <000001c497ad$63332890$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8B3GFrL050291 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Harry, I appreciate the clarification as noted below: As I stated above, we are not aware of any Microsoft IPR claims on MAIL FROM checking, so our license is not relevant. So, to be as clear as I can, if you're implementing spoof checks of both PRA and MAIL FROM under the framework described in Core (and our patent application is granted) then you would need a license for the PRA check but not the MAIL FROM check. If you are implementing spoof checking of MAIL FROM and _not_PRA, we have no IPR claims, and no license to offer. One comment: * Depending on whether the WG does proceed further with the consensus call as put forward by the co-chairs, I suggest you may wish to amend the FAQ to reflect your answers. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.752 / Virus Database: 503 - Release Date: 03/09/2004 From owner-ietf-mxcomp@mail.imc.org Fri Sep 10 23:49: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 XAA02945 for ; Fri, 10 Sep 2004 23:49:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8B3TPg3051181; Fri, 10 Sep 2004 20:29: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 i8B3TPDY051180; Fri, 10 Sep 2004 20:29:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8B3TPfV051174 for ; Fri, 10 Sep 2004 20:29:25 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.196]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040911032931.HGDQ29920.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 10 Sep 2004 23:29:31 -0400 From: "John Glube" To: "'Harry Katz'" , "'Dave Crocker'" , "'Andrew Newton'" , "'IETF MARID WG'" Subject: RE: consensus call on pra/mailfrom deployment and versioning/scope Date: Fri, 10 Sep 2004 23:27:12 -0400 Message-ID: <000101c497af$3a814d80$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8B3TPfV051175 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Andy, Thank you for facilitating an answer to my concern. As Harry noted in his response: >As I stated above, we are not aware of any Microsoft IPR >claims on MAIL FROM checking, so our license is not >relevent. So, to be as clear as I can, if you're >implementing spoof checks of both PRA and MAIL FROM under >the framework described in Core (and our patent application >is granted) then you would need a license for the PRA check >but not the MAIL FROM check. If you are implementing spoof >checking of MAIL FROM and _not_ PRA, we have no IPR claims, >and no license to offer. This answer clearly sets out the issue. The question remains as to whether it resolves the problem. A number of comments: * Unfortunately, based on my read of the most recent version of the FAQ, along with posts made to this mailing list, there continues to be a fundamental issue surrounding the lack of compatibility between Microsoft's draft patent license with the GPL. From where I sit, this problem requires resolution for smooth implementation of the consensus call. Why? One of the driving forces behind pra is the expressed need of the financial sector to control phishing attacks, along with the general desire of all domain owners to thwart spoofing and phishing attacks to retain brand integrity. Without resolution between Microsoft and the open source community this means pra checking will not be as widely implemented, so diminishing the effectiveness of this part of the layered defence for the benefit of those who need it most. As such this remains an underlying stumbling block which I suggest the WG chairs must consider in deciding how best to proceed with the consensus call. * The other concern I have revolves around the lack of an operational and security review by greybeards of both pra and mailfrom checking. This is not a new issue. Sender authentication, without implementation of reputation and accreditation services along the Aspen model will not achieve the ultimate objective of providing a reliable methodology for UBE volume control. (Please note, I do not believe we will ever be able to stop abusive behaviour online. The best we can hope for is to bring the problem under control.) There has been much discussion on this list about the merit or lack of merit of the two proposed "scopes" as underpinnings for use in developing reliable reputation models. I strongly believe such a peer review would help to flush out and resolve these issues, along with any underlying operational and security issues. If nothing else, it would certainly give added comfort to those who have to implement all of this. Until these two concerns are resolved, it remains my view that this WG can only proceed with "pra and mailfrom" as experimental protocols. I find this position somewhat awkward. I want sender authentication to succeed. I acknowledge there is a dramatic sense of urgency. Email is broken and needs fixing. I appreciate and support the vision. I acknowledge a number of large organizations have stepped forward and expressed a willingness to back "pra and mailfrom." Yet, I am reluctant to proceed full steam ahead when I can see cracks in the foundation which I believe will come back and bite us all at the end of the day. Thank you again for taking the time to listen to my concerns. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.752 / Virus Database: 503 - Release Date: 03/09/2004 From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 08:00: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 IAA11916 for ; Sat, 11 Sep 2004 08:00: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 i8BBPJgN096147; Sat, 11 Sep 2004 04:25:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BBPJJX096146; Sat, 11 Sep 2004 04:25:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BBPGm5096140 for ; Sat, 11 Sep 2004 04:25:19 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i8BBP72N005464; Sat, 11 Sep 2004 13:25:07 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i8BBOOn8022228; Sat, 11 Sep 2004 13:24:24 +0200 From: Hadmut Danisch Date: Sat, 11 Sep 2004 13:24:24 +0200 To: ietf-mxcomp@imc.org, asrg@ietf.org Subject: Patenting HOWTO/FAQ ? Message-ID: <20040911112424.GA21779@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, can anyone recommend any FAQ or HOWTO or a book about how to apply for a patent in the USA? I have done some further development of mechanisms which protect against spam, fraud, phishing etc. and improve e-mail for commercial and private use, but I do not want to repeat the same mistake as with RMX again. I'd like to protect against plagiarism and especially that kind of capture we've seen from Microsoft. I'd therefore like to apply for a patent and make the mechanism available for free for the open source community (like GPL), but to take license fees from commercial vendors like Microsoft. Beat 'em with their own weapons. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 08:29: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 IAA14243 for ; Sat, 11 Sep 2004 08:29:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BC8vNu097892; Sat, 11 Sep 2004 05:08: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 i8BC8vCm097891; Sat, 11 Sep 2004 05:08:57 -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 i8BC8vZe097882 for ; Sat, 11 Sep 2004 05:08:57 -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 i8BCJh3B008603; Sat, 11 Sep 2004 05:19:43 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8BCJhQN008600; Sat, 11 Sep 2004 05:19:43 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 11 Sep 2004 05:19:43 -0700 (PDT) From: "william(at)elan.net" To: Hadmut Danisch cc: ietf-mxcomp@imc.org, Subject: Re: [Asrg] Patenting HOWTO/FAQ ? In-Reply-To: <20040911112424.GA21779@danisch.de> 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: Its admirable that you want to protect the open source community from some corporate patent sharks :) But are you prepared to spend $20,000 of your own money to file such a patent ($2,000 - $5,000 if without a lawyer; but expect to have patent application returned to you for corrections or it might just get rejected entirely after two years of waiting...)? Are you also aware that once you disclose the idea or technology on public forum or published it as IETF draft, you can no longer file a patent for it (even if you're the author of the draft)? Best of luck to you if you answer yes to both questions above, in that case, please see http://www.uspto.gov/ebc/efs/index.html On Sat, 11 Sep 2004, Hadmut Danisch wrote: > Hi, > > can anyone recommend any FAQ or HOWTO or a book about > how to apply for a patent in the USA? > > I have done some further development of mechanisms > which protect against spam, fraud, phishing etc. and > improve e-mail for commercial and private use, > but I do not want to repeat the same mistake as with > RMX again. I'd like to protect against plagiarism > and especially that kind of capture we've seen from > Microsoft. I'd therefore like to apply for a patent > and make the mechanism available for free for the > open source community (like GPL), but to take license > fees from commercial vendors like Microsoft. Beat 'em > with their own weapons. > > regards > Hadmut From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 09:15: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 JAA16227 for ; Sat, 11 Sep 2004 09:15: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 i8BCq4VI000380; Sat, 11 Sep 2004 05: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 i8BCq4dj000379; Sat, 11 Sep 2004 05:52:04 -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 i8BCq3Yn000368 for ; Sat, 11 Sep 2004 05:52:03 -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 1C67ME-0005ty-Gk for ietf-mxcomp@imc.org; Sat, 11 Sep 2004 07:52:03 -0500 To: "IETF MARID WG" References: <20040911112424.GA21779@danisch.de> From: wayne Reply-To: "IETF MARID WG" Date: Sat, 11 Sep 2004 07:51:58 -0500 In-Reply-To: <20040911112424.GA21779@danisch.de> (Hadmut Danisch's message of "Sat, 11 Sep 2004 13:24:24 +0200") 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: Patenting HOWTO/FAQ ? 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.6 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 <20040911112424.GA21779@danisch.de> Hadmut Danisch writes: > can anyone recommend any FAQ or HOWTO or a book about > how to apply for a patent in the USA? I think this is pretty much off-topic for this list. > I'd therefore like to apply for a patent > and make the mechanism available for free for the > open source community (like GPL), but to take license > fees from commercial vendors like Microsoft. Beat 'em > with their own weapons. As mad as I am about the problems that the MS SenderID patent and license has caused, I don't think that two wrongs make a right. I hope that such a patent encumbered technology would not be put in any standard advanced by the IETF. -wayne From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 10:09: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 KAA19422 for ; Sat, 11 Sep 2004 10:09: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 i8BDi02d004100; Sat, 11 Sep 2004 06:44: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 i8BDi0pv004099; Sat, 11 Sep 2004 06:44:00 -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 i8BDhpWc004076 for ; Sat, 11 Sep 2004 06:43:53 -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 59A5316CD2 for ; Sat, 11 Sep 2004 09:53:03 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Fri, 10 Sep 2004 12:52:56 PDT." <1094845976.17587.151.camel@ddev.mail-abuse.org> Date: Sat, 11 Sep 2004 09:53:03 -0400 Message-Id: <20040911135303.59A5316CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > > i.e. 100% of messages from a domain pass RFC 2821 DNS checks, and > > are spam: the recipient may choose to blacklist the domain. > > I would restrict this to the EHLO domain. Using the MAIL FROM is making > an assumption of the integrity of the mail channel providing the > message. Perhaps you didn't read the sentence you quoted. I explicitly stated that the message passed DNS checks, and there is therefore NO need to make assumptions about the integrity of the mail channel providing the message. In the scenario I described, by *definition*, the mail channel has been verified to have integrity, so far as the RFC 2821 headers go. Please address that issue. Repeating the claim that a blacklist is based on "assumptions" when I explicitly described a scenario where it could be based on verifiable information is... not nice. > There is naturally a reasonably strong authentication of the IP > address through transport protocol interaction. Yes, you've said that many, many times. I understand that's your position. I'm trying to get you to understand my position. > Those checks with respect to MAIL FROM and even the more extreme From > with Sender-ID, still assumes the mail channel is secure. For Sender-Id, maybe. For MAIL FROM checks, absolutely not. Security != authentication. You can authenticate someone in an insecure system. MAIL FROM checks work in an insecure mail channel. They *don't* interact well with ".forward" systems, but that's an authentication issue, not a security issue. In fact, MAIL FROM checks use the source IP address (which you claim is the only secure/verifiable entity) to answer the question "is this IP permitted to use this domain name in MAIL FROM?" If we put additional conflicts with ".forward" systems aside for a moment, then MAIL FROM and EHLO based checks are identical in security. > > Shared services means shared accountability. If the recipient is > > unable to distinguish between a "good" party on a shared MTA and a > > "bad" party, then by definition, both parties fall into the same > > classification. > > Sharing an MTA is a highly effective method used by ISPs to abate abuse. > Reserve painting this technique with such a broad brush. I'm not. I'm talking about what information is out there, and what decisions can possibly be made, independent of any technical proposal. If someone can't tell the difference between two things, then it MUST treat the two things as identical. This is a well-known concept, and based solely on the available information. If you choose to disagree with this, that's your perogative, but it means that any system you come up with will be based on using information which is unavailable to anyone. > Holding those unable to take immediate corrective action accountable > will cause a most unwelcome backlash. This is a political response to a technical problem: the recipients cannot technically distinguish between two parties, and therefore treats both the same. If one party doesn't like it, the solution isn't political, it's technical: give the recipient additional information which lets him distinguish the two parties. > The party that must be held accountable is the entity administrating > policies of the MTA. That party is only identified by an > authenticated EHLO domain or the IP address. And other parties using that MTA will, by definition, get associated with the reputation of that MTA. This is what you call "a broad brush". Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 13:35:57 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 NAA29035 for ; Sat, 11 Sep 2004 13:35: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 i8BH7cjs014909; Sat, 11 Sep 2004 10:07: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 i8BH7cu3014908; Sat, 11 Sep 2004 10:07:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BH7bH6014886 for ; Sat, 11 Sep 2004 10:07:37 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i8BH5veX011849; Sat, 11 Sep 2004 10:05:57 -0700 In-Reply-To: <20040911112424.GA21779@danisch.de> References: <20040911112424.GA21779@danisch.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: asrg@ietf.org, "'IETF MARID WG'" From: Marshall Rose Subject: Re: Patenting HOWTO/FAQ ? Date: Sat, 11 Sep 2004 10:05:53 -0700 To: Hadmut Danisch 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 Sep 11, 2004, at 04:24, Hadmut Danisch wrote: > can anyone recommend any FAQ or HOWTO or a book about > how to apply for a patent in the USA? it is clear that your posting is completely inappropriate for the marid list. it is clear that your posting should not have copied both marid and asrg. it is clear that you have now been warned, and that further misbehavior will result in consequences. it is clear that if anyone else responds to your posting on the marid list, that they too will receive the attention of the co-chairs. /mtr From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 14:22: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 OAA00972 for ; Sat, 11 Sep 2004 14:22: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 i8BHxCdG017706; Sat, 11 Sep 2004 10:59: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 i8BHxC0R017705; Sat, 11 Sep 2004 10:59: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 i8BHxBec017692 for ; Sat, 11 Sep 2004 10:59:12 -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; Sat, 11 Sep 2004 13:59:08 -0400 id 000A0287.41433CEF.0000258E Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 Date: Sat, 11 Sep 2004 13:59:06 -0400 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 The following is the judgment of the co-chairs relating to consensus within the MARID working group during the last call period of 23-August-2004 through 10-September-2004. 1) On the issue of using a DNS name prefix, there is at least rough consensus that no prefix should be used. 2) On the issue of compliance with the use of the TXT record, the working group has at least rough consensus that TXT usage is acceptable for compliance and should not be specified as a configuration that will be non-compliant. However, there is at least rough consensus that the use of the SPF-specific record type is more desirable than the use of a TXT record type. It is the opinion of the co-chairs that the -protocol document clearly state that the usage of TXT records will most likely be deprecated by future protocol definition. 3) On the issue of ignoring patent claims, the working group has at least rough consensus that the patent claims should not be ignored. Additionally, there is at least rough consensus that the participants of the working group cannot accurately describe the specific claims of the patent application. This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application. We do feel that future changes regarding the patent claim or its associated license could significantly change the consensus of the working group, and at such a time it would be appropriate to consider new work of this type. 4) On the issue of the ABNF in section 3.4.1 of -protocol and multiple scopes, there is at least rough consensus to allow the syntax and record structure to support multiple scopes. With regard to items 3 and 4 above, it is also the opinion of the co-chairs that any attempt by the MARID working group to define any new scopes other than "mailfrom" and "pra" for the SPF syntax will at this time result in failure to find consensus within the working group. The document authors have agreed to producing new drafts intended to meet the chartered work item, and a consensus call on them or the appropriate diffs will be forthcoming. This work plan does not include scopes outside of "mail from" and "pra", and it is our opinion that no new work items of this type should be considered until MARID has successfully produced a first specification. -MARID co-chairs From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 15:12: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 PAA04087 for ; Sat, 11 Sep 2004 15:12:32 -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 i8BIlurn019822; Sat, 11 Sep 2004 11:47: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 i8BIluQn019821; Sat, 11 Sep 2004 11:47:56 -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 i8BIlt3K019814 for ; Sat, 11 Sep 2004 11:47:55 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id CA5714149B; Sat, 11 Sep 2004 11:47:59 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 11 Sep 2004 11:47:59 -0700 (PDT) Message-ID: <1118.64.142.13.68.1094928479.squirrel@harry.mail-abuse.org> In-Reply-To: <20040911135303.59A5316CD2@mail.nitros9.org> References: Your message of "Fri, 10 Sep 2004 12:52:56 PDT." <1094845976.17587.151.camel@ddev.mail-abuse.org> <20040911135303.59A5316CD2@mail.nitros9.org> Date: Sat, 11 Sep 2004 11:47:59 -0700 (PDT) Subject: Re: SPF abused by spammers From: "Douglas Otis" To: "Alan DeKok" Cc: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > "Alan DeKok" wrote: > Douglas Otis wrote: > >>> i.e. 100% of messages from a domain pass RFC 2821 DNS checks, and >>> are spam: the recipient may choose to blacklist the domain. >> >> I would restrict this to the EHLO domain. Using the MAIL FROM is making >> an assumption of the integrity of the mail channel providing the >> message. > > Perhaps you didn't read the sentence you quoted. I explicitly > stated that the message passed DNS checks, and there is therefore NO > need to make assumptions about the integrity of the mail channel > providing the message. A DNS check that obtains a list of addresses for a mailbox-domain, MUST assume channel integrity when holding the apparent originator of the message accountable. A mailbox-domain administrator may delegate mail services to many disparate sending domains which may also be shared with many other mailbox-domains. Publishing an SPF record does not include an implied acceptance of accountability for these other sending domains or the receiving domains within the recipient's realm. Due to forwarding issues, expect many lists to be left "open" to allow other unknown domains to forward messages. It is unfortunate, with the SPF draft, the expressed MTA/mailbox-domain relationship is used to also authorize the sending MTA. This means an "open" relationship will likely invite a problem the SPF record hoped to prevent. Complex macros aimed at rediscovering the actual sending MTA or, in the case of Sender-ID, the PRA algorithm used to indirectly resolve the sending MTA where the RFC2822 From had been superceded, can simply be replaced by authenticating the MTA EHLO. There are clearly two steps needed, but these two steps have been collapsed into a one very broken step with SPF or Sender-ID. Step 1: Authenticate the MTA EHLO name. Step 2: Compare the mailbox-domain/EHLO list to this name. If spam is detected at the MTA, the EHLO name is held accountable. By having this second step, confusion regarding which entity must be held accountable is removed and safely allows any level of restriction to be placed upon either the MAIL FROM or the From mailbox domains. By making the authenticated EHLO domain visible within the MUA and allowing a few institutions to publish a comprehensive rather than nominal mailbox-domain/EHLO list as an exceptional restriction, will provide superior consumer protection than possible with either SPF or Sender-ID. > In the scenario I described, by *definition*, the mail channel has been > verified to have integrity, so far as the RFC 2821 headers go. It is not a trivial matter defending a reputation service. Listing a name has potentially greater impact than an IP address. One can not defend assumptions of accountable entities by suggesting the mail channel is "defined" to have integrity. Nor is it reasonable for those seeking to have their mail accepted to be held accountable for the actions of others. SPF with "open" lists is seriously flawed, to say nothing about other security issues. Anyone sharing a domain and publishing an "open" list is susceptible to being spoofed. Because of the collapsing of the MTA authorization with the domain relationships and allowances for "open" lists, this actually invites spoofing. While listing "nominal" outbound servers may be useful for "coloring" the mail, these mailbox domains MUST NOT be held accountable for any abuse that may occur. > Please address that issue. Repeating the claim that a blacklist is > based on "assumptions" when I explicitly described a scenario where it > could be based on verifiable information is... not nice. Listing a name and blocking their mail because you don't care which entity actually caused the message to be sent is also... not nice. >> There is naturally a reasonably strong authentication of the IP >> address through transport protocol interaction. > > Yes, you've said that many, many times. I understand that's your > position. I'm trying to get you to understand my position. > >> Those checks with respect to MAIL FROM and even the more extreme From >> with Sender-ID, still assumes the mail channel is secure. > > For Sender-Id, maybe. For MAIL FROM checks, absolutely not. > > Security != authentication. You can authenticate someone in an > insecure system. > > MAIL FROM checks work in an insecure mail channel. They *don't* > interact well with ".forward" systems, but that's an authentication > issue, not a security issue. What entity should be held accountable? The entity authenticated as sending the mail, or the mailbox-domain that authorized the mail to be sent? Obtaining an authorization is not the same as authentication of the acting entity. > In fact, MAIL FROM checks use the source IP address (which you claim > is the only secure/verifiable entity) to answer the question "is this > IP permitted to use this domain name in MAIL FROM?" If we put > additional conflicts with ".forward" systems aside for a moment, then > MAIL FROM and EHLO based checks are identical in security. These checks are not the same. You are devising a system that requires mailbox-domains authorize other domains to send their mail. Those actually sending the mail can be authenticated as performing this directly. Simply authorizing a domain does not imply they accept accountability for these sending domains. If the sending MTA EHLO name is authenticated and authorized by the EHLO domain, then it does not matter what mailbox-domain is sent, this EHLO entity can be safely held accountable for the MTA actions. If there is a problem, only this entity can take immediate action or provide logs in the event of a crime. >> > Shared services means shared accountability. If the recipient is >> > unable to distinguish between a "good" party on a shared MTA and a >> > "bad" party, then by definition, both parties fall into the same >> > classification. >> >> Sharing an MTA is a highly effective method used by ISPs to abate abuse. >> Reserve painting this technique with such a broad brush. > > I'm not. I'm talking about what information is out there, and what > decisions can possibly be made, independent of any technical proposal. > > If someone can't tell the difference between two things, then it > MUST treat the two things as identical. But these things can be identified by an authenticated EHLO name. They MUST NOT be treated as identical. > This is a well-known concept, and based solely on the available > information. If you choose to disagree with this, that's your perogative, > but it means that any system you come up with will be based on using > information which is unavailable to anyone. SPF is proposing to add information, but then uses this information inappropreiately. CSV and MPR attempt to add information and use this information to establish accurate accountability. There is a difference and anyone can use this information. >> Holding those unable to take immediate corrective action accountable >> will cause a most unwelcome backlash. > > This is a political response to a technical problem: the recipients > cannot technically distinguish between two parties, and therefore > treats both the same. If one party doesn't like it, the solution > isn't political, it's technical: give the recipient additional > information which lets him distinguish the two parties. That is what CSV does. It allows a reputation service to distinguish those directly responsible without any assumptions of the mail channel integrity. >> The party that must be held accountable is the entity administrating >> policies of the MTA. That party is only identified by an >> authenticated EHLO domain or the IP address. > > And other parties using that MTA will, by definition, get associated > with the reputation of that MTA. This is what you call "a broad brush". A reputation service spends most of their efforts ensuring information. Using the IP address makes this process rather straight forward. Using an authenticated EHLO name follows the same model and directly identifies those sending the messages. To suggest that because the EHLO domain was not considered, means a reputation service can safely hold entities accountable for the action of others will not have much sway. Again, this is not a trivial matter. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 16:15: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 QAA07211 for ; Sat, 11 Sep 2004 16:15: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 i8BJgUTq022530; Sat, 11 Sep 2004 12:42: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 i8BJgUhS022529; Sat, 11 Sep 2004 12:42:30 -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 i8BJgTf5022523 for ; Sat, 11 Sep 2004 12:42:29 -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 1C6DlT-0001ha-IX for ietf-mxcomp@imc.org; Sat, 11 Sep 2004 14:42:33 -0500 To: "IETF MARID WG" References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Sat, 11 Sep 2004 14:42:27 -0500 In-Reply-To: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> (Andrew Newton's message of "Sat, 11 Sep 2004 13:59:06 -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: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 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.6 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 <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Andrew Newton writes: > 3) On the issue of ignoring patent claims, the working group has at > least rough consensus that the patent claims should not be ignored. > Additionally, there is at least rough consensus that the participants > of the working group cannot accurately describe the specific claims of > the patent application. This stems from the fact that the patent > application is not publicly available. Agreed. > Given this, it is the opinion > of the co-chairs that MARID should not undertake work on alternate > algorithms reasonably thought to be covered by the patent application. Uh, can you give an example of an alternative algorithm to the PRA that has been discussed that might be "reasonably thought to be covered by the PRA patent"? I can't think of any. As per RFC3668, which all participants of this mailing list are supposed to comply with, if we start creating an alternative that does happen to be covered by any IPR of any other participant, we will learn about such encumbrance. See: http://www.ietf.org/NOTEWELL.html http://www.ietf.org/rfc/rfc3668.txt So, while I agree that we shouldn't try to create a standard that we know is encumbered, isn't this pretty much what we have been trying to do already? > With regard to items 3 and 4 above, it is also the opinion of the > co-chairs that any attempt by the MARID working group to define any > new scopes other than "mailfrom" and "pra" for the SPF syntax will at > this time result in failure to find consensus within the working group. It is the opinion of this participant that the pra scope will not reach consensus due in large part to the patent mess, whether there is a mailfrom scope or not. It is the opinion of this participant that the mailfrom scope will not reach consensus. unless it also allows for the helo scope to be checked and thus be compatible with SPF-classic. SPF-classic is the current defacto standard and I think standardizing existing practice is the easiest way to reach a consensus. > This work plan does not > include scopes outside of "mail from" and "pra", and it is our opinion > that no new work items of this type should be considered until MARID > has successfully produced a first specification. Given this work plan, I do not expect this working group to ever produce a first specification. *very heavy sigh* -wayne From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 16:21: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 QAA07364 for ; Sat, 11 Sep 2004 16:21: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 i8BK05UK023093; Sat, 11 Sep 2004 13:00: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 i8BK05We023092; Sat, 11 Sep 2004 13:00:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BK03bS023086 for ; Sat, 11 Sep 2004 13:00:04 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i8BK05eA015401 for ietf-mxcomp@imc.org; Sat, 11 Sep 2004 22:00:05 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i8BJw0pS009409 for ietf-mxcomp@imc.org; Sat, 11 Sep 2004 21:58:00 +0200 From: Hadmut Danisch Date: Sat, 11 Sep 2004 21:58:00 +0200 To: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 Message-ID: <20040911195800.GA9312@danisch.de> References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 11, 2004 at 01:59:06PM -0400, Andrew Newton wrote: > > The document authors have agreed to producing new drafts intended to > meet the chartered work item, and a consensus call on them or the > appropriate diffs will be forthcoming. This work plan does not include > scopes outside of "mail from" and "pra", and it is our opinion that no > new work items of this type should be considered until MARID has > successfully produced a first specification. Is there any (estimated) timeline? Hadmut From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 16:21:04 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 QAA07388 for ; Sat, 11 Sep 2004 16:21:04 -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 i8BJxDVa023058; Sat, 11 Sep 2004 12:59:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BJxDeU023057; Sat, 11 Sep 2004 12:59:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BJxD3Q023050 for ; Sat, 11 Sep 2004 12:59:13 -0700 (PDT) (envelope-from csm@MoonGroup.com) Received: by server1.moongroup.com (Postfix, from userid 99) id 19C9111824022; Sat, 11 Sep 2004 15:59:15 -0400 (EDT) Received: from [192.168.0.10] (rdu74-170-067.nc.rr.com [24.74.170.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1.moongroup.com (Postfix) with ESMTP id 42CA111824021 for ; Sat, 11 Sep 2004 15:59:09 -0400 (EDT) Message-ID: <4143590C.2030907@MoonGroup.com> Date: Sat, 11 Sep 2004 15:59:08 -0400 From: Chuck Mead Reply-To: csm@moongroup.com Organization: MoonGroup.com User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> In-Reply-To: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.92.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Newton wrote: | 3) On the issue of ignoring patent claims, the working group has at | least rough consensus that the patent claims should not be ignored. | Additionally, there is at least rough consensus that the participants of | the working group cannot accurately describe the specific claims of the | patent application. This stems from the fact that the patent application | is not publicly available. Given this, it is the opinion of the | co-chairs that MARID should not undertake work on alternate algorithms | reasonably thought to be covered by the patent application. We do feel | that future changes regarding the patent claim or its associated license | could significantly change the consensus of the working group, and at | such a time it would be appropriate to consider new work of this type. I have to ask because it appears to me that you have left this somewhat nebulous. Does this mean that the PRA (with it's encumbrance) is being accepted as a part of the MARID specification? If so I do not know what in the world you could have been reading to draw the conclusion that there was "rough concensus" to go forward with it! - -- csm@moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBQ1kMv6Gjsf2pQ0oRAoozAKCyW2fTUnzfK5Lp6x83Po1Zf5VTXgCgrth4 TShS1faAt2DQlloNkEDtq6k= =7HLT -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 17:30: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 RAA11926 for ; Sat, 11 Sep 2004 17:30:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BL5jEd027256; Sat, 11 Sep 2004 14:05: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 i8BL5jDu027255; Sat, 11 Sep 2004 14:05:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BL5jHQ027249 for ; Sat, 11 Sep 2004 14:05:45 -0700 (PDT) (envelope-from gfk@logidac.com) Received: from ali.gfk-palace.org ([66.130.213.37]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0I3W00BMWAL5A6@falla.videotron.net> for ietf-mxcomp@imc.org; Sat, 11 Sep 2004 17:05:29 -0400 (EDT) Received: (qmail 8681 invoked by uid 1008); Sat, 11 Sep 2004 21:05:29 +0000 Received: from gfk@logidac.com by ali by uid 64011 with qmail-scanner-1.21 (spamassassin: 2.64. Clear:RC:1(192.168.0.5):. Processed in 0.016203 secs); Sat, 11 Sep 2004 21:05:29 +0000 Received: from unknown (HELO ?127.0.0.1?) (192.168.0.5) by ali.gfk-palace.org with SMTP; Sat, 11 Sep 2004 21:05:29 +0000 Date: Sat, 11 Sep 2004 17:05:46 -0400 From: Guillaume Filion Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-reply-to: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> To: IETF MARID WG Message-id: <414368AA.9020803@logidac.com> Organization: Logidac MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: fr-ca, en-ca, en, rs1_f00355d6782, rs2_f4a59bfdcfa, rs3_f3a52d2462 References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT Andrew Newton wrote: > [I]t is the opinion of the > co-chairs that MARID should not undertake work on alternate algorithms > reasonably thought to be covered by the patent application. We do feel > that future changes regarding the patent claim or its associated license > could significantly change the consensus of the working group, and at > such a time it would be appropriate to consider new work of this type. I'm not sure if I get this right, and by reading the replies it seems that we can't reach consensus of what you mean. hihihi Reading point 3, I understand that the MARID co-chairs seek an alternate, encumbered algorithm to replace the PRA algorithm. Is this correct? Regards, GFK's -- Guillaume Filion, ing. jr Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 17:32: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 RAA12082 for ; Sat, 11 Sep 2004 17:32: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 i8BL6fg9027283; Sat, 11 Sep 2004 14:06: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 i8BL6fiL027282; Sat, 11 Sep 2004 14:06:41 -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 i8BL6a8o027274 for ; Sat, 11 Sep 2004 14:06:41 -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 2968516CD2 for ; Sat, 11 Sep 2004 17:15:48 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Sat, 11 Sep 2004 11:47:59 PDT." <1118.64.142.13.68.1094928479.squirrel@harry.mail-abuse.org> Date: Sat, 11 Sep 2004 17:15:48 -0400 Message-Id: <20040911211548.2968516CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Douglas Otis" wrote: > A DNS check that obtains a list of addresses for a mailbox-domain, MUST > assume channel integrity when holding the apparent originator of the > message accountable. What channel? The only parties involved are: a) SMTP client b) SMTP server c) DNS server being queried The DNS server may return one, or a billion IP's "permitted" to send MAIL FROM with it's name. Any particular message may have traversed zero, or a billion intermediate SMTP hops before arriving at the current SMTP client, and being sent to the SMTP server. I fail to see how any party other than the three listed above could possibly be involved in "MAIL FROM" DNS checks. There is no "channel" beyond the current hop, which can be verified to exist. > Due to forwarding issues, expect many lists to be left "open" to allow > other unknown domains to forward messages. As has been noted here, as elsewhere, users affected by forwarding issues are a very, very small percentage of people on the net. As a result, the reasonable expectation is that very few domains will have "open" or permissive records. > There are clearly two steps needed, but these two steps have been > collapsed into a one very broken step with SPF or Sender-ID. > > Step 1: Authenticate the MTA EHLO name. > Step 2: Compare the mailbox-domain/EHLO list to this name. I'm not sure what you mean by the second step. > One can not defend assumptions of accountable entities by suggesting > the mail channel is "defined" to have integrity. You're not addressing my scenario, or my reasons for my position. You're just labelling my position as based on "assumptions", and therefore any "definition" I come up with is, in your opinion, defined to be indefensible. > Listing a name and blocking their mail because you don't care which entity > actually caused the message to be sent is also... not nice. Which is why I didn't say that. Please don't accuse me of saying "I don't care", it's rude and insulting. My position, if you had read my messages, is that IF the recipient cannot tell the difference between "good" and "bad" originators, then he MUST treat them as identical. Because, by definition, he has no information by which to distinguish them. Unless.. do you have a way for the recipient to treat "good" and "bad" originaters differently, in the absence of any data which can be used to distinguish them? If you do, I would be... surprised. > What entity should be held accountable? The entity authenticated as > sending the mail, or the mailbox-domain that authorized the mail to be > sent? Each has a different role, therefore their accountability should be different. > Obtaining an authorization is not the same as authentication of the > acting entity. I'm not sure how that applies to the issues on this list. An SMTP server can obtain authentication information from a DNS server for an SMTP client, and use that information to authorize the client. If there's no authentication information available, then the SMTP server cannot use that information to authorize the user. > > MAIL FROM and EHLO based checks are identical in security. > > These checks are not the same. Which is why I didn't say they were the same. > You are devising a system that requires mailbox-domains authorize > other domains to send their mail. No. "domains" don't send mail. SMTP clients send mail, and use domain names in fields in SMTP. The difference is crucial. SMTP clients can be correlated to domain names via: - rDNS - EHLO - MAIL FROM And not much else. Because there is no easily available mapping of "domain" to SMTP client, other than those fields, SMTP servers cannot use anything other than those fields to tie the SMTP client to a domain name. So talking about "authorizing domains" is a misconception. SMTP clients are authorized, nothing else can be. > If the sending MTA EHLO name is authenticated and authorized by the > EHLO domain, then it does not matter what mailbox-domain is sent, > this EHLO entity can be safely held accountable for the MTA actions. How? In contrast, by checking MAIL FROM, you can at least have some confidence that a bounce path exists, and any errant message will be accepted by the originator. > > If someone can't tell the difference between two things, then it > > MUST treat the two things as identical. > > But these things can be identified by an authenticated EHLO name. They > MUST NOT be treated as identical. If two domains use the same MTA, which uses only one authenticate EHLO name, then by your definition, only the domain in EHLO can be held accountable, and all recipients must therefore treat the two domains identically. Hmm... have I used your definitions to prove my point? > A reputation service spends most of their efforts ensuring information. > Using the IP address makes this process rather straight forward. Using an > authenticated EHLO name follows the same model and directly identifies > those sending the messages. It authenticates the MTA sending the messages, which is a little different. > To suggest that because the EHLO domain was not considered, means a > reputation service can safely hold entities accountable for the > action of others will not have much sway. It's not unreasonable to hold multiple parties accountable for a message. ISP's are already holding other ISP's responsible for the actions of their customers. It's not unreasonable to use MAIL FROM accountability in addition to EHLO. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 17:54:40 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 RAA13201 for ; Sat, 11 Sep 2004 17:54:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BLX883028596; Sat, 11 Sep 2004 14:33: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 i8BLX8qa028595; Sat, 11 Sep 2004 14:33:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BLX7v8028588 for ; Sat, 11 Sep 2004 14:33:08 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8BLWixB010495 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 11 Sep 2004 17:32:46 -0400 Date: Sat, 11 Sep 2004 17:32:44 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Sauer, Damon" cc: Markus Stumpf , Subject: RE: SPF abused by spammers In-Reply-To: <38363D9940D92A458010AAE24D162EB90521D090@bremocog-55> 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, 10 Sep 2004, Sauer, Damon wrote: > > > > Dean, > > > > > > You are missing where this is a GOOD thing. We WANT > > spammers to use > > > SPF. This will allow us to identify, publish, process, > > shred, pillage, > > > burn, destroy the IP addresses that this stuff is coming > > from. Nobody > > > is doing less stringent processing of the email that passes an SPF > > > check. It just makes it easier to block when identified. > > > > SPF doesn't make it easier to identify spammers. > > > > > I didn't say it did. How I identify the IP as a spammer is up to my > other processes. What it DOES do is allow me to make a informed decision > on whether or not to block that IP. (I am not sure how many different > ways I can try to explain this fact but here is another one) But SPF doesn't allow you to make any 'informed decision'. Your 'other processes' do that. SPF doesn't enter into it at all. > Only people that don't understand what SPF actually does say that SPF > blocks spam. I agree. SPF fails to block spam. > Now I do know that pobox has said something to this effect, > but it is my belief that they were writing that statement with the > end-user in mind. Basically, never mind HOW it blocks spam, just that it > will. It is up to the system admins and programmers to determine the > HOW. ??? Just have blind faith that it works??? We did this back in 1997 and many times since then. The blind faith didn't work then, nor did the anti-spam schemes. Thats why schemes are being held to more exacting standards of proof of effectiveness this time, and if the scheme isn't proven effective, then we aren't interested in giving up those things (such as unbundling email services) that are required for this scheme, because it doesn't work, and we aren't interested in any more expensive and large scale proofs of failure. > If someone of intellect higher than your average bumblebee can't see > where being able to prevent domain forgery is a good thing and being > able to put an IP address to a real domain is a great thing.... Then > bumblebees may eventually rule the world. Preventing domain forgery will have no effect on anything, and having no effect, it can't be good or bad. Well, it can be bad if it has some other detrimental effect, such as interfering with unbundled services, which is the case here. Secondly, and more to the point, I think, is that SPF doesn't prevent email address forgery, which is its //specific goal//. We can already associate an IP address with a domain via MX and A records. However, these checks aren't valid except to show that domain //can// receive email. We already know through experience that many more servers might validly send email from that domain. --Dean From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 18:11:36 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 SAA14676 for ; Sat, 11 Sep 2004 18:11: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 i8BLmEVJ029873; Sat, 11 Sep 2004 14:48: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 i8BLmEEH029872; Sat, 11 Sep 2004 14:48:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BLmB8E029863 for ; Sat, 11 Sep 2004 14:48:13 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C6FjC-0004hL-00 for ; Sat, 11 Sep 2004 14:48:14 -0700 To: "IETF MARID WG" Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> From: Daniel Quinlan Date: 11 Sep 2004 14:48:14 -0700 In-Reply-To: wayne's message of "Sat, 11 Sep 2004 14:42:27 -0500" Message-ID: Lines: 68 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IETF MARID WG co-chair wrote: >> Given this, it is the opinion of the co-chairs that MARID should not >> undertake work on alternate algorithms reasonably thought to be >> covered by the patent application. wayne writes: > Uh, can you give an example of an alternative algorithm to the PRA > that has been discussed that might be "reasonably thought to be > covered by the PRA patent"? I can't think of any. > > As per RFC3668, which all participants of this mailing list are > supposed to comply with, if we start creating an alternative that does > happen to be covered by any IPR of any other participant, we will > learn about such encumbrance. > > See: > http://www.ietf.org/NOTEWELL.html > http://www.ietf.org/rfc/rfc3668.txt > > So, while I agree that we shouldn't try to create a standard that we > know is encumbered, isn't this pretty much what we have been trying to > do already? I would also like to hear the answers to Wayne's above questions. (I agree with the point he is trying to make.) > It is the opinion of this participant that the pra scope will not > reach consensus due in large part to the patent mess, whether there is > a mailfrom scope or not. Agreed. If "mailfrom" is the only other scope, then I suspect Apache SpamAssassin, Apache James, and perhaps other open source implementations will wholly reject Sender ID. Maybe that's what some people want. I'm perplexed by this whole direction. > It is the opinion of this participant that the mailfrom scope will not > reach consensus. unless it also allows for the helo scope to be > checked and thus be compatible with SPF-classic. SPF-classic is the > current defacto standard and I think standardizing existing practice > is the easiest way to reach a consensus. Agreed, a "helo" scope should be explored. > Given this work plan, I do not expect this working group to ever > produce a first specification. *very heavy sigh* I disagree with this. I think we might produce a specification that will be largely ignored or succeed in handing a major part of the internet to anyone who brings patented technology into IETF standards. I don't mean to be inflammatory, but those are the only two *likely* outcomes I can see for the current plan: - the specification doesn't happen or is ignored - email authentication is owned by (the patent holder) since (the patent holder) can change the revocable patent license in the future It's *possible* the patent(s) will not be granted, but I prefer to avoid relying on things outside of my control as much as possible. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 18:27: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 SAA16034 for ; Sat, 11 Sep 2004 18:27: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 i8BM16SV030341; Sat, 11 Sep 2004 15:01: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 i8BM16IG030340; Sat, 11 Sep 2004 15:01:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BM15aL030321 for ; Sat, 11 Sep 2004 15:01:05 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i8BM133V026488 for ; Sat, 11 Sep 2004 15:01:03 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 5DA1B84F867; Sat, 11 Sep 2004 15:01:03 -0700 (PDT) Date: Sat, 11 Sep 2004 15:01:03 -0700 From: "Mark C. Langston" To: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 Message-ID: <20040911220103.GL49653@bitshift.org> References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 2:55PM up 9 days, 20:52, 7 users, load averages: 0.02, 0.04, 0.01 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 11, 2004 at 02:48:14PM -0700, Daniel Quinlan wrote: > > Agreed. If "mailfrom" is the only other scope, then I suspect Apache > SpamAssassin, Apache James, and perhaps other open source > implementations will wholly reject Sender ID. > > Maybe that's what some people want. I'm perplexed by this whole > direction. > > > It is the opinion of this participant that the mailfrom scope will not > > reach consensus. unless it also allows for the helo scope to be > > checked and thus be compatible with SPF-classic. SPF-classic is the > > current defacto standard and I think standardizing existing practice > > is the easiest way to reach a consensus. > > Agreed, a "helo" scope should be explored. Given that we're treading down this path, I'm wondering if it wouldn't be best to specify a range of scopes that cover the major elements of information supplied in both RFC2821 RFC2822. Then, if people wish to combine certain scopes in particular ways to provide unique solutions, and/or wish to patent these approaches, that's up to them. The documents would become references for what should be checked, and how. However, at that point, I think we'd be writing best practices for RFC2821 and RFC2822 checking for various types of abuse: spam, joe-jobbing, etc., as well as specifying mechanisms that aid in these "atomic" information checks. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 18:32:34 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 SAA16150 for ; Sat, 11 Sep 2004 18:32:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BM8dhj030766; Sat, 11 Sep 2004 15:08: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 i8BM8dww030765; Sat, 11 Sep 2004 15:08:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BM8avO030759 for ; Sat, 11 Sep 2004 15:08:38 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8BM8VC2011133 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 11 Sep 2004 18:08:32 -0400 Date: Sat, 11 Sep 2004 18:08:31 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: peter@bowyer.org cc: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers In-Reply-To: <56152ae9040909081013f4e72c@mail.gmail.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 Thu, 9 Sep 2004, Peter Bowyer wrote: > > > From: Dean Anderson > > (Sorry if I got the attribution wrong - confusing bad quoting and > top-posting going on) > > > It has been reported that AOL is already using SPF to give reduced > > filtering to SPF-using domains. Is this a good idea? > > On its own - no. > > Fortunately, it's not what they're doing - they're using SPF for > exactly what it was intended - as part of their reputation system. > They use SPF to confirm that a mail purporting to come from an > organisation on their whitelist is not forged. > > Domain on whitelist + SPF Pass = less filtering. This is exactly what I said. And this is a bad idea for the reasons I posited. --Dean From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 18:36:44 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 SAA16302 for ; Sat, 11 Sep 2004 18:36:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BMGT4i031067; Sat, 11 Sep 2004 15:16:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BMGSfB031066; Sat, 11 Sep 2004 15:16:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BMGSTs031060 for ; Sat, 11 Sep 2004 15:16:28 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i8BMGV3V029028 for ; Sat, 11 Sep 2004 15:16:31 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 2DD1184F865; Sat, 11 Sep 2004 15:16:31 -0700 (PDT) Date: Sat, 11 Sep 2004 15:16:31 -0700 From: "Mark C. Langston" To: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers Message-ID: <20040911221631.GO49653@bitshift.org> References: <7ae58c2204090908286db44d4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 3:12PM up 9 days, 21:09, 7 users, load averages: 0.10, 0.10, 0.08 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 11, 2004 at 06:11:07PM -0400, Dean Anderson wrote: > > Their website is clear. And their use amounts to less stringent checking > for those using SPF, which is bad for the reasons I stated. And I might > add that this explains why spammers have quickly adopted SPF. > Combine beahvior-based reputataion systems with SPF queries, and you acquire a fairly useful aggregation tool for reputation scores. In this manner, spammers adopting SPF can be a good thing. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 19:05:22 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 TAA17543 for ; Sat, 11 Sep 2004 19:05: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 i8BMfVrZ032560; Sat, 11 Sep 2004 15:41:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BMfVdD032559; Sat, 11 Sep 2004 15:41:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BMfUqr032553 for ; Sat, 11 Sep 2004 15:41:31 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8BMfXqV011768 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 11 Sep 2004 18:41:35 -0400 Date: Sat, 11 Sep 2004 18:41:33 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040911211548.2968516CD2@mail.nitros9.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 11 Sep 2004, Alan DeKok wrote: > > "Douglas Otis" wrote: > > A DNS check that obtains a list of addresses for a mailbox-domain, MUST > > assume channel integrity when holding the apparent originator of the > > message accountable. > > What channel? The only parties involved are: > > a) SMTP client > b) SMTP server > c) DNS server being queried I think he is refering to the channel referenced by information theory (guessing by the previous reference to Lampson's covert channel paper). This could refer to the complete path through the communication system, or it could refer to a single hop in a multihop system. Further, you've oversimplified the parties involved: The end user, optionally a third party relay [one or more] (because connection and mail services may be unbundled) The mailbox provider (where responses will go) The Mailbox provider nameservers The recipient mail server [one or more] The recipient nameservers The chain of nameservers between the recipient, root, and mailbox provider. At any point spoofing could occur. Going back to my spam examination where you are examining a spam message: Suppose the IP address in the received from header no longer matches the SPF records: In this case you don't know if your SPF check passed because DNS records were spoofed, or if the real DNS records were changed. All you know is that you got a spam from a certain IP address. You don't know whether it was forged or not. Suppose the IP address in the recieved header does match the SPF records. You don't know if the abuser signed up for an account with that domain, or if they got an infected machine under that domain. You don't know whether the nameserver was cracked, and incorrect records added. Most people can't tell the difference between a poisoned DNS cache and whether the records really come from an authoritative nameserver or even figure out where they got the DNS record from. So, similarly, all you really know is that you got a spam from a certain IP address. In both cases, all that can be done is report the incident to the operator of the domain and the operator of the IP address. And that's all that can be done now. THERE IS NO CHANGE. SPF doesn't prevent email forgery, nor even indicate whether forgery happened. > The DNS server may return one, or a billion IP's "permitted" to send > MAIL FROM with it's name. Any particular message may have traversed > zero, or a billion intermediate SMTP hops before arriving at the > current SMTP client, and being sent to the SMTP server. > > I fail to see how any party other than the three listed above could > possibly be involved in "MAIL FROM" DNS checks. There is no "channel" > beyond the current hop, which can be verified to exist. The current hop cannot be "verified to exist" beyond the TCP sequence numbers. There is no way to tell that the mail isn't forged. Even if email comes from a certain server, there is still no way to tell that the mail isn't forged. @aol.com coming from an AOL mailserver doesn't mean that it really came from Spammers can get accounts at AOL. Spammers can steal accounts at AOL by a number of vectors such as viruses. And what's more, from outside of AOL we can't be sure that AOL isn't pink-contracting with spammers. The notion of "spam-herding" is just so much wishful thinking. From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 19:17: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 SAA16173 for ; Sat, 11 Sep 2004 18:32:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BMBGsb030894; Sat, 11 Sep 2004 15:11: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 i8BMBGdU030893; Sat, 11 Sep 2004 15:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BMBGgu030887 for ; Sat, 11 Sep 2004 15:11:16 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8BMB7wF011227 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 11 Sep 2004 18:11:08 -0400 Date: Sat, 11 Sep 2004 18:11:07 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Michael Hammer cc: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers In-Reply-To: <7ae58c2204090908286db44d4@mail.gmail.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 Thu, 9 Sep 2004, Michael Hammer wrote: > > It might be useful if people checked their facts before using rumor or > secondhand reports as the basis of posting to the lsit. > > On Thu, 9 Sep 2004 10:58:34 -0400 (EDT), Dean Anderson wrote: > > > > Isn't that what I said would happen? > > > > --Dean > > > > > It has been reported that AOL is already using SPF to give reduced > > filtering to SPF-using domains. Is this a good idea? > > > > Please visit: http://postmaster.aol.com/spf/ > > AOL has NOT said they will do less stringent checking if you publish > an SPF record. What they have said is that in order to remain on their > whitelist (assuming you meet all of the other requirements) you must > publish SPF records. > > I think their website is pretty clear. Their website is clear. And their use amounts to less stringent checking for those using SPF, which is bad for the reasons I stated. And I might add that this explains why spammers have quickly adopted SPF. --Dean From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 19:27:49 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 TAA18813 for ; Sat, 11 Sep 2004 19:27:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BN3NUO033779; Sat, 11 Sep 2004 16:03:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BN3NOp033778; Sat, 11 Sep 2004 16:03:23 -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 i8BN3MOV033772 for ; Sat, 11 Sep 2004 16:03:22 -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 i8BNEZZq004708; Sat, 11 Sep 2004 16:14:35 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8BNEZdA004705; Sat, 11 Sep 2004 16:14:35 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 11 Sep 2004 16:14:35 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: <46385749-041C-11D9-B751-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 Sat, 11 Sep 2004, Andrew Newton wrote: > The following is the judgment of the co-chairs relating to consensus > within the MARID working group during the last call period of > 23-August-2004 through 10-September-2004. > > 1) On the issue of using a DNS name prefix, there is at least rough > consensus that no prefix should be used. I'm not sure there was rought consensus on this. I'll try to calculate number of posts for and against and post results, but unless I'm mistaken it was equal! I've privately made recomendation to co-chairs on this issue that it would be appropriate to ask official opinion of dns expert (meaning WG tech advisor on dns issues) and in fact co-chairs privately also agree that it is a good idea; it is unfortunete that they know decided the issue on their own without the expert opinion or clear consensus from the WG. > 2) On the issue of compliance with the use of the TXT record, the > working group has at least rough consensus that TXT usage is acceptable > for compliance and should not be specified as a configuration that will > be non-compliant. However, there is at least rough consensus that the > use of the SPF-specific record type is more desirable than the use of a > TXT record type. It is the opinion of the co-chairs that the -protocol > document clearly state that the usage of TXT records will most likely > be deprecated by future protocol definition. Yes, it seems that most opinions expressed were comparable to above. There does seem rough consensus on this. > 3) On the issue of ignoring patent claims, the working group has at > least rough consensus that the patent claims should not be ignored. Actually I have not seen rough consensus that patent claims should not be ignored, but I don't think there was consensus that they should be ignored either (not until we can read the actual patent), so we're still in limbo. > Additionally, there is at least rough consensus that the participants > of the working group cannot accurately describe the specific claims of > the patent application. This stems from the fact that the patent > application is not publicly available. Given this, it is the opinion > of the co-chairs that MARID should not undertake work on alternate > algorithms reasonably thought to be covered by the patent application. On this I STRONGLY disagree. I believe there was in fact consensus that we should work on alternative to PRA that is not covered by patent. I also note that in light of that we do not know what exactly patent said, nobody can not make a judgement call that any alternative would be covered by patent. In fact if we do work on alternative and it turns out to be covered by patent we'll know it because there would be another IPR disclosure as this is in fact appropriate way to describe patent claims. I'll publicly say that I'll ignore chairs recomendation that we do not work on alternatives to PRA because I believe based on opinion expressed by the large number of members of this WG that PRA would not reach consensus of this WG to proceed to be a standard unless we provide an alternative that does not have licensing limitations. > We do feel that future changes regarding the patent claim or its > associated license could significantly change the consensus of the > working group, and at such a time it would be appropriate to consider > new work of this type. Actually there was some consensus that changes to the license may lead to rough consensus on PRA, so at such time if changes are done we should consider it, but NOT the other way around! > 4) On the issue of the ABNF in section 3.4.1 of -protocol and multiple > scopes, there is at least rough consensus to allow the syntax and > record structure to support multiple scopes. Yes. > With regard to items 3 and 4 above, it is also the opinion of the > co-chairs that any attempt by the MARID working group to define any new > scopes other than "mailfrom" and "pra" for the SPF syntax will at this > time result in failure to find consensus within the working group. I do not see how you can make this judgement without actually seeing what alternatives are. > The document authors have agreed to producing new drafts intended to > meet the chartered work item, and a consensus call on them or the > appropriate diffs will be forthcoming. This work plan does not include > scopes outside of "mail from" and "pra", and it is our opinion that no > new work items of this type should be considered until MARID has > successfully produced a first specification. I'm going to disagree and work on alternatives, because I believe this WG will be unable to produce specification on PRA scope in its current form. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 19:35: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 TAA19193 for ; Sat, 11 Sep 2004 19:35: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 i8BNAFZq034799; Sat, 11 Sep 2004 16:10:15 -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 i8BNAFYD034798; Sat, 11 Sep 2004 16:10:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BNAF2M034789 for ; Sat, 11 Sep 2004 16:10:15 -0700 (PDT) (envelope-from alex@slot.hollandcasino.net) Received: by slot.hollandcasino.net (Postfix, from userid 500) id A4FB960244; Sun, 12 Sep 2004 01:08:18 +0200 (CEST) Date: Sun, 12 Sep 2004 01:08:18 +0200 From: Alex van den Bogaerdt To: ietf-mxcomp@vpnc.org Subject: Re: SPF abused by spammers Message-ID: <20040911230818.GA26726@slot.hollandcasino.net> Mail-Followup-To: ietf-mxcomp@vpnc.org References: <38363D9940D92A458010AAE24D162EB90521D090@bremocog-55> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 11, 2004 at 05:32:44PM -0400, Dean Anderson wrote: > Preventing domain forgery will have no effect on anything Excuse me ??? If _you_ would check _my_ SPF record, I will not receive _your_ out-of-office reply because _someone_else_ sent mail to _you_ using _my_ address. Because you are being stubborn, _I_ have to suffer. > We can already associate an IP address with a domain via MX and A records. > However, these checks aren't valid except to show that domain //can// > receive email. We already know through experience that many more servers > might validly send email from that domain. Indeed. MX or A define what addresses will _receive_ email. And SPF defines what addresses are allowed to _send_ email. Excellent point, but in favour of the opposite of what you are trying to defend. Alex From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 19:42:22 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 TAA19376 for ; Sat, 11 Sep 2004 19:42: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 i8BNJxWd036239; Sat, 11 Sep 2004 16:19: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 i8BNJxex036238; Sat, 11 Sep 2004 16:19: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 i8BNJwHw036231 for ; Sat, 11 Sep 2004 16:19: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 i8BNVFWV006732; Sat, 11 Sep 2004 16:31:15 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8BNVFtG006729; Sat, 11 Sep 2004 16:31:15 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 11 Sep 2004 16:31:15 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 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: It seems I made a mistake and did not notice that chairs did not say that we should not work alternatives AT ALL but said that we should not work on alternatives that WOULD BE covered by patent application. The above is appropriate, however I note that chairs said that we should not work on alernatives that "reasonably thought to be covered by the patent application". My objection still stands that in itself is meaningless because we'll know if alernative is covered when there would be another IPR disclosure as it relates to such possible alernative draft. Until there is one, we can not reasonable be expected to know what would be covered by patent application because we have not seen one! On Sat, 11 Sep 2004, william(at)elan.net wrote: > > 3) On the issue of ignoring patent claims, the working group has at > > least rough consensus that the patent claims should not be ignored. > Actually I have not seen rough consensus that patent claims should not be > ignored, but I don't think there was consensus that they should be ignored > either (not until we can read the actual patent), so we're still in limbo. > > > Additionally, there is at least rough consensus that the participants > > of the working group cannot accurately describe the specific claims of > > the patent application. This stems from the fact that the patent > > application is not publicly available. Given this, it is the opinion > > of the co-chairs that MARID should not undertake work on alternate > > algorithms reasonably thought to be covered by the patent application. > On this I STRONGLY disagree. I believe there was in fact consensus that > we should work on alternative to PRA that is not covered by patent. > > I also note that in light of that we do not know what exactly patent said, > nobody can not make a judgement call that any alternative would be covered > by patent. In fact if we do work on alternative and it turns out to be > covered by patent we'll know it because there would be another IPR > disclosure as this is in fact appropriate way to describe patent claims. > > I'll publicly say that I'll ignore chairs recomendation that we do not > work on alternatives to PRA because I believe based on opinion expressed > by the large number of members of this WG that PRA would not reach consensus > of this WG to proceed to be a standard unless we provide an alternative that > does not have licensing limitations. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 21:28:22 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 VAA25704 for ; Sat, 11 Sep 2004 21:28: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 i8C0xsSZ045007; Sat, 11 Sep 2004 17:59:54 -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 i8C0xsUt045006; Sat, 11 Sep 2004 17:59:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8C0xsow044995 for ; Sat, 11 Sep 2004 17:59:54 -0700 (PDT) (envelope-from george@m5p.com) Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by mailhost.m5p.com (8.12.11/8.12.11) with ESMTP id i8C0xp9W098301 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Sat, 11 Sep 2004 17:59:52 -0700 (PDT) Received: (from defang@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i8C0vGSa098293 for ; Sat, 11 Sep 2004 17:57:16 -0700 (PDT) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (MIMEDefang) with ESMTP id i8C0vGkO098292; Sat, 11 Sep 2004 17:57:16 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i8C0vFwa092659; Sat, 11 Sep 2004 17:57:15 -0700 (PDT) Date: Sat, 11 Sep 2004 17:57:15 -0700 (PDT) From: George Mitchell Message-Id: <200409120057.i8C0vFwa092659@m5p.com> To: andy@hxr.us, ietf-mxcomp@imc.org Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Congratulations to the chairs for your work on a contentious subject. I think you mostly got it right. > The following is the judgment of the co-chairs relating to consensus > within the MARID working group during the last call period of > 23-August-2004 through 10-September-2004. > > [...] > > With regard to items 3 and 4 above, it is also the opinion of the > co-chairs that any attempt by the MARID working group to define any new > scopes other than "mailfrom" and "pra" for the SPF syntax will at this > time result in failure to find consensus within the working group. This is the troublesome part. I think everyone agrees on "mailfrom", but not on "pra". Also, what happened to "helo"? > The document authors have agreed to producing new drafts intended to > meet the chartered work item, and a consensus call on them or the > appropriate diffs will be forthcoming. This work plan does not include > scopes outside of "mail from" and "pra", and it is our opinion that no > new work items of this type should be considered until MARID has > successfully produced a first specification. > > -MARID co-chairs > Despite my nitpicking, thanks for this sign of forward progress. -- George Mitchell From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 21:51:55 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 VAA28628 for ; Sat, 11 Sep 2004 21:51:54 -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 i8C1VFFl048492; Sat, 11 Sep 2004 18:31:15 -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 i8C1VF4N048491; Sat, 11 Sep 2004 18:31:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8C1VEqv048484 for ; Sat, 11 Sep 2004 18:31:14 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from pool-151-205-126-128.char.east.verizon.net ([151.205.126.128] helo=[192.168.1.103]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C6JD2-0000BW-OS; Sat, 11 Sep 2004 21:31:19 -0400 Message-ID: <4143A6A6.9000205@solidmatrix.com> Date: Sat, 11 Sep 2004 21:30:14 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton CC: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> In-Reply-To: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > 3) On the issue of ignoring patent claims, the working group has at > least rough consensus that the patent claims should not be ignored. > Additionally, there is at least rough consensus that the participants of > the working group cannot accurately describe the specific claims of the > patent application. This stems from the fact that the patent application > is not publicly available. Given this, it is the opinion of the > co-chairs that MARID should not undertake work on alternate algorithms > reasonably thought to be covered by the patent application. We do feel > that future changes regarding the patent claim or its associated license > could significantly change the consensus of the working group, and at > such a time it would be appropriate to consider new work of this type. > Are you referring to fetchmail and similar attempts? ... > > With regard to items 3 and 4 above, it is also the opinion of the > co-chairs that any attempt by the MARID working group to define any new > scopes other than "mailfrom" and "pra" for the SPF syntax will at this > time result in failure to find consensus within the working group. > > The document authors have agreed to producing new drafts intended to > meet the chartered work item, and a consensus call on them or the > appropriate diffs will be forthcoming. This work plan does not include > scopes outside of "mail from" and "pra", and it is our opinion that no > new work items of this type should be considered until MARID has > successfully produced a first specification. > Andy, Does this mean that the PRA scope can proceed? Yakov From owner-ietf-mxcomp@mail.imc.org Sat Sep 11 22:01:23 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 WAA29119 for ; Sat, 11 Sep 2004 22:01:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8C1eQO1049051; Sat, 11 Sep 2004 18:40:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8C1eQM9049050; Sat, 11 Sep 2004 18:40:26 -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 i8C1ePu3049044 for ; Sat, 11 Sep 2004 18:40:25 -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 1C6JLv-0005gC-SQ for ietf-mxcomp@imc.org; Sat, 11 Sep 2004 20:40:31 -0500 To: "IETF MARID WG" From: wayne Reply-To: "IETF MARID WG" Date: Sat, 11 Sep 2004 20:40:27 -0500 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: Will SPFv1 records be ok for the "MAIL FROM" scope? 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.6 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: Since the SPFv1 records were deployed with the understanding that they would be used for HELO and MAIL FROM scopes, will "v=spf1" be interpreted as equivalent to "spf2.0/helo,mailfrom"? It certainly would be nice to be able to get a jump-start using the tens of thousands of deployed SPFv1 records. -wayne From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 02:18: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 CAA24657 for ; Sun, 12 Sep 2004 02:18:32 -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 i8C5mIjH086341; Sat, 11 Sep 2004 22:48: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 i8C5mIO5086337; Sat, 11 Sep 2004 22:48:18 -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 i8C5mIqm086329 for ; Sat, 11 Sep 2004 22:48:18 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8C5mPrx029467 for ; Sat, 11 Sep 2004 22:48:25 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <5CAC0188-047F-11D9-BF67-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: What the lawyers and suits think (was e: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004) Date: Sat, 11 Sep 2004 22:48:24 -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 All, This post to the list has been rolling around in the back of my mind for a few days. I hope that you will find it useful, or at least interesting, and I hope that it is appropriate to this discussion. I'm piggy-backing it on to this below post, because I wanted to respond to it, and it is related: > It seems I made a mistake and did not notice that chairs did not say > that > we should not work alternatives AT ALL but said that we should not work > on alternatives that WOULD BE covered by patent application. > > The above is appropriate, however I note that chairs said that we > should > not work on alernatives that "reasonably thought to be covered by the > patent application". My objection still stands that in itself is > meaningless because we'll know if alernative is covered when there > would be another IPR disclosure as it relates to such possible > alernative > draft. Until there is one, we can not reasonable be expected to know > what > would be covered by patent application because we have not seen one! Reading this with my lawyer, geek, and lawyer geek hats on, I take this to mean "reasonably given what we do know or suspect of the patent". To take it to the extreme for the sake of example, it would be reasonable to believe that an exact Sender I.D. clone would be covered by the patent. It would not be reasonable to think that an elephant would be covered by the patent. Somewhere between the range of "elephant" and "exact clone" there are things on which one might focus which one could reasonably imagine would probably be covered by the undisclosed patent to the extent that we may imagine what is in it. I want to take a moment now to explain to those of you who may not know, exactly how lawyers and corporate suits in general look at the sorts of people who take part in working groups such as these, and in particular how they look at their (i.e. your) concerns. Note that I am *not* speaking of MS' lawyers or suits in particular (and I couldn't, as I have not discussed these things with them) - I am speaking from years of my own experience. First, there are _very_ few lawyers who are also geeks *and* who also *grok* email issues on a substantive technical level in general, and spam issues in particular. I am one of fewer than I can count on the fingers of both hands, and then *only* because Paul Vixie took me in-house at MAPS way back when, and took me under his wing, and so under his patient tutelage I came to understand way more than I even knew there *was* to know about the issues and inner workings of the processes. For the most part, lawyers and corporate executives (most especially the lawyers) think of you guys as very smart, driven, but slightly strange and obsessed people who work down in the email boiler room - they want you to make the things work, but your concerns carry about as much weight with them as an assembly line worker's concerns carry with the lawyers and execs over at General Motors. Don't believe me? Ask Paul, who I think will confirm that lawyers' and corporate executives' world views of these issues *rarely even focus on the same things*, let alone come to a confluence of opinions, as those of the people who are actually driving the email systems. Your concerns have almost *nothing* to do with the running of a corporation or the furthering of its corporate objectives. Your objectives are _not_ their objectives - they rarely cross - they aren't even parallel - in fact they are on completely different planes. Think about it - you here are focused on solving a problem - they are focused on creating a product, and on protecting their client's corporate interests. I would posit that this is the reason that you have very dedicated people here like Harry Katz who are sincerely and ferverently working on a solution, and that isn't at all at odds with the issues coming from the lawyers and suits at the same company. The people upstairs don't speak your language. They don't share your concerns. They don't have the same focus. Had I been in their position, say, ten years ago, I'd have been the same - I'd have been saying "those email geeks want us to do *what*? That's not how it works up here in the *real* world." The irony, of course, in all of this, is that it is those very same email geeks on who adoption of _any_ standard relies. Oh sure, it's very clever to get several major bulk email senders to agree to a standard - but at the end of the day it doesn't matter, because it is the email *receivers*, not the email senders, whose adoption will make or break any proposed standard. Every email sender on the planet can adopt Standard X, but if no receivers are cuing on Standard X, then so what? So the trick is to get the lawyers and the suits to realize that your concerns aren't just something they have to endure - they are something they have to satisfy. Anne From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 02:19:50 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 CAA24794 for ; Sun, 12 Sep 2004 02:19:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8C5uAoB089983; Sat, 11 Sep 2004 22:56:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8C5uA9s089982; Sat, 11 Sep 2004 22:56:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.salmark.net (mail.salmark.net [64.23.85.10] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8C5uA0c089958 for ; Sat, 11 Sep 2004 22:56:10 -0700 (PDT) (envelope-from peter@bowyer.org) Received: from [212.158.247.25] (port=10507 helo=pbdesktop) by mail.salmark.net with asmtp (Exim 4.41) id 1C6NLS-0004ds-RZ for ietf-mxcomp@imc.org; Sun, 12 Sep 2004 01:56:15 -0400 Message-ID: <01f301c4988d$3db131d0$0a46a8c0@pbdesktop> From: "Peter Bowyer" To: References: Subject: Re: SPF abused by spammers Date: Sun, 12 Sep 2004 06:56:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dean Anderson wrote: > On Thu, 9 Sep 2004, Michael Hammer wrote: > >> >> It might be useful if people checked their facts before using rumor >> or secondhand reports as the basis of posting to the lsit. >> >> On Thu, 9 Sep 2004 10:58:34 -0400 (EDT), Dean Anderson >> wrote: >>> >>> Isn't that what I said would happen? >>> >>> --Dean >>> >> >>> It has been reported that AOL is already using SPF to give reduced >>> filtering to SPF-using domains. Is this a good idea? >>> >> >> Please visit: http://postmaster.aol.com/spf/ >> >> AOL has NOT said they will do less stringent checking if you publish >> an SPF record. What they have said is that in order to remain on >> their whitelist (assuming you meet all of the other requirements) >> you must publish SPF records. >> >> I think their website is pretty clear. > > > Their website is clear. And their use amounts to less stringent > checking for those using SPF, which is bad for the reasons I stated. > And I might add that this explains why spammers have quickly adopted > SPF. But AOL won't have spammers on their whitelist. The only domains for which an SPF Pass means less filtering are those which are pre-whitelisted. And SPF will ensure that mail which appears to be from those domains isn't forged. What's your problem with this? It's using SPF for exactly what it was intended, and the fact that spammers publish SPF will have no effect on it at all. Peter From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 02:27: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 CAA25359 for ; Sun, 12 Sep 2004 02:27: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 i8C62gYp093684; Sat, 11 Sep 2004 23:02:42 -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 i8C62ga8093683; Sat, 11 Sep 2004 23:02:42 -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 i8C62g0C093651 for ; Sat, 11 Sep 2004 23:02:42 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id D5C074149B; Sat, 11 Sep 2004 23:02:47 -0700 (PDT) Received: from 24.10.108.240 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 11 Sep 2004 23:02:47 -0700 (PDT) Message-ID: <64718.24.10.108.240.1094968967.squirrel@harry.mail-abuse.org> In-Reply-To: <20040911211548.2968516CD2@mail.nitros9.org> References: Your message of "Sat, 11 Sep 2004 11:47:59 PDT." <1118.64.142.13.68.1094928479.squirrel@harry.mail-abuse.org> <20040911211548.2968516CD2@mail.nitros9.org> Date: Sat, 11 Sep 2004 23:02:47 -0700 (PDT) Subject: Re: SPF abused by spammers From: "Douglas Otis" To: "Alan DeKok" Cc: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "Alan DeKok" wrote: > "Douglas Otis" wrote: > >> A DNS check that obtains a list of addresses for a mailbox-domain, MUST >> assume channel integrity when holding the apparent originator of the >> message accountable. > > What channel? The only parties involved are: > a) SMTP client > b) SMTP server > c) DNS server being queried The MAIL FROM mailbox-domain was passed through the mail channel, for messages not originating at the SMTP client. This is normally the case for the SMTP client performing public delivery. This adds at least an additional SMTP client/server pair. > The DNS server may return one, or a billion IP's "permitted" to send > MAIL FROM with it's name. Any particular message may have traversed > zero, or a billion intermediate SMTP hops before arriving at the > current SMTP client, and being sent to the SMTP server. > > I fail to see how any party other than the three listed above could > possibly be involved in "MAIL FROM" DNS checks. There is no "channel" > beyond the current hop, which can be verified to exist. For accountability based upon the mailbox-domain, each hop is involved passing this identity through the mail channel. Holding the administrator of the mailbox-domain accountable would be ignoring the complexity of the mail channel, and the potential change of validation status moving from hop to hop. Publishing an SPF record is not tantamount to a contract accepting accountability for all published addresses. >> Due to forwarding issues, expect many lists to be left "open" to allow >> other unknown domains to forward messages. > > As has been noted here, as elsewhere, users affected by forwarding > issues are a very, very small percentage of people on the net. As a > result, the reasonable expectation is that very few domains will have > "open" or permissive records. While it may be a small percentage of users forward mail or use a type of list server, this generalization must not be applied to the mailbox domain, as there are typically many users per domain. SPF records are not typically user based, but are domain based. There will be expensive support issues caused by closing these records. >> There are clearly two steps needed, but these two steps have been >> collapsed into a one very broken step with SPF or Sender-ID. >> >> Step 1: Authenticate the MTA EHLO name. >> Step 2: Compare the mailbox-domain/EHLO list to this name. > > I'm not sure what you mean by the second step. First, authenticate the name of the MTA. Second, check against list of MTA names referenced by the mailbox-domain for a match. See the marid-mpr draft for more details. This list is obtained using a single DNS lookup, unlike SPF which may require dozens or hundreds of sequential lookups. This list can safely be declared "nominal" without being used as an authorization exploit, as with SPF. Depending upon the nature of the list, comprehensive or nominal, the message can be rejected at the MTA or "colored" at the MUA respectively. If the message was abusive, the MTA and NOT the mailbox-domain MUST be held accountable. >> One can not defend assumptions of accountable entities by suggesting >> the mail channel is "defined" to have integrity. > > You're not addressing my scenario, or my reasons for my position. > You're just labelling my position as based on "assumptions", and > therefore any "definition" I come up with is, in your opinion, defined > to be indefensible. I am not attempting to dodge your scenario. I do not agree you have adequately described the situation or considered risks involved making negative assessments against a name. >> Listing a name and blocking their mail because you don't care which >> entity actually caused the message to be sent is also... not nice. > > Which is why I didn't say that. Please don't accuse me of saying "I > don't care", it's rude and insulting. My position, if you had read my > messages, is that IF the recipient cannot tell the difference between > "good" and "bad" originators, then he MUST treat them as identical. > Because, by definition, he has no information by which to distinguish > them. I should have said "one" does not care. Sorry for my phrasing. I did not intend to be rude. I would hope the goal of the MARID group would be to provide a method that accurately distinguishes those accountable for abusive actions. Currently the group seems intent upon skipping a vital step. > Unless.. do you have a way for the recipient to treat "good" and > "bad" originaters differently, in the absence of any data which can be > used to distinguish them? If you do, I would be... surprised. Except for the case where the mailbox-domain referenced a comprehensive list and could not match the MTA name for authorization, no other assertions are safe. The concept of good and bad should be reserved for reputations of the MTA name. >> What entity should be held accountable? The entity authenticated as >> sending the mail, or the mailbox-domain that authorized the mail to be >> sent? > > Each has a different role, therefore their accountability should be > different. Yes, but with respect to a reputation service, only the MTA name may be safely assessed. >> Obtaining an authorization is not the same as authentication of the >> acting entity. > > I'm not sure how that applies to the issues on this list. > > An SMTP server can obtain authentication information from a DNS > server for an SMTP client, and use that information to authorize the > client. The client MUST be authenticated and the authorization validated when holding the MTA name accountable and asserting a reputation for the MTA name. A message (or message action) authorization is not sufficient to hold the mailbox-domain accountable and asserting a reputation for the mailbox domain. > If there's no authentication information available, then the > SMTP server cannot use that information to authorize the user. The alternative becomes an IP address blacklist. >> > MAIL FROM and EHLO based checks are identical in security. >> >> These checks are not the same. > > Which is why I didn't say they were the same. You seem to suggest the MAIL FROM and EHLO identities are equally strong. They are not. >> You are devising a system that requires mailbox-domains authorize >> other domains to send their mail. > > No. "domains" don't send mail. SMTP clients send mail, and use > domain names in fields in SMTP. The difference is crucial. SMTP > clients can be correlated to domain names via: > > - rDNS > - EHLO > - MAIL FROM I don't wish to get bogged down in semantics and protocol details. The MAIL FROM name may not correlate to the to entity accountable for the actions of the MTA. > And not much else. Because there is no easily available mapping of > "domain" to SMTP client, other than those fields, SMTP servers cannot > use anything other than those fields to tie the SMTP client to a > domain name. So talking about "authorizing domains" is a > misconception. SMTP clients are authorized, nothing else can be. Forgive my generalizations that failed to include the protocol. >> If the sending MTA EHLO name is authenticated and authorized by the >> EHLO domain, then it does not matter what mailbox-domain is sent, >> this EHLO entity can be safely held accountable for the MTA actions. > > How? The name of the MTA is held accountable. A name, by any other name, is still a name. :^) > In contrast, by checking MAIL FROM, you can at least have some > confidence that a bounce path exists, and any errant message will be > accepted by the originator. This is only true for the comprehensive list. But this does not mean it is safe to hold this entity accountable for the messages being sent by the MTA. If anything, the MTA entity (EHLO name) should come into question. >> > If someone can't tell the difference between two things, then it >> > MUST treat the two things as identical. >> >> But these things can be identified by an authenticated EHLO name. They >> MUST NOT be treated as identical. > > If two domains use the same MTA, which uses only one authenticate > EHLO name, then by your definition, only the domain in EHLO can be > held accountable, and all recipients must therefore treat the two > domains identically. > > Hmm... have I used your definitions to prove my point? You missed the concept of what entity is safely accountable for messages sent. It can not be determined by the mailbox-domain. When the name affected by reputation services is the provider, then either this MTA is rehabilitated, or their customers move to a different provider. The reputation service has not harmed the wrong party. >> A reputation service spends most of their efforts ensuring information. >> Using the IP address makes this process rather straight forward. Using >> an authenticated EHLO name follows the same model and directly identifies >> those sending the messages. > > It authenticates the MTA sending the messages, which is a little > different. Again, I was not including the protocol while explaining the entities involved. >> To suggest that because the EHLO domain was not considered, means a >> reputation service can safely hold entities accountable for the >> action of others will not have much sway. > > It's not unreasonable to hold multiple parties accountable for a > message. ISP's are already holding other ISP's responsible for the > actions of their customers. It's not unreasonable to use MAIL FROM > accountability in addition to EHLO. Reasonable will be determined by those unfairly harmed by overly broad concepts of what a DNS record suggests. Likely there will also be a fair amount of painful litigation in the case of SPF or Sender-ID. Perhaps there should be a warning in the SPF draft: Publishing SPF records may result in a negative reputation status through events beyond the control of the administrator. Publishing "open" records at your peril. These and many other problems do not exist for CSV and MPR. The other potential effort. :^) -Doug From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 05:03:48 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 FAA02761 for ; Sun, 12 Sep 2004 05:03:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8C8cLeL048391; Sun, 12 Sep 2004 01:38:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8C8cLXo048390; Sun, 12 Sep 2004 01:38:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miranda.server-plant.co.uk (miranda.server-plant.co.uk [193.110.88.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8C8cJNj048355 for ; Sun, 12 Sep 2004 01:38:20 -0700 (PDT) (envelope-from johnp@idimo.com) Received: from idimo2 ([62.87.72.21]) (authenticated) by miranda.server-plant.co.uk (8.11.6/8.11.2) with ESMTP id i8C8c8c27284 for ; Sun, 12 Sep 2004 09:38:09 +0100 Message-ID: <005d01c498a3$d47a69e0$1548573e@idimo2> From: "jpinkerton" To: References: <5CAC0188-047F-11D9-BF67-000A95AC5778@isipp.com> Subject: Re: What the lawyers and suits think Date: Sun, 12 Sep 2004 10:26:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have to agree with Anne Mitchell's post here - I used to be a "suit", I worked in international commerce for many years, and I can tell you all that there is almost no compatability between the corporate need and the technical need, and that the corporate need will always be satisfied first. I diverge from Anne's analysis here by saying that the technical need has to be the one that supplies an answer to the corporate need - therefore the first requirement is to consider the corporate need(s). Look at what the purported IPR holder was trying to do - I don't mean technically, but commercially. This WG is working on MTA-based authenticated e-mail delivery. A corporation who does not have the market share of MTA's that it thinks it should have, will do everything it can to increase it's market share of MTA's. I believe the co-chairs need to focus on a technical solution which does not have any IPR issues. They should steer the WG much more clearly away from such solutions. Kind regards, John Pinkerton. johnp@idimo.com ICQ 313355492 ----- Original Message ----- From: "Anne P. Mitchell, Esq." To: "IETF MARID WG" Sent: Sunday, September 12, 2004 7:48 AM Subject: What the lawyers and suits think (was e: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004) > > All, > > This post to the list has been rolling around in the back of my mind > for a few days. I hope that you will find it useful, or at least > interesting, and I hope that it is appropriate to this discussion. > > I'm piggy-backing it on to this below post, because I wanted to respond > to it, and it is related: > > > It seems I made a mistake and did not notice that chairs did not say > > that > > we should not work alternatives AT ALL but said that we should not work > > on alternatives that WOULD BE covered by patent application. > > > > The above is appropriate, however I note that chairs said that we > > should > > not work on alernatives that "reasonably thought to be covered by the > > patent application". My objection still stands that in itself is > > meaningless because we'll know if alernative is covered when there > > would be another IPR disclosure as it relates to such possible > > alernative > > draft. Until there is one, we can not reasonable be expected to know > > what > > would be covered by patent application because we have not seen one! > > Reading this with my lawyer, geek, and lawyer geek hats on, I take this > to mean "reasonably given what we do know or suspect of the patent". > To take it to the extreme for the sake of example, it would be > reasonable to believe that an exact Sender I.D. clone would be covered > by the patent. It would not be reasonable to think that an elephant > would be covered by the patent. Somewhere between the range of > "elephant" and "exact clone" there are things on which one might focus > which one could reasonably imagine would probably be covered by the > undisclosed patent to the extent that we may imagine what is in it. > > I want to take a moment now to explain to those of you who may not > know, exactly how lawyers and corporate suits in general look at the > sorts of people who take part in working groups such as these, and in > particular how they look at their (i.e. your) concerns. Note that I am > *not* speaking of MS' lawyers or suits in particular (and I couldn't, > as I have not discussed these things with them) - I am speaking from > years of my own experience. > > First, there are _very_ few lawyers who are also geeks *and* who also > *grok* email issues on a substantive technical level in general, and > spam issues in particular. I am one of fewer than I can count on the > fingers of both hands, and then *only* because Paul Vixie took me > in-house at MAPS way back when, and took me under his wing, and so > under his patient tutelage I came to understand way more than I even > knew there *was* to know about the issues and inner workings of the > processes. > > For the most part, lawyers and corporate executives (most especially > the lawyers) think of you guys as very smart, driven, but slightly > strange and obsessed people who work down in the email boiler room - > they want you to make the things work, but your concerns carry about as > much weight with them as an assembly line worker's concerns carry with > the lawyers and execs over at General Motors. Don't believe me? Ask > Paul, who I think will confirm that lawyers' and corporate executives' > world views of these issues *rarely even focus on the same things*, let > alone come to a confluence of opinions, as those of the people who are > actually driving the email systems. > > Your concerns have almost *nothing* to do with the running of a > corporation or the furthering of its corporate objectives. Your > objectives are _not_ their objectives - they rarely cross - they aren't > even parallel - in fact they are on completely different planes. > Think about it - you here are focused on solving a problem - they are > focused on creating a product, and on protecting their client's > corporate interests. > > I would posit that this is the reason that you have very dedicated > people here like Harry Katz who are sincerely and ferverently working > on a solution, and that isn't at all at odds with the issues coming > from the lawyers and suits at the same company. The people upstairs > don't speak your language. They don't share your concerns. They don't > have the same focus. Had I been in their position, say, ten years ago, > I'd have been the same - I'd have been saying "those email geeks want > us to do *what*? That's not how it works up here in the *real* world." > > The irony, of course, in all of this, is that it is those very same > email geeks on who adoption of _any_ standard relies. Oh sure, it's > very clever to get several major bulk email senders to agree to a > standard - but at the end of the day it doesn't matter, because it is > the email *receivers*, not the email senders, whose adoption will make > or break any proposed standard. Every email sender on the planet can > adopt Standard X, but if no receivers are cuing on Standard X, then so > what? > > So the trick is to get the lawyers and the suits to realize that your > concerns aren't just something they have to endure - they are something > they have to satisfy. > > Anne > > From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 09:38: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 JAA14500 for ; Sun, 12 Sep 2004 09:38:32 -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 i8CD9fGD003521; Sun, 12 Sep 2004 06:09: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 i8CD9frX003520; Sun, 12 Sep 2004 06:09:41 -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 i8CD9eDT003513 for ; Sun, 12 Sep 2004 06:09:40 -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 C3D8B17127 for ; Sun, 12 Sep 2004 09:18:55 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Sat, 11 Sep 2004 23:02:47 PDT." <64718.24.10.108.240.1094968967.squirrel@harry.mail-abuse.org> Date: Sun, 12 Sep 2004 09:18:55 -0400 Message-Id: <20040912131855.C3D8B17127@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Douglas Otis" wrote: > The MAIL FROM mailbox-domain was passed through the mail channel WHAT "mail channel"? I have described what I think of as the "mail channel", and given reasons for my conclusions. You haven't. > for messages not originating at the SMTP client. I explained why the SMTP server cannot verifiably know that, and why (for all practical purposes), the SMTP client is the only verifiable originator of the message. You haven't explained why you disagree, or what errors (if any) exist in my message. Simply stating a contrary position is not an argument. > This is normally the case for the SMTP client performing public > delivery. This adds at least an additional SMTP client/server pair. Which is effectively what I said in the paragraph below the one you quoted, and where I explained why it didn't matter to the SMTP server. > I am not attempting to dodge your scenario. I do not agree you have > adequately described the situation or considered risks involved making > negative assessments against a name. The risks involved are undertaken by the mailbox-domain, when it publishes MTA authentication records in DNS. The scope of those risks are defined by the documents under discussion in this group. As for my consideration of those risks, I've explained my reasons, and I don't think I've seen you refute any of them. You've just stated that you disagreed, and then talked about your position. That's nice, but it doesn't give me any insight as to why you disagree with my position, or what's wrong with my position. > The concept of good and bad should be reserved for reputations of > the MTA name. Why? I've explained why and how MAIL FROM accountability can be safely applied. > A message (or message action) authorization is not sufficient to > hold the mailbox-domain accountable and asserting a reputation for the > mailbox domain. Why? If any MAIL FROM authentication system is intended to hold a domain accountable, then MAIL FROM authorization is perfectly valid for holding that domain accountable. > You seem to suggest the MAIL FROM and EHLO identities are equally strong. > They are not. Why? And I'm not suggesting they're equally "strong", but that both may be used, each for different purposes. Saying "they have different kinds of accountability" is a clear statement that one may be more, or less, accountable than the other. > I don't wish to get bogged down in semantics and protocol details. Uh... what else is there? If we're not going to discuss the protocols involved, then we're talking about "angels on the head of a pin", and not doing engineering. > The MAIL FROM name may not correlate to the to entity accountable > for the actions of the MTA. And sometimes it may. The two statements are not contradictory. The MAIL FROM name may also correlate with the entity accepting accountability for the *message*, which is what I've been saying all along. And that statement does not contradict, or invalidate, the idea that an entity (possibly different0 is responsible for the actions of the MTA. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 09:43: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 JAA14673 for ; Sun, 12 Sep 2004 09:43: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 i8CDKebl004417; Sun, 12 Sep 2004 06:20:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8CDKe5j004416; Sun, 12 Sep 2004 06:20:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CDKekg004410 for ; Sun, 12 Sep 2004 06:20:40 -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; Sun, 12 Sep 2004 09:20:38 -0400 id 000A0252.41444D27.000016FA In-Reply-To: <5CAC0188-047F-11D9-BF67-000A95AC5778@isipp.com> References: <5CAC0188-047F-11D9-BF67-000A95AC5778@isipp.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <859B14CB-04BE-11D9-ACBD-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: What the lawyers and suits think (was e: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004) Date: Sun, 12 Sep 2004 09:20:31 -0400 To: "Anne P. Mitchell, Esq." 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 While perhaps interesting, discussion of non-intersecting subcultures is not relevant to this working group. On Sep 12, 2004, at 1:48 AM, Anne P. Mitchell, Esq. wrote: > Oh sure, it's very clever to get several major bulk email senders to > agree to a standard - but at the end of the day it doesn't matter This is very inappropriate. I don't think you would appreciate other participants of this group denouncing your voice. -andy From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 12:32: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 MAA24702 for ; Sun, 12 Sep 2004 12:32:45 -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 i8CG7AiR015356; Sun, 12 Sep 2004 09:07:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8CG7AvI015355; Sun, 12 Sep 2004 09:07:10 -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 i8CG79gP015344 for ; Sun, 12 Sep 2004 09:07:09 -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 1C6Wsa-00047O-7z for ietf-mxcomp@imc.org; Sun, 12 Sep 2004 11:07:10 -0500 To: "IETF MARID WG" References: <5CAC0188-047F-11D9-BF67-000A95AC5778@isipp.com> <859B14CB-04BE-11D9-ACBD-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Sun, 12 Sep 2004 11:07:04 -0500 In-Reply-To: <859B14CB-04BE-11D9-ACBD-000A95B3BA44@hxr.us> (Andrew Newton's message of "Sun, 12 Sep 2004 09:20:31 -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: What the lawyers and suits think 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.6 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 <859B14CB-04BE-11D9-ACBD-000A95B3BA44@hxr.us> Andrew Newton writes: > While perhaps interesting, discussion of non-intersecting subcultures > is not relevant to this working group. I disagree. While Anne may require two hand count the lawyers with a similar combination of being a geek, being a lawyer, and understanding email, I need only one finger. What Anne is explaining is basically what we need to do to help deployment, which is quite relevant to this working group. She is explaing why people who want to stop phishing prefer the PRA over the 2821.MAILFROM even though the PRA protects the 2822.Resent-Sender: header instead of the 2822.From: header in the critical case of actual phishing. > On Sep 12, 2004, at 1:48 AM, Anne P. Mitchell, Esq. wrote: > >> Oh sure, it's very clever to get several major bulk email senders to >> agree to a standard - but at the end of the day it doesn't matter > > This is very inappropriate. I don't think you would appreciate other > participants of this group denouncing your voice. I don't think Anne was was denouncing anyone's voice. She was trying to explain what we need to take into account when we design and try to get deployed a standard than needs buy-in non email-geeks. I think her last paragraph is very important: : So the trick is to get the lawyers and the suits to realize that your : concerns aren't just something they have to endure - they are : something they have to satisfy. A similar concept needs to be considered by us: We need to realize that lawyer/suit concerns aren't just something we have to endure - they are something we have to satisfy. In this sense, neither protecting almost invisible things like the Return-Path: nor the Resent-From: header really satisify their concerns. -wayne From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 12:57: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 MAA26698 for ; Sun, 12 Sep 2004 12:57:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CGQNHW016398; Sun, 12 Sep 2004 09:26:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8CGQNPN016397; Sun, 12 Sep 2004 09:26:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CGQNmx016389 for ; Sun, 12 Sep 2004 09:26:23 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [192.168.0.2] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id 855E630DF0; Sun, 12 Sep 2004 11:26:25 -0500 (CDT) Message-ID: <4144782E.70607@ehsco.com> Date: Sun, 12 Sep 2004 12:24:14 -0400 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Cc: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> In-Reply-To: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/11/2004 1:59 PM, Andrew Newton wrote: > 2) On the issue of compliance with the use of the TXT record, the > working group has at least rough consensus that TXT usage is acceptable > for compliance and should not be specified as a configuration that will > be non-compliant. However, there is at least rough consensus that the > use of the SPF-specific record type is more desirable than the use of a > TXT record type. It is the opinion of the co-chairs that the -protocol > document clearly state that the usage of TXT records will most likely > be deprecated by future protocol definition. I don't think that's good enough and would offer an alternative: * specs sent to last call MUST include a new RRType code * an addendum or a sibling spec MAY describe coexistence mechs for a TXT RR for backwards compatibilty This model ensures that future implementations cannot claim "compliance" until they fix whatever bugs are keeping them from using the new RRType, while also providing a support channel for legacy implementations. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 13:09:49 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 NAA27924 for ; Sun, 12 Sep 2004 13:09:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CGkwFl017688; Sun, 12 Sep 2004 09:46: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 i8CGkwTX017687; Sun, 12 Sep 2004 09:46:58 -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 i8CGkw3q017681 for ; Sun, 12 Sep 2004 09:46:58 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id DFC814149B; Sun, 12 Sep 2004 09:47:01 -0700 (PDT) Received: from 24.10.108.240 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sun, 12 Sep 2004 09:47:01 -0700 (PDT) Message-ID: <64743.24.10.108.240.1095007621.squirrel@harry.mail-abuse.org> In-Reply-To: <20040912131855.C3D8B17127@mail.nitros9.org> References: Your message of "Sat, 11 Sep 2004 23:02:47 PDT." <64718.24.10.108.240.1094968967.squirrel@harry.mail-abuse.org> <20040912131855.C3D8B17127@mail.nitros9.org> Date: Sun, 12 Sep 2004 09:47:01 -0700 (PDT) Subject: Re: SPF abused by spammers From: "Douglas Otis" To: "Alan DeKok" Cc: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "Alan DeKok" > "Douglas Otis" wrote: > >> The MAIL FROM mailbox-domain was passed through the mail channel >> for messages not originating at the SMTP client. > > WHAT "mail channel"? I have described what I think of as the "mail > channel", and given reasons for my conclusions. You haven't. Mail is normally passed from MTA to MTA on its journey to the destination. The MTA making the public delivery is often not where the message was created. The sequence of Mail Transfer Agents carrying the MAIL FROM identifier is what I had referred to as the mail channel. > I explained why the SMTP server cannot verifiably know that, and why > (for all practical purposes), the SMTP client is the only verifiable > originator of the message. You haven't explained why you disagree, or > what errors (if any) exist in my message. It is how the SMTP client is identified. This identifier, to allow safe reputation assertions, must reflect the identity of those administratively in control of the sending machine, and able to take immediate corrective action. An SPF record does not give a reputation service license to hold those that may have "authorized" the MTA to be accountable for the actions of this potentially different entity. Jim Lyon even stated an expectation of holding the mailbox-domain accountable even when the MTA had not been specifically "authorized" as a result of an "open" list. > Simply stating a contrary position is not an argument. You are saying one can not be sure of the origin of the MAIL FROM, but it is okay to use this identity to assert a reputation assessment against the actions of the SMTP client. I agree one can not be sure of the origin of the MAIL FROM and, as a result, the mailbox-domain MUST NOT be used to assert a reputation assessment against the actions of the SMTP client. There is an identity that accurately identifies the SMTP client. This is either the IP address or an authenticated EHLO. >> This is normally the case for the SMTP client performing public >> delivery. This adds at least an additional SMTP client/server pair. > > Which is effectively what I said in the paragraph below the one you > quoted, and where I explained why it didn't matter to the SMTP server. > >> I am not attempting to dodge your scenario. I do not agree you have >> adequately described the situation or considered risks involved making >> negative assessments against a name. > > The risks involved are undertaken by the mailbox-domain, when it > publishes MTA authentication records in DNS. What assurance can you provide that supports this opinion? There is AOL asking people to publish SPF records so they may be white-listed. Now you are saying publishers should also expect to be black-listed when they publish an "open" record as have AOL. Is this do as I say and not as I do? > The scope of those risks are defined by the documents under discussion in > this group. As for my consideration of those risks, I've explained my > reasons, and I don't think I've seen you refute any of them. You've just > stated that you disagreed, and then talked about your position. That's > nice, but it doesn't give me any insight as to why you disagree with my > position, or what's wrong with my position. Rather than justifying not obtaining the SMTP client name out of expediency, consider the outcomes when reputation is used to block the names obtained. Showing the name being blocked is the entity that actually sent the abusive mail will greatly aid the defense of the reputation service. To suggest it does not matter that the name being blocked only authorized the SMTP client and therefore accepted accountability for these disparate entities will be a much more difficult position to take. I would expect this position will not provide much protection in what will likely be a sizable litigation. >> The concept of good and bad should be reserved for reputations of >> the MTA name. > > Why? I've explained why and how MAIL FROM accountability can be > safely applied. You have not. You simply say you can hold the MAIL FROM entity accountable because they published with the clear warning within some discussion within this WG. >> A message (or message action) authorization is not sufficient to >> hold the mailbox-domain accountable and asserting a reputation for the >> mailbox domain. > > Why? If any MAIL FROM authentication system is intended to hold a > domain accountable, then MAIL FROM authorization is perfectly valid > for holding that domain accountable. It is not authenticating, it is authorizing the delivery of the message. The EHLO name can be authenticated, the MAIL FROM provides authorization as does the CSV record in a generic sense. >> You seem to suggest the MAIL FROM and EHLO identities are equally >> strong. They are not. > > Why? And I'm not suggesting they're equally "strong", but that both > may be used, each for different purposes. Saying "they have different > kinds of accountability" is a clear statement that one may be more, or > less, accountable than the other. The high risk act of asserting reputation demands authentication of those entities directly accountable for the actions of the SMTP client, and not based upon implied acceptance of accountability and assumed integrity of the mail channel. >> The MAIL FROM name may not correlate to the to entity accountable >> for the actions of the MTA. > > And sometimes it may. The two statements are not contradictory. > The MAIL FROM name may also correlate with the entity accepting > accountability for the *message*, which is what I've been saying all > along. Yes you have. But where does it say publishing an SPF record is accepting accountability for any message using this mailbox domain coming from an SMTP client? That is the million dollar question. > And that statement does not contradict, or invalidate, the > idea that an entity (possibly different is responsible for the > actions of the MTA. I am of the opinion these assumptions are caviler and needlessly risky. This risk will represent the demise of the reputation service. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 13:21: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 NAA28569 for ; Sun, 12 Sep 2004 13:21: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 i8CGvj34018218; Sun, 12 Sep 2004 09:57: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 i8CGvjiw018217; Sun, 12 Sep 2004 09:57:45 -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 i8CGvjgv018211 for ; Sun, 12 Sep 2004 09:57:45 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id D5BFC414C4; Sun, 12 Sep 2004 09:57:48 -0700 (PDT) Received: from 24.10.108.240 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sun, 12 Sep 2004 09:57:48 -0700 (PDT) Message-ID: <64507.24.10.108.240.1095008268.squirrel@harry.mail-abuse.org> In-Reply-To: References: <5CAC0188-047F-11D9-BF67-000A95AC5778@isipp.com><859B14CB-04BE-11D9-ACBD-000A95B3BA44@hxr.us> Date: Sun, 12 Sep 2004 09:57:48 -0700 (PDT) Subject: Re: What the lawyers and suits think From: "Douglas Otis" To: "IETF MARID WG" Cc: "IETF MARID WG" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "wayne" wrote: > What Anne is explaining is basically what we need to do to help > deployment, which is quite relevant to this working group. She is > explaing why people who want to stop phishing prefer the PRA over the > 2821.MAILFROM even though the PRA protects the 2822.Resent-Sender: > header instead of the 2822.From: header in the critical case of actual > phishing. The marid-mpr draft provides a method of protecting both fields without using the PRA algorithm. It provides solutions for the sequential DNS lookup, open list exploits problems, and allows safe reputation services. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 13:29: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 NAA29236 for ; Sun, 12 Sep 2004 13:29: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 i8CH6FL2018631; Sun, 12 Sep 2004 10:06:15 -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 i8CH6FFD018630; Sun, 12 Sep 2004 10:06:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CH6FiR018624 for ; Sun, 12 Sep 2004 10:06:15 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i8CH6Gv10487; Sun, 12 Sep 2004 10:06:16 -0700 Date: Sun, 12 Sep 2004 10:06:12 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1542943013.20040912100612@brandenburg.com> To: Andrew Newton CC: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew, AN> 2) On the issue of compliance with the use of the TXT record, the AN> working group has at least rough consensus that TXT usage is acceptable AN> for compliance and should not be specified as a configuration that will AN> be non-compliant. However, there is at least rough consensus that the AN> use of the SPF-specific record type is more desirable than the use of a AN> TXT record type. It is the opinion of the co-chairs that the -protocol AN> document clearly state that the usage of TXT records will most likely AN> be deprecated by future protocol definition. Please clarify. What, exactly, would be required to be supported and what would be optional? In particular, how will interoperability be assured at all stages of deployment and use? To be entirely pedantic, how will the specification ensure that the client does not implement an incompatible capability from the server? If client and server do no share at least one MUST, then there will be non-interoperability. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 13:38: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 NAA29495 for ; Sun, 12 Sep 2004 13:38: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 i8CHCTBh019023; Sun, 12 Sep 2004 10:12:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8CHCTA8019022; Sun, 12 Sep 2004 10:12:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CHCSnD019014 for ; Sun, 12 Sep 2004 10:12:29 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from ool-4357926a.dyn.optonline.net ([67.87.146.106] helo=[192.168.0.12]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C6Xtt-0004p6-Uz; Sun, 12 Sep 2004 13:12:30 -0400 Message-ID: <41448378.30603@solidmatrix.com> Date: Sun, 12 Sep 2004 13:12:24 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Andrew Newton , "IETF MXCOMP (E-mail)" Subject: Consensus decision vs. deployment concerns Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andy and Marshall, I am still unclear on the consensus decision in regards to combined mailfrom/pra scopes. As Daniel from Apache made it clear, it seems that the deployment concerns are not lessened with the mailfrom/pra combined proposal, but rather have remained the same. Can you perhaps elaborate in detail what you think the consensus in regards to PRA and deployment concerns is? Yakov From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 14:14:34 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 OAA01961 for ; Sun, 12 Sep 2004 14:14:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CHoo7l021113; Sun, 12 Sep 2004 10:50:50 -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 i8CHoogi021112; Sun, 12 Sep 2004 10:50:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CHoi2S021094 for ; Sun, 12 Sep 2004 10:50:49 -0700 (PDT) (envelope-from pk@TechFak.Uni-Bielefeld.DE) Received: from zeder.TechFak.Uni-Bielefeld.DE (zeder.TechFak.Uni-Bielefeld.DE [129.70.128.80]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i8CHodWe010689 for ; Sun, 12 Sep 2004 19:50:39 +0200 (MEST) Received: from localhost (pk@localhost) by zeder.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i8CHocL28553 for ; Sun, 12 Sep 2004 19:50:38 +0200 (MEST) Message-Id: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-reply-to: Your message of "Sun, 12 Sep 2004 12:24:14 EDT." <4144782E.70607@ehsco.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28548.1095011437.1@zeder.TechFak.Uni-Bielefeld.DE> Date: Sun, 12 Sep 2004 19:50:38 +0200 From: Peter Koch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Eric A. Hall" wrote: > * specs sent to last call MUST include a new RRType code > > * an addendum or a sibling spec MAY describe coexistence mechs for > a TXT RR for backwards compatibilty I fully agree. And the question of whether a prefix is necessary or not is of course closely related to the choice of RR type. TXT would need a prefix, a new type would not. And regarding the "installed base": while I appreciate the efforts by the proponents and the early adopters, recent counts for a certain larger TLD show that there are only a few thousand TXT RRs with "spf" content, often multiple of those existing in (below) the same 2nd level domain. Less than 2% of TXT RRs are used for SPF. This is of course a success for this project but does not constitute an installed base cast in stone compared to what would be necessary to talk about wide deployment. A6 seems to have been more popular before it was redirected down the experiment path. -Peter From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 17:08: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 RAA12232 for ; Sun, 12 Sep 2004 17:08: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 i8CKZVkr033701; Sun, 12 Sep 2004 13:35:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8CKZVKi033700; Sun, 12 Sep 2004 13:35:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org ([80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CKZTnl033694 for ; Sun, 12 Sep 2004 13:35:30 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C6b4L-0007KO-00 for ; Sun, 12 Sep 2004 22:35:29 +0200 Received: from a064176.dialin.hansenet.de ([213.191.64.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Sep 2004 22:35:29 +0200 Received: from nobody by a064176.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Sep 2004 22:35:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 Date: Sun, 12 Sep 2004 22:34:21 +0200 Organization: Lines: 23 Message-ID: <4144B2CD.42A@xyzzy.claranet.de> References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <200409120057.i8C0vFwa092659@m5p.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: a064176.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit George Mitchell wrote: > I think everyone agrees on "mailfrom", but not on "pra". Not sure about everyone, but certainly me. > Also, what happened to "helo"? IIRC the idea was to discuss CSV after SPF, and adding it now before this discussion could be confusing. As soon as we have completed spf2.0/mailfrom adding other scopes like PRA or HELO is easy. Maybe PRA is then unnecessary, and we find a simple solution by matching the relevant headers against MAIL FROM: If nothing matches, and if there's no Sender then it's probably a case of "2476bis 8.1 MAY-be not", otherwise it's a phisher. This could also solve the problem mentioned by Wayne and Anne: | In this sense, neither protecting almost invisible things | like the Return-Path: nor the Resent-From: header really | satisify their concerns. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 18:45: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 SAA18067 for ; Sun, 12 Sep 2004 18:45: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 i8CMIKSC040633; Sun, 12 Sep 2004 15:18:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8CMIKcb040632; Sun, 12 Sep 2004 15:18:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CMIJwr040621 for ; Sun, 12 Sep 2004 15:18:19 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8CMIA9e013303 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 12 Sep 2004 18:18:10 -0400 Date: Sun, 12 Sep 2004 18:18:10 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Sauer, Damon" cc: Markus Stumpf , Subject: RE: SPF abused by spammers In-Reply-To: <38363D9940D92A458010AAE24D162EB90521D090@bremocog-55> 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, 10 Sep 2004, Sauer, Damon wrote: > I didn't say it did. How I identify the IP as a spammer is up to my > other processes. What it DOES do is allow me to make a informed decision > on whether or not to block that IP. You don't see the contradition in these statements? A: Other processes identify IP as a spam/not-spam B: SPF allows me to make an informed decision on whether to block We expect to have spam/not-spam as the basis of our decision to block. B has nothing to do with A. --Dean From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 18:45:04 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 SAA18093 for ; Sun, 12 Sep 2004 18:45: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 i8CMPv9H041078; Sun, 12 Sep 2004 15:25: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 i8CMPvnK041077; Sun, 12 Sep 2004 15:25:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CMPubM041065 for ; Sun, 12 Sep 2004 15:25:56 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8CMQ0Cw013485 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 12 Sep 2004 18:26:01 -0400 Date: Sun, 12 Sep 2004 18:26:00 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040910152515.9101816CD2@mail.nitros9.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 10 Sep 2004, Alan DeKok wrote: > > Douglas Otis wrote: > > If the mailbox domain has been safely blacklisted, then no confirmation > > with respect to the IP address from the SPF records is needed. > > RFC 2821 header checking against authentication records in DNS > enables recipients to safely blacklist mailbox domains. > > i.e. 100% of messages from a domain pass RFC 2821 DNS checks, and > are spam: the recipient may choose to blacklist the domain. Many years ago, people started to block domains and email addresses. It was found that rather than blocking spam, this practice motivated more DOS attacks (joe-jobs). It would never be the case that 100% of the messages from a domain 'pass checks' and are spam, unless that domain has been subjected to a joe-job or the domain is disposable. If it is disposable, then blocking it won't have any effect, since it won't be used for long. > In the absence of those checks, the recipient can still blacklist > the domain, but has no way of knowing for sure if the messages are > forged, and thus an attack by a malicious third party, who wishes to > disrupt communications between the alleged originator and the > recipient. One still has no method of determining if the messages are forged, checks or no checks. The "checks" have no value. The message could still be forged, the DNS records could be forged, the senders machine could be compromised, the abuser could obtain an account at the ISP that hosts the domain, etc, etc, etc. --Dean From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 18:57: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 SAA18683 for ; Sun, 12 Sep 2004 18:57: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 i8CMXM9c041554; Sun, 12 Sep 2004 15:33:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8CMXMkI041553; Sun, 12 Sep 2004 15:33:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8CMXMJX041544 for ; Sun, 12 Sep 2004 15:33:22 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8CMWHIs013579 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 12 Sep 2004 18:32:18 -0400 Date: Sun, 12 Sep 2004 18:32:17 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Peter Bowyer cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <01f301c4988d$3db131d0$0a46a8c0@pbdesktop> 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, 12 Sep 2004, Peter Bowyer wrote: > > But AOL won't have spammers on their whitelist. The only domains for which > an SPF Pass means less filtering are those which are pre-whitelisted. And > SPF will ensure that mail which appears to be from those domains isn't > forged. This is a false assumption. Any domain that is whitelisted will attract spammers to that domain. There is no domain or ISP that can claim not to have spammers ever. Whether you use SPF as the reduced testing mechanism or some other mechanism is irrelevant. The 'bad thing' is to ever subject some mail to less filtering. > What's your problem with this? It's using SPF for exactly what it was > intended, and the fact that spammers publish SPF will have no effect on it > at all. SPF has no effect on anything except to interfere with legitimate email unbundling. SPF allows MSN and AOL to conspire to prevent email outsourciing, or to charge the outsourcers for the "privelege" of having an SPF record, or to interfere with such outsourced email by having unreliable nameservice for the outsourced SPF records. In exchange, SPF has no impact on spam, whatsoever. Thats my problem with SPF. From owner-ietf-mxcomp@mail.imc.org Sun Sep 12 21:41: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 VAA27161 for ; Sun, 12 Sep 2004 21:41: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 i8D1EDU7052136; Sun, 12 Sep 2004 18:14:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8D1EDG8052131; Sun, 12 Sep 2004 18:14:13 -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 i8D1DxmJ052042 for ; Sun, 12 Sep 2004 18:14: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 6763816CD2 for ; Sun, 12 Sep 2004 21:23:19 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Sun, 12 Sep 2004 09:47:01 PDT." <64743.24.10.108.240.1095007621.squirrel@harry.mail-abuse.org> Date: Sun, 12 Sep 2004 21:23:19 -0400 Message-Id: <20040913012319.6763816CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Douglas Otis" wrote: > > WHAT "mail channel"? I have described what I think of as the "mail > > channel", and given reasons for my conclusions. You haven't. > > Mail is normally passed from MTA to MTA on its journey to the destination. How does that affect MAIL FROM authentication via records in DNS? > The MTA making the public delivery is often not where the message was > created. The sequence of Mail Transfer Agents carrying the MAIL FROM > identifier is what I had referred to as the mail channel. None of which is relevant to MAIL FROM authentication via records in DNS. The previous hops are invisible to MAIL FROM checks. > You are saying one can not be sure of the origin of the MAIL FROM, but it > is okay to use this identity to assert a reputation assessment against the > actions of the SMTP client. I'm saying that the recipient may not know the "true" origin, and that that "true" origin may be un-knowable. The recipient CAN know that the current hop is authenticated, if the MAIL FROM satisfies authentication records in DNS. For the recipient, nothing else is verifiable, and therefore nothing else is relevant. All I'm doing here is taking your EHLO argument, and applying it to MAIL FROM. Your opposition to this process indicates conflict or confusion somewhere in the conversation. > Now you are saying publishers should also expect to be black-listed > when they publish an "open" record as have AOL. Publishers should expect recipients to do the most curious things, for the most inane reasons. > Showing the name being blocked is the entity that actually sent the > abusive mail will greatly aid the defense of the reputation service. Replace "sent" with "accepted responsibility for", and MAIL FROM checking is perfectly valid, if all parties agree. > > Why? I've explained why and how MAIL FROM accountability can be > > safely applied. > > You have not. You simply say you can hold the MAIL FROM entity > accountable because they published with the clear warning within some > discussion within this WG. No... that's dumb. "MTA's don't read mailing lists". In any protocol implementation, all parties involved agree as to what the information means, and how to interpret it. MARID implementations are nothing special in this regard. If this WG publishes standards defining accountability, then it's entirely reasonable to expect that implementors of the standard have accepted that accountability. > But where does it say publishing an SPF record is accepting > accountability for any message using this mailbox domain coming from > an SMTP client? That is the million dollar question. That spec isn't under consideration by this group, so any answer would be out of scope. But in general, I believe close examination of email scenarios may lead to such statements. > I am of the opinion these assumptions are caviler and needlessly risky. > This risk will represent the demise of the reputation service. Which is why I have great skepticism that any reputation system will work. Having my ability to run an MTA depend on kissing up to some third party? Sure... that fits into the freedom, and the "end to end" nature of the net. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 01:14: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 BAA10025 for ; Mon, 13 Sep 2004 01:14: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 i8D4mhJi072330; Sun, 12 Sep 2004 21:48: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 i8D4mhXG072329; Sun, 12 Sep 2004 21:48:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8D4mgSR072321 for ; Sun, 12 Sep 2004 21:48:42 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i8D4mgg30086; Sun, 12 Sep 2004 21:48:42 -0700 Date: Sun, 12 Sep 2004 21:48:37 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <587418158.20040912214837@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040913012319.6763816CD2@mail.nitros9.org> References: Your message of "Sun, 12 Sep 2004 09:47:01 PDT." <64743.24.10.108.240.1095007621.squirrel@harry.mail-abuse.org> <20040913012319.6763816CD2@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan, >> Mail is normally passed from MTA to MTA on its journey to the destination. AD> How does that affect MAIL FROM authentication via records in DNS? That depends upon the authentication scheme and the nature of the information coming from the DNS. However the fact that mail transits multiple MTAs is hardly remarkable insight. It has been the nature of networked email for more than 25 years, so it's not clear what prompts your particular question. >> The MTA making the public delivery is often not where the message was >> created. The sequence of Mail Transfer Agents carrying the MAIL FROM >> identifier is what I had referred to as the mail channel. AD> None of which is relevant to MAIL FROM authentication via records in AD> DNS. The previous hops are invisible to MAIL FROM checks. Actually, the fact that a mailfrom authentication is being performed an arbitrary number of MTA hops away from the mailfrom's creation is extremely relevant to the technical basis and administrative complexity of maintain DNS information needed to achieve that authentication. >> You are saying one can not be sure of the origin of the MAIL FROM, but it >> is okay to use this identity to assert a reputation assessment against the >> actions of the SMTP client. AD> I'm saying that the recipient may not know the "true" origin, and AD> that that "true" origin may be un-knowable. The recipient CAN know AD> that the current hop is authenticated, if the MAIL FROM satisfies AD> authentication records in DNS. Correct. If all the information lines up correctly, you know something useful. If, however, the information is missing or does not line up, then it is not at all clear you know anything. And if the scenarios for which the information lines up turn out to be few, then the entire mechanism has very limited utility. Given the aggregate cost of Internet standards, it is useful to worry a great deal about the technical, administrative, and operational complexity of a proposal. I pretentiously call this it's "physics", in the hope that folks will worry a bit about system dynamics. There is a tendency to focus only on very localized aspects of a design. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 01:35: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 BAA11053 for ; Mon, 13 Sep 2004 01:35:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8D5BC99077167; Sun, 12 Sep 2004 22:11: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 i8D5BBZo077164; Sun, 12 Sep 2004 22:11:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.salmark.net (mail.salmark.net [64.23.85.10] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8D5BA8X077154 for ; Sun, 12 Sep 2004 22:11:11 -0700 (PDT) (envelope-from peter@bowyer.org) Received: from [212.158.247.25] (port=10823 helo=pbdesktop) by mail.salmark.net with asmtp (Exim 4.41) id 1C6j7V-0007Ec-Sm for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 01:11:18 -0400 Message-ID: <0cb001c49950$22c3fec0$0a46a8c0@pbdesktop> From: "Peter Bowyer" To: References: Subject: Re: SPF abused by spammers Date: Mon, 13 Sep 2004 06:11:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dean Anderson wrote: > On Sun, 12 Sep 2004, Peter Bowyer wrote: > >> >> But AOL won't have spammers on their whitelist. The only domains for >> which an SPF Pass means less filtering are those which are >> pre-whitelisted. And SPF will ensure that mail which appears to be >> from those domains isn't forged. > > This is a false assumption. Any domain that is whitelisted will > attract spammers to that domain. There is no domain or ISP that can > claim not to have spammers ever. They don't whitelist ISP domains - only responsible bulk email senders. People whose mail you want your users to receive. > Whether you use SPF as the reduced testing mechanism or some other > mechanism is irrelevant. The 'bad thing' is to ever subject some mail > to less filtering. Wrong. You submit mail which you've already determined as 'truested' by your own reputation mechanism. > What's your problem with this? It's using SPF for exactly what it was >> intended, and the fact that spammers publish SPF will have no effect >> on it at all. > SPF has no effect on anything except to interfere with legitimate > email unbundling. SPF allows MSN and AOL to conspire to prevent email > outsourciing, or to charge the outsourcers for the "privelege" of > having an SPF record, or to interfere with such outsourced email by > having unreliable nameservice for the outsourced SPF records. In > exchange, SPF has no impact on spam, whatsoever. Thats my problem > with SPF. Well, you're entitled to your view, but your appreciation of the facts in the case of AOL is clearly inaccurate. And please remember that SPF is an authentication framework, not an anti-spam tool. Peter From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 02:17: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 CAA26985 for ; Mon, 13 Sep 2004 02:17: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 i8D5a3jf088117; Sun, 12 Sep 2004 22:36:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8D5a3iU088116; Sun, 12 Sep 2004 22:36:03 -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 i8D5a2pg088079 for ; Sun, 12 Sep 2004 22:36:02 -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 i8D5lWmt032607 for ; Sun, 12 Sep 2004 22:47:32 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8D5lWKA032604 for ; Sun, 12 Sep 2004 22:47:32 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 12 Sep 2004 22:47:32 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 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: In marid-core draft says in section 7.2 it is written: 7.2 E-Mail Forwarders A program that forwards received mail to other addresses MUST add an appropriate header that contains an email address that it is authorized to use. Such programs SHOULD use the Resent-From header for this purpose. But this recomendation for Forwarders to use Resent-From header directly contradicts what is written in section 3.6.6 of the RFC2822: Note: Reintroducing a message into the transport system and using resent fields is a different operation from "forwarding". "Forwarding" has two meanings: One sense of forwarding is that a mail reading program can be told by a user to forward a copy of a message to another person, making the forwarded message the body of the new message. A forwarded message in this sense does not appear to have come from the original sender, but is an entirely new message from the forwarder of the message. On the other hand, forwarding is also used to mean when a mail transport program gets a message and forwards it on to a different destination for final delivery. Resent header fields are not intended for use with either type of forwarding" -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 04:32:44 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 EAA05968 for ; Mon, 13 Sep 2004 04:32:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8D7vKSZ043862; Mon, 13 Sep 2004 00:57:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8D7vKJ0043861; Mon, 13 Sep 2004 00:57:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8D7vJfe043850 for ; Mon, 13 Sep 2004 00:57:19 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C6li6-0004Zf-00; Mon, 13 Sep 2004 00:57:14 -0700 To: Dave Crocker Cc: Andrew Newton , IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1542943013.20040912100612@brandenburg.com> From: Daniel Quinlan Date: 13 Sep 2004 00:57:14 -0700 In-Reply-To: Dave Crocker's message of "Sun, 12 Sep 2004 10:06:12 -0700" Message-ID: Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker writes: > If client and server do no share at least one MUST, then there will be > non-interoperability. Yes. It would also be nice if the world could avoid doing duplicate DNS queries for spf2 records. I don't think a single person has disagreed with that design goal and I noted this in my earlier comments, so I hope that is addressed in the next revision of the specifications. One or the other forever or both with a pre-specified flag day in the not-too-distant future. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 05:01: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 FAA07761 for ; Mon, 13 Sep 2004 05:01: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 i8D8Wxgi054993; Mon, 13 Sep 2004 01:32: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 i8D8WxpS054992; Mon, 13 Sep 2004 01:32:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail80.messagelabs.com (mail80.messagelabs.com [195.245.230.163]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8D8WwoR054978 for ; Mon, 13 Sep 2004 01:32:58 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-4.tower-80.messagelabs.com!1095064376!1651105 X-StarScan-Version: 5.2.10; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 15902 invoked from network); 13 Sep 2004 08:32:56 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-4.tower-80.messagelabs.com with SMTP; 13 Sep 2004 08:32:56 -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 ; Mon, 13 Sep 2004 09:32:56 +0100 Subject: Re: clarification on consensus call for compromise To: Yakov Shafranovich Cc: ietf-mxcomp@imc.org, Michel Bouissou X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Danny Angus Date: Mon, 13 Sep 2004 09:32:55 +0100 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 13/09/2004 09:32:56 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: Yakov wrote: >What about the scope idea itself? Do you agree with it? Yakov, My own view is that the scope idea looks like a bit of a get out for the WG because it removes the necessity to specify a single definitive identity and a single definitive algorithm for identifying it. Real life tends to weaken this argument by demonstrating time and again that any definitive identity and its accurate determination already is a moving target. "Scope" which implements extensibility, is therfore a reasonable future-proofing precaution, but we ought to take care that we don't use it as an excuse for avoiding the difficult issue. One (or more) initial madatory scope(s) would satisfy my desire to see that the specification as published be implementable without external refrence, and more importantly without contact (direct or indirect) between implementors being required for satisfactory interoperability. Surely this is the whole point of interoperability RFC's, and something which is lost if we first have to find out what scopes a recipient checks before we can send them mail. Leaving scope as extensible will allow those who follow to spend more time analysing and defining and evolving the truly sucessful scopes which this proposal requires in order to be sucessful. In the fullness of time perhaps one of these scopes could form the basis for the next generation of this work, by being both mandatory and effective. d. Danny Angus http://james.apache.org *************************************************************************** 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 Mon Sep 13 05:57:14 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 FAA11634 for ; Mon, 13 Sep 2004 05:57:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8D9TW0K075167; Mon, 13 Sep 2004 02:29:32 -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 i8D9TWmR075166; Mon, 13 Sep 2004 02:29:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8D9TUtO075130 for ; Mon, 13 Sep 2004 02:29:31 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 236C926C0AE; Mon, 13 Sep 2004 11:29:27 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 0B42D26C0AB; Mon, 13 Sep 2004 11:29:26 +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 i8D9TPm71032910; Mon, 13 Sep 2004 11:29:25 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id CEDE7FACE; Mon, 13 Sep 2004 11:29:25 +0200 (CEST) Date: Mon, 13 Sep 2004 11:29:25 +0200 From: Stephane Bortzmeyer To: Tony Finch Cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR (-core): current practice Message-ID: <20040913092925.GA30473@nic.fr> References: <20040907134308.GB5488@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040907134308.GB5488@nic.fr> 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 Tue, Sep 07, 2004 at 03:43:08PM +0200, Stephane Bortzmeyer wrote a message of 14 lines which said: > Does anyone has a comprehensive list of major MTAs' behaviour? > > For instance (just tested): > > Postfix 2.1 with ".forward" : adds a Delivered-To (not mentioned in > RFC 2822) but no Resent-something sendmail 8.12.3 with ".forward" : adds no header at all (and therefore no Resent-something) From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 06:33: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 GAA13625 for ; Mon, 13 Sep 2004 06:33: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 i8DA7bsQ089053; Mon, 13 Sep 2004 03:07:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DA7b1Q089052; Mon, 13 Sep 2004 03:07:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DA7OV5088956 for ; Mon, 13 Sep 2004 03:07:37 -0700 (PDT) (envelope-from SRS0+2212f71005eadfaf1d73+386+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C6njx-0005JZ-22; Mon, 13 Sep 2004 06:07:17 -0400 Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 From: David Woodhouse To: "william(at)elan.net" Cc: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Date: Mon, 13 Sep 2004 11:02:31 +0100 Message-Id: <1095069751.4995.144.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-09-12 at 22:47 -0700, william(at)elan.net wrote: > > In marid-core draft says in section 7.2 it is written: > > 7.2 E-Mail Forwarders > A program that forwards received mail to other addresses MUST add an > appropriate header that contains an email address that it is > authorized to use. Such programs SHOULD use the Resent-From header > for this purpose. > > But this recomendation for Forwarders to use Resent-From header directly > contradicts what is written in section 3.6.6 of the RFC2822: We should not abuse the Resent-From: header. Instead, we should either introduce a new header or simply add a new field to the Received: header. I favour the latter. I have not seen any reason given for abusing the existing Resent-From: header, nor do I understand why it is useful to do so instead of introducing something new and unambiguous. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 07:33: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 HAA17971 for ; Mon, 13 Sep 2004 07:33: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 i8DB2JI2009497; Mon, 13 Sep 2004 04:02:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DB2JgI009496; Mon, 13 Sep 2004 04:02:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DB2G5E009469 for ; Mon, 13 Sep 2004 04:02:18 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59637) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1C6oaz-0000LN-To (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 12:02:05 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C6oaz-0003vt-MI; Mon, 13 Sep 2004 12:02:05 +0100 Date: Mon, 13 Sep 2004 12:02:05 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: David Woodhouse cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 In-Reply-To: <1095069751.4995.144.camel@localhost.localdomain> Message-ID: References: <1095069751.4995.144.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 13 Sep 2004, David Woodhouse wrote: > > We should not abuse the Resent-From: header. Instead, we should either > introduce a new header or simply add a new field to the Received: > header. I favour the latter. The Received: field already includes a "for" clause which contains the recipients of the message. It is usually omitted if there is more than one recipient for privacy reasons (otherwise it could expose BCC recipients). If Sender-ID were to use that clause, what should it contain in the multiple recipients case? At least Resent-From: mailer-daemon makes some kind of sense. Received: for unspecified-recipients@unspecified-domains? Tony. -- f.a.n.finch http://dotat.at/ ROCKALL: CYCLONIC, BECOMING NORTH 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. SHOWERS. MAINLY GOOD. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 07:58: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 HAA20184 for ; Mon, 13 Sep 2004 07:58:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DBXStN012708; Mon, 13 Sep 2004 04:33: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 i8DBXSoA012705; Mon, 13 Sep 2004 04:33:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DBXP9h012665 for ; Mon, 13 Sep 2004 04:33:26 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38881) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1C6p5D-0001oT-Ox (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 12:33:19 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C6p5D-0002J5-NY; Mon, 13 Sep 2004 12:33:19 +0100 Date: Mon, 13 Sep 2004 12:33:19 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: David Woodhouse cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 In-Reply-To: <1095074666.4995.166.camel@localhost.localdomain> Message-ID: References: <1095069751.4995.144.camel@localhost.localdomain> <1095074666.4995.166.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 13 Sep 2004, David Woodhouse wrote: > > The 'for' clause indicates recipients, while a new clause would indicate > the purported _sender_ for the hop in question. It would be 'on behalf > of' or something similar. The Received: field is created at the wrong time for that information to be included, unless each hop adds both an incoming Received: field (like the current one) and an outgoing field for recording the submitter. Tony. -- f.a.n.finch http://dotat.at/ COLWYN BAY TO THE MULL OF GALLOWAY INCLUDING THE ISLE OF MAN: SOUTHWEST 5 TO 7, INCREASING GALE 8 FOR A TIME, BECOMING CYCLONIC 5 LATER. SQUALLY SHOWERS. MAINLY GOOD. MODERATE OR ROUGH. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 07:58: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 HAA20202 for ; Mon, 13 Sep 2004 07:58: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 i8DBTHJk012172; Mon, 13 Sep 2004 04:29:17 -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 i8DBTHjF012171; Mon, 13 Sep 2004 04:29:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DBTHOT012161 for ; Mon, 13 Sep 2004 04:29:17 -0700 (PDT) (envelope-from SRS0+2212f71005eadfaf1d73+386+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C6p1G-0005ZD-Me; Mon, 13 Sep 2004 07:29:15 -0400 Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 From: David Woodhouse To: Tony Finch Cc: ietf-mxcomp@imc.org In-Reply-To: References: <1095069751.4995.144.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Date: Mon, 13 Sep 2004 12:24:26 +0100 Message-Id: <1095074666.4995.166.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 2004-09-13 at 12:02 +0100, Tony Finch wrote: > On Mon, 13 Sep 2004, David Woodhouse wrote: > > > > We should not abuse the Resent-From: header. Instead, we should either > > introduce a new header or simply add a new field to the Received: > > header. I favour the latter. > > The Received: field already includes a "for" clause which contains the > recipients of the message. It is usually omitted if there is more than one > recipient for privacy reasons (otherwise it could expose BCC recipients). The 'for' clause indicates recipients, while a new clause would indicate the purported _sender_ for the hop in question. It would be 'on behalf of' or something similar. > If Sender-ID were to use that clause, what should it contain in the > multiple recipients case? At least Resent-From: mailer-daemon makes some > kind of sense. Received: for unspecified-recipients@unspecified-domains? For there to be multiple senders, I assume you speak of the case where the original message was to multiple local recipients, each of whom has a .forward file directed at a users on a the same third party host, and your MTA wants to send those messages in the same SMTP transaction. The problem is the same as with the Resent-From: header. Yes, you probably just use a mailer-dæmon address. I wasn't proposing any change to the information you include -- only that you should put it somewhere new instead of abusing the Resent-From: header. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 08: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 IAA21483 for ; Mon, 13 Sep 2004 08: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 i8DBgfmX013672; Mon, 13 Sep 2004 04:42: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 i8DBgfZZ013671; Mon, 13 Sep 2004 04:42:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DBgehw013665 for ; Mon, 13 Sep 2004 04:42:41 -0700 (PDT) (envelope-from SRS0+2212f71005eadfaf1d73+386+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C6pEH-0005aO-Hh; Mon, 13 Sep 2004 07:42:42 -0400 Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 From: David Woodhouse To: Tony Finch Cc: ietf-mxcomp@imc.org In-Reply-To: References: <1095069751.4995.144.camel@localhost.localdomain> <1095074666.4995.166.camel@localhost.localdomain> Content-Type: text/plain Date: Mon, 13 Sep 2004 12:37:55 +0100 Message-Id: <1095075475.4995.174.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-09-13 at 12:33 +0100, Tony Finch wrote: > On Mon, 13 Sep 2004, David Woodhouse wrote: > > > > The 'for' clause indicates recipients, while a new clause would indicate > > the purported _sender_ for the hop in question. It would be 'on behalf > > of' or something similar. > > The Received: field is created at the wrong time for that information to > be included, unless each hop adds both an incoming Received: field (like > the current one) and an outgoing field for recording the submitter. That's true. So perhaps the Received: header isn't the right place for such information -- but certainly the Resent-From: header isn't the right place for it either. Then we should add a new header for the purpose. An alternative would be to provide the selected address to the next hop by means of an extension such as 'SUBMITTER-RFC2822' which gets logged in the _next_ Received: header. I don't like that much -- defining a new header makes more sense. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 08:53:24 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 IAA24849 for ; Mon, 13 Sep 2004 08:53:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DCK9vo016632; Mon, 13 Sep 2004 05:20: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 i8DCK8Xo016630; Mon, 13 Sep 2004 05:20: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 i8DCK7gL016623 for ; Mon, 13 Sep 2004 05:20:08 -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 i8DCVaZA018787; Mon, 13 Sep 2004 05:31:36 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8DCVa5M018784; Mon, 13 Sep 2004 05:31:36 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Sep 2004 05:31:36 -0700 (PDT) From: "william(at)elan.net" To: David Woodhouse cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 In-Reply-To: <1095069751.4995.144.camel@localhost.localdomain> 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, 13 Sep 2004, David Woodhouse wrote: > We should not abuse the Resent-From: header. Instead, we should either > introduce a new header or simply add a new field to the Received: > header. I favour the latter. The received header unfortunetly has not been standartized (ok to be more precise it standartized by RFC2821 in section 4.4 but many systems still don't do it in correct way). Additionally Received header are specially designated to be trace fields, so they are like a loggin info. Normally in programming, one would not think of using loggin data to implement program processing (other then database logs where it is a journal that can be used to revert back to original state or in case of filesystems, like ext3 JFS to fix the original state in case of known errors). So in my view Received header is a bad place for adding this data. Plus to that Received header is normally added by systems when it received the message but Submitter information is added when message is being sent out. > I have not seen any reason given for abusing the existing Resent-From: > header, nor do I understand why it is useful to do so instead of > introducing something new and unambiguous. I completely agree. I'll be submitting proposal later this week on it. In the mean time I'll present the main ideas in separate email to get a view if WG has any interest in it and to try to resolve some of the issues I have not decided on. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 09:09: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 JAA26743 for ; Mon, 13 Sep 2004 09:09: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 i8DCh7pq018453; Mon, 13 Sep 2004 05:43: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 i8DCh7TN018452; Mon, 13 Sep 2004 05:43:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DCh6UR018445 for ; Mon, 13 Sep 2004 05:43:07 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52046) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1C6qAg-0002GJ-Fm (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 13:43:02 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C6qAg-00074d-8x; Mon, 13 Sep 2004 13:43:02 +0100 Date: Mon, 13 Sep 2004 13:43:02 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "william(at)elan.net" cc: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 13 Sep 2004, william(at)elan.net wrote: > > The received header unfortunetly has not been standartized (ok to be > more precise it standartized by RFC2821 in section 4.4 but many systems > still don't do it in correct way). It has been specified for over 20 years: the format was originally specified in RFC 821 (STD 10) and hasn't changed significantly since. Tony. -- f.a.n.finch http://dotat.at/ COLWYN BAY TO THE MULL OF GALLOWAY INCLUDING THE ISLE OF MAN: SOUTHWEST 5 TO 7, INCREASING GALE 8 FOR A TIME, BECOMING CYCLONIC 5 LATER. SQUALLY SHOWERS. MAINLY GOOD. MODERATE OR ROUGH. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 09:22:55 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 JAA28108 for ; Mon, 13 Sep 2004 09:22:54 -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 i8DCuHvT019620; Mon, 13 Sep 2004 05:56:17 -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 i8DCuHEj019619; Mon, 13 Sep 2004 05:56:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DCuGr8019608 for ; Mon, 13 Sep 2004 05:56:16 -0700 (PDT) (envelope-from SRS0+2212f71005eadfaf1d73+386+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C6qNS-0005gh-IZ; Mon, 13 Sep 2004 08:56:15 -0400 Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 From: David Woodhouse To: "william(at)elan.net" Cc: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Date: Mon, 13 Sep 2004 13:51:25 +0100 Message-Id: <1095079885.4995.213.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-09-13 at 05:31 -0700, william(at)elan.net wrote: > Additionally Received header are specially designated to be trace fields, > so they are like a loggin info. That's all they are here, surely? In a world where SenderID was ubiquitous you'd have mail servers automatically rewriting RFC2821 and RFC2822 identities on outgoing mail, and the SenderID validates _only_ that one hop; it's not end-to-end validation such as PGP, DomainKeys or Signed Envelope Senders would offer. You end up using a domain-based blacklist instead of the IP-address- based blacklists which are already common, but other than that the problem hasn't changed much. It's just a way of determining which are legitimate mail servers, and which are not. The information as to the 'purported responsible' domain in each hop really is just trace info which is of little importance after the fact. A sending mail server can choose any 'domain' it likes when modifying the mail it sends, as long as its IP address is designed as one of the permitted addresses for the 'domain'. The domain used doesn't have to be the same for all outgoing mail, and doesn't have to bear any relation to any domain name you'll actually see or use in your interaction with your email client. It's _purely_ a lookup key for your trust database or blacklist, and could be considered just that -- an arbitrary key. Mail forwarded by pobox.com uses 'bounce2.pobox.com' for example. Incidentally, once we realise that it's _just_ a single hop we're validating, and that the key is essentially arbitrary, the whole problem we're trying to solve can be seen in a different light. All we're doing is offering a way for sending mail hosts to offer an arbitrary 'trust key' of their choice, which the recipient can then look up in a database. As long as there's a way of checking that the host in question really is an authorised user of that 'trust key' it doesn't matter _what_ it is. For example, we could use signatures on TLS certificates. A listing in the database could be keyed on the _signatures_ on the cert which is presented by the sending mail host -- so the database lookup could result in a trust level (or a blacklist/whitelist entry) for some certificate related to 'infradead.org' and any mail server which presents a cert signed by that certificate would be treated accordingly. A trust scheme based on TLS certificates (or perhaps some other database key which is easy to verify) could be introduced without all the breakage at forwarding sites which would be caused by the proposed 'mailfrom' or 'pra' scopes of SenderID, and would achieve much the same benefit, since SenderID does _not_ offer end-to-end validation but only per-hop trust assessments of individual hosts. > Plus to that Received header is normally added by systems when it received > the message but Submitter information is added when message is being sent out. Tony already pointed that out, and it is true -- so it seems a new header does make more sense for purely practical reasons. > > I have not seen any reason given for abusing the existing Resent-From: > > header, nor do I understand why it is useful to do so instead of > > introducing something new and unambiguous. > > I completely agree. I'll be submitting proposal later this week on it. OK, good. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 09:58: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 JAA00973 for ; Mon, 13 Sep 2004 09:58:04 -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 i8DDTo42022361; Mon, 13 Sep 2004 06:29:50 -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 i8DDToUu022360; Mon, 13 Sep 2004 06:29:50 -0700 (PDT) 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 i8DDTntR022348 for ; Mon, 13 Sep 2004 06:29:50 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 5D5D31A6B9; Mon, 13 Sep 2004 15:29:46 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id ED7621A69D for ; Mon, 13 Sep 2004 15:29:43 +0200 (CEST) Message-Id: <0DGwyUSlzbflhEyueorJJA.md5@prosecco.oryx.com> Date: Mon, 13 Sep 2004 15:29:43 +0200 From: Arnt Gulbrandsen To: ietf-mxcomp@imc.org Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tony Finch writes: > On Mon, 13 Sep 2004, william(at)elan.net wrote: >> The received header unfortunetly has not been standartized (ok to be >> more precise it standartized by RFC2821 in section 4.4 but many >> systems still don't do it in correct way). > > It has been specified for over 20 years: the format was originally > specified in RFC 821 (STD 10) and hasn't changed significantly since. Further, the widespread noncompliance isn't a problem in this context: MTA authors who want to support sender-id can just as easily teach their software generate received fields as they can add a new field. Arnt From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 09:58: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 JAA00988 for ; Mon, 13 Sep 2004 09:58: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 i8DDRAgg022117; Mon, 13 Sep 2004 06:27:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DDRAIP022116; Mon, 13 Sep 2004 06:27:10 -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 i8DDR94s022109 for ; Mon, 13 Sep 2004 06:27: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 i8DDcd7D024838 for ; Mon, 13 Sep 2004 06:38:39 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8DDcdqp024834 for ; Mon, 13 Sep 2004 06:38:39 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Sep 2004 06:38:39 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: Request discussion about using SUBMITTER (together with new Submitted-By RFC 2822 header) as basis for futher work 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: Hello members of MARID WG, I request formal discussion on possibility of replacing current SenderID/PRA proposal with one that is based primarily on the extended Submitter draft with additional extension that would involve new Submitted-By RFC2822 header. In this case, the SUBMITTER SMTP extension would co-exist together with new Submitted-By header and this allows for quicker adoption allowing programs that are able to add headers (like software that operates mail lists and forwarders) to do so without necessarily a need to change how those programs call MTA program (i.e. it would require new interface option when calling /usr/bin/sendmail to communicate SUBMITTER value if it is entirely RFC2821 value). The SUBMITTER parameter of MAIL would also be set exclusively based on this new header. The Submitted-By header would have to be added by at least one entity at each mail network (I defined mail network as "group of one or more SMTP speakers that know each other and where each SMTP server in the network has means of identifying SMTP client from the same network") and it specifies Responsible Submitter entity, i.e. somebody that basicly takes responsibility for transmission of the email on its network and maybe contacted in case of problems. If there was reintroduction of email (such as mail list or forwarder), then this mail list of forwarder is such responsible party and it is supposed to add Submitted-By header (it may also add Resent-From or Sender headers if appropriate just like they do now) For email leaving the first "origin" network, the sender (as usually listed in "Sender" or "From" headers) is the responsible party and MTA that received email from MSA is supposed to add this new header (with value taken out of "Sender:" header if it was present or otherwise out of "From:"), but MSA itself MAY also add Submitted-By header directly and is recommended to do so if it is tranmitting message on behalf of third party (like hotel system or airport email kiosk). For verification of email by means of SPF protocol, the SUBMITTER scope would be used and clients that support it would be required to base their decision based on either SUBMITTER parameter of MAIL or based on the Submitted-By header if is top-most header in the email. If it is not top-most header, then client SHOULD find the first Submitted-By header and attempt to verify that. If it passes, everything is good, but if it fails it SHOULD NOT immediatly fail the message but MAY employ other means to attempt verification including possibility of deriving possible Responsible Submitter based on other headers (i.e. PRA or some other algorithm). The results of the verification are to be reported using "Authentication-Results:" header as to be defined further and based on the draft-kucherawy-sender-auth-header-00.txt. If this header is present (and MUA believes it was added by known MTA entity), then MUA program SHOULD display the Submitted-By header and inform the end-user that it has been verified. Otherwise, MUAs programs MAY display the first found Submitted-By header but MUST then inform user that it has not been verified. -------------- This is a general summary. I believe it represents proposal that achieves the same goals as current SenderID (and partly based on it) but does not have the same technical issues and I believe does not have IPR issues. I note about IPR that the system makes PRA optional rather then required part of the implementation to be considered consistent with the standard. Some may still decide to implement PRA in their software and in this case would need to get license, but opensource programs would be able to be compliant if they implement checking based only on "Submitted-By:" or they may choose algorithm other then PRA for deriving possible Reponsible Submitter value. Please feel free to comment what you think of these ideas and of possibility of proceeding with this SUBMITTER scope in place of current PRA. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 10:50: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 KAA05649 for ; Mon, 13 Sep 2004 10:50: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 i8DEG8ab026135; Mon, 13 Sep 2004 07:16: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 i8DEG8jP026134; Mon, 13 Sep 2004 07:16:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp2g.bellsouth.com (aismtp2g.bellsouth.com [139.76.165.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DEG7IN026066 for ; Mon, 13 Sep 2004 07:16:07 -0700 (PDT) (envelope-from Damon.Sauer@bellsouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp2g.bellsouth.com with ESMTP; Mon, 13 Sep 2004 10:16:01 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: SPF abused by spammers X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Mon, 13 Sep 2004 09:15:48 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB90521D5B0@bremocog-55> Thread-Topic: SPF abused by spammers Thread-Index: AcSYUMJTxSpvJvXaQTqXwEkorn5QRgBST3Vg From: "Sauer, Damon" To: "Dean Anderson" , "Alan DeKok" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8DEG7IN026128 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > > "Douglas Otis" wrote: > > > A DNS check that obtains a list of addresses for a > mailbox-domain, > > > MUST assume channel integrity when holding the apparent > originator > > > of the message accountable. > > > > What channel? The only parties involved are: > > > > a) SMTP client > > b) SMTP server > > c) DNS server being queried > > I think he is refering to the channel referenced by > information theory (guessing by the previous reference to > Lampson's covert channel paper). This could refer to the > complete path through the communication system, or it could > refer to a single hop in a multihop system. > > Further, you've oversimplified the parties involved: > > The end user, > optionally a third party relay [one or more] > (because connection and mail services may be unbundled) > The mailbox provider (where responses will go) > The Mailbox provider nameservers > The recipient mail server [one or more] > The recipient nameservers > The chain of nameservers between the recipient, root, > and mailbox > provider. > > At any point spoofing could occur. This is true HOWEVER the only points at which this can be checked are between the two current MTA's and DNS. How can my MTA possibly see what the other MTA's are doing? buzzzzz > > Going back to my spam examination where you are examining a > spam message: Suppose the IP address in the received from > header no longer matches the SPF records: In this case you > don't know if your SPF check passed because DNS records were > spoofed, or if the real DNS records were changed. All > you know is that you got a spam from a certain IP address. > You don't know > whether it was forged or not. This is why the delay time is there. (28 days?) If it is no longer there, then it *MUST* fail. > > Suppose the IP address in the received header does match the > SPF records. > You don't know if the abuser signed up for an account with > that domain, or > if they got an infected machine under that domain. You don't > know whether > the nameserver was cracked, and incorrect records added. Most > people can't > tell the difference between a poisoned DNS cache and whether > the records > really come from an authoritative nameserver or even figure > out where they > got the DNS record from. So, similarly, all you really know > is that you > got a spam from a certain IP address. Again, in this case it *MUST* fail > > In both cases, all that can be done is report the incident to > the operator > of the domain and the operator of the IP address. And that's > all that can > be done now. THERE IS NO CHANGE. > > SPF doesn't prevent email forgery, nor even indicate whether > forgery happened. It is only being used to authenticate the IP of the the sending MTA. > > > The DNS server may return one, or a billion IP's > "permitted" to send > > MAIL FROM with it's name. Any particular message may have > traversed > > zero, or a billion intermediate SMTP hops before arriving at the > > current SMTP client, and being sent to the SMTP server. > > > > I fail to see how any party other than the three listed > above could > > possibly be involved in "MAIL FROM" DNS checks. There is > no "channel" > > beyond the current hop, which can be verified to exist. > > The current hop cannot be "verified to exist" beyond the TCP sequence > numbers. There is no way to tell that the mail isn't forged. Even if > email comes from a certain server, there is still no way to > tell that the > mail isn't forged. @aol.com coming from an AOL > mailserver doesn't > mean that it really came from Spammers can get > accounts at AOL. > Spammers can steal accounts at AOL by a number of vectors > such as viruses. This would be AOL's problem. And considering AOL's propensity to sue spammers on it's network, I would love to see them try. > > And what's more, from outside of AOL we can't be sure that > AOL isn't pink-contracting with spammers. > > The notion of "spam-herding" is just so much wishful thinking. > "Spam-Herding" is my term and I believe that it will do exactly that. If you are concerned about 'pink' contracts, then the spammers will be herded to those. It will eventually become a matter of economics as pressure is brought to bear on the otherwise legitimate IPS that may be providing 'pink' contracts. Spam is not socially acceptable. It is likely hated as much as paying taxes if not more. Social engineering WILL take place with SPF fully deployed. The spam will be herded. Regards, Damon Sauer "Putting my bee suit on" ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 11:04: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 LAA06817 for ; Mon, 13 Sep 2004 11:04: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 i8DEZY48027754; Mon, 13 Sep 2004 07:35:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DEZYNt027753; Mon, 13 Sep 2004 07:35:34 -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 i8DEZXAp027732 for ; Mon, 13 Sep 2004 07:35:33 -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 3F3FB17111 for ; Mon, 13 Sep 2004 10:44:47 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Sun, 12 Sep 2004 21:48:37 PDT." <587418158.20040912214837@brandenburg.com> Date: Mon, 13 Sep 2004 10:44:47 -0400 Message-Id: <20040913144447.3F3FB17111@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > However the fact that mail transits multiple MTAs is hardly remarkable > insight. It has been the nature of networked email for more than 25 > years, so it's not clear what prompts your particular question. My focus in this thread has been MAIL FROM authentication via records in DNS. Could you explain how multi-hop transit affects the current scope of an SMTP server performing such authentication? a) one of the hops fails to forward the message, in which case the current hop doesn't exist. b) all of the hops forward the message, in which case none of that information is visible in MAIL FROM. e.g. an SMTP server sees "MAIL FROM: user@example.com". I have no idea how that server could use that data to determine that any previous hops existed. Therefore, for the purposes of MAIL FROM authentication via records in DNS, those previous hops do not exist. Can you, or Doug explain how the previous hops are relevant to MAIL FROM authentication via records in DNS? While I understand Doug is trying, all I've gleaned from his responses have been that "mail is multi-hop". This may be an attempt to say "a message must pass all MAIL FROM checks in all hops", but I haven't seen that stated anywhere, as it seems fairly obvious. > Actually, the fact that a mailfrom authentication is being performed an > arbitrary number of MTA hops away from the mailfrom's creation is > extremely relevant to the technical basis and administrative complexity > of maintain DNS information needed to achieve that authentication. I agree, but that's an issue for the sender, not for the recipient. There are multiple scopes involved. Each party has it's own scope; it's own narrow vision of the net. So far in this thread, I have focussed on the scope of the recipient. In that scope, none of the previous hops exist, because they cannot be verified to exist. > Correct. If all the information lines up correctly, you know something > useful. If, however, the information is missing or does not line up, > then it is not at all clear you know anything. I'm not sure what "line up correctly" means. Most of these checks have only negative value. A "pass" gives you little information. A "fail" gives you more. > Given the aggregate cost of Internet standards, it is useful to worry a > great deal about the technical, administrative, and operational > complexity of a proposal. I pretentiously call this it's "physics", in > the hope that folks will worry a bit about system dynamics. http://adsabs.harvard.edu/cgi-bin/nph-bib_query?2000NIMPA.449..172B Nuclear Instruments and Methods in Physics Research Section A, Volume 449, Issue 1-2, p. 172-207. I am not unfamiliar with such concepts. My training is in modelling, simulation, and development of large systems. The methods learned in that training are directly applicable to most systems, though I'm having difficulty applying them here. > There is a tendency to focus only on very localized aspects of a > design. Because they are simpler than trying to understand the system as a whole. And if we don't understand the local aspects of a design, we have very little hope of understanding the system. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 11:11: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 LAA07749 for ; Mon, 13 Sep 2004 11:11: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 i8DEjDY3028373; Mon, 13 Sep 2004 07:45:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DEjDks028372; Mon, 13 Sep 2004 07:45:13 -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 i8DEjC02028366 for ; Mon, 13 Sep 2004 07:45:13 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 93FA926C085; Mon, 13 Sep 2004 16:45:14 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id E631E26C07D; Mon, 13 Sep 2004 16:45:12 +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 i8DEjCm7609347; Mon, 13 Sep 2004 16:45:12 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id B91EEFACE; Mon, 13 Sep 2004 16:45:12 +0200 (CEST) Date: Mon, 13 Sep 2004 16:45:12 +0200 From: Stephane Bortzmeyer To: "william(at)elan.net" Cc: ietf-mxcomp@imc.org Subject: Re: Request discussion about using SUBMITTER (together with new Submitted-By RFC 2822 header) as basis for futher work Message-ID: <20040913144512.GA24029@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 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 Mon, Sep 13, 2004 at 06:38:39AM -0700, william(at)elan.net wrote a message of 76 lines which said: > I request formal discussion on possibility of replacing current > SenderID/PRA proposal with one that is based primarily on the > extended Submitter draft with additional extension that would > involve new Submitted-By RFC2822 header. I agree with the idea but, to be sure we understand each other, may I add some details? Tell me if I am on the right track. > If there was reintroduction of email (such as mail list or > forwarder), then this mail list of forwarder is such responsible > party and it is supposed to add Submitted-By header (it may also add > Resent-From or Sender headers if appropriate just like they do now) Do note that, in the pure forwarding case (use of Unix .forward), no header is added by sendmail and a custom header is added by Postfix (unlike what -core says in 7.2). Seeing the discussions about "forwarding" (a very loose word here and not really clearer in RFC 2822), it would be better to specify it. > For verification of email by means of SPF protocol, the SUBMITTER > scope would be used and clients that support it would be required to > base their decision based on either SUBMITTER parameter of MAIL or > based on the Submitted-By header if is top-most header in the > email. If it is not top-most header, then client SHOULD find the > first Submitted-By header First in message order, meaning last in time order. > and attempt to verify that. If it passes, > everything is good, Do not forget that the client MUST check that SUBMITTER agrees with Submitted-by. > The results of the verification are to be reported using > "Authentication-Results:" header as to be defined further and based > on the draft-kucherawy-sender-auth-header-00.txt. If this header is > present (and MUA believes it was added by known MTA entity), then > MUA program SHOULD display the Submitted-By header and inform the > end-user that it has been verified. Otherwise, MUAs programs MAY > display the first found Submitted-By header but MUST then inform > user that it has not been verified. The MUA MAY does its own SenderID check on the submitted-By header it found. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 11:52: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 LAA10799 for ; Mon, 13 Sep 2004 11:52: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 i8DFMFwr032770; Mon, 13 Sep 2004 08:22:15 -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 i8DFMFvL032769; Mon, 13 Sep 2004 08:22:15 -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 i8DFMEAg032763 for ; Mon, 13 Sep 2004 08:22:14 -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 i8DFXkZa002923; Mon, 13 Sep 2004 08:33:46 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8DFXjj3002920; Mon, 13 Sep 2004 08:33:45 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Sep 2004 08:33:45 -0700 (PDT) From: "william(at)elan.net" To: Stephane Bortzmeyer cc: ietf-mxcomp@imc.org Subject: Re: Request discussion about using SUBMITTER (together with new Submitted-By RFC 2822 header) as basis for futher work In-Reply-To: <20040913144512.GA24029@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 Mon, 13 Sep 2004, Stephane Bortzmeyer wrote: > On Mon, Sep 13, 2004 at 06:38:39AM -0700, > william(at)elan.net wrote > a message of 76 lines which said: > > > I request formal discussion on possibility of replacing current > > SenderID/PRA proposal with one that is based primarily on the > > extended Submitter draft with additional extension that would > > involve new Submitted-By RFC2822 header. > > I agree with the idea but, to be sure we understand each other, may I > add some details? Tell me if I am on the right track. Ok. > > If there was reintroduction of email (such as mail list or > > forwarder), then this mail list of forwarder is such responsible > > party and it is supposed to add Submitted-By header (it may also add > > Resent-From or Sender headers if appropriate just like they do now) > > Do note that, in the pure forwarding case (use of Unix .forward), no > header is added by sendmail and a custom header is added by Postfix > (unlike what -core says in 7.2). Seeing the discussions about > "forwarding" (a very loose word here and not really clearer in RFC > 2822), it would be better to specify it. It is difficult to write good description of what forwarding is (part of what is there I already posted when quiting 2822 yesterday). But I do think it is intent of this WG to specify case of forwarding in its documents. In fact core draft does it already in section 7.2 and submitter draft provides example of forwarding. It is most likely that section from core draft would have to be moved and modified to be in submitter draft (in addition to example that will also stay). Perhaps case of forwarding with .forward can be mentioned separately too or possibly an example added for that. > > For verification of email by means of SPF protocol, the SUBMITTER > > scope would be used and clients that support it would be required to > > base their decision based on either SUBMITTER parameter of MAIL or > > based on the Submitted-By header if is top-most header in the > > email. If it is not top-most header, then client SHOULD find the > > first Submitted-By header > > First in message order, meaning last in time order. Correct. > > and attempt to verify that. If it passes, > > everything is good, > > Do not forget that the client MUST check that SUBMITTER agrees with > Submitted-by. Yes. Like with current SUBMITTER draft, at the end after data is received, the MTA must also double-check that SUBMITTER MAIL parameter value corresponds properly with RFC2822 headers, i.e. that first Submitted-By header in email is the same. > > The results of the verification are to be reported using > > "Authentication-Results:" header as to be defined further and based > > on the draft-kucherawy-sender-auth-header-00.txt. If this header is > > present (and MUA believes it was added by known MTA entity), then > > MUA program SHOULD display the Submitted-By header and inform the > > end-user that it has been verified. Otherwise, MUAs programs MAY > > display the first found Submitted-By header but MUST then inform > > user that it has not been verified. > > The MUA MAY does its own SenderID check on the submitted-By header it > found. The problem is that MUA does not know for certain ip address of SMTP client that it needs to authorize. It must rely on the Received headers for that and they maybe forged along with submitted-by. So I would be very carefull on MUA doing this kind of verification and if it is mentioned, a separate security section about possibility of special type of forging that could pass MUA vericiation must also be present. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 11: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 LAA11444 for ; Mon, 13 Sep 2004 11:59: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 i8DFZ7JP034533; Mon, 13 Sep 2004 08:35: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 i8DFZ7pc034532; Mon, 13 Sep 2004 08:35:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DFZ6k2034526 for ; Mon, 13 Sep 2004 08:35:07 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:33016) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C6sr7-0007tD-Bv (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 16:35:01 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C6sr2-0001OB-P2; Mon, 13 Sep 2004 16:34:56 +0100 Date: Mon, 13 Sep 2004 16:34:56 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040913144447.3F3FB17111@mail.nitros9.org> Message-ID: References: <20040913144447.3F3FB17111@mail.nitros9.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 13 Sep 2004, Alan DeKok wrote: > > e.g. an SMTP server sees "MAIL FROM: user@example.com". > > I have no idea how that server could use that data to determine that > any previous hops existed. Therefore, for the purposes of MAIL FROM > authentication via records in DNS, those previous hops do not exist. > > Can you, or Doug explain how the previous hops are relevant to MAIL > FROM authentication via records in DNS? While I understand Doug is > trying, all I've gleaned from his responses have been that "mail is > multi-hop". This may be an attempt to say "a message must pass all > MAIL FROM checks in all hops", but I haven't seen that stated > anywhere, as it seems fairly obvious. What Doug means is that email can legitimately come to my servers from an IP address that is not anticipated by example.com because there was an extra hop in its journey: user@example.com sent the message to recipient@alumni.example.edu which forwarded it to recipient@example.cam.ac.uk. Therefore example.com can't correctly say that my servers will only receive email with an example.com bounce address from their outgoing email servers, because as you say I have no way of knowing about the message's previous hops, and example.com has no way of knowing about recipients' forwarding arrangements. I cannot work around this problem: I have no reasonable way of knowing that this forwarding relationship exists, or if I do know about it I have no reasonable way of maintaining a list of example.edu's outgoing email servers in order to whitelist them. Tony. -- f.a.n.finch http://dotat.at/ NORTH FITZROY SOLE LUNDY FASTNET IRISH SEA: WEST OR SOUTHWEST 6 TO GALE 8, PERHAPS SEVERE GALE 9, VEERING NORTHWEST 5 TO 7. SHOWERS. MAINLY GOOD. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 12:15: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 MAA13493 for ; Mon, 13 Sep 2004 12:15: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 i8DFj6lg035469; Mon, 13 Sep 2004 08:45: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 i8DFj6aL035468; Mon, 13 Sep 2004 08:45:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DFj5gh035462 for ; Mon, 13 Sep 2004 08:45:06 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8DFhiSh032618 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 13 Sep 2004 11:43:54 -0400 Date: Mon, 13 Sep 2004 11:43:44 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Peter Bowyer cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <0cb001c49950$22c3fec0$0a46a8c0@pbdesktop> 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, 13 Sep 2004, Peter Bowyer wrote: > > Dean Anderson wrote: > > On Sun, 12 Sep 2004, Peter Bowyer wrote: > > > >> > >> But AOL won't have spammers on their whitelist. The only domains for > >> which an SPF Pass means less filtering are those which are > >> pre-whitelisted. And SPF will ensure that mail which appears to be > >> from those domains isn't forged. > > > > This is a false assumption. Any domain that is whitelisted will > > attract spammers to that domain. There is no domain or ISP that can > > claim not to have spammers ever. > > They don't whitelist ISP domains - only responsible bulk email senders. > People whose mail you want your users to receive. Yes, such as MSN. > > Whether you use SPF as the reduced testing mechanism or some other > > mechanism is irrelevant. The 'bad thing' is to ever subject some mail > > to less filtering. > > Wrong. You submit mail which you've already determined as 'truested' by your > own reputation mechanism. This "trust" is a false assumption. MSN doesn't know whether a particular message is spam, until it gets a complaint. It doesn't know whether a computer is virus infected until it gets a complaint. It can't certify that it doesn't have spammers or virus infections or worms or etc. No one can. If MSN and AOL make that assertion, and that assertion is accepted by others, this fact alone will make MSN a target for spammers, viruses, worms, etc. This is why reduced filtering promotes more spam. > > What's your problem with this? It's using SPF for exactly what it was > >> intended, and the fact that spammers publish SPF will have no effect > >> on it at all. > > > SPF has no effect on anything except to interfere with legitimate > > email unbundling. SPF allows MSN and AOL to conspire to prevent email > > outsourciing, or to charge the outsourcers for the "privelege" of > > having an SPF record, or to interfere with such outsourced email by > > having unreliable nameservice for the outsourced SPF records. In > > exchange, SPF has no impact on spam, whatsoever. Thats my problem > > with SPF. > > Well, you're entitled to your view, but your appreciation of the facts in > the case of AOL is clearly inaccurate. And please remember that SPF is an > authentication framework, not an anti-spam tool. Likewise, you're entitled to your view, and we may have to agree to disagree. But besides your false assumptions of trust, you don't seem to appreciate the fact that DNS cannot be used for an authentication framework because it is so trivially and easilly spoofed. We learned the vulnerability way, way back with the Morris worm and the BSD R-command exploits. --Dean From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 12:31:40 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 MAA14570 for ; Mon, 13 Sep 2004 12:31: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 i8DG45TR037477; Mon, 13 Sep 2004 09:04: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 i8DG456O037469; Mon, 13 Sep 2004 09:04:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DG43QC037449 for ; Mon, 13 Sep 2004 09:04:03 -0700 (PDT) (envelope-from peeebeee@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so257737rnl for ; Mon, 13 Sep 2004 09:02:48 -0700 (PDT) Received: by 10.38.67.22 with SMTP id p22mr219453rna; Mon, 13 Sep 2004 09:02:47 -0700 (PDT) Received: by 10.38.72.24 with HTTP; Mon, 13 Sep 2004 09:02:47 -0700 (PDT) Message-ID: <56152ae904091309021b274cf3@mail.gmail.com> Date: Mon, 13 Sep 2004 17:02:47 +0100 From: Peter Bowyer Reply-To: peter@bowyer.org To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <0cb001c49950$22c3fec0$0a46a8c0@pbdesktop> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 13 Sep 2004 11:43:44 -0400 (EDT), Dean Anderson wrote: > On Mon, 13 Sep 2004, Peter Bowyer wrote: > > > > > Dean Anderson wrote: > > > On Sun, 12 Sep 2004, Peter Bowyer wrote: > > > > > >> > > >> But AOL won't have spammers on their whitelist. The only domains for > > >> which an SPF Pass means less filtering are those which are > > >> pre-whitelisted. And SPF will ensure that mail which appears to be > > >> from those domains isn't forged. > > > > > > This is a false assumption. Any domain that is whitelisted will > > > attract spammers to that domain. There is no domain or ISP that can > > > claim not to have spammers ever. > > > > They don't whitelist ISP domains - only responsible bulk email senders. > > People whose mail you want your users to receive. > > Yes, such as MSN. If they have whitelisted MSN, it will be because they want to receive mail which is verifiably from MSN. It's not a choice I would make myself, but their network - their rules. SPF has helped them with the verification. > This "trust" is a false assumption. MSN doesn't know whether a particular > message is spam, until it gets a complaint. It doesn't know whether a > computer is virus infected until it gets a complaint. It can't certify > that it doesn't have spammers or virus infections or worms or etc. No one > can. True - but that's the basis of all reputation mechanisms - there's no absolute authority to refer to, you decide whose opinion you trust. If AOL trusts MSN, that's their business. > If MSN and AOL make that assertion, and that assertion is accepted by > others, this fact alone will make MSN a target for spammers, viruses, > worms, etc. This is why reduced filtering promotes more spam. But AOL's whitelist is for their own consumption, not for others to rely on. I wouldn't choose to trust AOL's view of what mail to trust for a whole variety of reasons. To be fair, I don't believe they're suggesting that anyone should - its reason for existence is to help AOL themselves to accept email from sources they themselves trust. What process they go through to establish that trust is their business - might be a respected validation service, might be a suitcase full of used notes - that's up to them. > > > Well, you're entitled to your view, but your appreciation of the facts in > > the case of AOL is clearly inaccurate. And please remember that SPF is an > > authentication framework, not an anti-spam tool. > > Likewise, you're entitled to your view, and we may have to agree to > disagree. But besides your false assumptions of trust, you don't seem to > appreciate the fact that DNS cannot be used for an authentication > framework because it is so trivially and easilly spoofed. We learned the > vulnerability way, way back with the Morris worm and the BSD R-command > exploits. Yes, I agree there - but DNS spoofing is sufficiently rare and hard for the average email forger to do that a mechanism relying on DNS will have a tiny probability of being subject to forgery in the real world. Peter From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 12:48: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 LAA11445 for ; Mon, 13 Sep 2004 11:59: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 i8DFQwLh033669; Mon, 13 Sep 2004 08:26: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 i8DFQvfT033668; Mon, 13 Sep 2004 08:26:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DFQvDH033654 for ; Mon, 13 Sep 2004 08:26:57 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8DFQPVl032332 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 13 Sep 2004 11:26:27 -0400 Date: Mon, 13 Sep 2004 11:26:25 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Sauer, Damon" cc: Alan DeKok , Subject: RE: SPF abused by spammers In-Reply-To: <38363D9940D92A458010AAE24D162EB90521D5B0@bremocog-55> 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, 13 Sep 2004, Sauer, Damon wrote: > > The end user, > > optionally a third party relay [one or more] > > (because connection and mail services may be unbundled) > > The mailbox provider (where responses will go) > > The Mailbox provider nameservers > > The recipient mail server [one or more] > > The recipient nameservers > > The chain of nameservers between the recipient, root, > > and mailbox > > provider. > > > > At any point spoofing could occur. > > This is true HOWEVER the only points at which this can be checked are > between the two current MTA's and DNS. How can my MTA possibly see what > the other MTA's are doing? buzzzzz Exactly. You can't ever know that a message isn't forged. People wrongly think that SPF prevents forgery. > > Going back to my spam examination where you are examining a > > spam message: Suppose the IP address in the received from > > header no longer matches the SPF records: In this case you > > don't know if your SPF check passed because DNS records were > > spoofed, or if the real DNS records were changed. All > > you know is that you got a spam from a certain IP address. > > You don't know > > whether it was forged or not. > > This is why the delay time is there. (28 days?) If it is no longer > there, then it *MUST* fail. Delay time? *MUST* fail??? What are you talking about? > > Suppose the IP address in the received header does match the SPF > > records. You don't know if the abuser signed up for an account with > > that domain, or if they got an infected machine under that domain. > > You don't know whether the nameserver was cracked, and incorrect > > records added. Most people can't tell the difference between a > > poisoned DNS cache and whether the records really come from an > > authoritative nameserver or even figure out where they got the DNS > > record from. So, similarly, all you really know is that you got a > > spam from a certain IP address. > > Again, in this case it *MUST* fail Why would it fail if it the SPF "check" succeeds? Or is this just another case of blind faith? Yes, it *must* fail if SPF is to work. Except that it doesn't fail, and as a result SPF doesn't work. > > In both cases, all that can be done is report the incident to the > > operator of the domain and the operator of the IP address. And that's > > all that can be done now. THERE IS NO CHANGE. > > > > SPF doesn't prevent email forgery, nor even indicate whether > > forgery happened. > > It is only being used to authenticate the IP of the the sending MTA. Which proves nothing about the message. > > > The DNS server may return one, or a billion IP's "permitted" to > > > send MAIL FROM with it's name. Any particular message may have > > > traversed zero, or a billion intermediate SMTP hops before arriving > > > at the current SMTP client, and being sent to the SMTP server. > > > > > > I fail to see how any party other than the three listed above > > > could possibly be involved in "MAIL FROM" DNS checks. There is no > > > "channel" beyond the current hop, which can be verified to exist. > > > > The current hop cannot be "verified to exist" beyond the TCP sequence > > numbers. There is no way to tell that the mail isn't forged. Even if > > email comes from a certain server, there is still no way to tell that > > the mail isn't forged. @aol.com coming from an AOL mailserver > > doesn't mean that it really came from Spammers can get accounts > > at AOL. Spammers can steal accounts at AOL by a number of vectors > > such as viruses. > > This would be AOL's problem. And considering AOL's propensity to sue > spammers on it's network, I would love to see them try. They already do this. Every day. You seem to be saying that AOL sends no spam, and has no spammers, no viruses, no stolen accounts??? > > And what's more, from outside of AOL we can't be sure that AOL isn't > > pink-contracting with spammers. > > > > The notion of "spam-herding" is just so much wishful thinking. > > > > "Spam-Herding" is my term and I believe that it will do exactly that. If > you are concerned about 'pink' contracts, then the spammers will be > herded to those. It will eventually become a matter of economics as > pressure is brought to bear on the otherwise legitimate IPS that may be > providing 'pink' contracts. Spam is not socially acceptable. It is > likely hated as much as paying taxes if not more. Social engineering > WILL take place with SPF fully deployed. The spam will be herded. I note that you wrote this notion as an admin for Bell South. Has Bell South been able to clean spammers out of Bell South? Or clean virus infections out of Bell South? Or make it impossible for Bell South users to get viruses, worms, etc? Or do they just whack them as the find them? Or is this just another "blind faith" that you //think// will happen? If you've found some special immunity from spammers/viruses/worms, then I think you should share that. //That// would be far more valuable than SPF. If we could prevent spammers/viruses/worms then we wouldn't need anti-spam tools at all. --Dean From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 13:00:09 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 NAA16541 for ; Mon, 13 Sep 2004 13:00:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DGToQm039943; Mon, 13 Sep 2004 09:29:50 -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 i8DGTouF039942; Mon, 13 Sep 2004 09:29:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp1g.bellsouth.com (aismtp1g.bellsouth.com [139.76.165.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DGTnB8039923 for ; Mon, 13 Sep 2004 09:29:49 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp1g.bellsouth.com with ESMTP; Mon, 13 Sep 2004 12:29:41 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: SPF abused by spammers X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Mon, 13 Sep 2004 11:29:16 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB90521D705@bremocog-55> Thread-Topic: SPF abused by spammers Thread-Index: AcSZpmvXQy/kVRfTSDK0V7xWDGSjfgAAoJAA From: "Sauer, Damon" To: "Dean Anderson" Cc: "Alan DeKok" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8DGToB8039937 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [snip] > > > > Going back to my spam examination where you are examining a > > > spam message: Suppose the IP address in the received from > > > header no longer matches the SPF records: In this case you > > > don't know if your SPF check passed because DNS records were > > > spoofed, or if the real DNS records were changed. All > > > you know is that you got a spam from a certain IP address. > > > You don't know > > > whether it was forged or not. > > > > This is why the delay time is there. (28 days?) If it is no longer > > there, then it *MUST* fail. > > Delay time? > *MUST* fail??? > > What are you talking about? I apologize. I was actually thinking about something else when I wrote that. Don't know how I missed it in my re-read. So here is the answer I meant to give. So the IP address changes- So does the SPF record. The two should not be out of sync. This is an administrative issue. > > > > Suppose the IP address in the received header does match the SPF > > > records. You don't know if the abuser signed up for an > account with > > > that domain, or if they got an infected machine under that domain. > > > You don't know whether the nameserver was cracked, and incorrect > > > records added. Most people can't tell the difference between a > > > poisoned DNS cache and whether the records really come from an > > > authoritative nameserver or even figure out where they got the DNS > > > record from. So, similarly, all you really know is that you got a > > > spam from a certain IP address. > > > > Again, in this case it *MUST* fail > > Why would it fail if it the SPF "check" succeeds? > > Or is this just another case of blind faith? Yes, it *must* > fail if SPF is > to work. Except that it doesn't fail, and as a result SPF > doesn't work. That is not at ALL what it means. What it means is: It failed. It must and will fail. Just because the SPF record belongs to a spammer and the SPF check doesn't fail DOES NOT mean that SPF failed. It means it SUCCEEDED. [snip] > They already do this. Every day. You seem to be saying that > AOL sends no spam, and has no spammers, no viruses, no stolen > accounts??? > This is a very low percentage of spam and killable using other methods. > I note that you wrote this notion as an admin for Bell South. > Has Bell South been able to clean spammers out of Bell > South? Or clean virus infections out of Bell South? Or make > it impossible for Bell South users to get viruses, worms, > etc? Or do they just whack them as the find them? > Or is this just another "blind faith" that you //think// will happen? > > If you've found some special immunity from > spammers/viruses/worms, then I > think you should share that. //That// would be far more > valuable than SPF. > If we could prevent spammers/viruses/worms then we wouldn't > need anti-spam > tools at all. My opinions in this discussion group have always been, and always will be, my own. I delete my 'official' signature before I send any email to this group. If I wished to make an 'official' comment, it would be marked as such. Most people here know who I am and what I do. This lends itself to my credibility in a technical discussion, as I have direct, volumetric, and personal experience in direct relation to the issues. I hope you will understand why I believe the above is completely inappropriate and request that my employer not be brought into the discussion. Regards, Damon Sauer ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 13:25: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 NAA18302 for ; Mon, 13 Sep 2004 13:25: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 i8DGtgn0042353; Mon, 13 Sep 2004 09:55:42 -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 i8DGtgaw042352; Mon, 13 Sep 2004 09:55:42 -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 i8DGtf15042343 for ; Mon, 13 Sep 2004 09:55:41 -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 0AB1E16CD2; Mon, 13 Sep 2004 13:04:58 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Mon, 13 Sep 2004 16:34:56 BST." Cc: Tony Finch Date: Mon, 13 Sep 2004 13:04:57 -0400 Message-Id: <20040913170458.0AB1E16CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tony Finch wrote: > What Doug means is that email can legitimately come to my servers from > an IP address that is not anticipated by example.com because there was an > extra hop in its journey: I understand, but that doesn't affect the SMTP server which performs that validation. The multi-hop problem can be re-phrased as "any message must pass all checks at all intermediate hops for it to reach the final destination." This restriction is nothing new to SMTP. The specific technique of authentication records in DNS is new. > I cannot work around this problem: I have no reasonable way of knowing > that this forwarding relationship exists, or if I do know about it I have > no reasonable way of maintaining a list of example.edu's outgoing email > servers in order to whitelist them. And I don't see why (in the idealogical sense) this would be your problem. If other sites are forwarding your users messages, then that's a matter between them and the users. You shouldn't have to be involved. Practically, the practice is common, and people resist mightily changing their habits. We have to decide if the gain to some from performing MTA authentication is worth the cost to others. The people paying the cost naturally don't want to do so. That's what this WG is about. Maybe there is an alternate implementation where you don't have to pay the cost. We should find it, if possible. If not, I don't see why your need to have forwarding for your users should have any impact on my need to do what I want with my domain. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 13:31: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 NAA18781 for ; Mon, 13 Sep 2004 13:31: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 i8DH27cV042994; Mon, 13 Sep 2004 10:02:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DH276p042993; Mon, 13 Sep 2004 10:02:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DH260C042985 for ; Mon, 13 Sep 2004 10:02:06 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49796) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1C6uDM-0002kL-NJ (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 18:02:04 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C6uCz-0001ov-T7; Mon, 13 Sep 2004 18:01:41 +0100 Date: Mon, 13 Sep 2004 18:01:41 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040913170458.0AB1E16CD2@mail.nitros9.org> Message-ID: References: <20040913170458.0AB1E16CD2@mail.nitros9.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 13 Sep 2004, Alan DeKok wrote: > > And I don't see why (in the idealogical sense) this would be your > problem. If other sites are forwarding your users messages, then > that's a matter between them and the users. You shouldn't have to be > involved. If I naively start checking SPF records I will get involved because my users will kick up a fuss about their legitimate email being rejected. > If not, I don't see why your need to have forwarding for your users > should have any impact on my need to do what I want with my domain. I'll feel free to ignore your bogus SPF policy then. Tony. -- f.a.n.finch http://dotat.at/ WHITBY TO THE WASH: SOUTHWEST 5 TO 7. SHOWERS. GOOD. SLIGHT OR MODERATE. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 13:50:49 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 NAA20448 for ; Mon, 13 Sep 2004 13:50:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DHKluF044780; Mon, 13 Sep 2004 10:20:47 -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 i8DHKlN3044779; Mon, 13 Sep 2004 10:20:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DHKkZ1044771 for ; Mon, 13 Sep 2004 10:20:47 -0700 (PDT) (envelope-from csm@redhat.com) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8DHKliY020759 for ; Mon, 13 Sep 2004 13:20:47 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8DHKgr26349 for ; Mon, 13 Sep 2004 13:20:42 -0400 Received: from redhat.com (vpn50-55.rdu.redhat.com [172.16.50.55]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i8DHKgNp016710 for ; Mon, 13 Sep 2004 13:20:42 -0400 Message-ID: <4145D6DD.9030107@redhat.com> Date: Mon, 13 Sep 2004 13:20:29 -0400 From: Chuck Mead Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <4143590C.2030907@MoonGroup.com> In-Reply-To: <4143590C.2030907@MoonGroup.com> X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Mead wrote: | | Andrew Newton wrote: | | | 3) On the issue of ignoring patent claims, the working group has at | | least rough consensus that the patent claims should not be ignored. | | Additionally, there is at least rough consensus that the participants of | | the working group cannot accurately describe the specific claims of the | | patent application. This stems from the fact that the patent application | | is not publicly available. Given this, it is the opinion of the | | co-chairs that MARID should not undertake work on alternate algorithms | | reasonably thought to be covered by the patent application. We do feel | | that future changes regarding the patent claim or its associated license | | could significantly change the consensus of the working group, and at | | such a time it would be appropriate to consider new work of this type. | | I have to ask because it appears to me that you have left this somewhat | nebulous. | | Does this mean that the PRA (with it's encumbrance) is being accepted as | a part of the MARID specification? It would be nice if the co-chairs would be willing to answer this question. Thanx. - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBRdbcZfy0juH51WsRAn+GAKCe16YmfO8o6yxwdu0DGAyyLkihIwCfXXcA 45Bak/B635XY1XPNmHjJG10= =FWnJ -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 13:52: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 NAA20584 for ; Mon, 13 Sep 2004 13:52:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DHQVNS045301; Mon, 13 Sep 2004 10:26:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DHQVvU045300; Mon, 13 Sep 2004 10:26:31 -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 i8DHQVEQ045292 for ; Mon, 13 Sep 2004 10:26:31 -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 8FF5816CD2; Mon, 13 Sep 2004 13:35:50 -0400 (EDT) From: "Alan DeKok" To: Tony Finch Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Mon, 13 Sep 2004 18:01:41 BST." Cc: ietf-mxcomp@imc.org Date: Mon, 13 Sep 2004 13:35:50 -0400 Message-Id: <20040913173550.8FF5816CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tony Finch wrote: > If I naively start checking SPF records I will get involved because my > users will kick up a fuss about their legitimate email being rejected. Your users may think it's legitimate, but if it doesn't pass SPF checks, then the domain name they're using doesn't agree. Resolving that problem is an issue between those users, and the name of the domain they're using. > > If not, I don't see why your need to have forwarding for your users > > should have any impact on my need to do what I want with my domain. > > I'll feel free to ignore your bogus SPF policy then. Now you're getting personal. And I find it interesting that you admit you're not going to follow the policies that other domains publish. If this is true, I fail to see why you're active in this group, as any standard reached here will not be published, or checked, by you. It would also appear that you're opposed to the charter goals of this group, or at the least, not interested in them. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 14:18: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 NAA18780 for ; Mon, 13 Sep 2004 13:31: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 i8DH3DU5043143; Mon, 13 Sep 2004 10:03:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DH3DIE043142; Mon, 13 Sep 2004 10:03:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DH3DjC043136 for ; Mon, 13 Sep 2004 10:03:13 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 13 Sep 2004 10:03:16 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Sep 2004 10:03:16 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Sep 2004 10:03:15 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 10:03:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7399.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 Date: Mon, 13 Sep 2004 10:03:14 -0700 Message-ID: Thread-Topic: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 Thread-Index: AcSZoVqTDzm7T5liR+6taHP7viwm0QADhs9Q From: "Jim Lyon" To: Cc: "william\(at\)elan.net" , "Pete Resnick" X-OriginalArrivalTime: 13 Sep 2004 17:03:14.0820 (UTC) FILETIME=[8EDC1440:01C499B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8DH3DjC043137 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, September 13, 2004 at 1:47:32 AM. William Leibzon quotes RFC 2822 and argues that SenderID's use of Resent-From is inconsistent with RFC 2822. I disagree. RFC 2822 specifies Resent-From is not for "forwarding", in either of the following two senses: 1. Quoting from RFC 2822: One sense of forwarding is that a mail reading program can be told by a user to forward a copy of a message to another person, making the forwarded message the body of the new message. A forwarded message in this sense does not appear to have come from the original sender, but is an entirely new message from the forwarder of the message. This sense of "forwarding" is normally activated by a user pressing a "Forward" button in a UI (or similar action.) I completely agree that "Resent-From" has no place in this sense of forwarding. 2. Quoting from RFC 2822 again: On the other hand, forwarding is also used to mean when a mail transport program gets a message and forwards it on to a different destination for final delivery. I believe that what RFC 2822 refers to here as "forwarding" is what we today more commonly refer to as "relaying". That is, when an MTA merely accepts a message destined for a particular mailbox, and sends the message along to another MTA because the first MTA doesn't own the mailbox. The position that this sense of "forwarding" really means "relaying" is bolstered by the fact that RFC 2822 nowhere contains the words "relay" or "relaying". I completely agree with RFC 2822 that "Resent-From" has no place in this sense of forwarding. So, what's Resent-From for? It's for when a message arrives at the destination mailbox, and the owner of that mailbox gives instructions, either manually or automatically, that the message should instead or additionally be delivered to a different mailbox. A Unix ".forward" file is the canonical example of such automated instruction. It would probably be a good idea for Pete Resnick (editor of RFC 2822) to chime in on this interpretation. -- Jim Lyon Internet commerce will never really take off until you can buy something online without getting spammed by the vendor. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 14:21: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 OAA22921 for ; Mon, 13 Sep 2004 14:21: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 i8DHpSsE047118; Mon, 13 Sep 2004 10:51: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 i8DHpSLR047117; Mon, 13 Sep 2004 10:51:28 -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 i8DHpRrT047110 for ; Mon, 13 Sep 2004 10:51:28 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.254.82] (host66.209-113-184.oem.net [209.113.184.66]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i8DHpLIf025847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Sep 2004 13:51:28 -0400 Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1095097912.3377.11.camel@tuxtop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 13 Sep 2004 13:51:53 -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 Mon, 2004-09-13 at 13:03, Jim Lyon wrote: [snip] > So, what's Resent-From for? It's for when a message arrives at the > destination mailbox, and the owner of that mailbox gives instructions, > either manually or automatically, that the message should instead or > additionally be delivered to a different mailbox. A Unix ".forward" > file is the canonical example of such automated instruction. Well, if your going to use the Unix ".forward" file as a canonical example, then you should check what that does on a typical Unix box today (and historically). Frankly, that's an honest suggestion, because although I'm not too sure what they've done historically, I did just check it out on a Linux box of mine and sure enough, there are no Resent-* fields added whatsoever. In at least two places in section 3.6.6 of RFC2822, Resent-* fields are said to be used to identify a message as re-introduced *by a user* into the transport system. Furthermore, it also says this: "They MUST NOT be used in the normal processing of replies or other such automatic actions on messages." Which directly contradicts part of your interpretation above. It's not for 'manually or automatically' re-inserted messages, but only manually, given that the automatic re-insertion is excluded from using Resent-* fields according to the above line I've quoted from section 3.6.6 of RFC2822. > > It would probably be a good idea for Pete Resnick (editor of RFC 2822) > to chime in on this interpretation. Hmm, agreed. That would probably put an end to the discussion :-). -- -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 Mon Sep 13 14:54:17 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 OAA25600 for ; Mon, 13 Sep 2004 14:54:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DIOX9G051225; Mon, 13 Sep 2004 11:24:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DIOXZB051224; Mon, 13 Sep 2004 11:24:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DIOXR2051217 for ; Mon, 13 Sep 2004 11:24:33 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i8DIOYg11127; Mon, 13 Sep 2004 11:24:34 -0700 Date: Mon, 13 Sep 2004 11:24:30 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <361144888.20040913112430@brandenburg.com> To: Daniel Quinlan CC: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1542943013.20040912100612@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel, >> If client and server do no share at least one MUST, then there will be >> non-interoperability. DQ> Yes. It would also be nice if the world could avoid doing duplicate DNS DQ> queries for spf2 records. My concern is not about efficiency. It is about the fundamental ability to get any successful interoperability. If there is no core requirement for support of a particular record type, then there will be clients that support only one record type and servers that support only another. This means that the clients will not be able to access the information. The instant you talk about "duplicate queries" you are assuming that the client supports more than one type. The question is whether they are required to. That is, do they have a MUST for each type? DQ> so I hope DQ> that is addressed in the next revision of the specifications. One or DQ> the other forever or both with a pre-specified flag day in the DQ> not-too-distant future. For Internet-scale services there can be no such thing as a flag day. There is not central authority to assert it. Even if there were, there is no way to coordinate that scale of operation. Even centrally controlled companies cannot do flag-days for large-scale deployment changes. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 14:55: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 OAA25644 for ; Mon, 13 Sep 2004 14:55:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DILD7v051034; Mon, 13 Sep 2004 11:21:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DILDMn051033; Mon, 13 Sep 2004 11:21:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DILCZM051027 for ; Mon, 13 Sep 2004 11:21:12 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 13 Sep 2004 11:21:16 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Sep 2004 11:21:15 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Sep 2004 11:21:15 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 11:21:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7399.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders thatare not compatible with RFC 2822 Date: Mon, 13 Sep 2004 11:21:15 -0700 Message-ID: Thread-Topic: TECH-ERROR: SenderID sets recomendation for forwarders thatare not compatible with RFC 2822 Thread-Index: AcSZvEJa6ZFidvMnQNKT/ay7wn591wAAGzkw From: "Jim Lyon" To: "Paul Iadonisi" , X-OriginalArrivalTime: 13 Sep 2004 18:21:14.0810 (UTC) FILETIME=[7459E1A0:01C499BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8DILCZM051028 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, September 13, 2004, at 10:52 AM, Paul Iadonisi wrote: -- Jim Lyon mailto:JimLyon@Microsoft.Com tel:+1-425-706-0867 Internet commerce will never really take off until you can buy something online without getting spammed by the vendor. -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Paul Iadonisi Sent: Monday, September 13, 2004 10:52 AM To: ietf-mxcomp@imc.org Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders thatare not compatible with RFC 2822 > It [Resent-From] is not for 'manually or automatically' > re-inserted messages, but only manually, given that the > automatic re-insertion is excluded from using Resent-* > fields according to the above line I've quoted from > section 3.6.6 of RFC2822. I think the bright-line test to decide whether Resent-From is appropriate is: Is the action occurring at the desire of the mailbox owner, or is it occurring at the desire of the mail infrastructure owner? Otherwise, using the reading that you propose yields an absurd and unimplementable result: If my MUA has a "Resend" command, and I manually execute it, there should be a "Resent-From". But if an automated script executes my MUA's "Resend" command, there shouldn't be a "Resent-From". This appears nonsensical on its face, so an alternate interpretation is required. (It also begs the question of whether my secretary pressing the button constitutes "manual" or "automatic", when he's doing so under my standing orders with no discretion.) You need to read specs like a lawyer, not like a programmer. (Programmer: if the spec says "jump", I'll jump and damn the consequences. Lawyer: if the spec says "jump" and that's either ambiguous or nonsensical, I'll look beyond the words to the intended meaning.) Admittedly, the best specs are ones that yield the same result to both programmers and lawyers. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 15:02: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 PAA26188 for ; Mon, 13 Sep 2004 15:02: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 i8DIUrIr051677; Mon, 13 Sep 2004 11:30: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 i8DIUrA4051676; Mon, 13 Sep 2004 11:30:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DIUqkg051670 for ; Mon, 13 Sep 2004 11:30:52 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8DIUo56003314 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 13 Sep 2004 14:30:51 -0400 Date: Mon, 13 Sep 2004 14:30:50 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Sauer, Damon" cc: Alan DeKok , Subject: RE: SPF abused by spammers In-Reply-To: <38363D9940D92A458010AAE24D162EB90521D705@bremocog-55> 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, 13 Sep 2004, Sauer, Damon wrote: > [snip] > > > > > > Going back to my spam examination where you are examining a spam > > > > message: Suppose the IP address in the received from header no > > > > longer matches the SPF records: In this case you don't know if > > > > your SPF check passed because DNS records were spoofed, or if the > > > > real DNS records were changed. All you know is that you got a > > > > spam from a certain IP address. You don't know whether it was > > > > forged or not. > > So the IP address changes- So does the SPF record. The two should not be > out of sync. This is an administrative issue. I don't think you read my message. I'm analyzing the case where they are either out of sync (above) and in sync (below). In either case, you cannot make any decision based on SPF records. > > > > Suppose the IP address in the received header does match the SPF > > > > records. You don't know if the abuser signed up for an account > > > > with that domain, or if they got an infected machine under that > > > > domain. You don't know whether the nameserver was cracked, and > > > > incorrect records added. Most people can't tell the difference > > > > between a poisoned DNS cache and whether the records really come > > > > from an authoritative nameserver or even figure out where they got > > > > the DNS record from. So, similarly, all you really know is that > > > > you got a spam from a certain IP address. > That is not at ALL what it means. What it means is: It failed. It must > and will fail. Just because the SPF record belongs to a spammer and the > SPF check doesn't fail DOES NOT mean that SPF failed. It means it > SUCCEEDED. You've yet to explain this---wait, thats how this thread started--and that claim is bogus, given that we've come full circle. > > They already do this. Every day. You seem to be saying that > > AOL sends no spam, and has no spammers, no viruses, no stolen > > accounts??? > > > > This is a very low percentage of spam and killable using other methods. Well, my experience is that such spam is nearly the entire spamload, and is not easilly 'killable by other methods', but more importantly, is not killable by THIS method. If indeed you do work for Bell South, I expect you must know that viruses are sending significant amounts of spam. Are you really speaking from direct experience? > > I note that you wrote this notion as an admin for Bell South. > > Has Bell South been able to clean spammers out of Bell > > South? Or clean virus infections out of Bell South? Or make > > it impossible for Bell South users to get viruses, worms, > > etc? Or do they just whack them as the find them? > > Or is this just another "blind faith" that you //think// will happen? > > > > If you've found some special immunity from spammers/viruses/worms, > > then I think you should share that. //That// would be far more > > valuable than SPF. If we could prevent spammers/viruses/worms then we > > wouldn't need anti-spam tools at all. > > My opinions in this discussion group have always been, and always will > be, my own. I delete my 'official' signature before I send any email to > this group. If I wished to make an 'official' comment, it would be > marked as such. Most people here know who I am and what I do. This lends > itself to my credibility in a technical discussion, as I have direct, > volumetric, and personal experience in direct relation to the issues. I > hope you will understand why I believe the above is completely > inappropriate and request that my employer not be brought into the > discussion. Well, you should only say things that you know from experience, then. And you should avoid suggesting that somehow Bell South or //anyone else// has some magic bullet that prevents spammers from signing up for their services, or prevent viruses from infecting their users. http://www1.ietf.org/mail-archive/web/asrg/current/msg00334.html ========================================================================= As someone who has blocked over 1.1 billion spam messages last year at 49.8tb, I have come up with a few things that I would like to see discussed or implemented in some fashion. I call it "Spam herding", the migration of spammers off of legitimate ISP's and networks, to more "rogue" networks and ISP's. Once there, they can be penned, trapped and killed. (skinning is preferred by me) If they don't do it already, legitimate ISP's should close port 25. Route all SMTP traffic through their own servers and staff their abuse departments with enough people empowered to take direct and immediate action in spamming issues and in a timely fashion. ISP's should track credit cards. If an account is disabled for abuse (investigated and found to have merit) this credit card should be flagged by the ISP. All accounts established and/or associated with this card disabled and no further orders from this card should be taken. Charge for overuse of SMTP, over a certain level, for commercial email. Want to send 100,000 commercial emails? Charge a penny a piece over 10,000. This will not hurt list-serves as they are not commercial in nature and John Q. Public wont send 100,000 emails in his life. If you want to send legitimate commercial email, it is a value add service and should be charged for accordingly. ========================================================================= I note that this entire message is very self-confident, and seems like it has some technical experience, but is extremely flawed: 1) I already discredited the spam-herding notion. 2) Can't block port 25. Perhaps residential ISPs can. But again, their user has relay services by the ISP. Those relay services continue until the account is canceled. Abusers can use those relay services, too. 3) Credit card tracking is probably already done, but credit card services exists to provide 'per-use' credit cards. Plus, there are 30,000 ISPs where the card can be used. So a single credit card has a long lifetime in spammer disposable accounts. (even completely ignoring pink contracts) 4) Usage accounting for SMTP is hard. People have in fact tried it. Its hard to keep the stats without slowing down email. However, a large stable of virus infected machines can send a lot of spam at low rates from each machine. 5) None of this prevents disposable accounts or stolen accounts. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 15:05:59 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 PAA26593 for ; Mon, 13 Sep 2004 15:05: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 i8DIeE9S052315; Mon, 13 Sep 2004 11:40: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 i8DIeEqA052314; Mon, 13 Sep 2004 11:40:14 -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 i8DIeDAU052307 for ; Mon, 13 Sep 2004 11:40:13 -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 i8DIpjxI017997; Mon, 13 Sep 2004 11:51:45 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8DIpjDF017993; Mon, 13 Sep 2004 11:51:45 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Sep 2004 11:51:45 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: ietf-mxcomp@imc.org, Pete Resnick Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 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 Mon, 13 Sep 2004, Jim Lyon wrote: > On Monday, September 13, 2004 at 1:47:32 AM. William Leibzon quotes RFC > 2822 and argues that SenderID's use of Resent-From is inconsistent with > RFC 2822. I disagree. > > RFC 2822 specifies Resent-From is not for "forwarding", in either of the > following two senses: > > 1. Quoting from RFC 2822: > > One sense of forwarding is that a mail reading program > can be told by a user to forward a copy of a message to > another person, making the forwarded message the body > of the new message. A forwarded message in this sense > does not appear to have come from the original sender, > but is an entirely new message from the forwarder of the > message. > > This sense of "forwarding" is normally activated by a user > pressing a "Forward" button in a UI (or similar action.) I > completely agree that "Resent-From" has no place in this sense > of forwarding. I also agree with your interpretation of above quoted RFC2822 text. > 2. Quoting from RFC 2822 again: > > On the other hand, forwarding is also used to mean when > a mail transport program gets a message and forwards it > on to a different destination for final delivery. > > I believe that what RFC 2822 refers to here as "forwarding" is > what we today more commonly refer to as "relaying". That is, > when an MTA merely accepts a message destined for a particular > mailbox, and sends the message along to another MTA because > the first MTA doesn't own the mailbox. I disagree with your interpretation here. I think RFC2822 may have meant that use of Resent-From is inappropriate in all cases of forwarding, including for example when MTA finds that new email address is contained in its configuration (like /etc/aliases on unix systems) and has to forward the message further. I note that sendmail for example treats forwarding based on aliases in quite similar way to relaying. I would also like to add that RFC2822 may indicate that use of Resent-From is inappropriate for forwarding by other text as well. In particular the original use of From header is indicated as follows: 3.6.2. Originator fields In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message That clearly implies that "From:" is to be used to indicate only the author of the message and not anybody else. I understand that we're talking about "Resent-From:" (and not "From:"), but when RFC2822 first introduces Resent fields it seems to indicate that their use should be comparable to the original fields, i.e.: 3.6.6. Resent fields Resent fields SHOULD be added to any message that is reintroduced by a user into the transport system. A separate set of resent fields SHOULD be added each time this is done. ... Each of the resent fields corresponds to a particular field elsewhere in the syntax. For instance, the "Resent-Date:" field corresponds to the "Date:" field and the "Resent-To:" field corresponds to the "To:" field. I note that in above quoted text RFC2822 seems to indicate that use of Resent fields is only appropriate if message is reitroduced by the user (and its not clear how that implies in case of MTA is doing forwarding as in example I provided above). Additionally it seems to imply that Resent fields have the same meaning as original fields which I take as position that Resent-From field may only be used by user who is willing to become new author of the message (but does not make any alterations to the content when forwarding the message). I do not believe this applies to the case when user is the original recepient and when MTA automaticly uses his email when adding Resent-From. > The position that this sense of "forwarding" really means > "relaying" is bolstered by the fact that RFC 2822 nowhere > contains the words "relay" or "relaying". > I completely agree with RFC 2822 that "Resent-From" has no place > in this sense of forwarding. I also agree that "Resent-From" headers should not be used in this situaton. I would however add that some cases of such relaying email may pass through network boundary and in such situation the existing PRA algorithm can fail. For example email recepient may use several secondary MX servers that are not on his network or controlled by it. When email comes in first to one of those secondary MXs, the secondar MX servers maybe able to verify email based on PRA algorithm (i.e. it comes directly from the Sender and only has "From:" header and that header has domain address for which SPF record lists ip address of the sender system). Now when this secondary MX has to relay the email to primary MX (which lets say for simplicity is only MTA in destination network), then secondary MX per your understanding about relaying should not add new new "Resent-From:" or other header. In such a case the primary MX when it finally receives the email would still derive same PRA address based on the headers, but ip address would be that of secondary MX server and would fail SPF test. Now I'm hoping in this case the primary MX would be smart enough to recognize that its one if its secondary MX servers and whiltelist the email, but I can imagine there could be different simular scenarios where such thing would no longer work properly and where use of PRA would fail when relaying between independent networks is involved. > It would probably be a good idea for Pete Resnick (editor of RFC 2822) > to chime in on this interpretation. Indeed his help in interpreting RFC2822 would be much appreciated. And if he's willing to do it, I would also be interested in seeing his interpretation on if PRA algorithm represents an obvious derivitive or interpretation of RFC2822. In particular I note that RFC2822 says in section 3.6.2: The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear. That clearly indicates that when email leaves MSA, the Sender field should correspond to the "originator of the message". And if it is not there, we can assume that it would have been the same as "From:" and that is why it was omited. Now during processing email may have been reintroduced by user and in such cases Resent headers would have been added. As per text I already quoted, these headers carry similar meaning as original "From:" and "Sender:" headers, so if they are present, the top set of these headers would (in some, but not all cases) correspond to the the latest reintroduction and so if Resent-Sender and Resent-From are present they should be checked in the same order and same way as original Sender and From. So what we get is the following order: 1. Resent-Sender (only if present as part of set together with Resent-From) 2. Resent-From 3. Sender 4. From And that is pretty much what PRA algorithm has listed. And to me this all does not even appear to apply a derivitive, but simply an interpretation of RFC2822 when looking for information of the party responsible for last introduction of email by some user. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 15:13: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 PAA27818 for ; Mon, 13 Sep 2004 15:13: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 i8DIgpE3052485; Mon, 13 Sep 2004 11:42: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 i8DIgpNO052484; Mon, 13 Sep 2004 11:42:51 -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 i8DIgo7m052478 for ; Mon, 13 Sep 2004 11:42:51 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8DIgsEN001753 for ; Mon, 13 Sep 2004 11:42:54 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: What the lawyers and suits think (was e: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004) Date: Mon, 13 Sep 2004 11:42:53 -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 On Sep 12, 2004, at 6:20 AM, Andrew Newton wrote: >> Oh sure, it's very clever to get several major bulk email senders to >> agree to a standard - but at the end of the day it doesn't matter > > This is very inappropriate. I don't think you would appreciate other > participants of this group denouncing your voice. This was in _no_ way denouncing the senders - many of whom are *extremely* concerned about these issues, as they see spam as ruining it for everyone, and are as vested in developing a solution as any one. It was a reference to Microsoft wooing the large-scale bulk senders. I *sincerely* apologize if I was not clear enough on that. Anne From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 15:14:22 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 PAA27928 for ; Mon, 13 Sep 2004 15:14: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 i8DIhqaj052562; Mon, 13 Sep 2004 11:43: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 i8DIhqbF052561; Mon, 13 Sep 2004 11:43:52 -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 i8DIhqsH052555 for ; Mon, 13 Sep 2004 11:43:52 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8DIht9u022881 for ; Mon, 13 Sep 2004 11:43:55 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: What the lawyers and suits think Date: Mon, 13 Sep 2004 11:43:55 -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 > I think her last paragraph is very important: > > : So the trick is to get the lawyers and the suits to realize that your > : concerns aren't just something they have to endure - they are > : something they have to satisfy. > > A similar concept needs to be considered by us: We need to realize > that lawyer/suit concerns aren't just something we have to endure - > they are something we have to satisfy. Most importantly, I believe, and a point I perhaps did not highlight pointedly enough, is this: the lawyers and suits are the corporate decision-makers. They generally do *not* take the concerns of the technical people into account when making either legal or other corporate decisions. Considerations regarding technical infrastructure are _so_ far removed from the boardroom, from the revenue and profit bottom lines, that typically the full extent of any consideration which technical concerns about a new product or project are given is a rolling of the eyes. It's no different than when technical people raise concerns about a product to the sales people - the sales people just keep on selling (I know you all know what I mean here). It is in this climate that people in this group are saying "but someone who has intellectual property rights to this would _never_ do that, because it would be wrong - or would not be the best for the Internet". That's horribly naive. Their motive for wanting a product to be deployed is _very_ different than your motive. It has to do with marketshare, consumer capture and retention, or, at best, a solution to _their own problem_. This is true of *any* company, even primarily anti-spam companies, which have moved from garage to office suite, and *particularly* true of those which have moved from "a few guys doing something they care deeply about" to investors and shareholders. At that point, assume they are in it to make money. Moreover, assume their very reason for existing is to make money, and _anything else_ is a *very* distant second. Not only that, but they are *required* to put the bottom line first, and do what is best for the shareholders - or they face unpleasant things like shareholder lawsuits for breach of fiduciary duty. Now, I disagree that the tech guys - the people who are in the front lines of deployment - *you guys* [collectively herein referred to as "the Geek Front" :-) ] - have to satisfy that drive to put the corporate and shareholder interests first (and I don't really think that's what Wayne meant, but just in case anyone read it that way). My point, and I do have one, is that the lawyers and suits need to have an epiphany, and need to realize that this is a situation which is turned on its head from what they are used to - that not only do they have to take the concerns of the Geek Front into account - but that without the Geek Front they've got nothing. That if they don't satisfy the Geek Front, their product will _never_ reach the marketshare they want and need. That's a very unusual situation. It's outside of their experience, outside of their vocabulary - outside of their realm of imagination that there could be a time when the tech people - the people who actually *run* the Internet, would tell _them_ how it's going to be, rather than the other way around. But that's what has to happen, and I submit that the _only_ way a major corporation is going to be able to "own" authentication or anything else is if they get that they can only own it by *not* owning it.* Anne [*Of course, personally what I think should happen is that we need to take advantage of the fact that we have the best and brightest minds in email infrastructure technology *right here*, and that you guys should develop a wholly new standard (be it based on SPF or otherwise), completely unencumbered, commit it to open source, and then adopt the h*ll out of it. *That* is what is going to get everyone on board with a new standard, because a) it will be a level playing field that b) nearly everyone will adopt except for c) those who have corporate greed or ego tied up in the process, and d) they will have to fall in line when everyone else adopts the standard. YOU guys are in a unique position of both knowing what is best for the 'net, *and* getting to dictate that standard - *if* you do it decisively and quickly. But that's just me.] From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 15:18: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 PAA28583 for ; Mon, 13 Sep 2004 15:18: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 i8DInvmR053029; Mon, 13 Sep 2004 11:49: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 i8DInvG1053028; Mon, 13 Sep 2004 11:49:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DInhOH053003 for ; Mon, 13 Sep 2004 11:49:56 -0700 (PDT) (envelope-from SRS0+1cafed84d2e191a7613c+386+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C6vtT-0004rl-T4; Mon, 13 Sep 2004 19:49:42 +0100 Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 From: David Woodhouse To: Jim Lyon Cc: ietf-mxcomp@imc.org, "william(at)elan.net" , Pete Resnick In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1095101378.24547.69.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Mon, 13 Sep 2004 19:49:38 +0100 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 2004-09-13 at 10:03 -0700, Jim Lyon wrote: > On Monday, September 13, 2004 at 1:47:32 AM. William Leibzon quotes RFC > 2822 and argues that SenderID's use of Resent-From is inconsistent with > RFC 2822. I disagree. Nevertheless, others take a different view, and it is most certainly inconsistent with current practice. Given such disagreement, is there some reason why you consider the {ab,}use of Resent-From: header to be more appropriate than the introduction of a new header about which there would be no such disagreement? If consensus is being sought, surely it makes sense to use a new header which does not have alternative usage and meaning, unless there is an overriding reason for it to be 'Resent-From:'? Btw, since we're quoting RFC2822 at each other, perhaps you should pay attention to §3.6.4: Though optional, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate, as described below. ...and to RFC2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Can you explain in accordance with RFC2119 precisely how the full implications were weighed when you decided to post your reply without a References: or In-Reply-To: header, thus detaching your reply from the thread to which you were responding and causing inconvenience to all members of the mailing list who wish to use a 'threaded' view of its messages? Please have the courtesy to use a non-broken mail client if you participate in public fora. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 15:34:09 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 PAA00197 for ; Mon, 13 Sep 2004 15:34: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 i8DIxN3r053839; Mon, 13 Sep 2004 11:59:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DIxNki053838; Mon, 13 Sep 2004 11:59:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DIxNPw053832 for ; Mon, 13 Sep 2004 11:59:23 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:37566) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1C6w25-00057r-RQ (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 19:58:33 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C6w21-0002sA-3s; Mon, 13 Sep 2004 19:58:29 +0100 Date: Mon, 13 Sep 2004 19:58:29 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040913173550.8FF5816CD2@mail.nitros9.org> Message-ID: References: <20040913173550.8FF5816CD2@mail.nitros9.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 13 Sep 2004, Alan DeKok wrote: > Tony Finch wrote: > > > > If I naively start checking SPF records I will get involved because my > > users will kick up a fuss about their legitimate email being rejected. > > Your users may think it's legitimate, but if it doesn't pass SPF > checks, then the domain name they're using doesn't agree. > Resolving that problem is an issue between those users, and the name > of the domain they're using. That sounds like a statement that you are taking on the responsibility for any problems that arise when you email a forwarding address. > > I'll feel free to ignore your bogus SPF policy then. > > Now you're getting personal. No, I'll ignore everyone's :-) > And I find it interesting that you admit you're not going to follow > the policies that other domains publish. If this is true, I fail to > see why you're active in this group, as any standard reached here will > not be published, or checked, by you. > > It would also appear that you're opposed to the charter goals of > this group, or at the least, not interested in them. I am interested in encouraging the group to agree on a standard that doesn't break 5% of the legitimate email handled by my systems. From the point of view of MTA authorization, I think CSV is the best solution suggested so far. From the point of view of eliminating backscatter, I think BATV is the best solution suggested so far. I am actively contributing to both of these efforts. I am also working on extending BATV into a mechanism that can eliminate envelope forgery far more effectively and compatibly than SPF. Tony. -- f.a.n.finch http://dotat.at/ NORTH FITZROY SOLE: WEST OR SOUTHWEST 6 TO GALE 8, VEERING NORTHWEST 5 TO 7. SHOWERS. MAINLY GOOD. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 15:41:14 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 PAA00654 for ; Mon, 13 Sep 2004 15:41:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJDupB055763; Mon, 13 Sep 2004 12:13: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 i8DJDusa055762; Mon, 13 Sep 2004 12:13:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJDt8e055736 for ; Mon, 13 Sep 2004 12:13:55 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C6wGv-0004P4-00; Mon, 13 Sep 2004 12:13:53 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16709.61809.512443.130999@proton.pathname.com> Date: Mon, 13 Sep 2004 12:13:53 -0700 To: Dave Crocker Cc: Daniel Quinlan , IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: <361144888.20040913112430@brandenburg.com> References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1542943013.20040912100612@brandenburg.com> <361144888.20040913112430@brandenburg.com> X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave Crocker writes: > My concern is not about efficiency. It is about the fundamental > ability to get any successful interoperability. I'm concerned about that as well, but efficiency is a concern if you're trying to process mail as quickly as possible. The limit of 10 redirects/includes is a bit worrisome too. > If there is no core requirement for support of a particular record > type, then there will be clients that support only one record type and > servers that support only another. This means that the clients will > not be able to access the information. > > The instant you talk about "duplicate queries" you are assuming that > the client supports more than one type. The question is whether they > are required to. That is, do they have a MUST for each type? There definitely needs to be a shared MUST for one type. At that point, though, how much point is there in even mentioning the other? I absolutely don't want to see a MUST for two types for the receiver if there's no schedule for phasing TXT out. > For Internet-scale services there can be no such thing as a flag day. > There is not central authority to assert it. Even if there were, > there is no way to coordinate that scale of operation. Even centrally > controlled companies cannot do flag-days for large-scale deployment > changes. I agree it's not entirely practical, but as there is no easy or fast way to deploy new RR types, we're limited to the non-practical. Your point is well made. Maybe "flag day" is overstated, but a predefined recommended phase-out schedule would be a good idea if the TXT record is optional. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 16:06: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 QAA02481 for ; Mon, 13 Sep 2004 16:06: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 i8DJWAcQ057518; Mon, 13 Sep 2004 12:32:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DJWAja057517; Mon, 13 Sep 2004 12:32:10 -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 i8DJW9Bx057510 for ; Mon, 13 Sep 2004 12:32: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 i8DJhjbw020069 for ; Mon, 13 Sep 2004 12:43:45 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8DJhjGS020066 for ; Mon, 13 Sep 2004 12:43:45 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Sep 2004 12:43:45 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: TECH OMISSION + DEPLOY: PRA algorithm failure scenarios with mail lists that add only Sender header must be mentioned 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: I would like to point out that in some cases use of Resent headers by some forwarders but not by others would cause widespread failures of PRA algorithm. In particular I note that currently majority of mail list software modify/add "Sender" header to indicate that email is coming from the mail list (and marid-core draft notes that in section 7.3) On the other hand majority of forwarders do not add new header at all with some inappropriatly adding Resent-From header. The marid-core draft specifies in sections 7.2 and 7.3 that both mail list servers and forwarders should add Resent-From headers. When one reads the draft and sees PRA algorithm, a person may believe that updating mail list softwre to add Resent-From header is a low priority if the same software is already adding Sender header and since that header is already checked. Same person would believe that updating forwarders to add a header is high priority since most dont do it and that would cause widespread failures. But this intrepretation is actually not true. Lets consider the scenario of email path A->F->L->Z where A is sender, Z is destination and where F is forwarder or mail list software that has been updated to add Resent-From header and L is mail list that has not been updated and only adds Sender header. In this situation, email would contain Resent-From headers added by F on top somewhere in between the Received headers. But the Sender header added by mail list server L would be on the buttom (actually based on PRA algorithm, it does not matter where it is, it would not be checked if Resent-From is present). The result of interpretation of such email based on PRA algorithm would be that Resent-From header added by F would be found to be PRA when system Z is doing the SPF2.0/PRA verification and such SPF verification would fail because the stage it is verifying is actually L->Z. So in order for PRA algorithm to be used without failures its not only all forwarders that will need to be updated to add new Resent-From headers but also all mailing lists. That represents a significant issue for the quick deployment and adaption of SenderID because number of mail lists is very larger and update of all their software may take many years. This issue SHOULD be mentioned as part of the marid documents so that everyone understands the necessity to make necessary updates before it is possible to publish "-all" with SPF/PRA prefix if we actually choose to proceed on this path. P.S. I would like to request that this email be counted as part of last-call comments eventhough its 12 hours too late. I do also note that previous email (about Resent-From being incompatible with RFC2822) should also be counted and that it was not too late because Sunday still falls within 3rd added week of last call period (eventhough chairs have already announced their decision by that time, which may not have been appropriate given timeframe they themselve specified). --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 16:36: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 QAA06170 for ; Mon, 13 Sep 2004 16:36: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 i8DK6cUB060673; Mon, 13 Sep 2004 13:06: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 i8DK6c6D060672; Mon, 13 Sep 2004 13:06:38 -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 i8DK6cYM060665 for ; Mon, 13 Sep 2004 13:06:38 -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 i8DK6g2V019515; Mon, 13 Sep 2004 13:06:42 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Sep 2004 13:06:42 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Anne P. Mitchell, Esq.'" , IETF MARID WG Subject: RE: What the lawyers and suits think Date: Mon, 13 Sep 2004 13:06:34 -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: Anne P. Mitchell, Esq. [mailto:amitchell@isipp.com] > Most importantly, I believe, and a point I perhaps did not highlight > pointedly enough, is this: the lawyers and suits are the corporate > decision-makers. They generally do *not* take the concerns of the > technical people into account when making either legal or other > corporate decisions. I don't recall ever having a lawyer advise me to take a particular course of action for anything other than purely defensive reasons. Lawyers are rarely true decisions makers for that very reason, give them four alternative choices for action and they will provide you with reasons against five of them. > It is in this climate that people in this group are saying > "but someone > who has intellectual property rights to this would _never_ do that, > because it would be wrong - or would not be the best for the > Internet". That's horribly naive. It depends who, you can usually depend on parties to follow their own best interests. In the case of the largest computer compaines that generally means the industry interest as well. When it comes to the behemoths we are discussing whether or not we should risk them acquiring one extra missile, and not a particularly reliableone at that. This would worry me rather more if it wasn't for the fact that they already own more than enough missiles to ensure complete destruction if they go the nuclear route. > Their motive for wanting a product to be deployed is _very_ different > than your motive. It has to do with marketshare, consumer > capture and > retention, or, at best, a solution to _their own problem_. This is > true of *any* company, even primarily anti-spam companies, which have > moved from garage to office suite, and *particularly* true of those > which have moved from "a few guys doing something they care deeply > about" to investors and shareholders. The folk who have recently moved from garage to VC funded startups are actually a much bigger threat, they have no corporate interest in the commons. The established players do. > My point, and I do have one, is that the lawyers and suits need > to have an > epiphany, and need to realize that this is a situation which > is turned > on its head from what they are used to - that not only do > they have to > take the concerns of the Geek Front into account - but that > without the > Geek Front they've got nothing. Its called mindshare. A case in point is S/MIME vs PGP. The format dispute is an irrelevance from a technical point of view, but the failure of S/MIME to build a deployment constituency and the failure of PGP to gain industry support has meant that neither has been a success. The problem we have here is that the process was only designed to address the technical issues. It is quite possible to go from start to finish without having built the necessary constituency for deployment. Phill From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 16:36:40 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 QAA06171 for ; Mon, 13 Sep 2004 16:36: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 i8DK9UqK061032; Mon, 13 Sep 2004 13:09: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 i8DK9UJW061031; Mon, 13 Sep 2004 13:09:30 -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 i8DK9TGK061016 for ; Mon, 13 Sep 2004 13:09:29 -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 i8DKKiv6022134; Mon, 13 Sep 2004 13:20:44 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8DKKi78022131; Mon, 13 Sep 2004 13:20:44 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Sep 2004 13:20:44 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: Paul Iadonisi , Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders thatare not compatible with RFC 2822 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 Mon, 13 Sep 2004, Jim Lyon wrote: > You need to read specs like a lawyer, not like a programmer. > (Programmer: if the spec says "jump", I'll jump and damn the > consequences. Lawyer: if the spec says "jump" and that's either > ambiguous or nonsensical, I'll look beyond the words to the intended > meaning.) Admittedly, the best specs are ones that yield the same > result to both programmers and lawyers. As much as I'd want to be able to read some documents like a laywer, I'm not one and can not easily do it. I believe and many others would probably confirm that IETF documents are foremost intended to be read and interpreted by engineers and programmers and that likely scenario is that lawyer would not be able to understand complexities and technical details of many of the IETF protocols as he/she would not qualified unless he/she isa also engineer or programmer (such a person is for example Karl Auerbach and I actually dont even know any other lawyer who is also network engineer geek). --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 17:00: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 RAA10763 for ; Mon, 13 Sep 2004 17:00: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 i8DKU5rg063768; Mon, 13 Sep 2004 13:30: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 i8DKU5Hu063767; Mon, 13 Sep 2004 13:30: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 i8DKU3RB063755 for ; Mon, 13 Sep 2004 13:30:04 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.254.82] (host66.209-113-184.oem.net [209.113.184.66]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i8DKU5wX001521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Sep 2004 16:30:06 -0400 Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders thatare not compatible with RFC 2822 From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1095107435.3377.23.camel@tuxtop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 13 Sep 2004 16:30:36 -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 Mon, 2004-09-13 at 14:21, Jim Lyon wrote: [snip] > Is the action occurring at the desire of the mailbox owner, or is > it occurring at the desire of the mail infrastructure owner? > > Otherwise, using the reading that you propose yields an absurd and > unimplementable result: The reading I propose does not *at all* yield an 'absurd and unimplementable result'. That you have the nerve to call it absurd amazes me, given that it seems to be a *widely* accepted (though obviously not by you) reading of it. And the simple fact that it HAS been implemented this way for quite some time is extremely clear evidence that it is absolutely implementable. [snip] > You need to read specs like a lawyer, not like a programmer. I take exception to you telling me that I should read it like a lawyer. Lawyers don't have to implement these specs, so they are not written with lawyers in mind. And they shouldn't be. Please read Anne Mitchell's (she's a lawyer...oh, the irony ;-)) latest post to this list for a good summary of my views on this (I'd provide a link, but it hasn't shown up in the archives yet). It's her post with the subject 'Re: What the lawyers and suits think'. -- -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 Mon Sep 13 17:06:11 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 RAA11978 for ; Mon, 13 Sep 2004 17:06:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DKfpp4065499; Mon, 13 Sep 2004 13:41: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 i8DKfpkq065498; Mon, 13 Sep 2004 13:41:51 -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 i8DKfoBw065492 for ; Mon, 13 Sep 2004 13:41:50 -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 i8DKrQ66023650; Mon, 13 Sep 2004 13:53:26 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8DKrQFk023647; Mon, 13 Sep 2004 13:53:26 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Sep 2004 13:53:26 -0700 (PDT) From: "william(at)elan.net" To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: What the lawyers and suits think 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 Mon, 13 Sep 2004, Hallam-Baker, Phillip wrote: > Its called mindshare. A case in point is S/MIME vs PGP. The format > dispute is an irrelevance from a technical point of view, but the > failure of S/MIME to build a deployment constituency and the failure > of PGP to gain industry support has meant that neither has been > a success. You bring a very important example here. I believe it was IETF failure to achieve consensus and unified standard for signing mail that has results in the above deployment issue. We appear to be headed on the same path based on the announcement by list chairs with their intent to proceed with both SPF classic mail-from and SenderID PRA scopes without any one of these scopes having gained consensus by the WG and leaving it up to the deployment base to decide what would be used. This is so much like the S/MIME vs PGP situation (involving same two large groups of internet users) that it hurts me see us repeat the same mistake. I was truly hoping this WG would be able to bring both corporate big boys (ala SenderID supporters who also the guys supporting S/MIME) with opensource geek camp (ala SPF supporters who are also support mostly PGP). We really should try to come to one solution that has to be mandated to be supported by this IETF group (or more then one that should be mandated) or we'll end up in same situation and the new SPF2.0 will fail in achieving the deployment in either of the scopes. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 18:25: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 SAA20343 for ; Mon, 13 Sep 2004 18:25: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 i8DLm6QW071465; Mon, 13 Sep 2004 14:48: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 i8DLm6Lb071464; Mon, 13 Sep 2004 14:48:06 -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 i8DLm6l8071458 for ; Mon, 13 Sep 2004 14:48:06 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8DLmBvk027438; Mon, 13 Sep 2004 14:48:11 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9AE03CCA-05CE-11D9-B862-000A95AC5778@isipp.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: What the lawyers and suits think Date: Mon, 13 Sep 2004 14:48:10 -0700 To: "Hallam-Baker, Phillip" 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 Sep 13, 2004, at 1:06 PM, Hallam-Baker, Phillip wrote: >> From: Anne P. Mitchell, Esq. [mailto:amitchell@isipp.com] >> Most importantly, I believe, and a point I perhaps did not highlight >> pointedly enough, is this: the lawyers and suits are the corporate >> decision-makers. They generally do *not* take the concerns of the >> technical people into account when making either legal or other >> corporate decisions. > > I don't recall ever having a lawyer advise me to take a particular > course of action for anything other than purely defensive reasons. > > Lawyers are rarely true decisions makers for that very reason, give > them four alternative choices for action and they will provide you > with reasons against five of them. > > >> It is in this climate that people in this group are saying >> "but someone >> who has intellectual property rights to this would _never_ do that, >> because it would be wrong - or would not be the best for the >> Internet". That's horribly naive. > > It depends who, you can usually depend on parties to follow their > own best interests. In the case of the largest computer compaines > that generally means the industry interest as well. > > When it comes to the behemoths we are discussing whether or not > we should risk them acquiring one extra missile, and not a particularly > reliableone at that. This would worry me rather more if it wasn't > for the fact that they already own more than enough missiles to > ensure complete destruction if they go the nuclear route. > > >> Their motive for wanting a product to be deployed is _very_ different >> than your motive. It has to do with marketshare, consumer >> capture and >> retention, or, at best, a solution to _their own problem_. This is >> true of *any* company, even primarily anti-spam companies, which have >> moved from garage to office suite, and *particularly* true of those >> which have moved from "a few guys doing something they care deeply >> about" to investors and shareholders. > > The folk who have recently moved from garage to VC funded startups > are actually a much bigger threat, they have no corporate interest in > the commons. The established players do. > > >> My point, and I do have one, is that the lawyers and suits need >> to have an >> epiphany, and need to realize that this is a situation which >> is turned >> on its head from what they are used to - that not only do >> they have to >> take the concerns of the Geek Front into account - but that >> without the >> Geek Front they've got nothing. > > Its called mindshare. A case in point is S/MIME vs PGP. The format > dispute is an irrelevance from a technical point of view, but the > failure of S/MIME to build a deployment constituency and the failure > of PGP to gain industry support has meant that neither has been > a success. > > The problem we have here is that the process was only designed to > address the technical issues. It is quite possible to go from start > to finish without having built the necessary constituency for > deployment. > > > Phill > From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 18:28:34 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 SAA20787 for ; Mon, 13 Sep 2004 18:28:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DLxbLY072218; Mon, 13 Sep 2004 14:59:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DLxbO2072217; Mon, 13 Sep 2004 14:59:37 -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 i8DLxbtF072211 for ; Mon, 13 Sep 2004 14:59:37 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8DLxgJe014355 for ; Mon, 13 Sep 2004 14:59:42 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <36E2E3F0-05D0-11D9-B862-000A95AC5778@isipp.com> Content-Transfer-Encoding: 7bit From: "Anne P. Mitchell, Esq." Subject: Re: What the lawyers and suits think Date: Mon, 13 Sep 2004 14:59:41 -0700 To: IETF MARID WG 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 Sep 13, 2004, at 1:06 PM, Hallam-Baker, Phillip wrote: > > I don't recall ever having a lawyer advise me to take a particular > course of action for anything other than purely defensive reasons. > > Lawyers are rarely true decisions makers for that very reason, give > them four alternative choices for action and they will provide you > with reasons against five of them. ..only five? Seriously - I can guarantee you that what is going on up in Redmond right now is that the _lawyers_ are figuring out what to do about this situation (as no doubt are others). Now, it's likely that they will make a recommendation to other suits, so if that's what you meant by their not truly being decision-makers, well, yes, I don't disagree - perhaps "decision influencers" would be more appropriate a term, but don't underestimate the influence of those decisions. I certainly have been in situations as an in-house counsel where buy-off on my "recommendation" was a formality only, and I was actually the one making the decisions. I'm not about to put words in Harry's mouth here, but I wouldn't be at all surprised if people in Harry's position are frustrated by what is going on with legal, and would conversely be very surprised if they have the ability to do a blessed thing about it. Anne From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 18:34: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 SAA21240 for ; Mon, 13 Sep 2004 18:34: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 i8DM3N52072586; Mon, 13 Sep 2004 15:03:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DM3NGn072585; Mon, 13 Sep 2004 15:03:23 -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 i8DM3M3e072576 for ; Mon, 13 Sep 2004 15:03:23 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 13 Sep 2004 18:03:25 -0400 id 0015FB92.4146192D.00004D73 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: Work plan for Sender ID Date: Mon, 13 Sep 2004 18:03:23 -0400 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 Due to the fact that we released statements in two separate messages, there seems to be some confusion on how we intend this working group to proceed on Sender ID. First, the PRA document is not being dropped. Instead, we are proceeding with a document set that includes a non-encumbered (as far as we know) scope, "mailfrom", in addition to the "pra" scope. As we stated before, the objection to PRA is based on questions of deployment caused by incompatibilities with open source licenses. However, there were also a significant number for responses from participants stating that they had no such deployment issues. Second, it does not make sense to discuss alternatives to PRA if those alternatives may be reasonably inferred to be covered by the patent application (though not necessarily the license) since this working group does not wish to discount Microsoft's patent application. And since we do not know the specific claims of the patent application, construction of such an alternative would need to take into account a few things we do know: 1. The patent application covers at least -core and -pra in combination. There is no reason to think that Microsoft's application is limited to the technology in these two drafts. 2. It does not cover MAIL FROM because this question has been specifically asked of Microsoft. 3. The algorithm in -pra has changed through multiple revisions of the draft(s). This would seem to at least exclude any scopes that use 2822 headers to identify the party most recently responsible for injecting the message. We hope to have a schedule as soon as possible. -andy From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 19:55: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 TAA26592 for ; Mon, 13 Sep 2004 19:54: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 i8DNNjLD078538; Mon, 13 Sep 2004 16:23: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 i8DNNjs6078537; Mon, 13 Sep 2004 16:23:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DNNjdO078530 for ; Mon, 13 Sep 2004 16:23:45 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C70Ao-0006Xk-00; Mon, 13 Sep 2004 16:23:50 -0700 To: Andrew Newton Cc: IETF MARID WG Subject: Re: Work plan for Sender ID References: From: Daniel Quinlan Date: 13 Sep 2004 16:23:49 -0700 In-Reply-To: Andrew Newton's message of "Mon, 13 Sep 2004 18:03:23 -0400" Message-ID: Lines: 54 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > First, the PRA document is not being dropped. Instead, we are > proceeding with a document set that includes a non-encumbered (as far > as we know) scope, "mailfrom", in addition to the "pra" scope. As we > stated before, the objection to PRA is based on questions of deployment > caused by incompatibilities with open source licenses. However, there > were also a significant number for responses from participants stating > that they had no such deployment issues. Andrew, that is all true, but I think the interoperability of deployments needs to be considered more strongly. To use a reverse analogy, I would not want the IETF to standardize a protocol that was only reasonably licensed for use in GPL software (like some IBM Linux patents are). Deploying "pra" from when most receivers are unable to implement it seems like a major deployment issue. > Second, it does not make sense to discuss alternatives to PRA if those > alternatives may be reasonably inferred to be covered by the patent > application (though not necessarily the license) since this working > group does not wish to discount Microsoft's patent application. > identify the party most recently responsible for injecting the message. For example, I believe the "fetchmail" alternative is: a. possibly not encumbered by the Microsoft patent(s) and we could find out from Microsoft upon publication of the specification b. more likely to result in an invalidated patent *if* the patent application also covers the algorithm due to prior art Then, would it not be a good idea to encourge the workgroup to begin work on additional scopes in parallel with the other scopes? At worst, we would decide they were no less encumbered than PRA, but *both* (a) and (b) would have to go against them for that to be the case. > [...] > This would seem to at least exclude any scopes that use 2822 headers to I'm really confused as to why you think that's true. I think my reasoning is sound, can you explain why the chairs think a parallel effort on additional "backup" scopes (which has been suggested by more than a few people) should be ruled out? I don't want to delay the initial release of a "mailfrom" scope, but I also don't think we should wait to work on "fetchmail" (or whatever) and "helo" until after the others are done. By waiting, I think we might paint ourselves into a corner where the entire specification is rejected because only "mailfrom" is deemed interoperable by the email community as a whole and the "pra" scope is too much of a de-facto requirement. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 20:02:26 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 UAA27146 for ; Mon, 13 Sep 2004 20:02:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DNYU3o079583; Mon, 13 Sep 2004 16:34: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 i8DNYUfh079582; Mon, 13 Sep 2004 16:34:30 -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 i8DNYTYG079575 for ; Mon, 13 Sep 2004 16:34:29 -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 435CE414C6; Mon, 13 Sep 2004 16:34:28 -0700 (PDT) Subject: Re: SPF abused by spammers From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040913012319.6763816CD2@mail.nitros9.org> References: <20040913012319.6763816CD2@mail.nitros9.org> Content-Type: text/plain Message-Id: <1095118467.28424.254.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 13 Sep 2004 16:34:28 -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-09-12 at 18:23, Alan DeKok wrote: > "Douglas Otis" wrote: > > >> WHAT "mail channel"? I have described what I think of as the "mail > >> channel", and given reasons for my conclusions. You haven't. > > > > Mail is normally passed from MTA to MTA on its journey to the destination. > > How does that affect MAIL FROM authentication via records in DNS? There must not be assumptions made regarding mail channel integrity, so there can not be a conclusion MAIL FROM has been authenticated. The MTA may be authorized to send on behalf of MAIL FROM, but that is not the same as authenticating the entity associated with the identity MAIL FROM as being the originator. > > The MTA making the public delivery is often not where the message was > > created. The sequence of Mail Transfer Agents carrying the MAIL FROM > > identifier is what I had referred to as the mail channel. > > None of which is relevant to MAIL FROM authentication via records in > DNS. The previous hops are invisible to MAIL FROM checks. Although such hops are apparent through the RFC2822 headers, both for these headers and the RFC2821 MAIL FROM, there is no SPF or Sender-ID mechanism to allow the authentication of their origin. > > You are saying one can not be sure of the origin of the MAIL FROM, but it > > is okay to use this identity to assert a reputation assessment against the > > actions of the SMTP client. > > I'm saying that the recipient may not know the "true" origin, and > that that "true" origin may be un-knowable. The recipient CAN know > that the current hop is authenticated, if the MAIL FROM satisfies > authentication records in DNS. The current hop is authorized, not authenticated, to act on behalf of the entity associated with the MAIL FROM identity. SPF or Sender-ID confirmation does not mean this entity associated with the MAIL FROM identity had originated the message. This would be making unverifiable assumptions about the mail channel, whether the MTA is shared, and whether the list was "open". A check host function will not provide the nature of the list. > For the recipient, nothing else is verifiable, and therefore nothing > else is relevant. The EHLO name is verifiable and high relevant when there is to be a reputation assigned for abusive actions. > All I'm doing here is taking your EHLO argument, and applying it to > MAIL FROM. Your opposition to this process indicates conflict or > confusion somewhere in the conversation. The assessment of reputation must be assigned accurately to the entity acting as the cause of the abuse. You are extending the concept of authorization to be synonymous with having actually acted. > > Now you are saying publishers should also expect to be black-listed > > when they publish an "open" record as have AOL. > > Publishers should expect recipients to do the most curious things, > for the most inane reasons. What does this mean? > > Showing the name being blocked is the entity that actually sent the > > abusive mail will greatly aid the defense of the reputation service. > > Replace "sent" with "accepted responsibility for", and MAIL FROM > checking is perfectly valid, if all parties agree. How do you arrive at publishing an SPF record being tantamount to accepting accountability for all actions of these authorized entities? If one were to authorize a provider to send mail, and their provider's system became compromised, would it not be better to accredit the provider for resulting abuse? Won't this resolve the problem sooner than causing an innocent party to litigate for protection from a sloppy reputation assessment? In the case of an "open" record, this would hold the SPF publisher accountable for any actions within the entire Internet should they also expect to allow mail to be forwarded. > > > Why? I've explained why and how MAIL FROM accountability can be > > > safely applied. > > > > You have not. You simply say you can hold the MAIL FROM entity > > accountable because they published with the clear warning within some > > discussion within this WG. > > No... that's dumb. "MTA's don't read mailing lists". I assume there is an entity, meaning a sentient being able to read, associated with the MAIL FROM identity. > In any protocol implementation, all parties involved agree as to > what the information means, and how to interpret it. MARID > implementations are nothing special in this regard. If this WG > publishes standards defining accountability, then it's entirely > reasonable to expect that implementors of the standard have accepted > that accountability. This extension of SPF authorization into also meaning acceptance of accountability for the actions of authorized servers should be a warning made in all capital letters! I think such extension of accountability rules out a safe use of any "open" list as well as any hope of allowing forwarding and some list servers to function. > > But where does it say publishing an SPF record is accepting > > accountability for any message using this mailbox domain coming from > > an SMTP client? That is the million dollar question. > > That spec isn't under consideration by this group, so any answer > would be out of scope. But in general, I believe close examination of > email scenarios may lead to such statements. The marid-mpr draft shows how the authentication of the MTA client can be accomplished separately from the mailbox-domain authorization. By doing both steps independently, there is no need to hold the mailbox domain accountable for the actions of the client MTA they authorize. This allows the administrators of the mailbox domain to decide how they wish to handle mail forwarding and list servers without the risk of falsely obtaining a bad reputation. > > I am of the opinion these assumptions are caviler and needlessly risky. > > This risk will represent the demise of the reputation service. > > Which is why I have great skepticism that any reputation system will > work. > > Having my ability to run an MTA depend on kissing up to some third > party? Sure... that fits into the freedom, and the "end to end" > nature of the net. It does not require everyone to use a reputation service for such a service to be effective in curtailing abuse. Theses services assist providers in locating problems and fending off enough load as to remain viable. There is nothing that mandates use of such services, but adopting a universal means of accurately identifying the MTA client name is vital for there to be a name based reputation service. SPF and Sender-ID is worthless with respect to identifying the MTA client. Making the authenticated EHLO visible within the MUA will provide superior consumer protections over the PRA algorithm, and affords easier compliance. Start out with a nominal list useful for coloring mail. If protocols like a public version of BATV become prominent, then more may find it reasonable to declare their lists comprehensive. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 20:08: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 UAA27358 for ; Mon, 13 Sep 2004 20:08:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DNdWrv079928; Mon, 13 Sep 2004 16:39:32 -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 i8DNdWxN079927; Mon, 13 Sep 2004 16:39:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DNdV4U079918 for ; Mon, 13 Sep 2004 16:39:31 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-110-631.area3.spcsdns.net ([68.245.174.122]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C70Q0-0007HZ-AP; Mon, 13 Sep 2004 19:39:35 -0400 Message-ID: <41462FA3.4070900@solidmatrix.com> Date: Mon, 13 Sep 2004 19:39:15 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan DeKok CC: ietf-mxcomp@imc.org, Tony Finch Subject: Re: SPF abused by spammers References: <20040913170458.0AB1E16CD2@mail.nitros9.org> In-Reply-To: <20040913170458.0AB1E16CD2@mail.nitros9.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Alan DeKok wrote: > Tony Finch wrote: > >>I cannot work around this problem: I have no reasonable way of knowing >>that this forwarding relationship exists, or if I do know about it I have >>no reasonable way of maintaining a list of example.edu's outgoing email >>servers in order to whitelist them. > > > And I don't see why (in the idealogical sense) this would be your > problem. If other sites are forwarding your users messages, then > that's a matter between them and the users. You shouldn't have to be > involved. > > Practically, the practice is common, and people resist mightily > changing their habits. When the sender sends a message to the receiver, the edge of the receiver´s system in this case would be the forwarder. It is the responsibility of the receiver to make sure that the steps taken after the forwarder accepts the mail from the sender´s system are correct. Therefore in this specific case, the forwarder would have to do Sender-ID checks in order to protect its users. Therefore, you don´t have to do anything - it´s the end users that do. In a similar fashion when a mailing list is involved, it is the responsibility of the list to do the Sender-ID checks at the edge when it accepts the mail from its users, and the end users will do their own checks against the list itself. Yakov From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 20:17: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 UAA27861 for ; Mon, 13 Sep 2004 20:17: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 i8DNngcV080652; Mon, 13 Sep 2004 16:49:42 -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 i8DNngKv080651; Mon, 13 Sep 2004 16:49:42 -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 i8DNngvA080645 for ; Mon, 13 Sep 2004 16:49:42 -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 DA796414C5; Mon, 13 Sep 2004 16:49:47 -0700 (PDT) Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 From: Douglas Otis To: David Woodhouse Cc: "william(at)elan.net" , MARID In-Reply-To: <1095079885.4995.213.camel@localhost.localdomain> References: <1095079885.4995.213.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1095119387.28424.271.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 13 Sep 2004 16:49: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 Mon, 2004-09-13 at 05:51, David Woodhouse wrote: > On Mon, 2004-09-13 at 05:31 -0700, william(at)elan.net wrote: > > > Additionally Received header are specially designated to be trace fields, > > so they are like a loggin info. > > That's all they are here, surely? In a world where SenderID was > ubiquitous you'd have mail servers automatically rewriting RFC2821 and > RFC2822 identities on outgoing mail, and the SenderID validates _only_ > that one hop; it's not end-to-end validation such as PGP, DomainKeys or > Signed Envelope Senders would offer. > > You end up using a domain-based blacklist instead of the IP-address- > based blacklists which are already common, but other than that the > problem hasn't changed much. It's just a way of determining which are > legitimate mail servers, and which are not. Neither Sender-ID nor SPF safely allow the implementation of a name based blacklist. I would agree there may be a means of excluding messages where the SMTP client IP address was not authorized, but nothing else of significance is possible from this association. A positive association does not indicate the mailbox domain holder to be the originator. A negative association does not indicate the mailbox domain holder to be a spammer. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 20:40:55 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 UAA29333 for ; Mon, 13 Sep 2004 20:40: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 i8E0A0wv081991; Mon, 13 Sep 2004 17:10:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E0A0gm081990; Mon, 13 Sep 2004 17:10:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E09xN8081983 for ; Mon, 13 Sep 2004 17:09:59 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-110-631.area3.spcsdns.net ([68.245.174.122]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C70tW-0000at-Rb; Mon, 13 Sep 2004 20:10:04 -0400 Message-ID: <414636B1.5000904@solidmatrix.com> Date: Mon, 13 Sep 2004 20:09:21 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Quinlan CC: Andrew Newton , IETF MARID WG Subject: Re: Work plan for Sender ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Daniel Quinlan wrote: > Andrew Newton writes: > >>Second, it does not make sense to discuss alternatives to PRA if those >>alternatives may be reasonably inferred to be covered by the patent >>application (though not necessarily the license) since this working >>group does not wish to discount Microsoft's patent application. >>identify the party most recently responsible for injecting the message. > > > For example, I believe the "fetchmail" alternative is: > > a. possibly not encumbered by the Microsoft patent(s) and we could find > out from Microsoft upon publication of the specification > b. more likely to result in an invalidated patent *if* the patent > application also covers the algorithm due to prior art > > Then, would it not be a good idea to encourge the workgroup to begin > work on additional scopes in parallel with the other scopes? At worst, > we would decide they were no less encumbered than PRA, but *both* (a) > and (b) would have to go against them for that to be the case. > > >>[...] >>This would seem to at least exclude any scopes that use 2822 headers to > > > I'm really confused as to why you think that's true. I think my > reasoning is sound, can you explain why the chairs think a parallel > effort on additional "backup" scopes (which has been suggested by more > than a few people) should be ruled out? I don't want to delay the > initial release of a "mailfrom" scope, but I also don't think we should > wait to work on "fetchmail" (or whatever) and "helo" until after the > others are done. By waiting, I think we might paint ourselves into a > corner where the entire specification is rejected because only > "mailfrom" is deemed interoperable by the email community as a whole and > the "pra" scope is too much of a de-facto requirement. > We can always ask Microsoft as has been done with MAILFROM. We can ask Harry whether Wayne´s current draft falls under the IPR claims, and the fetchmail algorithm. If there is a definitive negative, than we are in the clear. Yakov From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 21:02:04 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 VAA01076 for ; Mon, 13 Sep 2004 21:02:04 -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 i8E0PAjF083596; Mon, 13 Sep 2004 17:25:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E0PAir083595; Mon, 13 Sep 2004 17:25:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E0P9Fd083585 for ; Mon, 13 Sep 2004 17:25:09 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Accountability!] RE: SPF abused by spammers X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 13 Sep 2004 19:25:12 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D055402@srv1.pan-am.ca> Thread-Topic: SPF abused by spammers Thread-Index: AcSZ70Ice6ZQokTlRvOsrJnHrVI/7QAANXkg From: "Gordon Fecyk" To: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8E0PAFd083590 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Replace "sent" with "accepted responsibility for", and MAIL FROM > > checking is perfectly valid, if all parties agree. > > How do you arrive at publishing an SPF record being tantamount to > accepting accountability for all actions of these authorized > entities? When I jumped into this little game I did so with the goal of: ======================== RESTORING ACCOUNTABILITY ======================== There, just so it's clear what I'm thinking, in case it wasn't clear every other time I've used the word "accountability" or "accountable" in an e-mail. Yes, this means knowing who to point fingers at for mail abuse. It would also mean fingering a domain administration who, wittingly or otherwise, allows a compromised system to send abusive mail on its behalf (and, hopefully, would correct that compromise somehow.) I wasn't aware that this working group shifted from that goal. Has it? -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 21:18: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 VAA02477 for ; Mon, 13 Sep 2004 21:18:45 -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 i8E0kbtF085281; Mon, 13 Sep 2004 17:46:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E0kbgb085280; Mon, 13 Sep 2004 17:46:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E0kb2G085271 for ; Mon, 13 Sep 2004 17:46:37 -0700 (PDT) (envelope-from msk@sendmail.com) Received: from protagonist.smi.sendmail.com ([10.210.202.26]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i8E0ke0O020695 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 13 Sep 2004 17:46:40 -0700 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i8E0ke0O020695 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=l3P58YBXmBFvULt3kJEDDUBms8qWF5jI21rkWFMzHrfYeIoyi1eWPtTHxEk9fdbFv dFd2e1Yq/37aYNhhjci/pI9wAodAM+IvTGZemCYjIvcwlL82f8K/N6PFRA5IkmsIQON mLomWthZ+EMu/K7uryHn9ciZjZouMOPSoWotPk4= Received: from protagonist.smi.sendmail.com (localhost [127.0.0.1]) by protagonist.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i8E0kdsP099197 for ; Mon, 13 Sep 2004 17:46:39 -0700 (PDT) (envelope-from msk@sendmail.com) Received: from localhost (msk@localhost) by protagonist.smi.sendmail.com (8.12.9/8.12.9/Submit) with ESMTP id i8E0kdrY099194 for ; Mon, 13 Sep 2004 17:46:39 -0700 (PDT) (envelope-from msk@sendmail.com) X-Authentication-Warning: protagonist.smi.sendmail.com: msk owned process doing -bs Date: Mon, 13 Sep 2004 17:46:38 -0700 (PDT) From: "Murray S. Kucherawy" X-X-Sender: msk@protagonist.smi.sendmail.com To: ietf-mxcomp@imc.org Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd) In-Reply-To: <41425D56.6E83@xyzzy.claranet.de> Message-ID: <20040913174322.A98830@protagonist.smi.sendmail.com> References: <41425D56.6E83@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 11 Sep 2004, Frank Ellermann wrote: > Yes, it could replace the "Received-SPF:" header in the SPF classic > draft. I'm a bit lost with one of the examples (9.4), it has auth=, > spf=, and sender-id=, but AUTH is done by the MSA, while spf resp. > sender-id tests are done by the MX / MDA. I included any authentication information that might be useful to an MUA or LDA when evaluating how trustworthy the sender data is. If for example there are multiple layers of transport within an organization, and sender-id, SPF and DomainKeys are only done at the border inbound but an internal message was injected for which the client authenticated using SMTP AUTH, I felt that fact should be relayed should the MUA or LDA wish to make a decision based on it. I also used it as the only available already-standard sender authentication scheme on the books; everything else is only a draft thus far. From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 21:44: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 VAA04492 for ; Mon, 13 Sep 2004 21:44:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E19Ao8088338; Mon, 13 Sep 2004 18:09:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E19A8I088337; Mon, 13 Sep 2004 18:09:10 -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 i8E199FP088323 for ; Mon, 13 Sep 2004 18:09:10 -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; Mon, 13 Sep 2004 21:09:09 -0400 id 0015FB92.414644B6.00005E63 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: Work plan for Sender ID Date: Mon, 13 Sep 2004 21:09:06 -0400 To: Daniel Quinlan 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 Sep 13, 2004, at 7:23 PM, Daniel Quinlan wrote: > I'm really confused as to why you think that's true. The long answer: Because the Microsoft IPR claim calls out -pra and -core in combination. And we know the algorithm has changed. And that is why I wrote "This would seem to at least exclude any scopes that use 2822 headers to identify the party most recently responsible for injecting the message." And I suspect it is actually broader than that. Therefore, using the fetchmail algorithm to do such a thing for anti-forgery using DNS records, which is not why the fetchmail algorithm is in fetchmail, seems to infringe upon the patent application. No matter what, the IETF cannot decide what is and what is not prior art -- courts do that. The short answer: Because if I had written the patent application, that's probably what I would have done. -andy From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 21:58:54 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 VAA05605 for ; Mon, 13 Sep 2004 21:58: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 i8E1M194090759; Mon, 13 Sep 2004 18:22: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 i8E1M1nR090758; Mon, 13 Sep 2004 18:22:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E1M0CJ090652 for ; Mon, 13 Sep 2004 18:22:00 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8E1Lx57015475; Mon, 13 Sep 2004 18:21:59 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8E1LuDY004584; Mon, 13 Sep 2004 18:21:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Mon, 13 Sep 2004 18:21:55 -0700 To: Daniel Quinlan , Andrew Newton From: Ted Hardie Subject: Re: Work plan for Sender ID Cc: IETF MARID WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:23 PM -0700 9/13/04, Daniel Quinlan wrote: > Deploying "pra" from when most receivers are unable to >implement it seems like a major deployment issue. > Note that deployment of "pra" resource records is not in any way encumbered. Zone maintainers may choose to include a "pra" scope for their domains as information for those who choose to check it. Those MTAs who do choose to check it will find it at some domains and not at others (just as those who check for the existence of a MARID record will not find it at some domains and will find it at others). There have been a number of assertions that there must be a mandatory scope if there are multiple scopes. From my perspective, there has never been a mandatory scope; it was always up to the zone maintainer to determine whether or not to put a record into her zone with the relevant data. An MTA performing a MARID check against a domain with no MARID record finds no data; an MTA performing a MARID check against a domain with a MARID record but with a different scope finds no relevant data. From an engineering standpoint, there are differences between the two (a present record with a different scope would likely have different caching characteristics, and would require bare minimum parsing), but many of the key characteristics are the same. So going in this direction may not result in the same level of convergence as might have occurred with a single scope, but it is an improvement over where we are now, with engineering consequences that are similar to the original proposal's. It may be worth noting also that a fair number of folks said that they would continue to check SPF records once spfv2/pra records were available, because they reflected different things. Having both scopes available allows those records to transition to the new RR, and supports those who want to check both as well as those who wish to check one or the other. > > Second, it does not make sense to discuss alternatives to PRA if those >> alternatives may be reasonably inferred to be covered by the patent >> application (though not necessarily the license) since this working >> group does not wish to discount Microsoft's patent application. >> identify the party most recently responsible for injecting the message. > >For example, I believe the "fetchmail" alternative is: > >a. possibly not encumbered by the Microsoft patent(s) and we could find > out from Microsoft upon publication of the specification >b. more likely to result in an invalidated patent *if* the patent > application also covers the algorithm due to prior art > >Then, would it not be a good idea to encourge the workgroup to begin >work on additional scopes in parallel with the other scopes? At worst, >we would decide they were no less encumbered than PRA, but *both* (a) >and (b) would have to go against them for that to be the case. > >> [...] >> This would seem to at least exclude any scopes that use 2822 headers to > >I'm really confused as to why you think that's true. At least to me, the fact that the PRA algorithm has changed during the course of the working group's deliberations but the need for the declaration has not suggests that the original patent claim covers the *idea* of checking the headers for the most recent injector into the mail system against a domain-based record maintained in the forward zone. Even without that indication, that is the broadest interpretation of the combination Microsoft has identified, and many folks have indicated that they wish to be very cautious in that regard. That implies to me that other scopes which might later be registered have to do something other than identify the most recent injector in order to avoid this particular IPR filing. Mail_from qualifies now. If Ned Fred's assessment is correct, the Sun algorithms would as well, since they are meant to indicate where to send replies, rather than to identify the most recent injector. But they do so by not identifying the same thing as PRA; anything that *does* the same thing as PRA may be inferred to be covered by the declaration and license. If Microsoft makes a different statement, of course, that would change. But that is my personal reading of the statements which have been made. Have I mentioned this was my personal opinion, said without hats? It is so. regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Mon Sep 13 23:59: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 XAA12000 for ; Mon, 13 Sep 2004 23:59: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 i8E3SU2p006848; Mon, 13 Sep 2004 20:28: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 i8E3SUJw006847; Mon, 13 Sep 2004 20:28:30 -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 i8E3STi9006839 for ; Mon, 13 Sep 2004 20:28:29 -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 1C73zZ-0006Wz-0t for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 22:28:35 -0500 To: "IETF MARID WG" References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> From: wayne Reply-To: "IETF MARID WG" Date: Mon, 13 Sep 2004 22:28:28 -0500 In-Reply-To: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> (Peter Koch's message of "Sun, 12 Sep 2004 19:50:38 +0200") 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: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 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.6 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 <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> Peter Koch writes: > And regarding the "installed base": while I appreciate the efforts by the > proponents and the early adopters, recent counts for a certain larger > TLD show that there are only a few thousand TXT RRs with "spf" content, > often multiple of those existing in (below) the same 2nd level domain. > Less than 2% of TXT RRs are used for SPF. I seem to recall a survey of the .de TLD, but I can't find it. (The closest I found was your survey of DNS servers.) If I recall correctly, the survey counted things a little bit differently than the surveys that I've done, but the results were reasonablely consistent when the differences were taken into account. For example, you say that 2% of TXT records are used for SPF. This may well be true, but at the spot in the domain hierarchy where SPF records are likely to be checked (the email domain names), I found 19% back in May and 36% in my most recent survey. Can you give me a pointer to this survey that you are referring to? Can you explain the differences between the 2% you quote and the 36% I found? Across all domains, the total is certainly over 100,000 as the SPF adoption roll is just under that number. Many of the SPF records I found in my survey aren't on the adoption roll since the adoption roll is completely optional. I would guess that there are somehwere between 150,000 and 300,000 SPF records currently deployed. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 00:02:14 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 AAA12184 for ; Tue, 14 Sep 2004 00:02: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 i8E3LQUX006214; Mon, 13 Sep 2004 20:21:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E3LQUP006213; Mon, 13 Sep 2004 20:21:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E3LOJg006148 for ; Mon, 13 Sep 2004 20:21:25 -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 1C73sY-00036t-Af for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 22:21:29 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 13 Sep 2004 22:21:13 -0500 In-Reply-To: (wayne@midwestcs.com's message of "Thu, 24 Jun 2004 02:39:28 -0500") 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: Some stats on TXT usage in domain names (updated) 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.6 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 late May and late June, I conducted surveys of a list of 1.3 million email domains found in a spammer's list. Yesterday, I ran another survey to see how things have progressed. There was a net increase of 5729 domains with SPF records, a 68.5% increase in the last three months. SPF records are by far the most common type of TXT record usage, and if trends continue, SPF records will represent over half of all TXT records atthe domain level by early next year. 1289260 total domain names (same as last time) 39205 total TXT records found (some domains have more than one) 14089 have SPF records -> 35.9% of all domain level TXT records are spf records. 34932 domains have txt records 99702 spf_domains adoption roll Earlier stats as a reference: In wayne writes: > 1289260 total domain names (same as last time) > 35115 total TXT records found (some domains have more than one) > 8360 have SPF records -> 23.8% of all domain level TXT records are > spf records. > > 26359 domains have txt records > > 18968 spf_domains adoption roll > > 87 have Caller-ID records > > > > Last months stats as a reference: > > In wayne writes: > >> 1289260 total domain names >> 33016 total TXT records found (some domains have more than one) >> 6320 have SPF records -> 19.1% of all domain level TXT records are >> spf records >> >> 26359 domains have txt records >> 6315 domains have spf records >> >> 1456 domains found that were also in the adopt roll -> 23.0% >> >> 14192 spf_domains adoption roll >> >> 61554 estimated domains have SPF records. (This probably misses >> most parked domains, of which I have heard rumors that there >> are a least a couple hundred thousand with SPF records. >> >> 82 have Caller-ID records >> 57 have both Caller-ID records and SPF records >> 45 have "testing=true" in the C-ID records. >> 25 have C-ID records only, of which three (10%) are microsoft.com, >> exchange.microsoft.com and hotmail.com >> From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 00:04: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 AAA12255 for ; Tue, 14 Sep 2004 00:04: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 i8E3dEEn008187; Mon, 13 Sep 2004 20:39:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E3dEJM008186; Mon, 13 Sep 2004 20:39:14 -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 i8E3dD8l008178 for ; Mon, 13 Sep 2004 20:39:13 -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 1C749w-00032W-BB for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 22:39:19 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 13 Sep 2004 22:39:12 -0500 In-Reply-To: (Ted Hardie's message of "Mon, 13 Sep 2004 18:21:55 -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: Work plan for Sender ID 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.6 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 Ted Hardie writes: > It may be worth noting also that a fair number of folks said > that they would continue to check SPF records once spfv2/pra records > were available, because they reflected different things. Having > both scopes available allows those records to transition to the new > RR, and supports those who want to check both as well as > those who wish to check one or the other. The SPFv1 records can not transition to the SPFv2 records unless the both the MAILFROM and HELO scopes are added. I again ask that the "v=spf1 " magic number be interpreted as "spf2.0/mailfrom,helo" in the SenderID spec. > That implies to me that other scopes which might later be registered have to > do something other than identify the most recent injector in order to > avoid this particular IPR filing. Mail_from qualifies now. If Ned Fred's > assessment is correct, the Sun algorithms would as well, since they > are meant to indicate where to send replies, rather than to identify > the most recent injector. But they do so by not identifying the > same thing as PRA; anything that *does* the same thing as PRA > may be inferred to be covered by the declaration and license. As has been pointed out several times, the NOTE WELL requirement for filing drafts and participating in this mailing list requires that Microsoft employees inform us of any drafts that we are considering that would be covered by their IPR. I see no problem with proceeding with I-Ds that deal with the 2822.From: identity and then, if someone tells us that they have IPR covering those I-Ds, we can consider our options. However, this direction can not even be tried because the co-chairs do not want to consider *any* alternatives to the PRA. This will again lead us to a Hobson's choice of either reject all 2822.From: checks, or proceed with an encumbered standard that can not be deployed to on a large percentage of the current MTAs. I just don't understand this. If I didn't know better, I would say that this is an attempt to force acceptance of something that would otherwise be quickly rejected. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 00:21: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 AAA13244 for ; Tue, 14 Sep 2004 00:21: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 i8E3k9P0008724; Mon, 13 Sep 2004 20:46: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 i8E3k9qP008723; Mon, 13 Sep 2004 20:46:09 -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 i8E3k8qF008717 for ; Mon, 13 Sep 2004 20:46:08 -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 1C74Gd-0006Gj-Ol for ietf-mxcomp@imc.org; Mon, 13 Sep 2004 22:46:14 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 13 Sep 2004 22:46:07 -0500 In-Reply-To: (Andrew Newton's message of "Mon, 13 Sep 2004 18:03:23 -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: Work plan for Sender ID 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.6 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 Andrew Newton writes: > First, the PRA document is not being dropped. Instead, we are > proceeding with a document set that includes a non-encumbered (as far > as we know) scope, "mailfrom", in addition to the "pra" scope. As we > stated before, the objection to PRA is based on questions of > deployment caused by incompatibilities with open source licenses. > However, there were also a significant number for responses from > participants stating that they had no such deployment issues. While there were quite a few people (especially by drive-by posters) who said that they could deploy SenderID with the PRA, many expressed reservations about the license anyway and only a few said that they wanted the PRA. Since the option of advancing SenderID with out the PRA was never given, I think it is unreasonable to assume that those that express support for SenderID were really expressing support for the PRA. For the people who objected to the PRA due to the patent license, I can't recall anyone that said that they would accept the PRA if other scopes were allowed also. I think that the PRA should be dropped since I can see no way that there will be a rough consensus for advancing it. Allowing other scopes will probably not change any of the votes against the PRA, and may well change some of the votes for it. I think continuing with the PRA is a very poor use of this working group's time. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 00:27:24 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 AAA13583 for ; Tue, 14 Sep 2004 00:27:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E3xQWL010011; Mon, 13 Sep 2004 20:59:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E3xQpw010010; Mon, 13 Sep 2004 20:59:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E3xPuY010001 for ; Mon, 13 Sep 2004 20:59:25 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C74LV-0007wX-00 for ; Tue, 14 Sep 2004 05:51:09 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 05:51:08 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 05:51:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Mon, 13 Sep 2004 15:45:09 +0100 Organization: Wacks Wicks Works Lines: 32 Message-ID: References: <81AC085044D04B429F5FB883D94FA1AF8FAD36@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAD36@df-fido-msg.exchange.corp.microsoft.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit JL> But wait, I hear critics cry: Doesn't that double the number of JL> lookups someone has to do? To which the correct answer would have been "Yes. But in the real world with the way that DNS lookups actually operate the situation isn't quite as simple as that; and in any case, other factors - such as EDNS0, the presence of other resource record sets making fallback to DNS/TCP more likely, and the presence of SMTP Relay clients performing their "ANY"/"CNAME"/"MX" lookups via the same proxy DNS servers - intervene to further complicate matters." JL> Yes, it does. But the large, complicated domains that have this issue JL> are almost exactly the ones that send lots of legitimate mail. As such, JL> their records will usually already be in your resolver's DNS cache. JL> (Said differently, it doesn't matter how complicated AOL's records are, JL> because your DNS cache will only fetch them once a week.) The paraphrase is false, for two reasons. First: The TTL of the resource record set will affect how often they are fetched. The existing "TXT" resource record set for "aol.com." has a TTL of 300 seconds, meaning that it will be fetched _at least_ once every 5 minutes by a caching proxy DNS server. Second: Most caching proxy DNS servers place a maximum upper bound on resource record set TTLs. However, not all caching proxy DNS servers use the _same_ upper bound, and even then it is configurable in many. (e.g. ISC's BIND has a default upper bound of 7 days, which is configurable with the "max-cache-ttl" option in its configuration file. Dan Bernstein's "dnscache" has a fixed non-configurable upper bound of 7 days. Microsoft's DNS server has a default upper bound of 1 day, which is configurable with the "MaxCacheTTL" value in the registry.) From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 00:32:26 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 AAA13797 for ; Tue, 14 Sep 2004 00:32:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E3xvNW010041; Mon, 13 Sep 2004 20:59: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 i8E3xvm7010040; Mon, 13 Sep 2004 20:59:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E3xuvm010032 for ; Mon, 13 Sep 2004 20:59:56 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C74U6-0008Gs-00 for ; Tue, 14 Sep 2004 06:00:02 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:00:02 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:00:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: All members of "we" please raise your hands. Date: Mon, 13 Sep 2004 20:54:57 +0000 Organization: Wacks Wicks Works Lines: 28 Message-ID: References: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (OS/2; U; Warp 4; en-US; rv:1.8a2) Gecko/20040719 X-Accept-Language: en-gb, en, en-us In-Reply-To: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit PF> It's pretty sad that people like the author of this article we PF> got a link to still see 1:1 mapping between "remove spam" and PF> "minimize the number of fake sender addresses". I thought "we" PF> as a collective had educated enough people to not get articles PF> like this. Does this "we" include those who are, right now, educating people with the following? "SPF reduces inbound spam." -- "If the message fails SPF tests, it's a forgery. That's how you can tell it's probably a spammer." -- (That first sentence is a lie, of course.) "Eventually, as SMTP improves its immunity to spam, we hope spammers will get discouraged." -- "'Why should SPF succeed when similar proposals have failed in the past?' The spam problem was never as bad in the past as it is now." -- "Saving the world from spam is an expensive duty." -- From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 00:38: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 AAA14118 for ; Tue, 14 Sep 2004 00:38: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 i8E3xP2U010003; Mon, 13 Sep 2004 20:59: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 i8E3xPJY010002; Mon, 13 Sep 2004 20:59:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E3xNDs009993 for ; Mon, 13 Sep 2004 20:59:23 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C74LS-0007wR-00 for ; Tue, 14 Sep 2004 05:51:06 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 05:51:06 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 05:51:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 Date: Mon, 13 Sep 2004 15:21:35 +0100 Organization: Wacks Wicks Works Lines: 85 Message-ID: References: <4144782E.70607@ehsco.com> <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit PK> [...] the question of whether a prefix is necessary or not is of PK> course closely related to the choice of RR type. TXT would need PK> a prefix, a new type would not. A new resource record type would require a "prefix" for exactly the same reasons that the "TXT" resource record type would. The benefit of a prefix in this instance is to reduce DNS response sizes, and it applies both to abusing the "TXT" resource record type and to using a new resource record type. To see why this is, one needs to look at what DNS lookups SMTP Relay clients and servers actually perform, and one needs to look at how the "SRV" resource record type could have been defined but wasn't. Even 3 years after the publication of RFC 2821, which obviated the requirement that caused these to be done in the first place, many SMTP Relay client softwares _still_ perform "ANY" DNS lookups instead of separate "CNAME" and "MX" lookups (or, better yet in light of RFC 2821, just "MX" lookups). By adding SPF-style information to, say, the domain name "aol.com.", the size of the response to an "ANY" query for that domain name is increased (and hence so too is the likelyhood of incurring the overhead of falling back to using DNS/TCP). Note two important points here: * Everyone thinks of the DNS lookups that SMTP Relay servers will be performing, but forgets that (because so many softwares lag more than 3 years behind the times), SMTP Relay _clients_ will be affected too, since they perform "ANY" lookups on the very same set of domain names (i.e. those that occur in the domain name portion of an SMTP mailbox name). * The actual type of the resource record is irrelevant. A 128-octet "TXT" resource record added to "aol.com." will have the same particular effect of increasing the size of an "ANY" response as a 128-octet "FOO" resource record would. Now consider how "SRV" resource records could have been designed, but weren't. "SRV" resource records _could_ have been designed to incorporate the protocol and the service names in their data portions example.org. IN SRV 86400 nicname tcp 0 0 43 whois.example.org. example.org. IN SRV 86400 ldap tcp 0 0 389 dir.example.org. example.org. IN SRV 86400 http tcp 0 0 80 www.example.org. and service lookup would have involved performing a "SRV" lookup and then scanning the resultant resource record set, which would have grown with each new service defined and provided, for resource records with names that matched the desired service. (Do this design and its concomitant problems seem somewhat familiar, boys and girls?) Instead, "SRV" resource records were designed so that the service and protocol names were encoded in the owner domain name, _nicname._tcp.example.org. IN SRV 86400 0 0 43 whois.example.org. _ldap._tcp.example.org. IN SRV 86400 0 0 389 dir.example.org. _http._tcp.example.org. IN SRV 86400 0 0 80 www.example.org. and thus so that individual "SRV" resource record sets only covered single services. Thus, looking up the locator information for an individual service doesn't present one with a whole slew of information about services that one wasn't interested in, that one then has to wade through picking out what one wants; and, also, the sizes of "SRV" resource record sets don't grow as "SRV" lookup is defined for further services. In database terms (and without going into detail about the DNS database schema): The primary key for the global, distributed, DNS database is an tuple, and service lookup encodes an search key into that tuple, thereby making use of the DNS lookup mechanism to ensure that the lookup yields only those data that are actually relevant. Client-restriction data in fact uses a very similar search key, which can be encoded in the same way. Ironically, this would have been clearer if we didn't have "MX" resource records but had used "SRV" resource records to find SMTP Relay servers. The pairing of _smtp._tcp.example.org. IN SRV 86400 0 0 25 a.mx.example.org. to locate the "example.org." SMTP Relay servers and _smtp._tcp.example.org. IN SPF 86400 "-all" to publish the restrictions on the "example.org." SMTP Relay clients would have seemed relatively straightforward. From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 00:43:23 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 AAA14630 for ; Tue, 14 Sep 2004 00:43: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 i8E49vHI010857; Mon, 13 Sep 2004 21:09: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 i8E49v6j010856; Mon, 13 Sep 2004 21:09:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E49u7X010850 for ; Mon, 13 Sep 2004 21:09:56 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C74dm-00009X-00 for ; Tue, 14 Sep 2004 06:10:02 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:10:02 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:10:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: Re: AOL's stance on SenderID and IPR issues Date: Mon, 13 Sep 2004 18:12:14 +0100 Organization: Wacks Wicks Works Lines: 39 Message-ID: References: Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 
It is my understanding that Yahoo is one of the largest (if not the largest) companies using qmail and there have been substantial discussions on this list in the last day that license terms may not compatible with that at all.
As Matt and others point out, this is irrelevant, as the license does not impact end-users of the code, only people who will redistribute it (which qmail doesn't allow anyways ;)
False.  One is permitted to distribute the original qmail package.  One can also distribute other people's patches to it, as long as their own respective licences, from their own respective authors, permit them to be redistributed of course.  (And indeed, this is exactly what happens right now with netqmail.)  Since the code covered by the purported Microsoft patent would be in a patch, not in qmail proper, Microsoft's patent licence would not affect qmail one whit.  qmail would be redistributable under the same terms as it is now.  Microsoft's patent licence would, however, affect the patch.  (The patch would have to be branded with a trademark.  It would have to be in object code, not source code, form.  It would have to be non-redistributable by "End Users" - the Microsoft patent licence does impact end users of the code - and thus couldn't be distributed under a licence such as the GPL.  And so on.) 

Moral: Don't go to an employee of Sendmail Inc. for correct information about qmail.  (-:
From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 00:48: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 AAA14987 for ; Tue, 14 Sep 2004 00:48: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 i8E4JvkZ011583; Mon, 13 Sep 2004 21:19: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 i8E4Jvgl011582; Mon, 13 Sep 2004 21:19:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E4Juu5011576 for ; Mon, 13 Sep 2004 21:19:57 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C74nT-0000Pl-00 for ; Tue, 14 Sep 2004 06:20:03 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:20:02 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:20:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: All members of "we" please raise your hands. Date: Thu, 09 Sep 2004 18:48:03 +0100 Organization: Wacks Wicks Works Lines: 28 Message-ID: References: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit PF> It's pretty sad that people like the author of this article we PF> got a link to still see 1:1 mapping between "remove spam" and PF> "minimize the number of fake sender addresses". I thought "we" PF> as a collective had educated enough people to not get articles PF> like this. Does this "we" include those who are, right now, educating people with the following? "SPF reduces inbound spam." -- "If the message fails SPF tests, it's a forgery. That's how you can tell it's probably a spammer." -- (That first sentence is a lie, of course.) "Eventually, as SMTP improves its immunity to spam, we hope spammers will get discouraged." -- "'Why should SPF succeed when similar proposals have failed in the past?' The spam problem was never as bad in the past as it is now." -- "Saving the world from spam is an expensive duty." -- From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 00:59: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 AAA15835 for ; Tue, 14 Sep 2004 00:59: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 i8E4TvSC012259; Mon, 13 Sep 2004 21:29: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 i8E4TvvB012258; Mon, 13 Sep 2004 21:29:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E4Tu8x012250 for ; Mon, 13 Sep 2004 21:29:56 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C74x8-0000jo-00 for ; Tue, 14 Sep 2004 06:30:02 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:30:02 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:30:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: Re: AOL's stance on SenderID and IPR issues Date: Mon, 13 Sep 2004 18:10:57 +0100 Organization: Wacks Wicks Works Lines: 26 Message-ID: References: Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit
[We] are one of the larger installations of qmail (2500 servers). However as a commercial company, like AOL, we don't have a problem with the [Microsoft] license. We can develop our own implementation and request a license from Microsoft to do so. The qmail license would only affect us if we wanted to distribute that code to others.
You mean the Microsoft patent licence, not the qmail copyright licence.  The qmail copyright licence doesn't affect your distribution of your own code implementing Sender-ID as an add-on to qmail.  It's the Microsoft patent licence that affects that.  (Your own code must be branded with a trademark.  You cannot distribute your own code in source form.  You cannot permit the recipients to redistribute your own code in their turn.  And so forth.)
From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 01:03:50 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 BAA16180 for ; Tue, 14 Sep 2004 01:03:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E4du1R012992; Mon, 13 Sep 2004 21:39: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 i8E4duQm012991; Mon, 13 Sep 2004 21:39:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E4dtx5012984 for ; Mon, 13 Sep 2004 21:39:56 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C756o-0000za-00 for ; Tue, 14 Sep 2004 06:40:02 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:40:02 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:40:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: Re: consensus call of RR prefix Date: Mon, 13 Sep 2004 17:10:34 +0100 Organization: Wacks Wicks Works Lines: 29 Message-ID: References: <16697.63831.938253.936526@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: <16697.63831.938253.936526@giles.gnomon.org.uk> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 
[...] leaving the TXT records in the domain.tld dataspace, while ugly, seems like a good bit of parallelism for the SPF records that will be published in the same place.
I concur.  Purely pragmatically, many people will want to check both SPF and IETF-compliant Sender ID.  Being able to fetch both with a single query is therefore beneficial.
... but also impossible if the resource records are, as here, of two different types - TXT and SPF, respectively.  (Before someone says it: No, "any" is not the same as "all".)  In the general case, which applies here, to look up two resource record sets of different types always requires two DNS transactions.
(Of course it doesn't matter if I use separate pieces of software to check SPF and Sender ID, both of which make their own queries; my local caching nameserver will still ensure that only one query is made to the authoritative nameservers.)
That is not what will happen.  Front-end transactions to proxy DNS servers only combine at the back-end if they are looking up the same resource record set keyed by the same <owner,class,type> tuple.
From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 01:17: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 BAA16857 for ; Tue, 14 Sep 2004 01:17: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 i8E4nudi013770; Mon, 13 Sep 2004 21:49: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 i8E4nuaB013769; Mon, 13 Sep 2004 21:49:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E4ntTC013762 for ; Mon, 13 Sep 2004 21:49:56 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C75GU-0001GR-00 for ; Tue, 14 Sep 2004 06:50:02 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:50:02 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 06:50:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: Re: consensus call of RR prefix Date: Mon, 13 Sep 2004 19:19:37 +0100 Organization: Wacks Wicks Works Lines: 60 Message-ID: References: Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 
It has been claimed that MTA software is generally configured to reject e-mail that comes from a domain that doesn't exist.  [...]

[...] many sites have wildcard MX records so that they can catch mail sent to any address.  This means that they want to receive mail, not matter how it is addressed within their domain, but they don't authorize sending with such addresses.  In theses cases, all domains exist (due to the wildcard MX record), and so other people's MTAs won't reject based on domain non-existance.
    
You're making an assumption that to check if domain exist one would make an "A" or "AAAA" query on that domain and if no record is received assume that domain is invalid, that is not correct.
No.  He's making the assumption that if an "MX" lookup returns a non-empty resource record set, the SMTP Relay server infers that the domain name does exist.  And he's entirely correct.
There is important difference that should be made by implementors about dns error codes. [...]
The distinction between a "no such name" error and an empty resource record set isn't relevant to what he is discussing here.  The wildcard transforms the "no such name" error into a non-empty MX resource record set, just as Verisign's wildcards did for A resource record sets.
Actually to be more precise NODATA should be given if answer section is empty, [...]
Wrong.  RFC 2308 shows several response forms comprising complete answers with empty resource record sets, that do not have empty "answer" sections.  Not only is an empty "answer" section not the definition of an empty resource record set answer, it actually doesn't convey the empty resource record set properly (because of a schema mismatch between the DNS protocol and the DNS database).  It doesn't convey the TTL information for the empty resource record set.
but dns resolvers can't make this assumption because of other problems;
They cannot make that assumption because it is a wrong one to make.
At the same time query for A when there is an AAAA on some servers would cause an AAAA to be addded to additional section, or possible that is the other way around...
Either way around is perfectly legitimate.  The well-known problem with some (broken) content DNS server softwares and AAAA resource record sets is that they'll answer with the data for an A query but give a "no such name" answer to an AAAA query, making the apparent existence of the name in IP6-aware applications dependent from the exact relative order in which the A and AAAA lookups are done.
From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 01:24: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 BAA17234 for ; Tue, 14 Sep 2004 01:24: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 i8E4xvaB014580; Mon, 13 Sep 2004 21:59: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 i8E4xvOE014579; Mon, 13 Sep 2004 21:59:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E4xupX014569 for ; Mon, 13 Sep 2004 21:59:57 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C75QA-0001Vp-00 for ; Tue, 14 Sep 2004 07:00:02 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 07:00:02 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 07:00:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve) Date: Mon, 13 Sep 2004 16:39:30 +0100 Organization: Wacks Wicks Works Lines: 57 Message-ID: References: <200408261200.21556.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: <200408261200.21556.davidb@verisignlabs.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 
The existence of names block wildcards at that name, and for any name below that name.
True for wildcards when one follows the RFC 1034 algorithm, and the operation of wildcards on some content DNS server softwares in some configurations.  However, not true in the general case.  Wildcards operate differently in several content DNS server softwares. 

For example 1: With Dan Bernstein's tinydns, the existence of mx.example.org. does not prevent *.example.org. from matching a.mx.example.org..  Only an explicit a.mx.example.org. record, of any type, does that.

For example 2: With Microsoft's DNS server configured to use "loose wildcarding", the existence of mx.example.org. does not prevent *.example.org. from matching a.mx.example.org..  Only an explicit a.mx.example.org. record of the requested type does that.

Ironically, these both provide the behaviour that people often actually want (and ask for, again and again) when they set up wildcard "MX" resource record sets, but that the RFC 1034 algorithm does not give them. 
It is true that wildcards are not useful as a default "fall-back" record solution.  They never were.
One better fallback mechanism would be to adopt the same fallback mechanism as used by nsupdate and the de facto WHOIS service DNS lookup scheme, namely if the domain name in question is fred.example.co.uk., perform the following lookups:
  1. IN SPF _smtp._tcp.fred.example.co.uk.
  2. IN SPF _smtp._tcp.example.co.uk.
  3. IN SPF _smtp._tcp.co.uk.
  4. IN SPF _smtp._tcp.uk.
  5. IN SPF _smtp._tcp.
From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 01:35: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 BAA17877 for ; Tue, 14 Sep 2004 01:35:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E4tkBU014223; Mon, 13 Sep 2004 21:55: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 i8E4tk00014221; Mon, 13 Sep 2004 21:55:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E4tjKP014207 for ; Mon, 13 Sep 2004 21:55:46 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 04:55:44 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: RE: Work plan for Sender ID Date: Mon, 13 Sep 2004 22:56:16 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 14 Sep 2004 04:55:44.0605 (UTC) FILETIME=[17B798D0:01C49A17] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: >The SPFv1 records can not transition to the SPFv2 records unless the >both the MAILFROM and HELO scopes are added. > >I again ask that the "v=spf1 " magic number be interpreted as >"spf2.0/mailfrom,helo" in the SenderID spec. I am also interested in a response to this request. It seems reasonable to me. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 01:40:48 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 BAA18172 for ; Tue, 14 Sep 2004 01:40:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E59uQA018217; Mon, 13 Sep 2004 22:09: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 i8E59uH4018215; Mon, 13 Sep 2004 22:09:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E59tLT018204 for ; Mon, 13 Sep 2004 22:09:56 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C75Zq-0001k6-00 for ; Tue, 14 Sep 2004 07:10:02 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 07:10:02 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 07:10:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: Re: DEPLOY: DNS Record Types Date: Mon, 13 Sep 2004 18:39:06 +0100 Organization: Wacks Wicks Works Lines: 21 Message-ID: References: <81AC085044D04B429F5FB883D94FA1AF8FAD6B@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAD6B@df-fido-msg.exchange.corp.microsoft.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 
The DNS resolver APIs on all Microsoft OS's don't let you query for an unknown record type.
Rubbish.
Even if you write your own DNS resolver code, if you're behind a firewall created by Microsoft ISA Server, you usually can't successfully send and receive a query for a new record type.
If one is behind certain makes and models of firewalls, one cannot use EDNS, too.  Yet RFC 2671 has made it on to the standards track.
From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 01:53:54 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 BAA19039 for ; Tue, 14 Sep 2004 01:53: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 i8E5JuZK021955; Mon, 13 Sep 2004 22:19: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 i8E5JuxR021954; Mon, 13 Sep 2004 22:19:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E5JtaS021943 for ; Mon, 13 Sep 2004 22:19:55 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C75jW-000237-00 for ; Tue, 14 Sep 2004 07:20:02 +0200 Received: from cpc3-warw1-3-0-cust110.brhm.cable.ntl.com ([80.5.186.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 07:20:02 +0200 Received: from J.deBoynePollard by cpc3-warw1-3-0-cust110.brhm.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2004 07:20:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Jonathan de Boyne Pollard Subject: Re: consensus call of RR prefix Date: Mon, 13 Sep 2004 16:56:29 +0100 Organization: Wacks Wicks Works Lines: 32 Message-ID: References: <1094255966.5841.24.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-warw1-3-0-cust110.brhm.cable.ntl.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en, en-us In-Reply-To: <1094255966.5841.24.camel@localhost.localdomain> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 
Any requirement (or even expectation) of DNS over TCP will probably kill widespread adoption of Sender ID, as DNS over TCP does not work over a large number of networks. Either it's blocked at a firewall, or it's disabled on the DNS server.
If DNS/TCP is blocked at a firewall, then that firewall is badly configured.  (People often come to DNS discussion fora asking what shape of holes they should knock into their firewalls.  The frequently given answer on the subject clearly states that such holes will encompass DNS/TCP for the back-ends of resolving proxy DNS servers.)  And if you think that resolving proxy DNS server softwares have the capability of disabling the use of DNS/TCP, then you are confused.  No mainstream resolving proxy DNS server has such a capability (and quite rightly so, given RFC 1123 section 6.1.3.2).  Only content DNS server softwares provide anything remotely like such a capability, and only one mainstream DNS server software package, djbdns, actually has the ability to selectively disable the use of DNS/TCP for its content DNS service.  Other content DNS server softwares have the capability of disabling the "zone transfer" database replication mechanism; but that is not the same as disabling the use of DNS/TCP, old wives tales to the contrary notwithstanding.
From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 04:49: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 EAA16685 for ; Tue, 14 Sep 2004 04:49:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E89dj6094304; Tue, 14 Sep 2004 01:09: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 i8E89dVJ094303; Tue, 14 Sep 2004 01:09:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E89PTS094193 for ; Tue, 14 Sep 2004 01:09:37 -0700 (PDT) (envelope-from SRS0+b6bc7fa9ee44c1c0e503+387+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C78NJ-0001Vv-DI; Tue, 14 Sep 2004 09:09:17 +0100 Subject: Re: [Accountability!] RE: SPF abused by spammers From: David Woodhouse To: Gordon Fecyk Cc: MARID In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D055402@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125D055402@srv1.pan-am.ca> Content-Type: text/plain; charset=UTF-8 Message-Id: <1095149356.9144.250.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Tue, 14 Sep 2004 09:09:16 +0100 Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 2004-09-13 at 19:25 -0500, Gordon Fecyk wrote: > There, just so it's clear what I'm thinking, in case it wasn't clear every > other time I've used the word "accountability" or "accountable" in an e-mail. > > Yes, this means knowing who to point fingers at for mail abuse. It would > also mean fingering a domain administration who, wittingly or otherwise, > allows a compromised system to send abusive mail on its behalf (and, > hopefully, would correct that compromise somehow.) Right. SPF and SenderID provide that accountability only for a single hop at a time. They do not provide end-to-end validation of a given email address. I could quite happily forge mail which appears to be from you by using an SRS reverse-path at my own domain containing your address, and a Resent-From: header with your username at my own domain despite the From: header still containing your normal address. Most users are naïve enough not to notice, and those who _would_ notice are mostly the same people who'd notice it without SenderID due to the Received: headers anyway. Of course, if I did that a lot my domain name would end up in a blacklist -- my mail servers would be considered untrustworthy. That's the point -- it's a hop-by-hop scheme. It's _all_ about how much you trust the one mail server which is sending you mail. Where before we had IP-based blacklists, now there are domain-based blacklists, without which SPF/SenderID is largely not useful. Since mail servers in the Brave New World are expected to modify the outgoing mail to add their 'domain', and since they can arbitrarily choose _any_ 'domain' which has a record permitting their IP address, it's clear that the 'domain' used for the check has essentially become just an arbitrary key into the blacklist/whitelist/trustdb. And that trust database isn't optional -- it's a required part of the scheme if the SenderID information is to be useful. So why are we looking at only mailfrom and pra scopes? There are many other arbitrary keys which we could use for the database -- all we need is some means of checking that the presenting mail host really is authorised to claim allegiance with whichever entity is represented by the key. One suggestion would be to use the signer of a TLS certificate. Every mail server in an administrative domain would present its TLS cert, and each cert signed to show that it legitimately belongs to that domain. Then your whitelist/blacklist/trustdb is keyed on the signing certificates. Note that 'administrative domain' isn't necessarily equivalent to DNS domain. And that self-signed certs are fine -- there's no need to pay anyone for a cert. Using the HELO scope is another possibility which makes some sense. Unlike the mailfrom or pra scopes, limiting the use of a given HELO name to certain IP addresses does actually have some basis in the real world today. Other alternatives might include a new SMTP extension for the client to provide its 'identity', which can be verified either by IP address or perhaps other means. The possibilities are endless -- there are many options which would not have the deployment and accuracy problems of the mailfrom and pra scopes. However, the mailfrom and pra scopes are not workable in today's Internet because they are based on the fundamentally flawed assumption that forwarding hosts will be upgraded to behave in strange and controversial new ways. Deployment of new standards in email is _extremely_ slow even when they are clearly a good thing, and the new world required to make the mailfrom and pra scopes actually workable would, in my opinion, _never_ be reached. I propose that we should abandon the mailfrom and pra scopes which abuse the RFC2821 and RFC2822 source addresses as a trust-database key, and instead look for alternative keys for our trust database -- such as the TLS certificate or the HELO name -- which do not break existing practice. Separate work is ongoing to provide end-to-end solutions for assuring that RFC2821 and RFC2822 sender addresses really are valid. A hop-by-hop scheme cannot reliably guarantee that _anyway_; SenderID and SPF are useful for assigning trust to individual (or groups of) mail hosts only, and there are _better_ ways of doing that than abusing the sender identities in a way which requires us to 'upgrade' all existing mail installations to cope. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 04:49: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 EAA16707 for ; Tue, 14 Sep 2004 04:49: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 i8E87Smr093595; Tue, 14 Sep 2004 01:07:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E87SSw093594; Tue, 14 Sep 2004 01:07:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail80.messagelabs.com (mail80.messagelabs.com [195.245.230.163]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8E87RrS093579 for ; Tue, 14 Sep 2004 01:07:28 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-6.tower-80.messagelabs.com!1095149102!1697505 X-StarScan-Version: 5.2.10; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 32177 invoked from network); 14 Sep 2004 08:05:02 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-6.tower-80.messagelabs.com with SMTP; 14 Sep 2004 08:05:02 -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 ; Tue, 14 Sep 2004 09:05:01 +0100 Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 To: "william(at)elan.net" Cc: ietf-mxcomp@imc.org, Jim Lyon , owner-ietf-mxcomp@mail.imc.org, Pete Resnick X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Danny Angus Date: Tue, 14 Sep 2004 09:05:02 +0100 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 14/09/2004 09:05:01 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: William at elan wrote: > I note that in above quoted text RFC2822 seems to indicate that use of > Resent fields is only appropriate if message is reitroduced by the user > (and its not clear how that implies in case of MTA is doing forwarding > as in example I provided above). Additionally it seems to imply that > Resent fields have the same meaning as original fields which I take > as position that Resent-From field may only be used by user who is > willing to become new author of the message (but does not make any > alterations to the content when forwarding the message). I do not > believe this applies to the case when user is the original recepient > and when MTA automaticly uses his email when adding Resent-From. However you could argue, and I would, that particularly in the case of ~/.forward and any kind of aliases that the user themselves have re-introduced the message into the mechanism. It may be an automated action, but it is in response to the users instruction (or the instruction of someone acting on their behalf) it just happens to be a "standing order" rather than an explicit decision per message. I'd also strongly support the notion that the user had reintroduced the message by knowingly sending a mail to a mechanism designed to re-introduce it to the system, such as a mailinglist. 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 Tue Sep 14 05:12: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 FAA18232 for ; Tue, 14 Sep 2004 05:11: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 i8E8bbBQ003683; Tue, 14 Sep 2004 01:37:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E8bbYb003682; Tue, 14 Sep 2004 01:37:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E8bbhI003675 for ; Tue, 14 Sep 2004 01:37:37 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8E8bZ1b019993; Tue, 14 Sep 2004 01:37:35 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <533F208D-0629-11D9-B862-000A95AC5778@isipp.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: Work plan for Sender ID Date: Tue, 14 Sep 2004 01:37:34 -0700 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: Content-Transfer-Encoding: 7bit On Sep 14, 2004, at 12:12 AM, william(at)elan.net wrote: > Dont you think its more appropraite per IETF practice (and based on > opinions > expressed by the majority of participants of this WG) to say and do the > other way around, that should proceed on the non-encumbered scopes > first > and in addition may consider "encumbered" scopes if they bring enough > benefits to make it worth deploying and if there are no non-encumbered > alternatives that can achieve similar results? > >> As we stated before, the objection to PRA is based on questions of >> deployment caused by incompatibilities with open source licenses. > > There have been significant number of objections to PRA on the > technical > ground as well and most of these have not been answered. But IPR issues > caused so much more discussions that technical problems were not being > noticed. But to say that IPR issues with deployment is the only > objection > to SenderID/PRA in its correction form is simply incorrect. > >> However, there were also a significant number for responses from >> participants stating that they had no such deployment issues. > > I would point out that majority of those expressing support were large > companies who are actually "end-users" that are willing to enter dns > records for their domains. This is significantly less important then > issues of software writers that have to implement capabilities to check > these records. > It would seem that not everyone agrees with you on these points; from a news.com article covering the very discussions going on here (you all are aware that the press is reading these archives and reporting on what they are reading, right?)...anyways, from a news.com article entitled "Standards group scuttles Microsoft e-mail proposal": "Microsoft spokesman Sean Sundwall said the company would continue with its plans to develop its own proposal, Caller ID for E-mail. In August, Microsoft had feted more than 80 e-mail service providers in Redmond, Wash., as part of the E-mail Service Provider Consortium. Between the company's participation in that group and the Anti-Spam Technical Alliance, Microsoft has done a good job of selling major Internet infrastructure companies on the benefits of its proposal. Sundwall would not say whether the IETF's censure would hinder the company's quest to get its Caller ID proposal accepted as a de facto Internet standard. But he did note that many participants stayed out of the vote on Microsoft's involvement. "If you look at the number of contributors that (voted), it is very small," he said." Full article at http://news.com.com/2100-1032-5364075.html Anne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 06:17: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 GAA23682 for ; Tue, 14 Sep 2004 06:17: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 i8E6f1iq060519; Mon, 13 Sep 2004 23:41: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 i8E6f05e060516; Mon, 13 Sep 2004 23:41:00 -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 i8E6f00e060504 for ; Mon, 13 Sep 2004 23:41:00 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id BEC8226C085; Tue, 14 Sep 2004 08:40:59 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id B395726C077; Tue, 14 Sep 2004 08:40:58 +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 i8E6ewm7747267; Tue, 14 Sep 2004 08:40:58 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 8F8CCFACC; Tue, 14 Sep 2004 08:40:58 +0200 (CEST) Date: Tue, 14 Sep 2004 08:40:58 +0200 From: Stephane Bortzmeyer To: Jonathan de Boyne Pollard Cc: ietf-mxcomp@imc.org Subject: Re: All members of "we" please raise your hands. Message-ID: <20040914064058.GB15185@nic.fr> References: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu, Sep 09, 2004 at 06:48:03PM +0100, Jonathan de Boyne Pollard wrote a message of 28 lines which said: > Does this "we" include those who are, right now, educating people with > the following? spf.pobox.com contains many marketing promises that are... careless. (Some people could say "dishonest".) They also keep pretending that there are "RFCs" about SPF. webmaster@pobox.com never replies on such matters. Nevertheless, here, in the MARID working group, we can say the truth :-) SPF (or SenderID) does not assert anything about the spaminess of the message but about its authenticity (a spam can be authentic). From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 06:18: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 GAA23748 for ; Tue, 14 Sep 2004 06:18: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 i8E6cIqY059441; Mon, 13 Sep 2004 23:38: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 i8E6cIPX059440; Mon, 13 Sep 2004 23:38:18 -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 i8E6c5Co059354 for ; Mon, 13 Sep 2004 23:38:18 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id B7F1D26C09C; Tue, 14 Sep 2004 08:38:04 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id A52EF26C076; Tue, 14 Sep 2004 08:38:03 +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 i8E6c3m7751956; Tue, 14 Sep 2004 08:38:03 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 77F45FACC; Tue, 14 Sep 2004 08:38:03 +0200 (CEST) Date: Tue, 14 Sep 2004 08:38:03 +0200 From: Stephane Bortzmeyer To: Jonathan de Boyne Pollard Cc: ietf-mxcomp@imc.org Subject: Re: consensus call of RR prefix Message-ID: <20040914063803.GA15185@nic.fr> References: <1094255966.5841.24.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Sep 13, 2004 at 04:56:29PM +0100, Jonathan de Boyne Pollard wrote a message of 32 lines which said: > and only one mainstream DNS server software package, [2]djbdns, > actually has the ability to selectively disable the use of > DNS/TCP for its content DNS service. Other content DNS server > softwares have the capability of disabling the "zone transfer" > database replication mechanism; but that is not the same as > disabling the use of DNS/TCP, old wives tales to the contrary > notwithstanding. I am not sure you know what you are talking about. nsd (http://www.nlnetlabs.nl/nsd/), which is used for k.root-servers.net and for our ns2.nic.fr, has such a capability (just run it with -n 0). From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 06: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 GAA23888 for ; Tue, 14 Sep 2004 06:19: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 i8E6vhm4067807; Mon, 13 Sep 2004 23:57: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 i8E6vh74067805; Mon, 13 Sep 2004 23:57:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E6vgLG067797 for ; Mon, 13 Sep 2004 23:57:42 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 13 Sep 2004 23:57:40 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Sep 2004 23:57:40 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Sep 2004 23:57:40 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 23:57:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7399.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: DNS Record Types Date: Mon, 13 Sep 2004 23:57:39 -0700 Message-ID: Thread-Topic: DEPLOY: DNS Record Types Thread-Index: AcSaG57R4qqo30C/T4q+T7fSc2mzcAACvUaQ From: "Jim Lyon" To: "Jonathan de Boyne Pollard" , X-OriginalArrivalTime: 14 Sep 2004 06:57:33.0563 (UTC) FILETIME=[1C3214B0:01C49A28] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8E6vgLG067799 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, September 13, 2004 at 10:39 PM, Jonathan de Boyne-Pollard said: > > The DNS resolver APIs on all Microsoft OS's don't let you > > query for an unknown record type. > Rubbish. > If you're behind a firewall and you call this API with an unknown record type, it will fail with INVALID_PARAMETER. > If one is behind certain makes and models of firewalls, one > cannot use EDNS, too. Yet RFC 2671 has made it on to the > standards track. Yep. But RFC 2671 doesn't mandate that resolvers use it. RFC 2671 was carefully designed so that DNS is still usable if either the resolver or the server doesn't understand EDNS. I'm just asking for similar behavior. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 06:20: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 GAA24019 for ; Tue, 14 Sep 2004 06:20: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 i8E70v8m069035; Tue, 14 Sep 2004 00:00: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 i8E70v1H069034; Tue, 14 Sep 2004 00:00:57 -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 i8E70uOL069000 for ; Tue, 14 Sep 2004 00:00:56 -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 i8E7CSgL028381; Tue, 14 Sep 2004 00:12:28 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8E7CS9f028378; Tue, 14 Sep 2004 00:12:28 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 14 Sep 2004 00:12:28 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: Work plan for Sender ID 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 Mon, 13 Sep 2004, Andrew Newton wrote: > First, the PRA document is not being dropped. Instead, we are > proceeding with a document set that includes a non-encumbered (as far > as we know) scope, "mailfrom", in addition to the "pra" scope. Dont you think its more appropraite per IETF practice (and based on opinions expressed by the majority of participants of this WG) to say and do the other way around, that should proceed on the non-encumbered scopes first and in addition may consider "encumbered" scopes if they bring enough benefits to make it worth deploying and if there are no non-encumbered alternatives that can achieve similar results? > As we stated before, the objection to PRA is based on questions of > deployment caused by incompatibilities with open source licenses. There have been significant number of objections to PRA on the technical ground as well and most of these have not been answered. But IPR issues caused so much more discussions that technical problems were not being noticed. But to say that IPR issues with deployment is the only objection to SenderID/PRA in its correction form is simply incorrect. > However, there were also a significant number for responses from > participants stating that they had no such deployment issues. I would point out that majority of those expressing support were large companies who are actually "end-users" that are willing to enter dns records for their domains. This is significantly less important then issues of software writers that have to implement capabilities to check these records. Unless I'm mistaken opensource mail servers account for > 60% of deployed email servers on the internet. You simply can not discount that majority of them will not be implementing SenderID (because their email server software package would not be implementing it). > Second, it does not make sense to discuss alternatives to PRA if those > alternatives may be reasonably inferred to be covered by the patent I disagree. I do not believe we can reasomably infer if the aleternative is convered by IPR unless that alternative is allowed to be presented. There is also exist a very "interesting" way of finding out if alternative is covered by IPR or not. One may send a draft as individual submission and if Microsoft is aware of the draft being published, it will have to disclose that it has IPR claims on what is presented there if their patent seems to apply for it. If they don't disclose it, we can assume that the draft had no IPR claims and may then proceed working on it in WG. > application (though not necessarily the license) since this working > group does not wish to discount Microsoft's patent application. There has not been clear consensus of WG wants or does not want to discount Microsoft patent application, but the number of people on this WG arguing to ignore the patent claims were actually highier then number of people that argued against it. > And since we do not know the specific claims of the patent application, > construction of such an alternative would need to take into account a > few things we do know: > 1. The patent application covers at least -core and -pra in > combination. There is no reason to think that Microsoft's application > is limited to the technology in these two drafts. Actually there are good reasons to believe that. Microsoft people have specifically commented that their IPR claims do not extend to any of the documents alone. This seems to imply that IPR issue is very specific to combination of those two documents and does not likely extend further. > 2. It does not cover MAIL FROM because this question has been > specifically asked of Microsoft. Good. > 3. The algorithm in -pra has changed through multiple revisions of > the draft(s). The changes were minor to account for cases of bad or incomplete header data. Order of headers in PRA algorithm has not changed. > This would seem to at least exclude any scopes that use 2822 headers to > identify the party most recently responsible for injecting the message. I completely reject this conclusion as not being based on the facts presented so far to this WG. Unless you know something of specifics of their patent that we dont I dont see any base to believe that IPR claims is so widespread to cover ANY 2822 headers that we may come up with. Furthermore the "party responsible for injecting the message" is not the only alternative available to us when working on algorithm that cover previous hop in the email transaction. And I have alredy given an alternative that is not based on it, but based on "party responsible for transmission of the message on its email network". --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 06:24: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 GAA24572 for ; Tue, 14 Sep 2004 06:24: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 i8E9keIC029718; Tue, 14 Sep 2004 02:46:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E9keUv029717; Tue, 14 Sep 2004 02:46:40 -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 i8E9kdJZ029699 for ; Tue, 14 Sep 2004 02:46:39 -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 i8E9wIC9001378; Tue, 14 Sep 2004 02:58:18 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8E9wH9j001375; Tue, 14 Sep 2004 02:58:17 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 14 Sep 2004 02:58:17 -0700 (PDT) From: "william(at)elan.net" To: "Anne P. Mitchell, Esq." cc: IETF MARID WG Subject: Re: Work plan for Sender ID In-Reply-To: <533F208D-0629-11D9-B862-000A95AC5778@isipp.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: > a news.com article covering the very discussions going on here (you all > are aware that the press is reading these archives and reporting on > what they are reading, right?)...anyways, from a news.com article > entitled "Standards group scuttles Microsoft e-mail proposal": Media is reading too much into technical and other discussions going on this group. This kind of media attention in my view is not helpfull to the the IETF process. It also allows different sides instead of using technical arguments inline with IETF process to pressure ietf into making possibly bad decisions due to presumed interest from outside based for example on wild speculation that they represent large groups (when these groups are in fact unwilling to comment directly) and by using interviews, press-conferences and other vendor organized public events to bolster their own image. It would be great if media stop interfering with our process until the WG actually produces standard track RFC documents. At that time, if documents were produced according with IETF standard process and represent concensus of WG participants on the technical solution that does not violate existing standards, then it becomes an issue of deployment of new standard/protocol and media exposure becomes very helpfull in widespread adaption of the new technology. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 07:31: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 HAA29422 for ; Tue, 14 Sep 2004 07:31:58 -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 i8EAsq0T055067; Tue, 14 Sep 2004 03:54: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 i8EAsqPF055066; Tue, 14 Sep 2004 03:54:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EAsphN055058 for ; Tue, 14 Sep 2004 03:54:52 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54479) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1C7AxR-0007ou-NQ (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 14 Sep 2004 11:54:45 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7AxR-00044G-6M; Tue, 14 Sep 2004 11:54:45 +0100 Date: Tue, 14 Sep 2004 11:54:45 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Daniel Quinlan cc: IETF MARID WG Subject: Re: Work plan for Sender ID In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 13 Sep 2004, Daniel Quinlan wrote: > > For example, I believe the "fetchmail" alternative is: I don't think the fetchmail algorithm is suitable. It's trying to guess what the return path was in the absence of any SMTP-time information and in the presence of crap installations that don't add a Return-Path: field when delivering into the POP mailbox. A /fetchmail scope would be semantically identical to a /mailfrom scope, but with some additional heuristics intended for use with non-standard and misconfigured systems. This is not appropriate for a technical standard. Tony. -- f.a.n.finch http://dotat.at/ SELSEY BILL TO LYME REGIS: SOUTHWEST VEERING WEST 6 TO GALE 8, DECREASING 4 OR 5 OVERNIGHT. SHOWERS. MAINLY GOOD. ROUGH OR VERY ROUGH, BECOMING MODERATE. From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 07:45: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 HAA29926 for ; Tue, 14 Sep 2004 07:45:32 -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 i8EBBsa8056359; Tue, 14 Sep 2004 04:11:54 -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 i8EBBsRn056358; Tue, 14 Sep 2004 04:11:54 -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 i8EBBrvL056352 for ; Tue, 14 Sep 2004 04:11:53 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 3A83926C081; Tue, 14 Sep 2004 13:11:54 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id DDBC526C076; Tue, 14 Sep 2004 13:11:52 +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 i8EBBqm7816682; Tue, 14 Sep 2004 13:11:52 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id B82DEFACC; Tue, 14 Sep 2004 13:11:52 +0200 (CEST) Date: Tue, 14 Sep 2004 13:11:52 +0200 From: Stephane Bortzmeyer To: "william(at)elan.net" Cc: "Anne P. Mitchell, Esq." , IETF MARID WG Subject: Re: Work plan for Sender ID Message-ID: <20040914111152.GA2646@nic.fr> References: <533F208D-0629-11D9-B862-000A95AC5778@isipp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue, Sep 14, 2004 at 02:58:17AM -0700, william(at)elan.net wrote a message of 30 lines which said: > It would be great if media stop interfering with our process until > the WG actually produces standard track RFC documents. It is of course impossible in a free country. And it would not even be sensible: face it, IETF working groups no longer work in a purely technical environment. Their decisions affect the work and lives of many people and media attention on a public process is perfectly normal and I wish it goes on (of course, I also wish future papers in the media to be more informed...) From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 08:14: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 IAA02111 for ; Tue, 14 Sep 2004 08:14: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 i8EBjPwC059376; Tue, 14 Sep 2004 04:45: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 i8EBjPce059375; Tue, 14 Sep 2004 04:45:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EBjN0x059363 for ; Tue, 14 Sep 2004 04:45:24 -0700 (PDT) (envelope-from paf@cisco.com) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 14 Sep 2004 13:53:20 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8EBj52X006578; Tue, 14 Sep 2004 13:45:15 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 13:44:33 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 13:44:33 +0200 In-Reply-To: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6E3094EA-0643-11D9-AAED-000A95B2B926@cisco.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 Date: Tue, 14 Sep 2004 13:44:26 +0200 To: Andrew Newton X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 14 Sep 2004 11:44:33.0254 (UTC) FILETIME=[33EE6860:01C49A50] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sep 11, 2004, at 19:59, Andrew Newton wrote: > 2) On the issue of compliance with the use of the TXT record, the > working group has at least rough consensus that TXT usage is > acceptable for compliance and should not be specified as a > configuration that will be non-compliant. However, there is at least > rough consensus that the use of the SPF-specific record type is more > desirable than the use of a TXT record type. It is the opinion of the > co-chairs that the -protocol document clearly state that the usage of > TXT records will most likely be deprecated by future protocol > definition. Given this text it is not clear to me whether the -protocol document will specify any kind of use of TXT records. My view is still that: - TXT records are in use for SPF and friends already - There is no need for the MARID wg to specify how to use TXT records - Instead the MARID wg should specify a new RR Type, and specify how it is used I.e. it is enough with one transition, from what some people use today, to what the MARID wg is specifying. Yes, it is ok for the -protocol document to talk about this transition, but...I don't like seeing "short term deployment of MARID things" because short-term doesn't exist on the Internet. Patrik From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 09:43: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 JAA09822 for ; Tue, 14 Sep 2004 09:43:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EDGUYO068756; Tue, 14 Sep 2004 06:16: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 i8EDGUMU068755; Tue, 14 Sep 2004 06:16:30 -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 i8EDGUKH068749 for ; Tue, 14 Sep 2004 06:16:30 -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; Tue, 14 Sep 2004 09:16:29 -0400 id 0015FAC4.4146EF2E.00002FDC In-Reply-To: References: <4144782E.70607@ehsco.com> <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48C10B41-0650-11D9-BCF4-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: Andrew Newton Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 Date: Tue, 14 Sep 2004 09:16:27 -0400 To: Jonathan de Boyne Pollard 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 Sep 13, 2004, at 10:21 AM, Jonathan de Boyne Pollard wrote: > Even 3 years after the publication of RFC 2821, which obviated the > requirement that caused these to be done in the first place, many SMTP > Relay client softwares _still_ perform "ANY" DNS lookups instead of > separate "CNAME" and "MX" lookups (or, better yet in light of RFC 2821, > just "MX" lookups). I looked into this about a year ago and found that most MTAs did MX then A,AAAA. -andy From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 09:43: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 JAA09844 for ; Tue, 14 Sep 2004 09:43: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 i8ED4d2g067226; Tue, 14 Sep 2004 06:04: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 i8ED4dXJ067225; Tue, 14 Sep 2004 06:04:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ED4b9G067205 for ; Tue, 14 Sep 2004 06:04:38 -0700 (PDT) (envelope-from paf@cisco.com) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 14 Sep 2004 15:12:38 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8ED4K2X020253; Tue, 14 Sep 2004 15:04:32 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 15:03:57 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 15:03:56 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8571C287-064E-11D9-AAED-000A95B2B926@cisco.com> Content-Transfer-Encoding: 7bit Cc: , "Jonathan de Boyne Pollard" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: DEPLOY: DNS Record Types Date: Tue, 14 Sep 2004 15:03:50 +0200 To: "Jim Lyon" X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 14 Sep 2004 13:03:56.0833 (UTC) FILETIME=[4B3EE110:01C49A5B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sep 14, 2004, at 08:57, Jim Lyon wrote: > On Monday, September 13, 2004 at 10:39 PM, Jonathan de Boyne-Pollard > said: > >>> The DNS resolver APIs on all Microsoft OS's don't let you >>> query for an unknown record type. >> Rubbish. >> > > If you're behind a firewall and you call this API with an unknown > record > type, it will fail with INVALID_PARAMETER. What is the chance/risk you have some box behind a firewall, allow incoming traffic using port 25/TCP but disallow the box to make outgoing 53/UDP+TCP connections? I.e. yes, you are correct on this limitation, but, it will in reality be possible for the box to send and receive DNS packets by itself IF it is located so it accept incoming SMTP connections over the Internet. And I claim enough boxes will be able to do that, and that a minority will have the problem. paf From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 10:16:49 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 KAA12891 for ; Tue, 14 Sep 2004 10:16:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EDm93F072828; Tue, 14 Sep 2004 06:48: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 i8EDm9dk072827; Tue, 14 Sep 2004 06:48:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EDm706072819 for ; Tue, 14 Sep 2004 06:48:08 -0700 (PDT) (envelope-from dwmw2@infradead.org) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 15:49:45 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 14 Sep 2004 15:44:03 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Sep 2004 10:33:28 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Sep 2004 10:35:07 +0200 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 i8E89dj6094304; Tue, 14 Sep 2004 01:09: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 i8E89dVJ094303; Tue, 14 Sep 2004 01:09:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E89PTS094193 for ; Tue, 14 Sep 2004 01:09:37 -0700 (PDT) (envelope-from SRS0+b6bc7fa9ee44c1c0e503+387+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C78NJ-0001Vv-DI; Tue, 14 Sep 2004 09:09:17 +0100 Subject: Re: [Accountability!] RE: SPF abused by spammers From: David Woodhouse To: Gordon Fecyk Cc: MARID In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D055402@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125D055402@srv1.pan-am.ca> Content-Type: text/plain; charset=UTF-8 Message-Id: <1095149356.9144.250.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Tue, 14 Sep 2004 09:09:16 +0100 X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html List-Archive: List-Unsubscribe: List-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id i8E89dj6094304 X-OriginalArrivalTime: 14 Sep 2004 08:35:07.0908 (UTC) FILETIME=[BDA83C40:01C49A35] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8EDm906072822 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 2004-09-13 at 19:25 -0500, Gordon Fecyk wrote: > There, just so it's clear what I'm thinking, in case it wasn't clear every > other time I've used the word "accountability" or "accountable" in an e-mail. > > Yes, this means knowing who to point fingers at for mail abuse. It would > also mean fingering a domain administration who, wittingly or otherwise, > allows a compromised system to send abusive mail on its behalf (and, > hopefully, would correct that compromise somehow.) Right. SPF and SenderID provide that accountability only for a single hop at a time. They do not provide end-to-end validation of a given email address. I could quite happily forge mail which appears to be from you by using an SRS reverse-path at my own domain containing your address, and a Resent-From: header with your username at my own domain despite the From: header still containing your normal address. Most users are naïve enough not to notice, and those who _would_ notice are mostly the same people who'd notice it without SenderID due to the Received: headers anyway. Of course, if I did that a lot my domain name would end up in a blacklist -- my mail servers would be considered untrustworthy. That's the point -- it's a hop-by-hop scheme. It's _all_ about how much you trust the one mail server which is sending you mail. Where before we had IP-based blacklists, now there are domain-based blacklists, without which SPF/SenderID is largely not useful. Since mail servers in the Brave New World are expected to modify the outgoing mail to add their 'domain', and since they can arbitrarily choose _any_ 'domain' which has a record permitting their IP address, it's clear that the 'domain' used for the check has essentially become just an arbitrary key into the blacklist/whitelist/trustdb. And that trust database isn't optional -- it's a required part of the scheme if the SenderID information is to be useful. So why are we looking at only mailfrom and pra scopes? There are many other arbitrary keys which we could use for the database -- all we need is some means of checking that the presenting mail host really is authorised to claim allegiance with whichever entity is represented by the key. One suggestion would be to use the signer of a TLS certificate. Every mail server in an administrative domain would present its TLS cert, and each cert signed to show that it legitimately belongs to that domain. Then your whitelist/blacklist/trustdb is keyed on the signing certificates. Note that 'administrative domain' isn't necessarily equivalent to DNS domain. And that self-signed certs are fine -- there's no need to pay anyone for a cert. Using the HELO scope is another possibility which makes some sense. Unlike the mailfrom or pra scopes, limiting the use of a given HELO name to certain IP addresses does actually have some basis in the real world today. Other alternatives might include a new SMTP extension for the client to provide its 'identity', which can be verified either by IP address or perhaps other means. The possibilities are endless -- there are many options which would not have the deployment and accuracy problems of the mailfrom and pra scopes. However, the mailfrom and pra scopes are not workable in today's Internet because they are based on the fundamentally flawed assumption that forwarding hosts will be upgraded to behave in strange and controversial new ways. Deployment of new standards in email is _extremely_ slow even when they are clearly a good thing, and the new world required to make the mailfrom and pra scopes actually workable would, in my opinion, _never_ be reached. I propose that we should abandon the mailfrom and pra scopes which abuse the RFC2821 and RFC2822 source addresses as a trust-database key, and instead look for alternative keys for our trust database -- such as the TLS certificate or the HELO name -- which do not break existing practice. Separate work is ongoing to provide end-to-end solutions for assuring that RFC2821 and RFC2822 sender addresses really are valid. A hop-by-hop scheme cannot reliably guarantee that _anyway_; SenderID and SPF are useful for assigning trust to individual (or groups of) mail hosts only, and there are _better_ ways of doing that than abusing the sender identities in a way which requires us to 'upgrade' all existing mail installations to cope. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 10:16: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 KAA12913 for ; Tue, 14 Sep 2004 10:16: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 i8EDjhQ1072523; Tue, 14 Sep 2004 06:45: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 i8EDjhkE072522; Tue, 14 Sep 2004 06:45:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EDjfme072479 for ; Tue, 14 Sep 2004 06:45:42 -0700 (PDT) (envelope-from william@elan.net) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 15:47:14 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 14 Sep 2004 15:43:56 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 14 Sep 2004 13:23:50 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Sep 2004 12:52:53 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Sep 2004 12:07:27 +0200 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 i8E9keIC029718; Tue, 14 Sep 2004 02:46:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E9keUv029717; Tue, 14 Sep 2004 02:46:40 -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 i8E9kdJZ029699 for ; Tue, 14 Sep 2004 02:46:39 -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 i8E9wIC9001378; Tue, 14 Sep 2004 02:58:18 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8E9wH9j001375; Tue, 14 Sep 2004 02:58:17 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 14 Sep 2004 02:58:17 -0700 (PDT) From: "william(at)elan.net" To: "Anne P. Mitchell, Esq." cc: IETF MARID WG Subject: Re: Work plan for Sender ID In-Reply-To: <533F208D-0629-11D9-B862-000A95AC5778@isipp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 14 Sep 2004 10:07:28.0054 (UTC) FILETIME=[A3D76D60:01C49A42] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > a news.com article covering the very discussions going on here (you all > are aware that the press is reading these archives and reporting on > what they are reading, right?)...anyways, from a news.com article > entitled "Standards group scuttles Microsoft e-mail proposal": Media is reading too much into technical and other discussions going on this group. This kind of media attention in my view is not helpfull to the the IETF process. It also allows different sides instead of using technical arguments inline with IETF process to pressure ietf into making possibly bad decisions due to presumed interest from outside based for example on wild speculation that they represent large groups (when these groups are in fact unwilling to comment directly) and by using interviews, press-conferences and other vendor organized public events to bolster their own image. It would be great if media stop interfering with our process until the WG actually produces standard track RFC documents. At that time, if documents were produced according with IETF standard process and represent concensus of WG participants on the technical solution that does not violate existing standards, then it becomes an issue of deployment of new standard/protocol and media exposure becomes very helpfull in widespread adaption of the new technology. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 10:22:49 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 KAA13673 for ; Tue, 14 Sep 2004 10:22:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EDtTpG074195; Tue, 14 Sep 2004 06:55:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EDtTGK074194; Tue, 14 Sep 2004 06:55:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EDtSAO074187 for ; Tue, 14 Sep 2004 06:55:28 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 15:57:05 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 14 Sep 2004 15:53:58 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Sep 2004 12:50:04 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Sep 2004 10:56:41 +0200 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 i8E8bbBQ003683; Tue, 14 Sep 2004 01:37:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E8bbYb003682; Tue, 14 Sep 2004 01:37:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8E8bbhI003675 for ; Tue, 14 Sep 2004 01:37:37 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8E8bZ1b019993; Tue, 14 Sep 2004 01:37:35 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <533F208D-0629-11D9-B862-000A95AC5778@isipp.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: Work plan for Sender ID Date: Tue, 14 Sep 2004 01:37:34 -0700 To: "william(at)elan.net" X-Mailer: Apple Mail (2.619) List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 14 Sep 2004 08:56:42.0199 (UTC) FILETIME=[C11D5E70:01C49A38] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sep 14, 2004, at 12:12 AM, william(at)elan.net wrote: > Dont you think its more appropraite per IETF practice (and based on > opinions > expressed by the majority of participants of this WG) to say and do the > other way around, that should proceed on the non-encumbered scopes > first > and in addition may consider "encumbered" scopes if they bring enough > benefits to make it worth deploying and if there are no non-encumbered > alternatives that can achieve similar results? > >> As we stated before, the objection to PRA is based on questions of >> deployment caused by incompatibilities with open source licenses. > > There have been significant number of objections to PRA on the > technical > ground as well and most of these have not been answered. But IPR issues > caused so much more discussions that technical problems were not being > noticed. But to say that IPR issues with deployment is the only > objection > to SenderID/PRA in its correction form is simply incorrect. > >> However, there were also a significant number for responses from >> participants stating that they had no such deployment issues. > > I would point out that majority of those expressing support were large > companies who are actually "end-users" that are willing to enter dns > records for their domains. This is significantly less important then > issues of software writers that have to implement capabilities to check > these records. > It would seem that not everyone agrees with you on these points; from a news.com article covering the very discussions going on here (you all are aware that the press is reading these archives and reporting on what they are reading, right?)...anyways, from a news.com article entitled "Standards group scuttles Microsoft e-mail proposal": "Microsoft spokesman Sean Sundwall said the company would continue with its plans to develop its own proposal, Caller ID for E-mail. In August, Microsoft had feted more than 80 e-mail service providers in Redmond, Wash., as part of the E-mail Service Provider Consortium. Between the company's participation in that group and the Anti-Spam Technical Alliance, Microsoft has done a good job of selling major Internet infrastructure companies on the benefits of its proposal. Sundwall would not say whether the IETF's censure would hinder the company's quest to get its Caller ID proposal accepted as a de facto Internet standard. But he did note that many participants stayed out of the vote on Microsoft's involvement. "If you look at the number of contributors that (voted), it is very small," he said." Full article at http://news.com.com/2100-1032-5364075.html Anne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 10:27:55 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 KAA14148 for ; Tue, 14 Sep 2004 10:27:54 -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 i8EDmDhw072844; Tue, 14 Sep 2004 06:48:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EDmDRO072843; Tue, 14 Sep 2004 06:48:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EDm708072819 for ; Tue, 14 Sep 2004 06:48:12 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 15:49:45 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 14 Sep 2004 15:44:04 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Sep 2004 10:33:32 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Sep 2004 10:35:13 +0200 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 i8E87Smr093595; Tue, 14 Sep 2004 01:07:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8E87SSw093594; Tue, 14 Sep 2004 01:07:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail80.messagelabs.com (mail80.messagelabs.com [195.245.230.163]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8E87RrS093579 for ; Tue, 14 Sep 2004 01:07:28 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-6.tower-80.messagelabs.com!1095149102!1697505 X-StarScan-Version: 5.2.10; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 32177 invoked from network); 14 Sep 2004 08:05:02 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-6.tower-80.messagelabs.com with SMTP; 14 Sep 2004 08:05:02 -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 ; Tue, 14 Sep 2004 09:05:01 +0100 Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 To: "william(at)elan.net" Cc: ietf-mxcomp@imc.org, Jim Lyon , owner-ietf-mxcomp@mail.imc.org, Pete Resnick X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Danny Angus Date: Tue, 14 Sep 2004 09:05:02 +0100 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 14/09/2004 09:05:01 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 14 Sep 2004 08:35:13.0376 (UTC) FILETIME=[C0EA9600:01C49A35] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: William at elan wrote: > I note that in above quoted text RFC2822 seems to indicate that use of > Resent fields is only appropriate if message is reitroduced by the user > (and its not clear how that implies in case of MTA is doing forwarding > as in example I provided above). Additionally it seems to imply that > Resent fields have the same meaning as original fields which I take > as position that Resent-From field may only be used by user who is > willing to become new author of the message (but does not make any > alterations to the content when forwarding the message). I do not > believe this applies to the case when user is the original recepient > and when MTA automaticly uses his email when adding Resent-From. However you could argue, and I would, that particularly in the case of ~/.forward and any kind of aliases that the user themselves have re-introduced the message into the mechanism. It may be an automated action, but it is in response to the users instruction (or the instruction of someone acting on their behalf) it just happens to be a "standing order" rather than an explicit decision per message. I'd also strongly support the notion that the user had reintroduced the message by knowingly sending a mail to a mechanism designed to re-introduce it to the system, such as a mailinglist. 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 Tue Sep 14 10:41: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 KAA14994 for ; Tue, 14 Sep 2004 10:41: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 i8EECbKD076374; Tue, 14 Sep 2004 07:12:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EECbQd076373; Tue, 14 Sep 2004 07:12:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EECb3B076367 for ; Tue, 14 Sep 2004 07:12:37 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Accountability!] RE: SPF abused by spammers X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 14 Sep 2004 09:12:39 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D055405@srv1.pan-am.ca> Thread-Topic: [Accountability!] RE: SPF abused by spammers Thread-Index: AcSaYXlIfLUHFsqjQOiLow5z27iVHAAAv99w From: "Gordon Fecyk" To: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8EECb3B076368 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > That's the point -- it's a hop-by-hop scheme. It's _all_ > about how much > you trust the one mail server which is sending you mail. > Where before we > had IP-based blacklists, now there are domain-based > blacklists, without > which SPF/SenderID is largely not useful. I would live with domain based blacklisting. It's easier to manage currently than IP based blacklisting, until reputation services start to take hold or other measures could apply to domains - named entities - instead of numbers. I'm more interested in knowing that example.com is accountable for mail sent in its name. I can deal with whether example.com is worthy or not later. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 10:45: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 KAA15431 for ; Tue, 14 Sep 2004 10:45: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 i8EE6aff075813; Tue, 14 Sep 2004 07:06:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EE6aTN075812; Tue, 14 Sep 2004 07:06:36 -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 i8EE6aTe075806 for ; Tue, 14 Sep 2004 07:06:36 -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 i8EEIHjd010044; Tue, 14 Sep 2004 07:18:17 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8EEIFdU010041; Tue, 14 Sep 2004 07:18:15 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 14 Sep 2004 07:18:15 -0700 (PDT) From: "william(at)elan.net" To: Danny Angus cc: ietf-mxcomp@imc.org, Pete Resnick , Jim Lyon Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 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 Tue, 14 Sep 2004, Danny Angus wrote: > I'd also strongly support the notion that the user had reintroduced the > message by knowingly sending a mail to a mechanism designed to re-introduce > it to the system, such as a mailinglist. In such a case if you believe user has reintroduced the message, that user would have be listed in Resent headers (as per RFC2822 text below), but in reality it is mailing list that is to be listed in Resent-From headers per the marid-core draft. Additionally mailing lists reguarly modify email message and both add their own headers (List-Id, List-Unsubscibe, List-Archive are the ones added by imc mailing list software for example) and modify existing headers (Sender header is replaced by email address, many lists modify Subject, some modify To and Cc) and add new content (mail list footer added to the buttom of the email message). But RFC 2822 says: Resent fields are used to identify a message as having been reintroduced into the transport system by a user. The purpose of using resent fields is to have the message appear to the final recipient as if it were sent directly by the original sender, with all of the original fields remaining the same. I emphasise that it says "all the original fields remaining the same", so it would appear RFC2822 specifically says that Mail lists can not be considered a true user reintroduction of the message and thus Resent-From is inappropriate to be used in such a case. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 10:59:22 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 KAA16264 for ; Tue, 14 Sep 2004 10:59: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 i8EEU5bf077996; Tue, 14 Sep 2004 07:30: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 i8EEU5KZ077995; Tue, 14 Sep 2004 07:30:05 -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 i8EEU0bw077971 for ; Tue, 14 Sep 2004 07:30:04 -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 5EA8116CD2 for ; Tue, 14 Sep 2004 10:39:17 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Mon, 13 Sep 2004 16:34:28 PDT." <1095118467.28424.254.camel@ddev.mail-abuse.org> Date: Tue, 14 Sep 2004 10:39:17 -0400 Message-Id: <20040914143917.5EA8116CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > The MTA may be authorized to send on behalf of MAIL FROM, but that > is not the same as authenticating the entity associated with the > identity MAIL FROM as being the originator. I agree 100%. The problem is that because the bounce path is not verifiable, the originator is anonymous, and the MAIL FROM identity can't be trusted for anything. In the absence of a method to verify the bounce path, authenticating the MTA using the domain in the MAIL FROM identity is a good first step. I can think of scenarios where a domain sends mail from *only* one MTA, and that MTA uses EHLO with another domain name. In that case, the first domain SHOULD have some way of saying "this MTA sends MAIL FROM using my name". Authenticating the EHLO doesn't get you that information, so we need something more. > SPF or Sender-ID confirmation does not mean this entity associated > with the MAIL FROM identity had originated the message. But the recipient can't tell who the "real" originator is. So far as it seesm the SMTP client talking to it's SMTP server *is* the originator. > > Publishers should expect recipients to do the most curious things, > > for the most inane reasons. > > What does this mean? 'publishers should also expect to be black-listed when they publish an "open" record' Not because it's a good idea, but because people will do anything they want, including blacklisting domains containing the letter "a". In other words, our desires about how the records are interpreted may be written down in a specification, but we should not expect everyone to follow that specification. > How do you arrive at publishing an SPF record being tantamount to > accepting accountability for all actions of these authorized entities? If that's what the spec says publishing a record means, that's the semantics of the record. > If one were to authorize a provider to send mail, and their provider's > system became compromised, would it not be better to accredit the > provider for resulting abuse? Multiple parties were involved, multiple parties share the reputation gained through sending those messages. > Won't this resolve the problem sooner than causing an innocent party > to litigate for protection from a sloppy reputation assessment? That's a local legal issue. Some jurisdictions have reasonable laws, others don't. We shouldn't let the possibility of legal action dissuade us from designing a solution. > The marid-mpr draft shows how the authentication of the MTA client can > be accomplished separately from the mailbox-domain authorization. By > doing both steps independently, there is no need to hold the mailbox > domain accountable for the actions of the client MTA they authorize. Interesting. If I authorize someone to act on my behalf, I am generally accountable for at least some of their actions. Removing this accountability is a unique feature of MPR. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 11:36:59 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 LAA18632 for ; Tue, 14 Sep 2004 11:36: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 i8EF6nib082504; Tue, 14 Sep 2004 08:06: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 i8EF6n5D082502; Tue, 14 Sep 2004 08:06:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EF6mmK082495 for ; Tue, 14 Sep 2004 08:06:48 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-086-056.area3.spcsdns.net ([68.245.78.219]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C7EtK-00073A-IX; Tue, 14 Sep 2004 11:06:48 -0400 Message-ID: <414708E6.1080702@solidmatrix.com> Date: Tue, 14 Sep 2004 11:06:14 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "william(at)elan.net" CC: "Anne P. Mitchell, Esq." , IETF MARID WG Subject: Re: Work plan for Sender ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit william(at)elan.net wrote: > >>a news.com article covering the very discussions going on here (you all >>are aware that the press is reading these archives and reporting on >>what they are reading, right?)...anyways, from a news.com article >>entitled "Standards group scuttles Microsoft e-mail proposal": > > > Media is reading too much into technical and other discussions going on > this group. This kind of media attention in my view is not helpfull to > the the IETF process. It also allows different sides instead of using > technical arguments inline with IETF process to pressure ietf into making > possibly bad decisions due to presumed interest from outside based for > example on wild speculation that they represent large groups (when these > groups are in fact unwilling to comment directly) and by using interviews, > press-conferences and other vendor organized public events to bolster > their own image. > > It would be great if media stop interfering with our process until the WG > actually produces standard track RFC documents. At that time, if documents > were produced according with IETF standard process and represent concensus > of WG participants on the technical solution that does not violate existing > standards, then it becomes an issue of deployment of new standard/protocol > and media exposure becomes very helpfull in widespread adaption of the > new technology. > The Tao of the IETF (RFC 3160) points this out as well (section 8.2): ¨Considering all this, it's not surprising that some IETFers would prefer to have the press stay as far away from meetings as possible. Having a bit of press publicity for protocols that are almost near completion and will become significant in the industry in the next year can be a good thing. However, it is the rare reporter who can resist over-hyping a nascent protocol as the next savior for the Internet. Such stories do much more harm than good, both for the readers of the article and for the IETF.¨ Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 11:38: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 LAA18715 for ; Tue, 14 Sep 2004 11:38: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 i8EF50Wx082376; Tue, 14 Sep 2004 08:05:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EF50RL082375; Tue, 14 Sep 2004 08:05:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EF4xKF082364 for ; Tue, 14 Sep 2004 08:04:59 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-086-056.area3.spcsdns.net ([68.245.78.219]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C7ErU-0006tj-HQ; Tue, 14 Sep 2004 11:04:54 -0400 Message-ID: <41470867.5090706@solidmatrix.com> Date: Tue, 14 Sep 2004 11:04:07 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Jim Lyon , ietf-mxcomp@imc.org, Jonathan de Boyne Pollard Subject: Re: DEPLOY: DNS Record Types References: <8571C287-064E-11D9-AAED-000A95B2B926@cisco.com> In-Reply-To: <8571C287-064E-11D9-AAED-000A95B2B926@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Patrik Fältström wrote: > > > On Sep 14, 2004, at 08:57, Jim Lyon wrote: > >> On Monday, September 13, 2004 at 10:39 PM, Jonathan de Boyne-Pollard >> said: >> >>>> The DNS resolver APIs on all Microsoft OS's don't let you >>>> query for an unknown record type. >>> >>> Rubbish. >>> >> >> >> If you're behind a firewall and you call this API with an unknown record >> type, it will fail with INVALID_PARAMETER. > > > What is the chance/risk you have some box behind a firewall, allow > incoming traffic using port 25/TCP but disallow the box to make outgoing > 53/UDP+TCP connections? > > I.e. yes, you are correct on this limitation, but, it will in reality be > possible for the box to send and receive DNS packets by itself IF it is > located so it accept incoming SMTP connections over the Internet. And I > claim enough boxes will be able to do that, and that a minority will > have the problem. > Microsoft is planning on deploying Sender-ID on the MUA level in Outlook and Exchange. Either Jim or Harry mentioned before that they have a working prototype that uses PRA to analyze email. In these cases, the DNS traffic would still be blocked. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 12:04: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 MAA20840 for ; Tue, 14 Sep 2004 12:04:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EFRgJ7084889; Tue, 14 Sep 2004 08:27:42 -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 i8EFRghs084888; Tue, 14 Sep 2004 08:27:42 -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 i8EFRgla084869 for ; Tue, 14 Sep 2004 08:27:42 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id CF01640E4 for ; Tue, 14 Sep 2004 08:27:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: Interpreting "v=spf1" (was Work plan for Sender ID) Date: Tue, 14 Sep 2004 08:27:37 -0700 To: IETF MARID WG 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 Sep 13, 2004, at 8:39 PM, wayne wrote: > I again ask that the "v=spf1 " magic number be interpreted as > "spf2.0/mailfrom,helo" in the SenderID spec. Since "v=spf1" has always been experimental, and changing over time, and hence there is no normative reference for it, I do not think that the next round of drafts should include any official endorsement of what to do with such records. That said, I don't see anything wrong with implementations deciding to support these records as well. However, I would caution that it seems the opinion of many on this list (myself included), that "v=spf1" be treated as valid for only the "mailfrom" scope. I.e.: as "spf2.0/mailfrom". I note that there is no "helo" scope defined (nor will I support one now -- I leave this question for later when we all tackle CSV.) Furthermore, the use of the HELO domain in the classic SPF check does not constitute a check on the HELO scope: It is not ascertaining the authorization of the use of the domain name in HELO. The use of the HELO domain to construct a MAIl FROM identity when the reverse-path is null ("<>") is still checking the authorized use of the domain name as a MAIL FROM name. It does not constitute a blanket assertion about domain use in HELO. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 12:39: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 MAA23651 for ; Tue, 14 Sep 2004 12:38: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 i8EG9OIF089587; Tue, 14 Sep 2004 09:09: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 i8EG9OiV089586; Tue, 14 Sep 2004 09:09:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EG9NJa089579 for ; Tue, 14 Sep 2004 09:09:23 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8EG8C12027161 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Sep 2004 12:08:12 -0400 Date: Tue, 14 Sep 2004 12:08:12 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: peter@bowyer.org cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <56152ae904091309021b274cf3@mail.gmail.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 Mon, 13 Sep 2004, Peter Bowyer wrote: > > On Mon, 13 Sep 2004 11:43:44 -0400 (EDT), Dean Anderson wrote: > > On Mon, 13 Sep 2004, Peter Bowyer wrote: > > > > > > > > Dean Anderson wrote: > > > > On Sun, 12 Sep 2004, Peter Bowyer wrote: > > > > > > > >> > > > >> But AOL won't have spammers on their whitelist. The only domains for > > > >> which an SPF Pass means less filtering are those which are > > > >> pre-whitelisted. And SPF will ensure that mail which appears to be > > > >> from those domains isn't forged. > > > > > > > > This is a false assumption. Any domain that is whitelisted will > > > > attract spammers to that domain. There is no domain or ISP that can > > > > claim not to have spammers ever. > > > > > > They don't whitelist ISP domains - only responsible bulk email senders. > > > People whose mail you want your users to receive. > > > > Yes, such as MSN. > > If they have whitelisted MSN, it will be because they want to receive > mail which is verifiably from MSN. It's not a choice I would make > myself, but their network - their rules. SPF has helped them with the > verification. SPF didn't "verify" anything. SPF just helped AOL paint a target on MSN for spammers and virus writers. Not that I feel sorry for MSN, if they were dumb enough to go along with that. And of course, the "trust" would probably be mutual, so MSN paints a similar target on AOL for spammers and viruses. Mutual self anihilation, I guess. Maybe self-immolation. > > This "trust" is a false assumption. MSN doesn't know whether a particular > > message is spam, until it gets a complaint. It doesn't know whether a > > computer is virus infected until it gets a complaint. It can't certify > > that it doesn't have spammers or virus infections or worms or etc. No one > > can. > > True - but that's the basis of all reputation mechanisms - there's no > absolute authority to refer to, you decide whose opinion you trust. If > AOL trusts MSN, that's their business. I agree. Reputation and trust can't be based on false assumptions. You can't accept promises that you know the other party can't keep, even if they really wanted to. That's true for just about everything, not just spam. Trust implies honesty: Honesty about whether you can perform the promise. If you know you can't perform, yet you promise, you are dishonest. How can you possibly trust someone who is dishonest? > Yes, I agree there - but DNS spoofing is sufficiently rare and hard > for the average email forger to do that a mechanism relying on DNS > will have a tiny probability of being subject to forgery in the real > world. It is rare only because no one trusts DNS, and r-commands have all been turned off. There is nothing to exploit, so there is no point to DNS spoofing. However, it is trivial, and it is easily done by the average forger, if they were motivated to spoof DNS. DNS spoofing of SPF records can result in the ability to send spam, and the ability to deny service. Both bad things. One may be worse than the other. --Dean From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 12:41: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 MAA23815 for ; Tue, 14 Sep 2004 12:41: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 i8EG6vT1089154; Tue, 14 Sep 2004 09:06: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 i8EG6v1k089153; Tue, 14 Sep 2004 09:06:57 -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 i8EG6ug2089144 for ; Tue, 14 Sep 2004 09:06:57 -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; Tue, 14 Sep 2004 12:06:56 -0400 id 0015FAF3.41471721.000042DB Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: by the numbers Date: Tue, 14 Sep 2004 12:06:52 -0400 To: "IETF MARID WG" 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 Sep 13, 2004, at 11:28 PM, wayne wrote: > Can you give me a pointer to this survey that you are referring to? > Can you explain the differences between the 2% you quote and the 36% I > found? Attached you will find a survey that Marcos Sanz and I did of com, net, and de. We did look at every domain but we did sample a statistically significant number of them. I'll reserve my conclusions for now, save the fact that your numbers depend on where you look. -andy com/net de MX Reocrds 7,617,555 1,164,17 MX Records With Address In Target 63,797 521 MX Records With Unresolvable Targets 358,369 13,324 MX Records Pointing To Loopback Address 125,956 949 MX Records At Zone Apex 6,949,466 1,119,31 Wildcard MX Record 668,089 44,861 Unique MX Record by IP Address 2,264,858 196,545 TXT Records 407,961 17,850 Wildcard TXT Record 25,669 187 TXT Records at Zone Apex 356,537 17,474 CNAME'd TXT Records at Zone Apex 248 4 TXT with SPF Content 185,607 2,304 TXT with Caller-ID Content 137 2 TXT with _ep Prefix 25,755 189 TXT with _ep Prefix and No Caller-ID Content 25,624 187 TXT with _ep Prefix and Caller-ID Content 131 2 TXT with _ep Prefix and SPF Content 24,368 156 Wildcard TXT with SPF Content 24,378 156 Wildcard TXT with Caller-ID Content 0 0 TXT at Zone Apex with SPF Content 136,861 1,992 TXT at Zone Apex with Caller-ID Content 6 0 Average Size of All TXT Records 39 21 Avearge Size of All Wildcard TXT Records 12 27 Average Size of All Apex TXT Recrods 43 21 Average Size of All SPF Records 56 27 Average Size of All Caller-ID Records 82 76 Largest TXT Record 423 232 Largest SPF Record 386 232 Largest Caller-ID Record 249 96 Total Number of Domains Scanned 8,477,489 736,725 Domains with A Record at Zone Apex 5,574,982 503,652 Domains with A Record at Apex Pointing to Loopba 867 269 Domains with AAAA Record at Zone Apex 2,284 58 Domains with Address in MX Record 62,513 499 Domains with Unresolvable MX Target 226,673 12,497 Domains with MX Pointing to Loopback Address 86,344 915 Domains with MX Record at Zone Apex 4,697,344 676,517 Domains with TXT Record at Zone Apex 329,707 15,071 Domains with Wildcard MX Record 437,982 26,616 Domains with Wildcard TXT Record 25,619 186 Domains with Apex MX and Wildcard MX 418,547 26,443 Domains with Apex TXT and Wildcard TXT 24,531 181 Domains with SPF 138,603 1,993 Domains with Caller-ID 136 2 Domains with both SPF and Caller-ID 107 1 Domains with SPF and Wildcard TXT 24,378 156 Domains with SPF in Wildcard TXT 24,378 156 Domains with SPF and Wildcard TXT but not Both 0 0 Domains with SPF and Other Content in Wildcard T 4 0 Domains with SPF at Zone Apex 136,853 1,991 Domains with SPF '+all' 7 0 Domains with SPF '-all' 76,386 571 Domains with SPF '?all' 51,005 105 Domains with SPF '~all' 10,351 96 Domains with Caller-ID and Wildcard TXT 26 0 Domains with Caller-ID in Wildcard TXT 0 0 Domains with Caller-ID and Wildcard TXT but not 26 0 Domains with Caller-ID and Other Content in Wild 0 0 Domains with a valid A or MX at the Apex 6,104,870 693,109 Domains with a valid A or MX at the Apex and SPF 130,464 1,926 Domains with a valid A or MX at the Apex and Cal 121 2 Average Size of Wildcard TXT for Domains with Wi 12 27 Average Size of Apex TXT for Domains with Apex T 43 20 Total Number of Domains In Zone(s) 33,887,010 5,896,72 Total Number of Domains Processed 8,477,489 736,725 From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 13:02:23 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 NAA25345 for ; Tue, 14 Sep 2004 13:02:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EGNPhp090817; Tue, 14 Sep 2004 09:23: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 i8EGNPhS090816; Tue, 14 Sep 2004 09:23:25 -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 i8EGNNgV090810 for ; Tue, 14 Sep 2004 09:23:23 -0700 (PDT) (envelope-from sb0-06750fe7d0-johnl@iecc.com) Received: (qmail 16556 invoked by uid 100); 14 Sep 2004 16:23:26 -0000 Date: 14 Sep 2004 16:23:26 -0000 Message-ID: <20040914162326.16555.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: the TCP argument again, consensus call of RR prefix In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: J.deBoynePollard@Tesco.NET Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > If DNS/TCP is blocked at a firewall, then that firewall is badly > configured. No doubt, but if we had all agreed to disregard problems due to misconfiguration, we'd be having a very different discussion. The people who run UltraDNS tell me that they've observed a widespread resolver library bug that fails unpleasantly when a DNS TCP transaction doesn't fit in a single TCP segment. The client incorrectly concludes that the other end aborted the session and it tries again immediately. They discovered this when an apparent DDOS attack turned out in fact to be a whole lot of buggy resolvers trying to fetch an RR set that had recently grown beyond 512 bytes. You don't need to tell us that this shouldn't be a problem. But the reality appears to be that we won't be able to use widespread DNS over TCP for a long time, if ever. It's probably easier to roll out EDNS0, even with all its problems. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I shook hands with Senators Dole and Inouye," said Tom, disarmingly. -- 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 Tue Sep 14 13:12: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 NAA26388 for ; Tue, 14 Sep 2004 13:12: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 i8EGk5q3093499; Tue, 14 Sep 2004 09:46: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 i8EGk542093498; Tue, 14 Sep 2004 09:46:05 -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 i8EGk5ZE093492 for ; Tue, 14 Sep 2004 09:46:05 -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; Tue, 14 Sep 2004 12:46:05 -0400 id 0015FB9B.4147204D.00004769 In-Reply-To: <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8DAA4A62-066D-11D9-BCF4-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: "IETF MARID WG" From: Andrew Newton Subject: Re: by the numbers Date: Tue, 14 Sep 2004 12:45:58 -0400 To: Andrew Newton 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 Sep 14, 2004, at 12:06 PM, Andrew Newton wrote: > We did look at every domain but we did sample a statistically > significant number of them. Correction: We did NOT look at every domain but we did sample a statistically significant number of them. -andy From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 13:24: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 NAA27643 for ; Tue, 14 Sep 2004 13:24: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 i8EGoss2093866; Tue, 14 Sep 2004 09:50:54 -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 i8EGosRf093865; Tue, 14 Sep 2004 09:50:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EGor3F093859 for ; Tue, 14 Sep 2004 09:50:54 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-092-502.area3.spcsdns.net ([68.245.103.240]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C7GW7-000548-1C; Tue, 14 Sep 2004 12:50:56 -0400 Message-ID: <4147214A.5070009@solidmatrix.com> Date: Tue, 14 Sep 2004 12:50:18 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Lentczner CC: IETF MARID WG Subject: Re: Interpreting "v=spf1" (was Work plan for Sender ID) References: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> In-Reply-To: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > > On Sep 13, 2004, at 8:39 PM, wayne wrote: > >> I again ask that the "v=spf1 " magic number be interpreted as >> "spf2.0/mailfrom,helo" in the SenderID spec. > > > Since "v=spf1" has always been experimental, and changing over time, and > hence there is no normative reference for it, I do not think that the > next round of drafts should include any official endorsement of what to > do with such records. > > That said, I don't see anything wrong with implementations deciding to > support these records as well. However, I would caution that it seems > the opinion of many on this list (myself included), that "v=spf1" be > treated as valid for only the "mailfrom" scope. I.e.: as > "spf2.0/mailfrom". Would there be anything wrong with a separate informational draft on this, especially considering that something like your statement above is not readily apparent to implementation authors. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 13:45: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 NAA29098 for ; Tue, 14 Sep 2004 13:45:45 -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 i8EH9OTB095394; Tue, 14 Sep 2004 10:09: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 i8EH9NH2095393; Tue, 14 Sep 2004 10:09:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EH9A7X095356 for ; Tue, 14 Sep 2004 10:09:23 -0700 (PDT) (envelope-from SRS0+12768aad941760ca164b+387+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7Gni-0000HY-OS; Tue, 14 Sep 2004 18:09:08 +0100 Subject: RE: [Accountability!] RE: SPF abused by spammers From: David Woodhouse To: Gordon Fecyk Cc: MARID In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D055405@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125D055405@srv1.pan-am.ca> Content-Type: text/plain; charset=UTF-8 Message-Id: <1095181734.24547.300.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Tue, 14 Sep 2004 18:08:54 +0100 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.2 (+) X-Spam-Report: SpamAssassin version 2.63 on pentafluge.infradead.org summary: Content analysis details: (1.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.1 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [213.86.99.236 listed in dnsbl.sorbs.net] 0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS [213.86.99.236 listed in dnsbl.sorbs.net] X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 2004-09-14 at 09:12 -0500, Gordon Fecyk wrote: > > That's the point -- it's a hop-by-hop scheme. It's _all_ > > about how much > > you trust the one mail server which is sending you mail. > > Where before we > > had IP-based blacklists, now there are domain-based > > blacklists, without > > which SPF/SenderID is largely not useful. > > I would live with domain based blacklisting. It's easier to manage currently > than IP based blacklisting, until reputation services start to take hold or > other measures could apply to domains - named entities - instead of numbers. > > I'm more interested in knowing that example.com is accountable for mail sent > in its name. But for that you need an end-to-end scheme. What you're talking about now is only sufficient to determine the status of _one_ hop. Suppose you receive a message with... MAIL FROM: and Received: from [2002:c1ed:8229:10:2c0:f0ff:fe31:e18] (helo=me) by pentafluge.infradead.org with esmtpsa id 1C7Ej2-0008II-SZ; Tue, 14 Sep 2004 15:56:09 +0100 From: Forwarded-For: joeuser@joeuser.srs.infradead.org (Note I don't use Resent-From: as an example since no reason has been presented for using it instead of a new header. I picked 'Forwarded-For' mostly at random). ... from one of my servers. The mail obviously appears as if it were originally sent by , with authenticated SMTP ('esmtpsa') through my server. Certainly there are people who use my servers that way, because I listen on the MSA port as well as port 25, and some ISPs block port 25. But was it _really_ sent by joeuser@example.com? You have no way of knowing, because this is _not_ an end-to-end validation scheme. You can only decide how much you trust _my_ servers. Note that most current mail user agents will display only the 'From:' header in the above example; the naïve user will see nothing to indicate that this might not actually be from joeuser@example.com. By introducing the rewriting schemes which modify the RFC2821 and RFC2822 identities, which is _required_ for SenderID to be viable in practice, we have turned the 'domain' into nothing more than an arbitrary key which can be selected by each sending mail server. There's nothing _wrong_ with that per se -- at least if we make the naïve assumption that we can get the whole world to 'upgrade' -- but it's unrealistic to pretend that SenderID will let you verify for certain that such a mail really did come from Joe. SenderID can offer only validation of a single hop, and to get any real benefit it needs to be used in conjunction with a trust-database using domain names as its key. And there are _better_ things you could use as a key in your database, without all the breakage that either the mailfrom or pra-replacement scopes require. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 13:57:17 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 NAA00098 for ; Tue, 14 Sep 2004 13:57: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 i8EHMVLk096589; Tue, 14 Sep 2004 10:22:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EHMVZI096588; Tue, 14 Sep 2004 10:22:31 -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 i8EHMVkn096582 for ; Tue, 14 Sep 2004 10:22:31 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8EHMYw8009471 for ; Tue, 14 Sep 2004 10:22:35 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Anne P. Mitchell, Esq." Subject: Re: Work plan for Sender ID Date: Tue, 14 Sep 2004 10:22:34 -0700 To: IETF MARID WG 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 >> a news.com article covering the very discussions going on here (you >> all >> are aware that the press is reading these archives and reporting on >> what they are reading, right?)...anyways, from a news.com article >> entitled "Standards group scuttles Microsoft e-mail proposal": > > Media is reading too much into technical and other discussions going on > this group. This kind of media attention in my view is not helpfull to > the the IETF process. Well, yes. But that really wasn't my point so much as that Microsoft is saying this about what is going on here, and their plans: "Microsoft spokesman Sean Sundwall said the company would continue with its plans to develop its own proposal, Caller ID for E-mail. In August, Microsoft had feted more than 80 e-mail service providers in Redmond, Wash., as part of the E-mail Service Provider Consortium. Between the company's participation in that group and the Anti-Spam Technical Alliance, Microsoft has done a good job of selling major Internet infrastructure companies on the benefits of its proposal. Sundwall would not say whether the IETF's censure would hinder the company's quest to get its Caller ID proposal accepted as a de facto Internet standard. But he did note that many participants stayed out of the vote on Microsoft's involvement. "If you look at the number of contributors that (voted), it is very small," he said." I felt that a fairly interesting data point for what it means for several aspects of the discussions going on here. Anne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 14:35: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 OAA02860 for ; Tue, 14 Sep 2004 14:35: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 i8EHsLG9099941; Tue, 14 Sep 2004 10:54:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EHsLE6099940; Tue, 14 Sep 2004 10:54:21 -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 i8EHsJcT099925 for ; Tue, 14 Sep 2004 10:54:20 -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 1C7HVR-0004Jx-8m for ietf-mxcomp@imc.org; Tue, 14 Sep 2004 12:54:22 -0500 To: "IETF MARID WG" References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 14 Sep 2004 12:54:17 -0500 In-Reply-To: <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> (Andrew Newton's message of "Tue, 14 Sep 2004 12:06:52 -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: by the numbers 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.6 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 <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> Andrew Newton writes: > Attached you will find a survey that Marcos Sanz and I did of com, > net, and de. Thank you very much for posting this! Very interesting. A few questions/comments: * can you tell me when this survey was conducted? * for those looking closely at the numbers, it appears that the last digit of the numbers for the de TLD were sometimes droppped. * it appears that you survedy about 25% of com/net and 12.5% of de. * scaling up the numbers, there appears to be about 750,000 SPF records in com/net and 18,000 SPF records in de. * you found SPF records for around 2% of the com/net domains, but only 0.3% of the de domains. * for com/net, SPF records account for 45% of all TXT records, for de it is only 13% > I'll reserve my conclusions for now, save the fact that your numbers > depend on where you look. I'm sure this is very true. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 14:45: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 OAA03599 for ; Tue, 14 Sep 2004 14:45: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 i8EI7mCF001787; Tue, 14 Sep 2004 11:07: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 i8EI7mSh001786; Tue, 14 Sep 2004 11:07:48 -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 i8EI7l96001780 for ; Tue, 14 Sep 2004 11:07:47 -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 1C7HiS-0002Gl-5d for ietf-mxcomp@imc.org; Tue, 14 Sep 2004 13:07:51 -0500 To: "IETF MARID WG" References: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 14 Sep 2004 13:07:43 -0500 In-Reply-To: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> (Mark Lentczner's message of "Tue, 14 Sep 2004 08:27:37 -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: Interpreting "v=spf1" 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.6 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 <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> Mark Lentczner writes: > On Sep 13, 2004, at 8:39 PM, wayne wrote: >> I again ask that the "v=spf1 " magic number be interpreted as >> "spf2.0/mailfrom,helo" in the SenderID spec. > > Since "v=spf1" has always been experimental, and changing over time, > and hence there is no normative reference for it, I do not think that > the next round of drafts should include any official endorsement of > what to do with such records. Uh, say what? Yes, there have been some changes to the SPF spec since last November, mostly in the area of where can be placed modifiers. Still the marid-protocol spec is almost completely compatible with every SPF spec I can think of. In all the time that we have been discussing using SPFv1 records in this working group, I think this is the first time I've heard anyone claim that they should not be used because they are "experimental." We have heard for people who say that the PRA scope is not the same as the mailfrom and helo scope that SPFv1 uses, and therefore the PRA should have a different record, but that is a different subject. > Furthermore, the use of the HELO domain in the classic SPF check does > not constitute a check on the HELO scope: It is not ascertaining the > authorization of the use of the domain name in HELO. The use of the > HELO domain to construct a MAIl FROM identity when the reverse-path is > null ("<>") is still checking the authorized use of the domain name as > a MAIL FROM name. It does not constitute a blanket assertion about > domain use in HELO. As far as I can see, this is a distinction without a difference. SPF-classic would use apply the check_host() function on the HELO domain in almost exactly the same way that the Unified-SPF HELO check would. All HELO domains would are subject to this checking under SPF-classic, and thus this should be acknowledged. If you want to continue to make a distinction without a difference, call this the mailfrom-helo scope, or the null-mailfrom-helo scope or something. It completely boggles me that you would suggest throwing out the deployment of maybe up to a million SPF records deployed over the last 10 months, just because they are "experimental". -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 14:54:11 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 OAA04058 for ; Tue, 14 Sep 2004 14:54:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EILI3M003397; Tue, 14 Sep 2004 11:21: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 i8EILIos003396; Tue, 14 Sep 2004 11:21:18 -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 i8EILIau003390 for ; Tue, 14 Sep 2004 11:21:18 -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 5596C414C4; Tue, 14 Sep 2004 11:21:22 -0700 (PDT) Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 From: Douglas Otis To: "william(at)elan.net" Cc: Danny Angus , MARID , Pete Resnick , Jim Lyon In-Reply-To: References: Content-Type: text/plain Message-Id: <1095186082.29489.70.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Sep 2004 11:21:22 -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 Tue, 2004-09-14 at 07:18, william(at)elan.net wrote: > On Tue, 14 Sep 2004, Danny Angus wrote: > > > I'd also strongly support the notion that the user had reintroduced the > > message by knowingly sending a mail to a mechanism designed to re-introduce > > it to the system, such as a mailinglist. > > In such a case if you believe user has reintroduced the message, that > user would have be listed in Resent headers (as per RFC2822 text below), > but in reality it is mailing list that is to be listed in > Resent-From headers per the marid-core draft. > Additionally mailing lists reguarly modify email message and both add > their own headers (List-Id, List-Unsubscibe, List-Archive are the > ones added by imc mailing list software for example) and modify existing > headers (Sender header is replaced by email address, many lists modify > Subject, some modify To and Cc) and add new content (mail list footer > added to the buttom of the email message). But RFC 2822 says: > > Resent fields are used to identify a message as having been > reintroduced into the transport system by a user. The purpose of > using resent fields is to have the message appear to the final > recipient as if it were sent directly by the original sender, with > all of the original fields remaining the same. > > I emphasise that it says "all the original fields remaining the same", > so it would appear RFC2822 specifically says that Mail lists can not > be considered a true user reintroduction of the message and thus > Resent-From is inappropriate to be used in such a case. This issue goes away when the MTA EHLO domain is used instead. It also allows the mailbox domain, MAIL FROM or From, to specify a simple name list that can be obtained in a single, non-sequential lookup, to authorize or note as nominal the MTA senders. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 14:54:14 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 OAA04079 for ; Tue, 14 Sep 2004 14:54: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 i8EIH8KP003073; Tue, 14 Sep 2004 11:17: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 i8EIH8qS003072; Tue, 14 Sep 2004 11:17:08 -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 i8EIH1dQ003061 for ; Tue, 14 Sep 2004 11:17:01 -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 BEC2D414C4; Tue, 14 Sep 2004 11:17:04 -0700 (PDT) Subject: Re: SPF abused by spammers From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040914143917.5EA8116CD2@mail.nitros9.org> References: <20040914143917.5EA8116CD2@mail.nitros9.org> Content-Type: text/plain Message-Id: <1095185824.29489.64.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Sep 2004 11:17:04 -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 Tue, 2004-09-14 at 07:39, Alan DeKok wrote: > Douglas Otis wrote: > > The MTA may be authorized to send on behalf of MAIL FROM, but that > > is not the same as authenticating the entity associated with the > > identity MAIL FROM as being the originator. > > I agree 100%. > > The problem is that because the bounce path is not verifiable, the > originator is anonymous, and the MAIL FROM identity can't be trusted > for anything. In the absence of a method to verify the bounce path, > authenticating the MTA using the domain in the MAIL FROM identity is a > good first step. You describe that as authenticating the MTA, but what this operation is doing is validating the MTA as authorized to send a message containing the MAIL FROM. This identity has not been authenticated as originating from the entity associated with the MAIL FROM. > I can think of scenarios where a domain sends mail from *only* one > MTA, and that MTA uses EHLO with another domain name. In that case, > the first domain SHOULD have some way of saying "this MTA sends MAIL > FROM using my name". Authenticating the EHLO doesn't get you that > information, so we need something more. There are two things needed as independent steps. One, authenticate the name of the MTA to allow safe reputation assertions. Two, determine the MTA names authorized by the selected mailbox domain. This can include the MAIL FROM and the From mailbox domains. These two steps then allow for the reputation assertions and the blocking of spoofed mail for either of these mailbox domains. If the authorization list is only nominal, then this list can be used to 'color' the mail at the MUA rather than blocking it. > > SPF or Sender-ID confirmation does not mean this entity associated > > with the MAIL FROM identity had originated the message. > > But the recipient can't tell who the "real" originator is. So far > as it seesm the SMTP client talking to it's SMTP server *is* the > originator. But neither SPF nor Sender-ID properly identify the MTA. > > > Publishers should expect recipients to do the most curious things, > > > for the most inane reasons. > > > > What does this mean? > > 'publishers should also expect to be black-listed when they publish > an "open" record' > > Not because it's a good idea, but because people will do anything > they want, including blacklisting domains containing the letter "a". > > In other words, our desires about how the records are interpreted > may be written down in a specification, but we should not expect > everyone to follow that specification. This means one of two things with respect to SPF or Sender-ID. A) Remove all open list options. B) Demand no reputations be based upon SPF/Sender-ID identities. Option A breaks forwarding and several list servers. Option B only helps reduce some of the spoofing, but does not allow a named based reputation system using SPF or Sender-ID. > > How do you arrive at publishing an SPF record being tantamount to > > accepting accountability for all actions of these authorized entities? > > If that's what the spec says publishing a record means, that's the > semantics of the record. That has not been made clear in the draft nor would allowing open lists reflect this reality. > > If one were to authorize a provider to send mail, and their provider's > > system became compromised, would it not be better to accredit the > > provider for resulting abuse? > > Multiple parties were involved, multiple parties share the > reputation gained through sending those messages. The multiple parties are the customers of the MTA provider. By basing reputation upon the provider by way of the EHLO name, a provider that is not watching their logs or ensuring their server is secure, gets the bad reputation. This directly addresses the abuse problem by stopping the source of the problem. Blocking by the mailbox domain may unfairly block innocent victims of spoofing, but blocking by the MTA EHLO name will safely block the MTA with the problem. If there is a mailbox domain causing abuse, the provider must remove these problem accounts to protect their reputation. That is how it works today, but by using names rather than IP addresses, history is easier to maintain. > > Won't this resolve the problem sooner than causing an innocent party > > to litigate for protection from a sloppy reputation assessment? > > That's a local legal issue. Some jurisdictions have reasonable > laws, others don't. We shouldn't let the possibility of legal action > dissuade us from designing a solution. The solution should be able to accurately identify the source of abuse as a means of avoiding these legal issues. An email reputation service must deal with the entire world. > > The marid-mpr draft shows how the authentication of the MTA client can > > be accomplished separately from the mailbox-domain authorization. By > > doing both steps independently, there is no need to hold the mailbox > > domain accountable for the actions of the client MTA they authorize. > > Interesting. If I authorize someone to act on my behalf, I am > generally accountable for at least some of their actions. Removing > this accountability is a unique feature of MPR. This is establishing a hierarchy of accountability. Those sending mail must vet the accounts they relay to protect their reputation. Those holding accounts must then answer to their providers. If a provider fails to do their job, then as customers see their mail rejected, they are free to find a different provider. Providers will need their own method to vet new accounts. Neither Sender-ID nor SPF help in this regard. Sender-ID and SPF allows lax efforts of providers to hurt their customer's reputation unfairly. This model only seems to offer litigation as a recourse for those unfairly harmed by this sloppy reputation mechanism. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 14:59: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 OAA04377 for ; Tue, 14 Sep 2004 14:59: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 i8EIV5po003948; Tue, 14 Sep 2004 11:31: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 i8EIV5JU003947; Tue, 14 Sep 2004 11:31:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EIV4hL003940 for ; Tue, 14 Sep 2004 11:31:04 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8EIU1IS029776 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Sep 2004 14:30:02 -0400 Date: Tue, 14 Sep 2004 14:30:01 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: peter@bowyer.org cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers 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 Tue, 14 Sep 2004, Dean Anderson wrote: > On Mon, 13 Sep 2004, Peter Bowyer wrote: > > If they have whitelisted MSN, it will be because they want to receive > > mail which is verifiably from MSN. It's not a choice I would make > > myself, but their network - their rules. SPF has helped them with the > > verification. I also forgot to point out the MSN didn't send email, MSN __users__ sent email. We already know they are MSN users from the IP addresses in the Received headers. We still don't know which user it was. Only MSN knows that, and even then, they don't know if it was due to virus/worm/cracking until they investigate. > SPF didn't "verify" anything. SPF just helped AOL paint a target on MSN > for spammers and virus writers. Not that I feel sorry for MSN, if they > were dumb enough to go along with that. And of course, the "trust" would > probably be mutual, so MSN paints a similar target on AOL for spammers and > viruses. Mutual self anihilation, I guess. Maybe self-immolation. Sorry to respond to my own message, but there is one more thing that our proverbial big providers get from this: They get to mutually deny unbundled email services. That is, they get to force their customers to purchase connectivity services from them. There is much more profit margin in the connectivity than in the email anyway. Email is usually free or low dollars. That just causes customers to spend more money with them by abandoning paid-for services that now don't have to be provided. So what if SPF also brings in more spammers and viruses? Preventing unbundling could be good for the bottom line for some providers. --Dean From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 15:06: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 PAA04884 for ; Tue, 14 Sep 2004 15:06: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 i8EITfaL003858; Tue, 14 Sep 2004 11:29: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 i8EITfNh003857; Tue, 14 Sep 2004 11:29:41 -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 i8EITfn1003851 for ; Tue, 14 Sep 2004 11:29:41 -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 EA712414C8; Tue, 14 Sep 2004 11:29:44 -0700 (PDT) Subject: RE: [Accountability!] RE: SPF abused by spammers From: Douglas Otis To: Gordon Fecyk Cc: MARID In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D055405@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125D055405@srv1.pan-am.ca> Content-Type: text/plain Message-Id: <1095186584.29489.80.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Sep 2004 11:29:44 -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 Tue, 2004-09-14 at 07:12, Gordon Fecyk wrote: > > That's the point -- it's a hop-by-hop scheme. It's _all_ about how > > much you trust the one mail server which is sending you mail. Where > > before we had IP-based blacklists, now there are domain-based > > blacklists, without which SPF/SenderID is largely not useful. > > I would live with domain based blacklisting. It's easier to manage currently > than IP based blacklisting, until reputation services start to take hold or > other measures could apply to domains - named entities - instead of numbers. > > I'm more interested in knowing that example.com is accountable for mail sent > in its name. I can deal with whether example.com is worthy or not later. Neither Sender-ID nor SPF provide an identity that will allow this later reputation to be safely established. When example.com sends mail using a EHLO name of mx.example.com, this is not much different than example.com using a MAIL FROM domain of rp.example.com. For that matter, the From mailbox domain does not need to match the identity checked for either Sender-ID and SPF. This makes EHLO no different. Using EHLO does protect customers from lax providers. Making the authenticated EHLO visible would also greatly help reduce phishing. EHLO offers consumer protections that Sender-ID had only promised but without many of the risks. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 15:08:22 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 PAA05333 for ; Tue, 14 Sep 2004 15:08: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 i8EIavDn004511; Tue, 14 Sep 2004 11:36: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 i8EIavrM004510; Tue, 14 Sep 2004 11:36:57 -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 i8EIavfe004498 for ; Tue, 14 Sep 2004 11:36:57 -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; Tue, 14 Sep 2004 14:36:56 -0400 id 0015FB9C.41473A4A.000053FB Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_zak.ecotroph.net-21499-1095187019-0001-2" In-Reply-To: References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> Message-Id: <0C3633E5-067D-11D9-BCF4-000A95B3BA44@hxr.us> From: Andrew Newton Subject: Re: by the numbers Date: Tue, 14 Sep 2004 14:36:52 -0400 To: "IETF MARID WG" 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-21499-1095187019-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On Sep 14, 2004, at 1:54 PM, wayne wrote: > * can you tell me when this survey was conducted? com/net was done July 5. I believe de was done August 18. I do have com/net numbers around mid-august, by the were not much different. I just don't have them handy at the moment. > * for those looking closely at the numbers, it appears that > the last digit of the numbers for the de TLD were sometimes droppped. I'll attach a CSV (the other CSV) format. > * it appears that you survedy about 25% of com/net and 12.5% of de. I believe both are well above the number needed for statistical significance. >> I'll reserve my conclusions for now, save the fact that your numbers >> depend on where you look. > > I'm sure this is very true. I was merely pointing out the differences between com/net and de. -andy --=_zak.ecotroph.net-21499-1095187019-0001-2 Content-Type: text/tab-separated-values; x-mac-type=54455854; x-unix-mode=0644; x-mac-creator=5843454C; name="maridscan.csv"; charset=iso-8859-1 Content-Disposition: attachment; filename=maridscan.csv Content-Transfer-Encoding: quoted-printable ,com/net,de=0DMX Reocrds,"7,617,555","1,164,178"=0DMX Records With = Address In Target,"63,797",521=0DMX Records With Unresolvable = Targets,"358,369","13,324"=0DMX Records Pointing To Loopback = Address,"125,956",949=0DMX Records At Zone Apex,"6,949,466","1,119,317"=0D= Wildcard MX Record,"668,089","44,861"=0D=0DUnique MX Record by IP = Address,"2,264,858","196,545"=0D=0DTXT Records,"407,961","17,850"=0D= Wildcard TXT Record,"25,669",187=0DTXT Records at Zone = Apex,"356,537","17,474"=0DCNAME'd TXT Records at Zone Apex,248,4=0DTXT = with SPF Content,"185,607","2,304"=0DTXT with Caller-ID Content,137,2=0D= TXT with _ep Prefix,"25,755",189=0DTXT with _ep Prefix and No Caller-ID = Content,"25,624",187=0DTXT with _ep Prefix and Caller-ID Content,131,2=0D= TXT with _ep Prefix and SPF Content,"24,368",156=0DWildcard TXT with SPF = Content,"24,378",156=0DWildcard TXT with Caller-ID Content,0,0=0DTXT at = Zone Apex with SPF Content,"136,861","1,992"=0DTXT at Zone Apex with = Caller-ID Content,6,0=0D=0DAverage Size of All TXT Records,39,21=0D= Avearge Size of All Wildcard TXT Records,12,27=0DAverage Size of All = Apex TXT Recrods,43,21=0DAverage Size of All SPF Records,56,27=0DAverage = Size of All Caller-ID Records,82,76=0DLargest TXT Record,423,232=0D= Largest SPF Record,386,232=0DLargest Caller-ID Record,249,96=0D=0DTotal = Number of Domains Scanned,"8,477,489","736,725"=0DDomains with A Record = at Zone Apex,"5,574,982","503,652"=0DDomains with A Record at Apex = Pointing to Loopback Addr,867,269=0DDomains with AAAA Record at Zone = Apex,"2,284",58=0DDomains with Address in MX Record,"62,513",499=0D= Domains with Unresolvable MX Target,"226,673","12,497"=0DDomains with MX = Pointing to Loopback Address,"86,344",915=0DDomains with MX Record at = Zone Apex,"4,697,344","676,517"=0DDomains with TXT Record at Zone = Apex,"329,707","15,071"=0DDomains with Wildcard MX = Record,"437,982","26,616"=0DDomains with Wildcard TXT = Record,"25,619",186=0DDomains with Apex MX and Wildcard = MX,"418,547","26,443"=0DDomains with Apex TXT and Wildcard = TXT,"24,531",181=0DDomains with SPF,"138,603","1,993"=0DDomains with = Caller-ID,136,2=0DDomains with both SPF and Caller-ID,107,1=0DDomains = with SPF and Wildcard TXT,"24,378",156=0DDomains with SPF in Wildcard = TXT,"24,378",156=0DDomains with SPF and Wildcard TXT but not Both,0,0=0D= Domains with SPF and Other Content in Wildcard TXT,4,0=0DDomains with = SPF at Zone Apex,"136,853","1,991"=0DDomains with SPF '+all',7,0=0D= Domains with SPF '-all',"76,386",571=0DDomains with SPF = '?all',"51,005",105=0DDomains with SPF '~all',"10,351",96=0DDomains with = Caller-ID and Wildcard TXT,26,0=0DDomains with Caller-ID in Wildcard = TXT,0,0=0DDomains with Caller-ID and Wildcard TXT but not Both,26,0=0D= Domains with Caller-ID and Other Content in Wildcard TXT,0,0=0DDomains = with a valid A or MX at the Apex,"6,104,870","693,109"=0DDomains with a = valid A or MX at the Apex and SPF,"130,464","1,926"=0DDomains with a = valid A or MX at the Apex and Caller-ID,121,2=0D=0DAverage Size of = Wildcard TXT for Domains with Wildcard TXT,12,27=0DAverage Size of Apex = TXT for Domains with Apex TXT,43,20=0D=0DTotal Number of Domains In = Zone(s),"33,887,010","5,896,720"=0DTotal Number of Domains = Processed,"8,477,489","736,725"= --=_zak.ecotroph.net-21499-1095187019-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --=_zak.ecotroph.net-21499-1095187019-0001-2-- From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 15: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 PAA05454 for ; Tue, 14 Sep 2004 15:09: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 i8EIXVno004181; Tue, 14 Sep 2004 11:33:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EIXVcF004180; Tue, 14 Sep 2004 11:33:31 -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 i8EIXVqB004174 for ; Tue, 14 Sep 2004 11:33:31 -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 43E91414C5; Tue, 14 Sep 2004 11:33:35 -0700 (PDT) Subject: Re: All members of "we" please raise your hands. From: Douglas Otis To: Stephane Bortzmeyer Cc: Jonathan de Boyne Pollard , MARID In-Reply-To: <20040914064058.GB15185@nic.fr> References: <7E16C0A4-027B-11D9-AAED-000A95B2B926@cisco.com> <20040914064058.GB15185@nic.fr> Content-Type: text/plain Message-Id: <1095186815.29489.85.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Sep 2004 11:33:35 -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 Mon, 2004-09-13 at 23:40, Stephane Bortzmeyer wrote: > On Thu, Sep 09, 2004 at 06:48:03PM +0100, > Jonathan de Boyne Pollard wrote > a message of 28 lines which said: > > > Does this "we" include those who are, right now, educating people with > > the following? > > spf.pobox.com contains many marketing promises that > are... careless. (Some people could say "dishonest".) They also keep > pretending that there are "RFCs" about SPF. webmaster@pobox.com never > replies on such matters. > > Nevertheless, here, in the MARID working group, we can say the truth > :-) SPF (or SenderID) does not assert anything about the spaminess of > the message but about its authenticity (a spam can be authentic). SPF or Sender-ID validates the MTA as authorized to send messages on behalf of the mailbox domain. Neither of these mechanisms authenticate the message as originating from the specific mailbox domain. That assumption of authentication will lead to grievous errors. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 16:49: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 QAA19247 for ; Tue, 14 Sep 2004 16:49: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 i8EKIHs9011947; Tue, 14 Sep 2004 13:18:17 -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 i8EKIHvQ011946; Tue, 14 Sep 2004 13:18:17 -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 i8EKIE07011939 for ; Tue, 14 Sep 2004 13:18:17 -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 028F716CD2 for ; Tue, 14 Sep 2004 16:27:36 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Tue, 14 Sep 2004 11:17:04 PDT." <1095185824.29489.64.camel@ddev.mail-abuse.org> Date: Tue, 14 Sep 2004 16:27:36 -0400 Message-Id: <20040914202737.028F716CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > You describe that as authenticating the MTA, but what this operation is > doing is validating the MTA as authorized to send a message containing > the MAIL FROM. The recipient (SMTP server) is authorizing the MTA (SMTP client) as an MTA authentically within the domain named in MAIL FROM. > There are two things needed as independent steps. One, authenticate the > name of the MTA to allow safe reputation assertions. And that's where I disagree. For me, the point of MAIL FROM authentication is not about reputation assertions, it's about the ability of the domain named in MAIL FROM to control the use of it's name. e.g. example.com & example.org share an outgoing MTA: out.example.com. In SMTP conversations, it announces itself as "EHLO out.example.com". It may then say "MAIL FROM: user@example.org". Nothing in SMTP today permits the recipient to determine if "out.example.com" is a valid outgoing MTA for example.org. My goal in this area is to provide a way to make that determination. Stopping spam, and reputation services, are interesting, but not something I find to be practical. i.e. If MAIL FROM authentication records in DNS stop other people using my name in vain, that's great. I don't care how other people restrict (or not) the user of their names: that's up to them. For me, the issue isn't that authentication will stop other people from spamming me, it's that it will stop other people from claiming that I'm spamming them. > But neither SPF nor Sender-ID properly identify the MTA. For some meaning of the word "properly". > Blocking by the mailbox domain may unfairly block innocent victims > of spoofing, but blocking by the MTA EHLO name will safely block the > MTA with the problem. You then label everyone at the MTA with a broad brush. Sure, the MTA is ultimately responsible, but if a recipient can use "MAIL FROM" to tell that a subset of domains via that MTA are "bad", then it would be imprudent to label *all* domains at that MTA "bad", just because you authenticated the MTA via EHLO. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 17:14: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 RAA21895 for ; Tue, 14 Sep 2004 17:14: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 i8EKiG7J014693; Tue, 14 Sep 2004 13:44: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 i8EKiGaJ014692; Tue, 14 Sep 2004 13:44:16 -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 i8EKiGxQ014686 for ; Tue, 14 Sep 2004 13:44:16 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8EKiKgx016120 for ; Tue, 14 Sep 2004 13:44:20 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: SPF abused by spammers Date: Tue, 14 Sep 2004 13:44:19 -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 > > True - but that's the basis of all reputation mechanisms - there's no > > absolute authority to refer to, you decide whose opinion you trust. > If > > AOL trusts MSN, that's their business. > > I agree. Reputation and trust can't be based on false assumptions. You > can't accept promises that you know the other party can't keep, even if > they really wanted to. That's true for just about everything, not just > spam. This is exactly why reputation is only one part of it, and only offers a complete package when coupled (tripled?) authentication and accreditation - our IADB (ISIPP Accreditation Database) being one example of the latter. Look for more accreditation databases to show up, particularly as authentication moves more into place. The *big* difference is that an accreditation database doesn't promise anything about the quality of the email coming from the IPs listed therein. It tells you factual information about the mailing policies, processes, and other data about the sender. For example, IADB tells you (via a DNS lookup) whether the sender uses confirmed (double) opt-in, whether they publish SPF records, whether they are listed in Habeas or Bonded Sender, etc.. The latter two, by contrast, are reputation databases, even though some (mistakenly in my opinion) call them accreditation. They are whitelists which tell you what email you should accept from the sender, and why ("because we say so, for such-and-such a reason"), which is reputation. An accreditation database is not a whitelist - it simply reports factual information, and you base your own email processing and delivery decisions based thereon. All three have a part - an important part. Authentication gets you to "who is this really?"; accreditation gets you to "what are they doing?", and reputation gets you to "what do others whom I trust think about what they are doing". In a perfect world, in my opinion, everyone would check SPF or other authentication records, query an accreditation database like IADB, and then either query a reputation system of their choice such Habeas or Bonded Sender - or make a note from the IADB results that the sender is listed with a service like Habeas or Bonded Sender (note that this does not diminish the Habeas or Bonded Sender model - in fact it helps them - we give points for participating in either - it just reduces the query to their database by one). It's free to do those checks and queries, and if done properly, the time you save in how you can more efficiently deal with questionable mail more than makes up for any extra lookups. Anne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 17:50:17 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 RAA25027 for ; Tue, 14 Sep 2004 17:50:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ELEFSn016227; Tue, 14 Sep 2004 14:14:15 -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 i8ELEF2j016226; Tue, 14 Sep 2004 14:14:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend1.messagingengine.com (frontend1.messagingengine.com [66.111.4.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ELEENr016220 for ; Tue, 14 Sep 2004 14:14:14 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: AYX1r+aWsLXa45+QuEuh4w 1095196457 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend1.messagingengine.com (Postfix) with ESMTP id 33F31C15556; Tue, 14 Sep 2004 17:14:15 -0400 (EDT) Message-ID: <41475F45.90707@elvey.com> Date: Tue, 14 Sep 2004 14:14:45 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF-MXCOMP Cc: Carl Hutzler , Stephane Bortzmeyer , Jim Lyon , John Leslie Subject: HELO, IPR, A&R means new draft?; scope; Microsoft - (Re: DEPLOY - IP, HELO & touch count. ) 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 This is a belated-due-to-to-travel follow-up to replies to this post: http://www.imc.org/ietf-mxcomp/mail-archive/msg03596.html (Summary: Sender ID fails to be a solution that only requires sysadmin action; it mandates end-user reconfiguration on a massive scale, because it doesn't say that HELO checking should/must be done... The Microsoft IPR are too encumbered...) The issues I raised in my last post were appropriate during a last call: They were raised earlier, and there were strong indications that they would be addressed (e.g. the Unified SPF discussion and documents). Yet they were in fact not addressed by the specs that were in last call. "=-=-=-=" <-- topic separator I think John Leslie said that under SenderID, a domain's reputation would be looked up by looking up the IPs its SPF2 record lists in an IP blacklist. I think John is confused - that's not what I am expecting. I'm expecting the domain itself to be looked up in a RHSBL. That's Right Hand Side Block List. (John's idea could prove useful, but I'd be surprised if it, e.g., scored well if coded as a SpamAssassin rule and evaluated) =-=-=-=-= On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey: > > >> Phrased differently: >> Sender ID fails to be a solution that only requires sysadmin action; it >> mandates end-user reconfiguration on a massive scale, because, IIRC, it >> doesn't say that HELO checking should/must be done. Hence I (of >> elvey.com) would have to get all my domain's end users to use MSAs that >> I (as DNS admin of elvey.com) knew about. For fastmail.fm, my email >> provider, who hosts mail for thousands of domains, they would have to >> support this for each user of each domain!) If HELO checking is >> mandatory, they just send HELO fastmail.fm, and ensure that fastmail.fm >> has a good reputation. > > > This is a VERY interesting approach. I think you are saying, scratch using > DNS for "listing Domains allowed to be sent by an IP address", and instead > have the system admin "program" those domains into the MTAs (e.g. a config > in sendmail). The MTA would HELO the domain they are about to send for, IF > THE MTA is told they are allowed to send for that domain in the first > place > - otherwise the mail is rejected (and likely much closer to the submission > MTA/MSA). > > This sounds really cool. But I am an engineer and must always ask, what is > wrong with this and why has it not been thought of before? > > Lets see, forwarding cases....might work here with some PRA/Submitter type > changes. Not a huge problem. Forwarding case would work GREAT - no PRA/SUBMITTER needed. Yes, 'The MTA would HELO the domain they are about to send for.' This domain wouldn't have to match the MAIL FROM or PRA or SUBMITTER. It would simply need to be a domain that had an appropriate reputation for the content. E.g. if we assume AOL is responsible about ensuring very little spam is sent using the servers it authorizes to do HELO aol.com, and sends all email through these servers, then there is no forwarding to worry about. Helo aol.dom would trigger a reputation check on aol.dom as used in HELO, the repuation would be excellent, and no further checks would be necessary - the From: domain or PRA could be elvey.dom or DomainWithNoSPFrecord.dom. Here's a sophisticated possible scenario that provides more flexibility: AOL might do HELO goodAolPayingCustomer.dom, if the mail is from one, and the customer hasn't recently sent a ton of email. It might use HELO aolSuspectCustomer.dom where appropriate, before cutting the customer off completely. AOL wouldn't have to pay to give goodAolPayingCustomer.dom a good reputation; it would deserve it. AOL wouldn't have to cut off customers as often - it could limit use in a less draconian way. Helo aolTrialUser.dom and HELO AOLFreeEmailUser.dom would make sense, provided AOL provided and used dedicated IPs for such mail and created the appropriate DNS records. Just to clarify: the above is a sophisticated, enhanced solution that HELO-based reputations make *possible*. It will be perfectly OK for an MTA (or all of a domain's MTAs) to have one domain that goes in all HELO/EHLO commands sent, and this is likely to be the usual case, and will work well. > > OK so what is wrong with this? Well, no criticism so far, other than from Jim, which I've addressed thoroughly. > > > -Carl > > On 8/26/2004 11:12 AM, Jim Lyon accurately summarized and conveyed: > Matthew Elvey raises two points that I summarize as follows: > >> 1. If you don't know what a domain's outward-facing MTAs are, >> it's really hard to build a SenderID record. (And he estimates >> that half of his customers are in this boat.) > > > True. > >> 2. If instead of SenderID, we'd merely authenticated the HELO name, >> and built up reputation systems that say whether particular >> HELO names behave reasonably, these people's lives would be easier. > > > It's true, but it's a whole lot weaker form of authentication. Please, I've already explained why it is stronger. If you're going to say it's weaker after it's been explained WHY it's stronger, please respond to the provided arguments. You need to do this or you drag the conversation to the level. [edit: it looks like you've had the argument with Doug in this thread.] > I don't > care whether a mail server is who he says he is, I care whether he's > authorized to send the message he's trying to send. Can we please graduate to more advanced banter than this? The charter says what we care about. (It's adequate, even if the main goal is to address spam, including joe-jobs, phishing, etc.) The first half of the sentence states that you don't care about the server's Identity, and I know that you in fact do; SenderID relies on Identity. I fail to find a logical argument for ignoring HELO. You imply you care about the body of the message, but SenderID doesn't look at the body. (Why are you calling a mail server a 'he'? It's confusing.) Jim Lyon later also said: > Authorization: The SenderID test determines whether the sending MTA is > authorized to send mail that claims to come from a particular domain. This is a too-short definition (which you later improved upon); it's actually not accurate. A mail message can claim to be from several domains. Jim later clarified things: > The identity being authorized is the > sending MTA's IP address. The action being authorized is to send a > message on behalf of the PRA. The organization doing the authorization > is the domain of the PRA. PRA, if adopted, will be manipulated by spammers by the insertion of forged headers. (I'm working on an example.) =-=-=-=-=-=-= I understand that the last call was considered by the Chairs to be a failure only because of the IPR issues. There are other issues, I believe. Some other points that inform whether SenderID was ready for RFC status: I indicated that certain changes that appeared to be imminent would make SenderID gain my support, but it turned out that those changes were not made. E.g. In June, I posted here: http://www.imc.org/ietf-mxcomp/mail-archive/msg02404.html : > "I'm not trying to deep 6 SPF. I'm trying to make it stronger and > better by attacking its weaknesses virtually, while they are readily > fixable. Note, I recently expressed my support Unified SPF (which > incorporates a CSV-like check). BTW, I was surprised that the -01 > SenderID drafts that came out didn't have any Unified SPF stuff in > 'em. I interpreted something Meng said to mean that I should expect > to see it in a draft soon, so I'm still expecting that." The cynic in me wonders if this was an effort to derail my plan to create an I-D that remedied the weaknesses I saw. That was its effect. -=-=-=- I have a $50+ spf t-shirt. I'm trying to make MARID's work successful. OTOH: A principal of my mail provider (fastmail.fm's Jeremy H) is so unhappy with SPF that he's suggesting configurations that appear designed to *sabotage* its effectivenness; an IESG member's criticism is provided as justification: http://www.emailaddresses.com/forum/showthread.php?threadid=22341&highlight=spf A comment on the power of reputation: Remember, Unified SPF and its cousins rely on reputation services. Such services already exist : [DNS|RHS][W|B]LS, etc. If an EHLO domain gets an initial pass, the reputation check could be a lookup of that domain speficially with respect to its use in EHLO, such as a DNS lookup of nonspammers.dom.ehlo.mail-abuse.org. However, I suspect this may not be necessary, and a DNS lookup such as nonspammers.dom.SPF.mail-abuse.org would suffice, and a reputation service would only need maintain a single reputation per domain with respect to is use with Unified SPF and cousins. What do folks think? A reputation service would need maintain how many reputations per domain with respect to is use with Unified SPF and cousins? An add'l reputation that may be useful would be at, say nonspammers.dom.bounce.SPF.mail-abuse.org. This reputation might reflect whether nonspammers.dom's mailservers were properly configured to refuse mail at smtp time whenever possible, and thus not likely sources of bogus bounces such as joe-jobs. Andrew Newton wrote: > On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote: >> A HELO scope would be useful. > That is already being covered by the CSV proposals. No, not even close. -protocol with CSV, and -protocol with a HELO scope would be EXTREMELY different, can't believe you don't see this, Andy! It's certainly been explained many times, on-list, by many people. I see strong confirmation that HELO scope would be useful, and an appropriate change to make. I see little reasoned opposition to a A HELO scope. Let's add it or hear some reasoned opposition. -protocol with a HELO scope would have giant advantages over plain -protocol or -protocol with CSV, which have been detailed on-list, e.g. by me as reasons to make a HELO check mandatory, and as reasoning for Unified SPF. Certainly it has some disadvantages as well, which have also been detailed on-list. The only one that made sense to me was that it would make it more likely for a domain not to specify a list to be used for PRA or MAIL FROM verification. The disadvantage of that is that such a domain would receive more joe-job bounces, though there's an argument that there would be fewer as well: MARID requiring HELO is easier to deploy effectively, therefore likely to be deployed faster. Also this disadvantage applies to SenderID as well- it allows joe-job-type bounces to joe-job victims. Only SPF+SRS doesn't have this disadvantage, and only where the unwanted bounces would be coming from a server that had implemented SPF. Some reasons the market may go with the HELO scope instead of the others (assuming this leave-it-to-the-market proposal flies) are that it has the advantages of not using restricted IPR, doesn't break forwarding/mail-list/backup mx operations, and doesn't require end-user action to implement. Also, Accuspam implicitly asked an interesting question - why specify what the list of servers may be used for? Here's an answer: It's generally much easier to specify a list of servers that will legitimately use a domain (e.g. elvey.com) in HELO than it is to specify a list of servers that will use that domain in PRA or 2821.MAIL FROM! Hence some folks will only want to specify the former. Some folks may want to specify a smaller set of servers for one versus another. Accuspam said : "Publishing the approved mail servers is something everybody can agree to do I think?" but this is more complicated than it seems at first glance, because the set of approved servers for a given domain is different depending on what its approved for. As Meng said, if HELO and SUBMITTER (modified to not use the encumbered IPR) always override MAIL-FROM, then there is no need for SRS. In addition to/as part of the security review of SenderID: I think it's necessary that a number of MAYs and SHOULD [NOT]s turn into SHOULD [NOT]s and MUST [NOT]s. There is far too much waffling - MUST [NOTs] MUST be used whereever there isn't a compelling reason not to. IETF standards demand it. Also, the way that Accredidation and Reputation services are to be used is essential. It belongs in a BCP, which should specify BFP (Best Future Practice) for how various tests should be interpreted and acted upon. SPF claims to address the spam problem (according to text that was on the spf.pobox.com home page) so the Accredidation and Reputation services that are a necessary component to this solution must be specified. An incomplete spec that lacks these things has no business aspiring to be an Internet Standard. How can a spec that is grossly incomplete be properly reviewed by us or the IESG? It can't! E.g. John Leslie is quite confused about how A&R might work, or I am, as mentioned above. Regarding IPR: I am certain that the Microsoft staff working in this area are smart enough to be aware of how their license is defective and how it needs to be fixed. They can all read. As time passes and they continue to fail to fix it, blame for failure of the IETF to address the spam problem falls gradually more squarely on Microsoft and its staff's shoulders. (They got involved in the process, worked patent pending ideas they have claims on into drafts amid promises of licensing that wouldn't be problematic, Microsoft threw its weight around, and now the licensing is not satisfactory.) As they've had ample time to do so and haven't done so, we need to move on without PRA. =-=-=-=-= Subj:Re: problems with patents: the IDN example from RFC3669 wayne wrote: >... the people running this working group. > As I understand it: The members of the working group run the working group. The chairs have limited authority. They mostly express their opinion as to what the rules are, and what consensus has been reached, and help provide needed infrastructure. Their opinions are not binding, AFAIK. For example, they've expressed an (IMO chilling, incorrect and inappropriate) opinion that certain comments regarding Microsoft and its interests were inappropriate. I explained in my last post why some (not necessarily all, of course) of such comments ARE appropriate in this forum, with reference to IETF policy describing what is and is not appropriate. They don't get to decide. (They get to invoke BCP 83 mechanisms, and the IESG can express binding opinions.) WRT to the importance of the highly divisive IPR issues, their opinion doesn't hold much more weight than anyone else's, IMO. I believe they shoot themselves in the foot by making consensus claims that aren't accurate, e.g claiming rough consensus has been reached on something when in fact it hasn't. I sympathize however; they are trying to meet deadlines and keep the peace. It's a tough job. I'm sorry if the above is felt inflammatory. I talked to a couple folks who felt it needed to be said, and is as toned down as I could make it. =-=-=-=- Clarification: On 8/25/2004 1:55 AM, Stephane Bortzmeyer sent forth electrons to convey: > On Tue, Aug 24, 2004 at 08:05:52PM -0700, > Matthew Elvey wrote > a message of 80 lines which said: > >> 1)A good fraction (I'd estimate 1/2) of my end users have their MTAs >> configured to send through several SMTP servers, using different >> From:'s > > You mean "their MUAs", not "their MTAs"? Because, although I know MUA > with source routing (Thunderbird), I do not know how to do it > properly with typical Unix MTAs. > Yes. =-=-=-=-= Sorry these comments weren't more timely. So, who's for a new draft with two scopes: HELO and MAIL-FROM? (Wait, how about a third scope: From:? This would be something phishedbank.dom might want to use to indicate that it would rather break forwarding than allow its domain to be used in From: without its authorization. Do folks think phishedbanks would actually use such a scope? (I'm reopening a closed can of worms; perhaps given the failed last call, it's time to do so.)) From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 18:25: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 SAA00188 for ; Tue, 14 Sep 2004 18:25: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 i8ELjXeW019042; Tue, 14 Sep 2004 14:45:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ELjXq5019041; Tue, 14 Sep 2004 14:45:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ELjIEB019018 for ; Tue, 14 Sep 2004 14:45:31 -0700 (PDT) (envelope-from SRS0+b6bc7fa9ee44c1c0e503+387+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7L6v-0006LP-56; Tue, 14 Sep 2004 22:45:13 +0100 Subject: RE: [Accountability!] RE: SPF abused by spammers From: David Woodhouse To: Douglas Otis Cc: Gordon Fecyk , MARID In-Reply-To: <1095186584.29489.80.camel@ddev.mail-abuse.org> References: <700EEF5641B7E247AC1C9B82C05D125D055405@srv1.pan-am.ca> <1095186584.29489.80.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1095198312.9144.318.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Tue, 14 Sep 2004 22:45:12 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-09-14 at 11:29 -0700, Douglas Otis wrote: > > I'm more interested in knowing that example.com is accountable for mail sent > > in its name. I can deal with whether example.com is worthy or not later. > > Neither Sender-ID nor SPF provide an identity that will allow this later > reputation to be safely established. Right. > When example.com sends mail using a EHLO name of mx.example.com, this > is not much different than example.com using a MAIL FROM domain of > rp.example.com. Indeed. It's just an arbitrary key into some form of trust database now -- just some identification handle for the 'entity' which claims to take responsibility for the mail server or group of mail servers in question. > For that matter, the From mailbox domain does not need to match the > identity checked for either Sender-ID and SPF. This is a very important point. We're _not_ verifying the From: header or indeed anything which the user is actually going to see. It _doesn't_ help stop your muppet users from clicking on the link and entering all their bank details. You'd need an end-to-end solution for that, not a hop-by-hop solution which permits me to send: MAIL FROM: From: admin@bigbank.com To: sucker@darwinwaswrong.com Forwarded-For: sucker@mydomain.org Please enter your details doing?", and reputation gets you to "what do others whom I trust think > about what they are doing". Authentication: yes. Reputation: yes. Accreditation: why would I care? By this I mean: can you give an example of how this would change my opinion based on their reputation? Alex From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 18:50: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 SAA02034 for ; Tue, 14 Sep 2004 18:50: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 i8EMN6AI021943; Tue, 14 Sep 2004 15:23: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 i8EMN60l021942; Tue, 14 Sep 2004 15:23:06 -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 i8EMN67D021936 for ; Tue, 14 Sep 2004 15:23:06 -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 394CE414C4; Tue, 14 Sep 2004 15:23:11 -0700 (PDT) Subject: Re: SPF abused by spammers From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040914202737.028F716CD2@mail.nitros9.org> References: <20040914202737.028F716CD2@mail.nitros9.org> Content-Type: text/plain Message-Id: <1095200590.29546.72.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Sep 2004 15:23:11 -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 Tue, 2004-09-14 at 13:27, Alan DeKok wrote: > Douglas Otis wrote: > > You describe that as authenticating the MTA, but what this operation is > > doing is validating the MTA as authorized to send a message containing > > the MAIL FROM. > > The recipient (SMTP server) is authorizing the MTA (SMTP > client) as an MTA authentically within the domain named in MAIL FROM. >From the Latin authenticus- coming from the real author, of original or first-hand authority. It would be a mistake to apply this term to a second-hand authority, as is the case with SPF or Sender-ID. It would be safer not to describe the real author (the mailbox domain at least) as authenticated. Rather, this mailbox domain has authorized second-hand parties to act on their behalf and claim this authorization has been validated. > > There are two things needed as independent steps. One, authenticate the > > name of the MTA to allow safe reputation assertions. > > And that's where I disagree. For me, the point of MAIL FROM > authentication is not about reputation assertions, it's about the > ability of the domain named in MAIL FROM to control the use of it's > name. > > e.g. example.com & example.org share an outgoing MTA: > out.example.com. In SMTP conversations, it announces itself as "EHLO > out.example.com". It may then say "MAIL FROM: user@example.org". > > Nothing in SMTP today permits the recipient to determine if > "out.example.com" is a valid outgoing MTA for example.org. My goal in > this area is to provide a way to make that determination. Stopping > spam, and reputation services, are interesting, but not something I > find to be practical. If the EHLO name had been authenticated and the authorization validated, as possible with CSV, then to assert which MTAs are authorized to send mail on behalf of a mailbox domain only requires a very simple list of PTR records. This list can be obtained from a single DNS query and not require any subsequent lookups to ascertain related addresses. The addresses will have already been checked by the "no-added overhead" CSV operation. > i.e. If MAIL FROM authentication records in DNS stop other people > using my name in vain, that's great. I don't care how other people > restrict (or not) the user of their names: that's up to them. For me, > the issue isn't that authentication will stop other people from > spamming me, it's that it will stop other people from claiming that > I'm spamming them. >From an overhead standpoint, this goal of stopping spoofed mail is better done using two steps. One is CSV, and the other is MPR. CSV does not add to the DNS overhead at all. MPR only requires a highly deterministic single query to obtain authorization lists and the level of the assertions. This has the added advantage of not providing a spam exploit where these authorization list are claimed to offer (bogus) "authentication" of the MTA. > > But neither SPF nor Sender-ID properly identify the MTA. > > For some meaning of the word "properly". It is not proper to claim an MTA, authorized to send messages with my-small-business mailbox domain, is the same as being administered by my-small-business.com. With SPF or Sender-ID, don't suggest second-party servers for big-isp.com are administered by my-small-business.com simply because an SPF or Sender-ID record granted big-isp.com authorization to send messages. To say that SPF or Sender-ID authenticate big-isp.com as "being" my-small-business.com only confuses the issue. The risk from this muddled thinking is that these identities may be employed to unfairly establish reputations. > > Blocking by the mailbox domain may unfairly block innocent victims > > of spoofing, but blocking by the MTA EHLO name will safely block the > > MTA with the problem. > > You then label everyone at the MTA with a broad brush. Sure, the > MTA is ultimately responsible, but if a recipient can use "MAIL FROM" > to tell that a subset of domains via that MTA are "bad", then it would > be imprudent to label *all* domains at that MTA "bad", just because > you authenticated the MTA via EHLO. When the MTA administrator does not revoke access to abusive accounts, why consider any message from this MTA to be valid? The MTA may be compromised or not checking SPF or Sender-ID records. To block some mailbox domain coming from a suspect MTA will also block this mailbox domain from all other MTAs. When the problem was with the MTA in question, blocking the mailbox domain currently being spoofed will only cause great harm to that domain and not stop the problem, as the abuser will simply spoof the next mailbox domain (victim). The reputation service is unable to determine what is being checked at the MTA. The reputation service does not know the source of the message as you wish to imply. The reputation service would be making a grievous error assuming the MTA was being properly administered and the mailbox domain was actually the source of the message. Again, the mailbox domain was not authenticated as you imply. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 18:58: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 SAA02404 for ; Tue, 14 Sep 2004 18:58: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 i8EMXvhV023165; Tue, 14 Sep 2004 15:33: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 i8EMXv8N023164; Tue, 14 Sep 2004 15:33:57 -0700 (PDT) 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 i8EMXuML023158 for ; Tue, 14 Sep 2004 15:33:56 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Tue, 14 Sep 2004 18:33:59 -0400 id 0000000000157937.00000000414771D7.000030F0 X-IMAP-Sender: mrsam@courier-mta.com References: <4144782E.70607@ehsco.com> <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> <48C10B41-0650-11D9-BCF4-000A95B3BA44@hxr.us> 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: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 Date: Tue, 14 Sep 2004 18:33:58 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-12392-1095201238-0005"; 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-12392-1095201238-0005 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Andrew Newton writes: > > > On Sep 13, 2004, at 10:21 AM, Jonathan de Boyne Pollard wrote: > >> Even 3 years after the publication of RFC 2821, which obviated the >> requirement that caused these to be done in the first place, many SMTP >> Relay client softwares _still_ perform "ANY" DNS lookups instead of >> separate "CNAME" and "MX" lookups (or, better yet in light of RFC 2821, >> just "MX" lookups). > > I looked into this about a year ago and found that most MTAs did MX > then A,AAAA. Generally, DNS servers will return a CNAME in response to a query for any RR for that hostname; and recursive resolvers will follow the CNAME chain. The original client receives a reply that includes all the CNAMEs, and the MX RRs; provided that everything fits in the UDP packet. --=_mimegpg-commodore.email-scan.com-12392-1095201238-0005 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBR3HWx9p3GYHlUOIRArGBAJ4y4/zpXj2iND00dxdpEqMSOkbURwCfedJ9 SfX/sHbsqM0SPuwJuzwT7ts= =ZFkd -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-12392-1095201238-0005-- From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 18:58:48 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 SAA02445 for ; Tue, 14 Sep 2004 18:58:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EMP5pe022078; Tue, 14 Sep 2004 15:25: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 i8EMP5Uj022077; Tue, 14 Sep 2004 15:25:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EMP3Kn022061 for ; Tue, 14 Sep 2004 15:25:03 -0700 (PDT) (envelope-from SRS0+b6bc7fa9ee44c1c0e503+387+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7LjX-0006P1-Jo; Tue, 14 Sep 2004 23:25:07 +0100 Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 From: David Woodhouse To: Andrew Newton Cc: IETF MARID WG In-Reply-To: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1095200707.9144.376.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Tue, 14 Sep 2004 23:25:07 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2004-09-11 at 13:59 -0400, Andrew Newton wrote: > The document authors have agreed to producing new drafts intended to > meet the chartered work item, and a consensus call on them or the > appropriate diffs will be forthcoming. This work plan does not include > scopes outside of "mail from" and "pra", and it is our opinion that no > new work items of this type should be considered until MARID has > successfully produced a first specification. I strongly disagree with this opinion. I believe that it does not make sense to have multiple scopes, and certainly not to plan to add even more scopes later. I shall explain my reasoning: The 'mail from' and 'pra' scopes require significant changes in current practice, which would essentially require the entire Internet to 'upgrade' to conform. Setting aside the deployment problems posed by this, let us assume that despite the fact that most of them haven't even discovered ESMTP yet, the whole world _does_ actually manage to upgrade tomorrow; to perform SRS and to add whatever we decide to use instead of the badly-chosen 'Resent-From:' header. Once such an upgrade has occurred, the identities actually _checked_ by either scope would be modified automatically by mail servers as the mail is in transit -- each mail server could pick any arbitrary 'domain' to put into those identities for checking, as long as the DNS records for that 'domain' permit the IP address of the server in question. The identity which is being checked at each hop would no longer be directly related to the original sender of the mail, but merely serves as a verified identifier for the entity which controls the mail server in question, and can be used to determine a level of trust for that server. Therefore, the 'mail from' and 'pra' scopes should be considered equal, not as complementary forms of 'authentication'. Once the whole world has upgraded, each scope provides merely an arbitrary handle by which to classify the mail host which is submitting a given mail. That is why it does not make sense to offer multiple scopes. One would suffice, and it should be one which does not suffer potential IPR problems and which does not require such a worldwide 'upgrade'. The HELO identifier checked against an IP address, or a signature on TLS certificates, or perhaps the SUBMITTER SMTP extension, would provide an equally suitable identifier for the entity responsible for a given mail server, without any of the technical difficulties. Therefore, the working group should abandon the 'mail from' and 'pra' scopes and seek a _single_ scope which serves the purpose of identifying the entity responsible for a given mail server. The problem of true authentication of senders is a separate one which needs to be addressed by a true end-to-end method. To use a hop-by-hop method based solely on IP addresses for such a task is inherently insecure and is counter-productive due to the confusion it causes. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 19:02: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 TAA02681 for ; Tue, 14 Sep 2004 19:02: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 i8EMcUxK023520; Tue, 14 Sep 2004 15:38: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 i8EMcUn1023519; Tue, 14 Sep 2004 15:38:30 -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 i8EMcTmh023509 for ; Tue, 14 Sep 2004 15:38:29 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id E5A4340E0 for ; Tue, 14 Sep 2004 15:38:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: Interpreting "v=spf1" Date: Tue, 14 Sep 2004 15:38:28 -0700 To: "IETF MARID WG" 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 I worded my post on this topic carefully. I never said that "v=spf1" records "should not be used", nor did I suggest "throwing out the deployment of .. SPF records". I am against them being included as part of the standard. We should not drag the "v=spf1" records into issues of conformance, interoperability, future deployment and/or deprecation, etc. Let's not complicate the situation for publishers of records even more by throwing "v=spf1" into the mix. I am for implementations supporting them. Of course "v=spf1" records can be almost certainly interpreted at "spf2.0/mailfrom". Surely, any implementation can do this trivially. They should. But when things go wrong with "v=spf1" records, for any reason, better for us to be able to all say: "Use the standard" - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 19:45:04 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 TAA05610 for ; Tue, 14 Sep 2004 19:45:04 -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 i8ENECwn026208; Tue, 14 Sep 2004 16:14: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 i8ENECVW026207; Tue, 14 Sep 2004 16:14:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ENEBg1026196 for ; Tue, 14 Sep 2004 16:14:12 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3EF1EE06B1; Tue, 14 Sep 2004 19:14:15 -0400 (EDT) Date: Tue, 14 Sep 2004 19:14:15 -0400 From: John Leslie To: Matthew Elvey Cc: IETF-MXCOMP Subject: Re: HELO, IPR, A&R means new draft?; scope; Microsoft - (Re: DEPLOY - IP, HELO & touch count. ) Message-ID: <20040914231415.GC84206@verdi> References: <41475F45.90707@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41475F45.90707@elvey.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Matthew Elvey wrote: > > I think John Leslie said that under SenderID, a domain's reputation > would be looked up by looking up the IPs its SPF2 record lists in an IP > blacklist. More exactly, I said one could build a reputation service this way. It was _a_ way to build a reputation service; not an _only_ way. > I think John is confused - that's not what I am expecting. I'm > expecting the domain itself to be looked up in a RHSBL. The question is, how would such a RHSBL be maintained? It seemed to me that any RHS that scored poorly under that scheme would need to be on a hair-trigger because it could go from zero to a million spams in a matter of seconds. (I'm not the least bit sure this is a good time to discuss the issue, but I'd like to minimize confusion about what the issue is...) -- John Leslie From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 19:50:34 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 TAA05858 for ; Tue, 14 Sep 2004 19:50:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ENJ3ld026706; Tue, 14 Sep 2004 16:19:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ENJ2dv026705; Tue, 14 Sep 2004 16:19:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ENJ2dO026698 for ; Tue, 14 Sep 2004 16:19:02 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i8ENJ40A002485 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Sep 2004 19:19:06 -0400 Date: Tue, 14 Sep 2004 19:19:04 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Anne P. Mitchell, Esq." cc: IETF MARID WG Subject: Re: SPF abused by spammers 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 Tue, 14 Sep 2004, Anne P. Mitchell, Esq. wrote: > > > True - but that's the basis of all reputation mechanisms - there's no > > > absolute authority to refer to, you decide whose opinion you trust. > > If > > > AOL trusts MSN, that's their business. > > > > I agree. Reputation and trust can't be based on false assumptions. You > > can't accept promises that you know the other party can't keep, even if > > they really wanted to. That's true for just about everything, not just > > spam. > > This is exactly why reputation is only one part of it, and only offers > a complete package when coupled (tripled?) authentication and > accreditation - our IADB (ISIPP Accreditation Database) being one > example of the latter. Look for more accreditation databases to show > up, particularly as authentication moves more into place. I'm not sure these databases aren't a good idea. I haven't really thought them through enough to offer an opinion. My first impression on hearing of them was that they were just another scam to get money from ISPs. First impressions aren't always right. Knowing policies seems like it couldn't hurt, although, like blacklists (ORBS, SORBS, MAPS, etc), these database operators could easily lie and do harm. Since we've already had so many bad experiences with blacklists, we aren't so gullible anymore about who we trust. (well less so anyway) The present scheme for blacklists is to find some college student with no assets in another country to claim ownership or else to be completely anonymous to prevent being held legally and financially responsible for false statemnts. And the anti-spam community also has no scruples about continuing associations with court-proven liars and those who have previously violated the trust placed in them to block only spammers. I'm not sure I'd call such databases "reputation". "Reputation" is something that is acquired over time, by the opinion of many people, not just one person. Not even a smallish group of people. 'Reputation' is that thing that some will try to smear, and others honestly report. Time reveals truth and reputation. No database can do that. > All three have a part - an important part. Authentication gets you to > "who is this really?"; accreditation gets you to "what are they > doing?", and reputation gets you to "what do others whom I trust think > about what they are doing". But to get an answer to "who is this really", the authentication has to actually work. MTA Authentication doesn't achieve this goal. Even with MTA 'authentication', the sender isn't really authenticated, and you don't know who you're really dealing with. Further, no indication either way is given. A system that is always right in a certain situation and often wrong in others can still be useful. While a system that is uncertain in all situations has no use. Accredidation just lists a companies/end users/ISPs policies. A user won't know if they really implement those policies, and there is no way to distinguish a company with pink contracts from ordinary security and disposable signup problems. But even larger, given our past bad experiences with blacklists, we can't trust anyone not to use such lists for revenge. And there is still the problem I described with reputation: since an ISP/end user/company/etc can never vouch that it will never sign up a (disposable) spammer nor vouch that its users won't get viruses or worms, nor even that its own systems won't be compromised. So reputation systems based on such claims are based on dishonesty to begin with. Such a system is basically just a negative reputation system: It lists only those who lie or aren't smart enough to know they're lying. I don't think this triad works. > In a perfect world, in my opinion, everyone would check SPF or other > authentication records, query an accreditation database like IADB, and > then either query a reputation system of their choice such Habeas or > Bonded Sender - or make a note from the IADB results that the sender is > listed with a service like Habeas or Bonded Sender (note that this > does not diminish the Habeas or Bonded Sender model - in fact it helps > them - we give points for participating in either - it just reduces the > query to their database by one). A little offtopic: I don't think the spam problem can be solved technically, based on information theory constraints, that is on the notion that one can't ever prove that there aren't covert channels in a communication system. The term 'covert channels' specifically comes from the analysis of operating systems and spying, but the information theory principles on which the notion of covert channels is based are not specific to operating systems or spying. Similar analyses have been done on other types of systems, using different terms than 'covert channel', such as 'sneaky channel' Without going into too much detail, this means the spam problem (like the spying problem) is always a whack-a-mole problem. We can detect spam, and whack spammers. But spammers are always free to sign up again, infect systems, etc, and otherwise adapt to whatever means we invent to detect spam. The alternative is to restrict their behavior non-technically, and that requires a lawful means of coercion, which requires some kind of legal process. Further off-topic, a thought occured to me recently after someone recently mentioned "the economics of spam". My first thought was that they were misusing the term economics. They meant "profits". 'Economics' is a science about how costs, and profits and such things interact. One cannot actually change the "economics" of spam. One can only change the costs and profits of spam. Then it occured to me: a principle of economics states that if a business finds a way to reduce costs, then the rest of its competitors __have_no_choice__ but to follow suit in order to remain competitive. In other words, spam should have a measurable impact on the industry segments whose products are being spammed. In other words, the Viagra retailers not using spam should be going broke. Viagra may not be a good example, since Viagra is a prescription drug, and nearly all Viagra spam is a hoax, not actually selling Viagra. But there are other products that are being advertised via spam. The competing companies should be going broke because the spamming companies have lowered their costs. Just like the local grocery store is hard hit by Walmart. But, for some reason, this isn't happening. I don't have the background to do the necessary economic research, but there should be a measurable impact due to spam, and not just on ISPs. For those who didn't follow the above, let me put it this way: When Walmart comes to town, things change. We should be able to detect and measure those changes. --Dean From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 20:22: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 UAA07688 for ; Tue, 14 Sep 2004 20:22: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 i8ENn7og028715; Tue, 14 Sep 2004 16:49: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 i8ENn7gQ028714; Tue, 14 Sep 2004 16:49:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ENn6BF028708 for ; Tue, 14 Sep 2004 16:49:06 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: Tc5/BsVvVHCJ6BjR9JeRyQ 1095205749 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 6650756D3A7; Tue, 14 Sep 2004 19:49:08 -0400 (EDT) Message-ID: <414783A9.6050904@elvey.com> Date: Tue, 14 Sep 2004 16:50:01 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Lentczner , mengwong+spf@pobox.com, MXCOMP Subject: Misinformation - Re: Interpreting "v=spf1" (was Work plan for Sender ID) References: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> In-Reply-To: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> 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 "v=spf1" MUST be valid for the "HELO" scope or the message/record is not compliant enough with the SPF specification to ensure a 'pass'. Mark's statements to the contrary are incorrect. (Read the spec - the SPF I-D - http://spf.pobox.com/spf-draft-200406.txt , which says that the HELO check MAY be done on any message. Hey, Meng - it's way too hard to find the I-Ds on the site since the redesign! ) From the spec: "An SMTP sending host MUST also resolve a "pass" for all the SPF-conformant domains which appear in the "HELO" or "EHLO" command." Mark Lentczner wrote: > On Sep 13, 2004, at 8:39 PM, wayne wrote: > >> I again ask that the "v=spf1 " magic number be interpreted as >> "spf2.0/mailfrom,helo" in the SenderID spec. > > [T]he use of the HELO domain in the classic SPF check does not > constitute a check on the HELO scope: See spec. > It is not ascertaining the authorization of the use of the domain name > in HELO. See spec. > The use of the HELO domain to construct a MAIL FROM identity when > the reverse-path is null ("<>") is still checking the authorized use > of the domain name as a MAIL FROM name. See spec. > It does not constitute a blanket assertion about domain use in HELO. See spec. From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 20:23: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 UAA07714 for ; Tue, 14 Sep 2004 20:23: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 i8ENrbmj028920; Tue, 14 Sep 2004 16:53:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ENrbZe028919; Tue, 14 Sep 2004 16:53:37 -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 i8ENrbVX028902 for ; Tue, 14 Sep 2004 16:53:37 -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 89B8D414C5; Tue, 14 Sep 2004 16:53:34 -0700 (PDT) Subject: Re: HELO, IPR, A&R means new draft?; scope; Microsoft - (Re: DEPLOY - IP, HELO & touch count. ) From: Douglas Otis To: Matthew Elvey Cc: IETF-MXCOMP , Carl Hutzler , Stephane Bortzmeyer , Jim Lyon , John Leslie In-Reply-To: <41475F45.90707@elvey.com> References: <41475F45.90707@elvey.com> Content-Type: text/plain Message-Id: <1095206014.29546.143.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Sep 2004 16:53: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 Tue, 2004-09-14 at 14:14, Matthew Elvey wrote: > This is a belated-due-to-to-travel follow-up to replies to this post: > http://www.imc.org/ietf-mxcomp/mail-archive/msg03596.html > (Summary: Sender ID fails to be a solution that only requires sysadmin > action; it mandates end-user reconfiguration on a massive scale, because > it doesn't say that HELO checking should/must be done... The Microsoft > IPR are too encumbered...) > > The issues I raised in my last post were appropriate during a last > call: They were raised earlier, and there were strong indications that > they would be addressed (e.g. the Unified SPF discussion and > documents). Yet they were in fact not addressed by the specs that were > in last call. > > "=-=-=-=" <-- topic separator > > I think John Leslie said that under SenderID, a domain's reputation > would be looked up by looking up the IPs its SPF2 record lists in an IP > blacklist. > I think John is confused - that's not what I am expecting. I'm > expecting the domain itself to be looked up in a RHSBL. That's Right > Hand Side Block List. (John's idea could prove useful, but I'd be > surprised if it, e.g., scored well if coded as a SpamAssassin rule and > evaluated) The obvious reaction to this technique would be to spoof IP addresses of known good MX servers in these records. As I said before, the mailbox domain within SPF and Sender-ID is worthless for reputation checks. In this respect, John is right in this case. The address must be used for any checks or reputation assessment. > =-=-=-=-= > On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey: > > > > > > >> Phrased differently: > >> Sender ID fails to be a solution that only requires sysadmin action; it > >> mandates end-user reconfiguration on a massive scale, because, IIRC, it > >> doesn't say that HELO checking should/must be done. Hence I (of > >> elvey.com) would have to get all my domain's end users to use MSAs that > >> I (as DNS admin of elvey.com) knew about. For fastmail.fm, my email > >> provider, who hosts mail for thousands of domains, they would have to > >> support this for each user of each domain!) If HELO checking is > >> mandatory, they just send HELO fastmail.fm, and ensure that fastmail.fm > >> has a good reputation. > > > > > > This is a VERY interesting approach. I think you are saying, scratch using > > DNS for "listing Domains allowed to be sent by an IP address", and instead > > have the system admin "program" those domains into the MTAs (e.g. a config > > in sendmail). The MTA would HELO the domain they are about to send for, IF > > THE MTA is told they are allowed to send for that domain in the first > > place > > - otherwise the mail is rejected (and likely much closer to the submission > > MTA/MSA). > > > > This sounds really cool. But I am an engineer and must always ask, what is > > wrong with this and why has it not been thought of before? It has been considered and there is language within CSV that accommodates this approach. : ) > > Lets see, forwarding cases....might work here with some PRA/Submitter type > > changes. Not a huge problem. > > Forwarding case would work GREAT - no PRA/SUBMITTER needed. Yes, 'The > MTA would HELO the domain they are about to send for.' This domain > wouldn't have to match the MAIL FROM or PRA or SUBMITTER. It would > simply need to be a domain that had an appropriate reputation for the > content. E.g. if we assume AOL is responsible about ensuring very > little spam is sent using the servers it authorizes to do HELO aol.com, > and sends all email through these servers, then there is no forwarding > to worry about. Helo aol.dom would trigger a reputation check on aol.dom > as used in HELO, the repuation would be excellent, and no further checks > would be necessary - the From: domain or PRA could be elvey.dom or > DomainWithNoSPFrecord.dom. > Here's a sophisticated possible scenario that provides more flexibility: > AOL might do HELO goodAolPayingCustomer.dom, if the mail is from one, > and the customer hasn't recently sent a ton of email. It might use HELO > aolSuspectCustomer.dom where appropriate, before cutting the customer > off completely. AOL wouldn't have to pay to give > goodAolPayingCustomer.dom a good reputation; it would deserve it. AOL > wouldn't have to cut off customers as often - it could limit use in a > less draconian way. Helo aolTrialUser.dom and HELO AOLFreeEmailUser.dom > would make sense, provided AOL provided and used dedicated IPs for such > mail and created the appropriate DNS records. > Just to clarify: the above is a sophisticated, enhanced solution that > HELO-based reputations make *possible*. It will be perfectly OK for an > MTA (or all of a domain's MTAs) to have one domain that goes in all > HELO/EHLO commands sent, and this is likely to be the usual case, and > will work well. > > > OK so what is wrong with this? > > Well, no criticism so far, other than from Jim, which I've addressed > thoroughly. > > > -Carl > > > On 8/26/2004 11:12 AM, Jim Lyon accurately summarized and conveyed: > > > Matthew Elvey raises two points that I summarize as follows: > > > >> 1. If you don't know what a domain's outward-facing MTAs are, > >> it's really hard to build a SenderID record. (And he estimates > >> that half of his customers are in this boat.) > > > > True. > > > >> 2. If instead of SenderID, we'd merely authenticated the HELO name, > >> and built up reputation systems that say whether particular > >> HELO names behave reasonably, these people's lives would be easier. > > > > It's true, but it's a whole lot weaker form of authentication. > > Please, I've already explained why it is stronger. If you're going to > say it's weaker after it's been explained WHY it's stronger, please > respond to the provided arguments. You need to do this or you drag the > conversation to the level. > [edit: it looks like you've had the argument with Doug in this thread.] I find it difficult to believe people will allow themselves to be harmed by reputation services that hold them accountable for any MTA authorized to send their mail. I can imagine the conversation: (ac=angry party, rs=reputation service) ap> Why in the h*ll did you put by domain on your rhsbl? rs> There are incidents where this mailbox domain was used in spam. ap> I never sent this cr*p! rs> Ah, but you authorized the MTA that sent it. ap> What authorization caused this problem? rs> This will require investigating and a fee to resolve. ap> Too bad Sender-ID does not identify the authentic sender! > > I don't care whether a mail server is who he says he is, I care > > whether he's authorized to send the message he's trying to send. May I add that the marid-mpr draft can safely answer this question within a single DNS query and not require the potentially hundreds needed by Sender-ID or SPF. > Can we please graduate to more advanced banter than this? The charter > says what we care about. (It's adequate, even if the main goal is to > address spam, including joe-jobs, phishing, etc.) > The first half of the sentence states that you don't care about the > server's Identity, and I know that you in fact do; SenderID relies on > Identity. I fail to find a logical argument for ignoring HELO. You > imply you care about the body of the message, but SenderID doesn't look > at the body. (Why are you calling a mail server a 'he'? It's confusing.) > > Jim Lyon later also said: > > > Authorization: The SenderID test determines whether the sending MTA is > > authorized to send mail that claims to come from a particular domain. > > This is a too-short definition (which you later improved upon); it's > actually not accurate. A mail message can claim to be from several > domains. > > Jim later clarified things: > > > The identity being authorized is the sending MTA's IP address. The > > action being authorized is to send a message on behalf of the PRA. > > The organization doing the authorization is the domain of the PRA. > > PRA, if adopted, will be manipulated by spammers by the insertion of > forged headers. (I'm working on an example.) > > =-=-=-=-=-=-= > Andrew Newton wrote: > > On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote: > >> A HELO scope would be useful. > > That is already being covered by the CSV proposals. > > No, not even close. -protocol with CSV, and -protocol with a HELO scope > would be EXTREMELY different, can't believe you don't see this, Andy! Please consider the need for two steps in this process. One, authenticate and validate the authorization of the MTA EHLO name. Two, obtain a list of authorized EHLO names referenced by the mailbox domain being examined. This list can be either nominal or comprehensive without the nominal case inviting spoofing. In which case, CSV remains "as-is". MPR records are much simpler and easier to maintain and obtain than scripts for SPF or Sender-ID. I would suggest avoiding sequential TXT scripts needed with either SPF or Sender-ID as being unworkable. CSV used in combination with MPR and BATV provides all the features claimed by either SPF, SRS or Sender-ID without disrupting email to the same extent. There is another issue with either SPF or Sender-ID records. CSV and MPR are named based solutions that work within the natural scale of DNS and only require single non-sequential lookups. SPF or Sender-ID require either extensive iterative references to record names to obtain addresses, or the repeating of IP addresses in a script form. The maintenance of such a list will be high, or the relative overhead to use such a list will be high or both. > As Meng said, if HELO and SUBMITTER (modified to not use the encumbered > IPR) always override MAIL-FROM, then there is no need for SRS. With a public version of BATV there is no need for SRS either. > In addition to/as part of the security review of SenderID: > I think it's necessary that a number of MAYs and SHOULD [NOT]s turn > into SHOULD [NOT]s and MUST [NOT]s. There is far too much waffling - > MUST [NOTs] MUST be used whereever there isn't a compelling reason not > to. IETF standards demand it. > > Also, the way that Accredidation and Reputation services are to be used > is essential. It belongs in a BCP, which should specify BFP (Best > Future Practice) for how various tests should be interpreted and acted > upon. SPF claims to address the spam problem (according to text that > was on the spf.pobox.com home page) so the Accredidation and Reputation > services that are a necessary component to this solution must be > specified. An incomplete spec that lacks these things has no business > aspiring to be an Internet Standard. How can a spec that is grossly > incomplete be properly reviewed by us or the IESG? It can't! > E.g. John Leslie is quite confused about how A&R might work, or I am, as > mentioned above. Let me clarify. Neither Sender-ID nor SPF will support RHSBLs. > =-=-=-=-= > Sorry these comments weren't more timely. > > So, who's for a new draft with two scopes: HELO and MAIL-FROM? > > (Wait, how about a third scope: From:? This would be something > phishedbank.dom might want to use to indicate that it would rather break > forwarding than allow its domain to be used in From: without its > authorization. Do folks think phishedbanks would actually use such a > scope? (I'm reopening a closed can of worms; perhaps given the failed > last call, it's time to do so.)) You will find that the marid-mpr draft does allow the protection of the >From and the MAIL FROM and is a good alternative to the PRA approach. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 20:28:36 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 UAA08169 for ; Tue, 14 Sep 2004 20:28:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ENsegd029010; Tue, 14 Sep 2004 16:54:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ENse4U029009; Tue, 14 Sep 2004 16:54:40 -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 i8ENsbTL029002 for ; Tue, 14 Sep 2004 16:54:40 -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 i8ENsaRu014684; Tue, 14 Sep 2004 16:54:42 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Sep 2004 16:54:36 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'David Woodhouse'" , Andrew Newton Cc: IETF MARID WG Subject: RE: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 Date: Tue, 14 Sep 2004 16:54:35 -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: I agree with Andy. I thought we should have done this all along. The mail from and pra mechanisms are merely means of interpreting and using the SPF data. The data itself consists of no more and no less than a set of IP addresses corresponding to approved outgoing edge servers which may or may not be known (and specified) to be complete. Phill > -----Original Message----- > From: David Woodhouse [mailto:dwmw2@infradead.org] > Sent: Tuesday, September 14, 2004 6:25 PM > To: Andrew Newton > Cc: IETF MARID WG > Subject: Re: co-chair judgment of consensus related to last > call period > of 23-Aug-2004 to 10-Sept-2004 > > > > On Sat, 2004-09-11 at 13:59 -0400, Andrew Newton wrote: > > The document authors have agreed to producing new drafts > intended to > > meet the chartered work item, and a consensus call on them or the > > appropriate diffs will be forthcoming. This work plan does > not include > > scopes outside of "mail from" and "pra", and it is our > opinion that no > > new work items of this type should be considered until MARID has > > successfully produced a first specification. > > I strongly disagree with this opinion. I believe that it does not make > sense to have multiple scopes, and certainly not to plan to add even > more scopes later. I shall explain my reasoning: > > The 'mail from' and 'pra' scopes require significant changes > in current > practice, which would essentially require the entire Internet to > 'upgrade' to conform. > > Setting aside the deployment problems posed by this, let us > assume that > despite the fact that most of them haven't even discovered ESMTP yet, > the whole world _does_ actually manage to upgrade tomorrow; to perform > SRS and to add whatever we decide to use instead of the badly-chosen > 'Resent-From:' header. > > Once such an upgrade has occurred, the identities actually > _checked_ by > either scope would be modified automatically by mail servers > as the mail > is in transit -- each mail server could pick any arbitrary 'domain' to > put into those identities for checking, as long as the DNS records for > that 'domain' permit the IP address of the server in question. > > The identity which is being checked at each hop would no longer be > directly related to the original sender of the mail, but merely serves > as a verified identifier for the entity which controls the mail server > in question, and can be used to determine a level of trust for that > server. > > Therefore, the 'mail from' and 'pra' scopes should be > considered equal, > not as complementary forms of 'authentication'. Once the > whole world has > upgraded, each scope provides merely an arbitrary handle by which to > classify the mail host which is submitting a given mail. > > That is why it does not make sense to offer multiple scopes. One would > suffice, and it should be one which does not suffer potential IPR > problems and which does not require such a worldwide > 'upgrade'. The HELO > identifier checked against an IP address, or a signature on TLS > certificates, or perhaps the SUBMITTER SMTP extension, would > provide an > equally suitable identifier for the entity responsible for a > given mail > server, without any of the technical difficulties. > > Therefore, the working group should abandon the 'mail from' and 'pra' > scopes and seek a _single_ scope which serves the purpose of > identifying > the entity responsible for a given mail server. > > The problem of true authentication of senders is a separate one which > needs to be addressed by a true end-to-end method. To use a hop-by-hop > method based solely on IP addresses for such a task is inherently > insecure and is counter-productive due to the confusion it causes. > > -- > dwmw2 > > From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 21:45:57 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 VAA15998 for ; Tue, 14 Sep 2004 21:45: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 i8F1JbIn034154; Tue, 14 Sep 2004 18:19: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 i8F1JWeh034151; Tue, 14 Sep 2004 18:19:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8F1JURl034142 for ; Tue, 14 Sep 2004 18:19:31 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 2140 invoked from network); 15 Sep 2004 01:21:00 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 15 Sep 2004 01:21:00 -0000 In-Reply-To: <20040914220354.GA12575@slot.hollandcasino.net> References: <20040914220354.GA12575@slot.hollandcasino.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4B2FA436-06B5-11D9-8E48-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Margaret Olson Subject: Re: SPF abused by spammers Date: Tue, 14 Sep 2004 21:19:30 -0400 To: Alex van den Bogaerdt 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 Sep 14, 2004, at 6:03 PM, Alex van den Bogaerdt wrote: > > On Tue, Sep 14, 2004 at 01:44:19PM -0700, Anne P. Mitchell, Esq. wrote: > >> All three have a part - an important part. Authentication gets you to >> "who is this really?"; accreditation gets you to "what are they >> doing?", and reputation gets you to "what do others whom I trust think >> about what they are doing". > > Authentication: yes. > Reputation: yes. > > Accreditation: why would I care? > > By this I mean: can you give an example of how this would change my > opinion based on their reputation? Very small senders won't have the volume to create a statistically significant reputation. But if they are accredited ("this is a shoe shop, established in 1985, uses good practices") and the reputation data is essentially empty, then you know something. If you just have empty reputation without accreditation you don't know if they are new, and potentially churning identities, or just small. Margaret. From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 21:50: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 VAA16739 for ; Tue, 14 Sep 2004 21:50: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 i8F1HtAs034037; Tue, 14 Sep 2004 18:17:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F1HtBQ034036; Tue, 14 Sep 2004 18:17:55 -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 i8F1HqRq034027 for ; Tue, 14 Sep 2004 18:17:54 -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 1C7OQh-0007lg-Pj for ietf-mxcomp@imc.org; Tue, 14 Sep 2004 20:17:57 -0500 To: "IETF MARID WG" References: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 14 Sep 2004 20:17:51 -0500 In-Reply-To: (Mark Lentczner's message of "Tue, 14 Sep 2004 15:38:28 -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: Interpreting "v=spf1" 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.6 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 Mark Lentczner writes: > I am against them being included as part of the standard. > > [....] > > I am for implementations supporting them. *UGH* What next? Implementations should (*wink* *wink*) support ipv4: as an alias for ip4:? And prt: is ok for ptr:? And putting an IP address on a: is something implementations should support because there are alread a lot of records out there that have it? > Of course "v=spf1" records can be almost certainly interpreted at > "spf2.0/mailfrom". Surely, any implementation can do this trivially. > They should. But when things go wrong with "v=spf1" records, for any > reason, better for us to be able to all say: "Use the standard" This is circular reasoning. Things will go wrong with both the SPFv1 records and SPFv2 records. By excluding them from the standard you are by definition making them non-standard. By making them non-standard, people will not want to support them, or if they support them, they won't have anything to guide them. How fricken hard it is it put a sentence in the standard that says: "Records that begin with v=spf1 MUST be interpreted as spf2.0/mailfrom,helo" -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 22:06: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 WAA17479 for ; Tue, 14 Sep 2004 22:06:45 -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 i8F1ZpPE035449; Tue, 14 Sep 2004 18:35: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 i8F1Zpb4035448; Tue, 14 Sep 2004 18:35:51 -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 i8F1ZoXr035441 for ; Tue, 14 Sep 2004 18:35:50 -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 1C7Oi6-0000MB-Pz for ietf-mxcomp@imc.org; Tue, 14 Sep 2004 20:35:56 -0500 To: "IETF MARID WG" References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 14 Sep 2004 20:35:50 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 14 Sep 2004 16:54:35 -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: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 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.6 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: [top quoting fixed, extra words deleted, and the Reference: header restored. All due to brain-dead mail software.] In "Hallam-Baker, Phillip" writes: > David Woodhouse [mailto:dwmw2@infradead.org] wrote: >> >> On Sat, 2004-09-11 at 13:59 -0400, Andrew Newton wrote: >> > This work plan does not include >> > scopes outside of "mail from" and "pra", and it is our opinion that no >> > new work items of this type should be considered until MARID has >> > successfully produced a first specification. >> >> I strongly disagree with this opinion. I believe that it does not make >> sense to have multiple scopes, and certainly not to plan to add even >> more scopes later. I shall explain my reasoning: > > I agree with Andy. No, apparently you agree with David Woodhouse. It is easy to get confused when you don't use proper quoting. > I thought we should have done this all along. Yes, I know. This was discussed long ago. The rough consensus was against your opinion. I thought that while there should be multiple scopes, we could have one record that covered them all. The rough consensus was against my opinion. Now, can we *PLEASE* stop re-raising old issues everything someone new comes into this working group? -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 22:15: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 WAA17983 for ; Tue, 14 Sep 2004 22:15:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F1jvTY036114; Tue, 14 Sep 2004 18:45: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 i8F1jvOr036113; Tue, 14 Sep 2004 18:45:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F1juWm036107 for ; Tue, 14 Sep 2004 18:45:56 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i8F1u0Pj024460 for ; Tue, 14 Sep 2004 21:56:01 -0400 From: terry@greatgulfhomes.com To: "'IETF MARID WG'" Subject: RE: Interpreting "v=spf1" Date: Tue, 14 Sep 2004 21:40:54 -0400 Message-ID: <004801c49ac5$0abe6060$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of wayne > Sent: Tuesday, September 14, 2004 9:18 PM > To: IETF MARID WG > Subject: Re: Interpreting "v=spf1" > > > > In Mark > Lentczner writes: > > > I am against them being included as part of the standard. > > > > [....] > > > > I am for implementations supporting them. > > How fricken hard it is it put a sentence in the standard that says: > > "Records that begin with v=spf1 MUST be interpreted as > spf2.0/mailfrom,helo" > > > -wayne > Given the thought: > I am for implementations supporting them. I see no other choice but then to agree with Wayne v=spf1 === spf2.0/mailfrom,helo Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 22:29: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 WAA18496 for ; Tue, 14 Sep 2004 22:29: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 i8F1xUJf037124; Tue, 14 Sep 2004 18:59: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 i8F1xUHW037123; Tue, 14 Sep 2004 18:59:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F1xTDU037117 for ; Tue, 14 Sep 2004 18:59:30 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (unknown [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id A2957132CD1 for ; Tue, 14 Sep 2004 21:57:28 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 51F6F5B9; Tue, 14 Sep 2004 21:59:34 -0400 (EDT) Date: Tue, 14 Sep 2004 21:59:34 -0400 From: Meng Weng Wong To: IETF MARID WG Subject: Re: Interpreting "v=spf1" Message-ID: <20040915015934.GG23667@dumbo.pobox.com> References: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 14, 2004 at 08:17:51PM -0500, wayne wrote: | | "Records that begin with v=spf1 MUST be interpreted as spf2.0/mailfrom,helo" | I agree with the sentiment behind this suggestion. It might even be more useful if v=spf1 records were defined to mean spf2.0/pra,mailfrom,helo,pra or perhaps spf2.0/pra,mailfrom,helo,pra,ptr and if a sender is uncomfortable with those semantics then they should publish proper spf2.0 records that override the v1 entries. From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 22:57: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 WAA20462 for ; Tue, 14 Sep 2004 22:57: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 i8F2KLvL038332; Tue, 14 Sep 2004 19:20:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F2KLaB038331; Tue, 14 Sep 2004 19:20:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F2KKHU038325 for ; Tue, 14 Sep 2004 19:20:20 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: LGVBkXdeieE1qDsEwTYbWw 1095214821 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 724A956D381; Tue, 14 Sep 2004 22:20:20 -0400 (EDT) Message-ID: <4147A731.2000807@elvey.com> Date: Tue, 14 Sep 2004 19:21:37 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Leslie , MXCOMP Subject: RHSBLs (was Re: HELO, IPR, A&R ... References: <41475F45.90707@elvey.com> <20040914231415.GC84206@verdi> In-Reply-To: <20040914231415.GC84206@verdi> 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 On 9/14/2004 4:14 PM, John Leslie sent forth electrons to convey: >Matthew Elvey wrote: > > The question is, how would such a RHSBL be maintained? It seemed to >me that any RHS that scored poorly under that scheme would need to be >on a hair-trigger because it could go from zero to a million spams in >a matter of seconds. > > This is a FAQ. You can find an answer here: http://spf.pobox.com/faq.html#churn There are RHSBLs in production already. They are maintained much like regular BLs. (There are also URIRBLs that work quite well, BTW, but that is very OT.) > (I'm not the least bit sure this is a good time to discuss the issue, >but I'd like to minimize confusion about what the issue is...) > > From owner-ietf-mxcomp@mail.imc.org Tue Sep 14 23:09: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 XAA21606 for ; Tue, 14 Sep 2004 23:09: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 i8F2fm4e040066; Tue, 14 Sep 2004 19:41:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F2fmG1040065; Tue, 14 Sep 2004 19:41:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F2fl8x040059 for ; Tue, 14 Sep 2004 19:41:47 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (unknown [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id A3ED3132CD1; Tue, 14 Sep 2004 22:39:47 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 6545B5B9; Tue, 14 Sep 2004 22:41:51 -0400 (EDT) Date: Tue, 14 Sep 2004 22:41:51 -0400 From: Meng Weng Wong To: Matthew Elvey Cc: IETF-MXCOMP , Carl Hutzler Subject: HELO and Unified Message-ID: <20040915024151.GH23667@dumbo.pobox.com> References: <41475F45.90707@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41475F45.90707@elvey.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 14, 2004 at 02:14:45PM -0700, Matthew Elvey wrote: | I have a $50+ spf t-shirt. I'm trying to make MARID's work | successful. OTOH: A principal of my mail provider (fastmail.fm's | Jeremy H) is so unhappy with SPF that he's suggesting configurations | that appear designed to *sabotage* its effectivenness; an IESG | member's criticism is provided as justification: | http://www.emailaddresses.com/forum/showthread.php?threadid=22341&highlight=spf The unhappiness there seems to be with SPF Classic, and is remedied by Unified. I would like to take this opportunity to expand on some ideas for the working group's consideration. | It's certainly been explained many times, on-list, by many people. I | see strong confirmation that HELO scope would be useful, and an | appropriate change to make. I see little reasoned opposition to a A | HELO scope. I now agree that checking HELO can be very useful, as it satisfies the ESP->ISP whitelisting requirement nicely, and also has the benefit of making life easier for forwarders who would then be able to skip SRS. The ESP->ISP whitelisting requirement can be satisfied by way of a private arrangement between the parties involved, so strictly speaking we do not need to standardize that convention. But if we want to remove the SRS requirement for forwarders without weakening protection for the other identities, we would have to require either one of two things: 1) that we make HELO checking mandatory for receivers, and that receivers be easily capable of whitelisting forwarding systems by that identity, or 2) that we make SUBMITTER mandatory for forwarding senders and receivers. Of course, we would also specify that a positive result (where auth+policy both pass) would override failures elsewhere in the system. Note that the trusted-forwarder.org checking in most SPF Classic implementations essentially sneaks the first benefit into the system, by way of a PTR identity. That first rule changes that to a HELO identity, but provides the same benefit. If consensus does not oppose HELO checking, then a "unification" draft could require that receivers always check the HELO identity (setting aside questions of protocol and syntax). Also mandatory would be the return path, SUBMITTER (when checking before DATA), and PRA (when checking after DATA) identities. This choice of identities is justified by the following argument: Making HELO-checking mandatory should satisfy folks who want to get their MTAs whitelisted easily. This includes ESPs and forwarders. Checking the return path would satisfy folks who want to limit unauthorized use of their domain names in the return path. Checking the SUBMITTER and PRA identities would satisfy folks who think validating those addresses will help with phishing. If folks agree, it might be useful to standardize that set of identities in the "must check" list. The essential difference between the HELO identity and an IP address is that it's easier for a receiver to whitelist *.mta.example.com and not worry about IPs. This is one big driver in the ESP->ISP whitelisting relationship. The essential difference between the HELO identity and the PTR, both of which are (nominally) hostnames, is that it's easier for senders in some parts of the world to set up forward-lookup (domain -> SPF/TXT/A -> ip) mappings than reverse-lookup (ip -> PTR -> domain) mappings due to PTR delegation brokenness. Also we have been asked by the DNS people to refrain from putting additional load on the PTR system if possible. | Some reasons the market may go with the HELO scope instead of the others | (assuming this leave-it-to-the-market proposal flies) are that it has | the advantages of not using restricted IPR, doesn't break | forwarding/mail-list/backup mx operations, and doesn't require end-user | action to implement. Agreed, many of the CSV proponents have made these arguments also. | Also, the way that Accredidation and Reputation services are to be used | is essential. It belongs in a BCP, which should specify BFP (Best | Future Practice) for how various tests should be interpreted and acted | upon. SPF claims to address the spam problem (according to text that | was on the spf.pobox.com home page) so the Accredidation and Reputation | services that are a necessary component to this solution must be | specified. An incomplete spec that lacks these things has no business | aspiring to be an Internet Standard. How can a spec that is grossly | incomplete be properly reviewed by us or the IESG? It can't! | E.g. John Leslie is quite confused about how A&R might work, or I am, as | mentioned above. Yes, a Unified proposal would need to discuss at least reputation, at least in terms of local policy. A spec for Accreditation would also be useful. As we are getting off topic for MARID, which is focused on Sender ID at the moment, I suggest we discuss Unified further in another forum, and report back with our findings at a more appropriate time. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 01:54:40 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 BAA01368 for ; Wed, 15 Sep 2004 01:54: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 i8F5OQd2058053; Tue, 14 Sep 2004 22:24:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F5OQIT058052; Tue, 14 Sep 2004 22:24:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F5OPOd058026 for ; Tue, 14 Sep 2004 22:24:26 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C7SHI-00082M-00; Tue, 14 Sep 2004 22:24:24 -0700 To: Meng Weng Wong Cc: Matthew Elvey , IETF-MXCOMP , Carl Hutzler Subject: Re: HELO and Unified References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> From: Daniel Quinlan Date: 14 Sep 2004 22:24:24 -0700 In-Reply-To: Meng Weng Wong's message of "Tue, 14 Sep 2004 22:41:51 -0400" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong writes: > 1) that we make HELO checking mandatory for receivers, and > that receivers be easily capable of whitelisting > forwarding systems by that identity, or Yes. > 2) that we make SUBMITTER mandatory for forwarding senders > and receivers. This cannot work since not all receivers can do SUBMITTER since matching SUBMITTER to the message is patent-encumbered and the license... you know. Other than that point, I agree and I like. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 01:58: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 BAA01460 for ; Wed, 15 Sep 2004 01:58: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 i8F5QDKi058672; Tue, 14 Sep 2004 22:26:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F5QDO2058671; Tue, 14 Sep 2004 22:26:13 -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 i8F5QD7a058664 for ; Tue, 14 Sep 2004 22:26:13 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8F5QKBJ016423 for ; Tue, 14 Sep 2004 22:26:20 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <533F208D-0629-11D9-B862-000A95AC5778@isipp.com> References: <533F208D-0629-11D9-B862-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Anne P. Mitchell, Esq." Subject: Re: Work plan for Sender ID Date: Tue, 14 Sep 2004 22:26:19 -0700 To: IETF MARID WG 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 > Sundwall would not say whether the IETF's censure would hinder the > company's > quest to get its Caller ID proposal accepted as a de facto Internet > standard. > But he did note that many participants stayed out of the vote on > Microsoft's > involvement. > > "If you look at the number of contributors that (voted), it is very > small," he > said." > > Full article at http://news.com.com/2100-1032-5364075.html > Additionally, InfoWorld today has an article with quotes from an email statement from Microsoft made on the issues - a search for the quotes turned up nothing, so I surmise that it was an email likely sent directly to the reporter, or forwarded to the reporter from an original recipient. I assume these are of interest to the group at this point because the information contained herein may have bearing on in what direction people want to go from here - please let me know if that is not the case: "In an e-mail statement, Microsoft said that MARID's decision "does not mean Sender ID has been rejected," but that changes proposed by MARID will make the standard more flexible. Microsoft is "excited to continue our collaboration with industry stakeholders to help move this important authentication protocol forward" and sees a future in which "complementary technologies" will be used with Sender ID to fight spam. ... In its statement, Microsoft said that the Sender ID framework has essentially been accepted, and that MARID's decision only means there will be "an alternative spoof checking mechanism to the proposed PRA check." "While we would have preferred a single technical mechanism as the standard, we believe this proposal to allow multiple scopes in the protocol is a reasonable approach to provide additional choice and flexibility," Microsoft said in the statement." --- Particularly taken with the quote from News.com, I read this as an indication that they plan to move forward on their own with Sender I.D. regardless of what recommendations or other standards may come from this group. What their end goal is, and how this fits with the current recommendations here, I wouldn't hazard to say, and leave as an exercise to the reader. Full article at: http://www.infoworld.com/article/04/09/14/HNietfmsblow_1.html From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 02:21: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 CAA20353 for ; Wed, 15 Sep 2004 02:21: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 i8F5o2vG071597; Tue, 14 Sep 2004 22:50: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 i8F5o2Pj071595; Tue, 14 Sep 2004 22:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F5o0Ih071582 for ; Tue, 14 Sep 2004 22:50:01 -0700 (PDT) (envelope-from SRS0=ZczYekMW=ME=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8F5o72d092140 for ; Wed, 15 Sep 2004 07:50:07 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409150550.I8F5O6DH092130@asarian-host.net> Date: Wed, 15 Sep 2004 05:50:07 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: Interpreting "v=spf1" X-Trace: +cpUCS8YqDMB5LVHnLLMv83PrE2O9wdA/Q2zldHJ/kyv0uIEmbAQTbwAEJNuof0FbcmCRvszpQsjhxeY0luV1Q== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> <20040915015934.GG23667@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUfYDzFqW1BleBN9AQFMvAf/QlKt3Kr6xygul4jSrNsWwmfJaINJEuIZ vaozcQsHyGSBLXPN3I3zxxHHno07Tw2VDHeigrBODCjYjqlCJbdAy7XBy9MWJfqM CloTiO3hbLzupioqFbkR0wUaa+mtXGDfrJR5sQLSrlfy+iV/JQuHHDzWT70dSqaU mxJyhntbzXeOa6LEmZBgET5h87v1gnMzNwwgQykr4ZvMhieUTGmZkbSxRA/TdI5d 7HI5p06CZ5um4eXyYQ/W/fPGCOedBFSDl3oaUC5KyqloEi0Wv9m9uPphsGDpb/WP 5xMlFWHVpTY+5W6Wtl9U/pAJ1Boy24MW7oNcPBCgrSB657qKNLLC5w== =41Vw Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng Weng Wong wrote: > On Tue, Sep 14, 2004 at 08:17:51PM -0500, wayne wrote: >> >> "Records that begin with v=spf1 MUST be interpreted as >> spf2.0/mailfrom,helo" I am in favor of this. > I agree with the sentiment behind this suggestion. It might > even be more useful if v=spf1 records were defined to mean > > spf2.0/pra,mailfrom,helo,pra Could you clarify this, please? I mean, currently, pra is not part of v=spf1, right? I could see v=spf1 to mean this, though: spf2.0/mailfrom,submitter,helo I am not really sure, though, whether "helo" should be mentioned as a separate entity. It feels to me that "helo" is an implicit part of the mailfrom check (namely in the case of MAIL FROM: <>). > and if a sender is uncomfortable with those semantics then > they should publish proper spf2.0 records that override the > v1 entries. As soon as this workgroup decides on its syntax, I will publish such new records. :) Well, having said that, in reality I will probably wind up publishing both types of records, so as not to break downward compatibility. - Mark From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 02:47:09 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 CAA03085 for ; Wed, 15 Sep 2004 02:47: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 i8F6Iwjt084553; Tue, 14 Sep 2004 23:18: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 i8F6Iwpd084552; Tue, 14 Sep 2004 23:18:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F6IvrI084531 for ; Tue, 14 Sep 2004 23:18:57 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: PrlUC/mfwqhSjID+FUguiQ 1095229132 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 34A9E56D368; Wed, 15 Sep 2004 02:18:52 -0400 (EDT) Message-ID: <4147DF3B.2060608@elvey.com> Date: Tue, 14 Sep 2004 23:20:43 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis Cc: IETF-MXCOMP , Carl Hutzler , John Leslie Subject: Re: HELO, IPR, A&R means new draft?; scope; Microsoft - (Re: DEPLOY - IP, HELO & touch count. ) References: <41475F45.90707@elvey.com> <1095206014.29546.143.camel@ddev.mail-abuse.org> In-Reply-To: <1095206014.29546.143.camel@ddev.mail-abuse.org> 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 On 9/14/2004 4:53 PM, Douglas Otis sent forth electrons to convey: >On Tue, 2004-09-14 at 14:14, Matthew Elvey wrote: > > >>This is a belated-due-to-to-travel follow-up to replies to this post: >>http://www.imc.org/ietf-mxcomp/mail-archive/msg03596.html >>(Summary: Sender ID fails to be a solution that only requires sysadmin >>action; it mandates end-user reconfiguration on a massive scale, because >>it doesn't say that HELO checking should/must be done... The Microsoft >>IPR are too encumbered...) >> >> >> > >The obvious reaction to [John's] technique would be to spoof IP addresses of >known good MX servers in these records. > Yes, the technique won't work. For folks unfamiliar with RHSBLs: http://www.rfc-ignorant.org/how_to_domain.php has usage info for their RHSBLs. Ditto http://www.securitysage.com/antispam/rhsbl.html; http://www.scconsult.com/bill/dnsblhelp.html#3-8 > <>As I said before, the mailbox > domain within SPF and Sender-ID is worthless for reputation checks. <> <> > <>I find it difficult to believe people will allow themselves to be harmed > by reputation services that hold them accountable for any MTA authorized > to send their mail. >Let me clarify. Neither Sender-ID nor SPF will support RHSBLs. > Doug, did you get my email - of a possible broad, strong example showing it falling down. If foo.dom's SPF/SenderID record lists just MX, and doesn't send spam, how/why would a reputation service blacklist foo.dom? e.g . foo.dom. IN TXT "v=spf1 mx -all" > > >>=-=-=-=-= >>On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey: >> >> >> >>> >>> >>> >>> >>>>Phrased differently: >>>>.... >>>> >>>> >>>This is a VERY interesting approach. [...] >>> >>>This sounds really cool. But I am an engineer and must always ask, what is >>>wrong with this and why has it not been thought of before? >>> >>> > >It has been considered and there is language within CSV that >accommodates this approach. : ) > > Right, it's not new. It just doesn't have Marketing Might behind it. Of course now it has an encouraging nod from AOL...unofficially, of course :) > > >>>Lets see, forwarding cases....might work here with some PRA/Submitter type >>>changes. Not a huge problem. >>> >>> >>Forwarding case would work GREAT - no PRA/SUBMITTER needed. Yes, 'The >>MTA would HELO the domain they are about to send for.' This domain >>wouldn't have to match the MAIL FROM or PRA or SUBMITTER. It would >>simply need to be a domain that had an appropriate reputation for the >>content. E.g. if we assume AOL is responsible about ensuring very >>little spam is sent using the servers it authorizes to do HELO aol.com, >>and sends all email through these servers, then there is no forwarding >>to worry about. Helo aol.dom would trigger a reputation check on aol.dom >>as used in HELO, the reputation would be excellent, and no further checks >>would be necessary - the From: domain or PRA could be elvey.dom or >>DomainWithNoSPFrecord.dom. >>Here's a sophisticated possible scenario that provides more flexibility: >>AOL might do HELO goodAolPayingCustomer.dom, if the mail is from one, >>and the customer hasn't recently sent a ton of email. It might use HELO >>aolSuspectCustomer.dom where appropriate, before cutting the customer >>off completely. AOL wouldn't have to pay to give >>goodAolPayingCustomer.dom a good reputation; it would deserve it. AOL >>wouldn't have to cut off customers as often - it could limit use in a >>less draconian way. Helo aolTrialUser.dom and HELO AOLFreeEmailUser.dom >>would make sense, provided AOL provided and used dedicated IPs for such >>mail and created the appropriate DNS records. >>Just to clarify: the above is a sophisticated, enhanced solution that >>HELO-based reputations make *possible*. It will be perfectly OK for an >>MTA (or all of a domain's MTAs) to have one domain that goes in all >>HELO/EHLO commands sent, and this is likely to be the usual case, and >>will work well. >> >> Carl- I'm curious as to whether you think AOL would take advantage of this flexibility if it was available. Is this planned use of HELO roughly what you thought it was? > >>>I don't care whether a mail server is who he says he is, I care >>>whether he's authorized to send the message he's trying to send. >>> >>> > >May I add that the marid-mpr draft can safely answer this question >within a single DNS query and not require the potentially hundreds >needed by Sender-ID or SPF. > > Cool, though to be fair: what's the upper limit on the number of DNS queries marid-mpr might require, assuming a malicious sender attempting a DoS? > > > > >>Andrew Newton wrote: >> > On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote: >> >> A HELO scope would be useful. >> > That is already being covered by the CSV proposals. >> >>No, not even close. -protocol with CSV, and -protocol with a HELO scope >>would be EXTREMELY different, can't believe you don't see this, Andy! >> >> > >Please consider the need for two steps in this process. One, >authenticate and validate the authorization of the MTA EHLO name. Two, >obtain a list of authorized EHLO names referenced by the mailbox domain >being examined. This list can be either nominal or comprehensive >without the nominal case inviting spoofing. In which case, CSV remains >"as-is". MPR records are much simpler and easier to maintain and obtain >than scripts for SPF or Sender-ID. > > Confusing paragraph, that. >I would suggest avoiding sequential TXT scripts needed with either SPF >or Sender-ID as being unworkable. CSV used in combination with MPR and >BATV provides all the features claimed by either SPF, SRS or Sender-ID >without disrupting email to the same extent. > >There is another issue with either SPF or Sender-ID records. CSV and >MPR are named based solutions that work within the natural scale of DNS >and only require single non-sequential lookups. SPF or Sender-ID >require either extensive iterative references to record names to obtain >addresses, or the repeating of IP addresses in a script form. The >maintenance of such a list will be high, or the relative overhead to use >such a list will be high or both. > > Very efficient. >... > > >>In addition to/as part of the security review of SenderID: >> I think it's necessary that a number of MAYs and SHOULD [NOT]s turn >> into SHOULD [NOT]s and MUST [NOT]s. There is far too much waffling - >> MUST [NOTs] MUST be used whereever there isn't a compelling reason not >> to. IETF standards demand it. >> >> Folks agree/disagree with that? (Applies only to SPF and SenderID.) >>Also, the way that Accredidation and Reputation services are to be used >>is essential. It belongs in a BCP, which should specify BFP (Best >>Future Practice) for how various tests should be interpreted and acted >>upon. SPF claims to address the spam problem (according to text that >>was on the spf.pobox.com home page) so the Accredidation and Reputation >>services that are a necessary component to this solution must be >>specified. An incomplete spec that lacks these things has no business >>aspiring to be an Internet Standard. How can a spec that is grossly >>incomplete be properly reviewed by us or the IESG? It can't! >> Folks agree/disagree that MARID specs should cover how they will work with A&R services? (IMO blacklists and whitelists ARE A&R services.) The result codes from, e.g. sorbs - http://www.dnsbl.us.sorbs.net/using.shtml are more than a binary result - some BLs provide bitmapped result codes. Doug: What do you think? > >You will find that the marid-mpr draft does allow the protection of the >>From and the MAIL FROM and is a good alternative to the PRA approach. > Indeed. I have. It's hell slogging through the acronyms though - MCAL, MCNL, etc. I'll have to read it again in order to be clear on what goes where - A vs PTR vs APL... Just read BATV - glad to see it! Perhaps it could pursue a standards track - the 'Public Tagging' component means interoperability is important so it should pursue standardization. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 02:48: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 CAA03233 for ; Wed, 15 Sep 2004 02:48: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 i8F6Ohm9086709; Tue, 14 Sep 2004 23:24: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 i8F6OhEr086708; Tue, 14 Sep 2004 23:24:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend1.messagingengine.com (frontend1.messagingengine.com [66.111.4.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F6OhPe086696 for ; Tue, 14 Sep 2004 23:24:43 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: H/tSQBc0TJJOLcKL1XP50g 1095229482 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend1.messagingengine.com (Postfix) with ESMTP id 58C0BC15284; Wed, 15 Sep 2004 02:24:40 -0400 (EDT) Message-ID: <4147E098.5010707@elvey.com> Date: Tue, 14 Sep 2004 23:26:32 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: PRA is dead. Media, nanae/nanabl.(was Re: Work plan for Sender ID) 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 On 9/13/2004 8:46 PM, wayne sent forth electrons to convey: >I think continuing with the PRA is a very poor use of this working >group's time. > I agree with the majority. If a small minority (the Chairs) wish to continue to claim that is not what the WG is doing, I won't try to stop them. But the WG is not interested in PRA, for reasons well expressed by, e.g. William Leibzon in this thread. And that's what DOES matter, because this is the IETF, and that's how things work here. It would be nice if the several clear requests of the Chairs to eliminate IPR-encumbered solutions from the running not be given short shrift, but then elimination of the encumberances would be nice too. Instead, document authors need to produce new drafts intended to meet the chartered work items, and a consensus call on them is needed*. Marid-mpr is such an item. They will find rough consensus if they are well written and well defended, because, again, this is the IETF. If you try to ram junk through, you induce posts like this. *Contrast this sentence with the fait-accompli tone of "The document authors have agreed to producing new drafts intended to meet the chartered work item, and a consensus call on them or the appropriate diffs will be forthcoming." I had written "*new* document authors ..." but Meng just posted again about HELO, so there's hope... =-=-=-=-= More media coverage of MARID - FYI: http://www.theregister.co.uk/2004/09/13/ietf_bounces_sender_id/ BTW, if anyone is following nanae or nanabl and has noticed interesting threads discussing our work here, I'd be interested in links. Some of the battle-hardened know rather well what tricks spammers [might] use. Kinda answered my own question - found some months old posts: I found support from Bill Cole: (who posts here too, seems to be letting folks there know of milestones reached - thanks.) http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=bill-55E121.16123407082004%40fireproof.scconsult.com&rnum=3&prev=/groups%3Fnum%3D20%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26scoring%3Dd%26q%3Dmarid%2Babuse%26btnG%3DSearch Anton Squeegee: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=bill-55E121.16123407082004%40fireproof.scconsult.com&rnum=3&prev=/groups%3Fnum%3D20%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26scoring%3Dd%26q%3Dmarid%2Babuse%26btnG%3DSearch Vernon Schryver: tough criticism, but answerable with something that's easy enough to implement that it can become mandatory in a reasonable time period: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=bill-6C26C6.21474829072004%40fireproof.scconsult.com&rnum=4&prev=/groups%3Fnum%3D20%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26scoring%3Dd%26q%3Dmarid%2Babuse%26btnG%3DSearch From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 02: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 CAA03987 for ; Wed, 15 Sep 2004 02: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 i8F6OXBF086643; Tue, 14 Sep 2004 23:24:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F6OXqX086642; Tue, 14 Sep 2004 23:24:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F6OXDE086616 for ; Tue, 14 Sep 2004 23:24:33 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 14 Sep 2004 23:24:14 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 14 Sep 2004 23:24:14 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Sep 2004 23:24:14 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 23:24:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-359fe655-5835-4e17-a24c-cb8aabcdbfc9" Subject: FW: Microsoft's Updated Statement about IPR Claimed in and in Combination Date: Tue, 14 Sep 2004 23:24:13 -0700 Message-ID: Thread-Topic: Microsoft's Updated Statement about IPR Claimed in and in Combination thread-index: AcSatLYwB1Ijphp3Rl+opYeRGXebIQANrnWE From: "Harry Katz" To: "IETF MARID List" X-OriginalArrivalTime: 15 Sep 2004 06:24:14.0300 (UTC) FILETIME=[9EF481C0:01C49AEC] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPartTM-000-359fe655-5835-4e17-a24c-cb8aabcdbfc9 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49AEC.9EAF52B3" ------_=_NextPart_001_01C49AEC.9EAF52B3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Today Microsoft filed the following disclosure statement with the IETF = Secretariat regarding IPR claimed in relation to Sender ID. This = statement does not mean that patents have been granted in any of the = jurisdictions mentioned below, only that the patent applications = themselves are due to be published shortly. =20 ________________________________ Subject: Microsoft's Updated Statement about IPR Claimed in = and in = Combination Microsoft is aware of the existence of US, EP; JP; CN; KR; and IN patent = applications that are likely to include claims that would necessarily be = infringed when implementing the combination of the specifications = entitled "Purported Responsible Address in E-mail Messages", file name = draft-ietf-marid-pra-00.txt, and located at the following link on August = 23, 2004, url: = http://www.ietf.org/internet-drafts/draft-ietf-marid-pra-00.txt and the = specification entitled "Sender ID: Authenticating E-mail", file name: = draft-ietf-marid-core-03.txt, url: = http://www.ietf.org/internet-drafts/draft-ietf-marid-core-03.txt. The = patent applications are expected to be published by the respective = patent offices on or around September 13, 2004. The relevant patent = application information is:=20 =20 US - Title: "Reducing Unwanted And Unsolicited Electronic Messages By = Preventing Connection Hijacking And Domain Spoofing", Serial no. = 10/684020 =20 EP - Title: "Coordinated Reduction of Unwanted and Unsolicited = Electronic Mail Messages", Serial no. 04005644.2 =20 JP - Title: "Coordinated Reduction of Unwanted and Unsolicited = Electronic Mail Messages", Serial no. 2004-71769 =20 CN - Title: "Coordinated Reduction of Unwanted and Unsolicited = Electronic Mail Messages", Serial no. 200410028682.3 =20 KR - Title: "Coordinated Reduction of Unwanted and Unsolicited = Electronic Mail Messages", Serial no. 10-2004-16409 =20 IN - Title: "Coordinated Reduction of Unwanted and Unsolicited = Electronic Mail Messages", Serial no. 298/DEL/2004 =20 =20 A patent license with reasonable and non-discriminatory terms and = conditions, with no fees or royalties is available at = http://www.microsoft.com/mscorp/ip/standards/ or another public site = that Microsoft may subsequently use to post the license. =20 ------_=_NextPart_001_01C49AEC.9EAF52B3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Today = Microsoft filed the =0A= following disclosure statement with the IETF Secretariat regarding IPR = claimed =0A= in relation to Sender ID.  This statement does not mean that = patents have =0A= been granted in any of the jurisdictions mentioned below, only that the = patent =0A= applications themselves are due to be published =0A= shortly.  
=0A=

=0A=
=0A= Subject: Microsoft's Updated = Statement about IPR =0A= Claimed in <draft-ietf-marid-core-03.txt> and =0A= <draft-ietf-marid-pra-00.txt> in Combination

Microsoft is =0A= aware of the existence of US, EP; JP; CN; KR; and IN patent applications = that =0A= are likely to include claims that would necessarily be infringed when =0A= implementing the combination of the specifications entitled = “Purported =0A= Responsible Address in E-mail Messages", file name = draft-ietf-marid-pra-00.txt, =0A= and located at the following link on August 23, 2004, url: = http://www.ietf.org/internet-drafts/draft-ietf-marid-pra-00.txt =0A= and the specification entitled  "Sender ID:  Authenticating = E-mail", =0A= file name: draft-ietf-marid-core-03.txt, url: http://www.ietf.org/internet-drafts/draft-ietf-marid-core-03.txt.&nb= sp; =0A= The patent applications are expected to be published by the respective = patent =0A= offices on or around September 13, 2004. The relevant patent application =0A= information is:
=0A=
=0A=
=0A=

 

=0A=

US – Title: = “Reducing Unwanted And =0A= Unsolicited Electronic Messages By Preventing Connection Hijacking And = Domain =0A= Spoofing”, Serial no. 10/684020

=0A=

 

=0A=

EP – Title: = “Coordinated Reduction =0A= of Unwanted and Unsolicited Electronic Mail Messages”, Serial no. =0A= 04005644.2

=0A=

 

=0A=

JP – Title: = “Coordinated Reduction =0A= of Unwanted and Unsolicited Electronic Mail Messages”, Serial no. =0A= 2004-71769

=0A=

 

=0A=

CN – Title: = “Coordinated Reduction =0A= of Unwanted and Unsolicited Electronic Mail Messages”, Serial no. =0A= 200410028682.3

=0A=

 

=0A=

KR – Title: = “Coordinated Reduction =0A= of Unwanted and Unsolicited Electronic Mail Messages”, Serial no. =0A= 10-2004-16409

=0A=

 

=0A=

IN – Title: = “Coordinated Reduction =0A= of Unwanted and Unsolicited Electronic Mail Messages”, Serial no. =0A= 298/DEL/2004

=0A=

 

=0A=

 

=0A=

A patent license with = reasonable and =0A= non-discriminatory terms and conditions, with no fees or royalties is = available =0A= at http://www.microso= ft.com/mscorp/ip/standards/ =0A= or another public site that Microsoft may subsequently use to post the =0A= license.

=0A=

 

=0A= =0A= =0A= =0A= =0A= ------_=_NextPart_001_01C49AEC.9EAF52B3-- ------=_NextPartTM-000-359fe655-5835-4e17-a24c-cb8aabcdbfc9-- From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 03:23:54 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 DAA05989 for ; Wed, 15 Sep 2004 03:23: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 i8F6sq3U098375; Tue, 14 Sep 2004 23:54: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 i8F6sq6H098373; Tue, 14 Sep 2004 23:54:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8F6so2e098361 for ; Tue, 14 Sep 2004 23:54:51 -0700 (PDT) (envelope-from support@accuspam.com) Received: (qmail 60544 invoked from network); 15 Sep 2004 06:54:48 -0000 Received: from 210.14.14.14.pldtvibe.com (HELO vaio) (210.14.14.14) by relay.pair.com with SMTP; 15 Sep 2004 06:54:48 -0000 X-pair-Authenticated: 210.14.14.14 Message-Id: <4.1.20040915141325.00a97450(null)> X-Sender: spam@mail.accuspam.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 15 Sep 2004 15:06:42 +0800 To: ietf-mxcomp@vpnc.org From: AccuSpam Subject: Re: [Fwd: HELO, IPR, A&R means new draft?; scope; Microsoft - (Re: DEPLOY - IP, HELO & touch count. )] Cc: Matthew Elvey In-Reply-To: <41477258.7030103@elvey.com> 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: I was unsubscribed, but someone cc'ed me, so let me make one final post to this mess. I wasn't going to bother, because co-chairs already made their decision, but since someone mentioned AccuSpam in this post, I might as well explain how you all misunderstood my point. >Also, Accuspam implicitly asked an interesting question - why specify >what the list of servers may be used for? Here's an answer: It's >generally much easier to specify a list of servers that will >legitimately use a domain (e.g. elvey.com) in HELO than it is to specify >a list of servers that will use that domain in PRA or 2821.MAIL FROM! >Hence some folks will only want to specify the former. Some folks may >want to specify a smaller set of servers for one versus another. >Accuspam said : "Publishing the approved mail servers is something >everybody can agree to do I think?" but this is more complicated than it >seems at first glance, because the set of approved servers for a given >domain is different depending on what its approved for. Apparently no one got my point during the concensus call. Scopes in MARID is useless complication. People in this discussion list are using arguments about the FAIL case to argue that scopes are needed. The non-PASS cases will FOR A LONG TIME (as in probably our whole lifetimes) be mired in issues about incomplete adoption, and alternative spoofing identities. The logic: 1) None of the possible MARID scopes can provide hard FAIL without unacceptable false positives: a) Incomplete adoption of forwarding solution means honoring hard FAIL generates false positives. Even with 80% adoption, you still have 20% risk of false positives. b) Humans are not perfect and can not always be expected to always send from approved mail servers. Thus false positives. This scales really poorly the more humans are sharing a domain (e.g. ISPs, businesses, etc). c) Generally in life anything that requires more than 20% of participants to make some change before any benefit (e.g. use of FAIL) can be obtained will not gain momentum in marketplace. FAIL has to provide benefit for early adopters in order to snowball. It is a chicken and egg, and 80% chicken or 80% egg won't help. 100% anything is impossible. 2) All of the possible MARID scopes can forge alternate important identities: a) PRA can forge From: and MAILFROM: etc. b) SPF can forge any header 3) Thus MARID scopes are entirely useless for deleting e-mail. MARID does not detect forgery. You can try to measure probabilities on non-PASS cases for domains to build reputation services, but you will get very noisy data because the identities are not well correlated to forgery or spam because of #1 and #2 above. Spammers can do many "tricks" (some alluded to above) to make sure that anything but a PASS case is too noisy to prevent false positives or false negatives. 4) Only the PASS case of MARID scopes is a useful datum. The PASS case tells you that the e-mail is not a forgery (except for intra-domain forgery, e.g. a spammer who uses an Earthlink.net account to spam all Earthlink.net users). The non-PASS cases tells you an e-mail might be forgery, but with no certain probability. The users of the result (anti-spam) have to build algorithms which correctly do not generate false positives (because recipients do not accept anti-spam with many false positives). In fact, AccuSpam already has developed a proprietary anti-spam algorithm (we will soon release it) which ignores all but the PASS cases of the various MARID identities. 5) Thus declaring scopes is useless. A unified DNS record can be used to test against all identities for the PASS case. 6) Declaring scopes will just result in a war between syntaxes and fragmentation and loss of unencumbered adoption. Any way, you all do what you want. It seems the co-chairs are determined to push a "pra" scope in a separate DNS record ("rough concensus" is an oxymoron), so that eventually we will end up with major corporations only publishing "pra" records and eventually Microsoft adding new syntaxes to that record (defacto standards via monopoly control) and eventually any hope of a unified record or unencumbered identities will die. Sigh. (And the above logic has nothing to do with what is in your silly archives of endless circular discussion). Now please do not CC me. I do not care what you do. More power to Microsoft! I have no problem using "pra" records in an unencumbered AccuSpam algorithm. I tried to help encourage a unified record because FAIL is not important, only PASS is, but it really doesn't matter that much to me. -Shelby Moore http://AccuSpam.com From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 03:48: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 DAA09495 for ; Wed, 15 Sep 2004 03:48: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 i8F7JJOU008137; Wed, 15 Sep 2004 00:19:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F7JJmA008136; Wed, 15 Sep 2004 00:19:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F7JHNu008117 for ; Wed, 15 Sep 2004 00:19:18 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: baVgDExgqsfHaoZKYCr8XA 1095232752 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 9785A56D359; Wed, 15 Sep 2004 03:19:11 -0400 (EDT) Message-ID: <4147ED67.1040301@elvey.com> Date: Wed, 15 Sep 2004 00:21:11 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Meng Weng Wong Cc: IETF-MXCOMP , Carl Hutzler Subject: Re: HELO and Unified References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> In-Reply-To: <20040915024151.GH23667@dumbo.pobox.com> 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 On 9/14/2004 7:41 PM, Meng Weng Wong sent forth electrons to convey: >On Tue, Sep 14, 2004 at 02:14:45PM -0700, Matthew Elvey wrote: >|... >| http://www.emailaddresses.com/forum/showthread.php?threadid=22341&highlight=spf > >The unhappiness there seems to be with SPF Classic, and is >remedied by Unified. I would like to take this opportunity >to expand on some ideas for the working group's >consideration. > >| It's certainly been explained many times, on-list, by many people. I >| see strong confirmation that HELO scope would be useful, and an >| appropriate change to make. I see little reasoned opposition to a A >| HELO scope. > >I now agree that checking HELO can be very useful, as it >satisfies the ESP->ISP whitelisting requirement nicely, and >also has the benefit of making life easier for forwarders >who would then be able to skip SRS. > > I don't understand why you always talk about HELO checks only in combination with whitelisting. Any domain relevant for a MARID record check is a good candidate for checking whitelists and blacklists (A&R services)... Certainly, it's particularly urgent that forwarders get whitelisted if an SPF check on MAIL FROM will otherwise be done because it will fail. But it makes sense, IMO, for any domain used in HELO that has a good reputation (and is authorized for use by the MTA, of course) to result in a 'pass'. BTW, is there a definition of ESP? As I understand it, fastmail.fm and hotmail.com, for example, aren't what you'd call ESPs. (I'm not sure what I would call them.) Is ESP a euphamism for Bulk Mailer? (E.g. that sends anything from bank statements, and bank marketing spam, to mainsleaze) I'd say it's http://www.espcoalition.org/members.php and competitors. >The ESP->ISP whitelisting requirement can be satisfied by >way of a private arrangement between the parties involved, >so strictly speaking we do not need to standardize that >convention. > >But if we want to remove the SRS requirement for forwarders >without weakening protection for the other identities, we >would have to require either one of two things: > >1) that we make HELO checking mandatory for receivers, and > that receivers be easily capable of whitelisting > forwarding systems by that identity, or > > > I don't see the necessity of the second half of that sentence. You assume receivers will insource whitelist maintenance, and I see no reason for making that assumption. I'd say "1) that we make HELO checking mandatory for receivers, and easy for A&R service checks to be made on the authorized domain." >2) that we make SUBMITTER mandatory for forwarding senders > and receivers. > >Of course, we would also specify that a positive result >(where auth+policy both pass) would override failures >elsewhere in the system. > >Note that the trusted-forwarder.org checking in most SPF >Classic implementations essentially sneaks the first benefit >into the system, by way of a PTR identity. > That's good, but the full A&R stuff should be in there too. > That first rule >changes that to a HELO identity, but provides the same >benefit. > >If consensus does not oppose HELO checking, then a >"unification" draft could require that receivers always > > IIRC, a unification draft was started. Right? Should this new unification draft be called SPF3? SenderID2? USPF? What would you prefer it be called? >check the HELO identity (setting aside questions of protocol >and syntax). > >Also mandatory would be the return path, > > Mandatory? My reading of the Unified stuff (e.g. the .ppt slideshow) was that if HELO resulted in a pass (i.e. a whitelist or strong A&R check) then no further checks would be made. Also what's mandatory? a DNS record supporting it? It always being tested and passing? >SUBMITTER (when checking before DATA), and PRA (when >checking after DATA) identities. This choice of identities >is justified by the following argument: > > Making HELO-checking mandatory should satisfy folks who want > to get their MTAs whitelisted easily. This includes ESPs > and forwarders. > > Checking the return path would satisfy folks who want to > limit unauthorized use of their domain names in the return > path. > > Checking this would make sense if previous tests hadn't resulted in a pass and/or the retrn path was going to be used - a bounce was going to be induced/sent to it. > Checking the SUBMITTER and PRA identities would satisfy > folks who think validating those addresses will help with > phishing. > > You've gotta drop PRA. You'll never get a majority, let alone rough consensus, for something 'till you do; someone else's draft will proceed. >If folks agree, it might be useful to standardize that set >of identities in the "must check" list. > >The essential difference between the HELO identity and an IP >address is that it's easier for a receiver to whitelist >*.mta.example.com and not worry about IPs. This is one big >driver in the ESP->ISP whitelisting relationship. > > It's also easier to blacklist a domain than an IP! >The essential difference between the HELO identity and the >PTR, both of which are (nominally) hostnames, is that it's >easier for senders in some parts of the world to set up >forward-lookup (domain -> SPF/TXT/A -> ip) mappings than >reverse-lookup (ip -> PTR -> domain) mappings due to PTR >delegation brokenness. Also we have been asked by the DNS >people to refrain from putting additional load on the PTR >system if possible. > > Oh, I missed that request. A pointer and/or quote would be appreciated if it wasn't made on this list. >| Some reasons the market may go with the HELO scope instead of the others >| (assuming this leave-it-to-the-market proposal flies) are that it has >| the advantages of not using restricted IPR, doesn't break >| forwarding/mail-list/backup mx operations, and doesn't require end-user >| action to implement. > >Agreed, many of the CSV proponents have made these arguments >also. > > Yup - I was surprised HELO wasn't in SenderID; I had expected it to be more, not less prominent than it was in SFP. >| Also, the way that Accredidation and Reputation services are to be used >| is essential. It belongs in a BCP, which should specify BFP (Best >| Future Practice) for how various tests should be interpreted and acted >| upon. SPF claims to address the spam problem (according to text that >| was on the spf.pobox.com home page) so the Accredidation and Reputation >| services that are a necessary component to this solution must be >| specified. An incomplete spec that lacks these things has no business >| aspiring to be an Internet Standard. How can a spec that is grossly >| incomplete be properly reviewed by us or the IESG? It can't! >| E.g. John Leslie is quite confused about how A&R might work, or I am, as >| mentioned above. > >Yes, a Unified proposal would need to discuss at least >reputation, at least in terms of local policy. A spec for >Accreditation would also be useful. > >As we are getting off topic for MARID, which is focused on >Sender ID at the moment, I suggest we discuss Unified >further in another forum, and report back with our findings >at a more appropriate time. > > > IMO, this is the right place/time to discuss HELO and Unified. CSV/MPR and Unified are the leading contenders now. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 04:25: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 EAA11877 for ; Wed, 15 Sep 2004 04:24: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 i8F7wvaE023562; Wed, 15 Sep 2004 00:58: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 i8F7wvO9023561; Wed, 15 Sep 2004 00:58:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F7wh1o023466 for ; Wed, 15 Sep 2004 00:58:56 -0700 (PDT) (envelope-from SRS0+09fe345cccf7d91838b9+388+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7Ugd-0007CS-Ek for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 08:58:43 +0100 Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 From: David Woodhouse To: IETF MARID WG In-Reply-To: References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=UTF-8 Message-Id: <1095235122.9144.990.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 08:58:43 +0100 Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 2004-09-14 at 20:35 -0500, wayne wrote: > [top quoting fixed, extra words deleted, and the Reference: header > restored. All due to brain-dead mail software.] Thanks for fixing that; it's amazing how poorly people will behave in public fora. Personally, I configure my mailing lists to reject any mail with 'Re:' in the Subject: header but neither References: nor In-Reply-To: headers. Philip, you really ought to invest in some non-broken mail software if you want to use it in public. > "Hallam-Baker, Phillip" writes: > > David Woodhouse [mailto:dwmw2@infradead.org] wrote: > >> I strongly disagree with this opinion. I believe that it does not make > >> sense to have multiple scopes, and certainly not to plan to add even > >> more scopes later. I shall explain my reasoning: > > > > I agree with Andy. > > No, apparently you agree with David Woodhouse. It is easy to get > confused when you don't use proper quoting. > > > I thought we should have done this all along. > > Yes, I know. This was discussed long ago. The rough consensus was > against your opinion. I thought that while there should be multiple > scopes, we could have one record that covered them all. The rough > consensus was against my opinion. > > Now, can we *PLEASE* stop re-raising old issues everything someone new > comes into this working group? Maybe I have indeed missed the discussion on this precise topic, but I suspect you might both have missed my point -- and in either case I apologise. Philip might be used to upside-down email and have thought that my first paragraph was in fact my conclusion, but I didn't expect that of you so it's probably my fault for not being concise enough in the first place. I was not saying that we should ditch either pra or mail-from scope and continue with only one or the two, which I know is an opinion which has been voiced before. I was saying that we should ditch _both_ pra and mail-from scopes and continue with something more appropriate. The point was that the mail-from and pra scopes are _both_ only useful for determining a trust level for a given mail server, by determining whom it belongs to. The 'domain' we use becomes nothing more than an arbitrary 'trust handle' which isn't even seen by most users anyway, as it's hidden in the Return-Path: or Resent-From:^WForwarded-For: headers. The mailfrom/pra scopes are not useful as end-to-end validation that a given mail really did come from the person from whom it claims to come. A mailfrom/pra 'PASS' is neither necessary nor sufficient to make that judgement reliably. There are both false positives and false negatives if one were to inadvisedly use it for such a purpose. Yet the very nature of the scopes makes it easy for the naïve user or admin to believe that they can be used that way. Therefore, it is actually counterproductive -- because it encourages a mistaken belief that this provides real end-to-end authentication when it cannot. My suggestion is that we should go forward with an entirely _different_ scope, not just unify on either mail-from or whatever the unencumbered pra replacement would be. There are many possibilities which would offer us some 'handle' on the owner of the mail server in question, without all the problems which both mail-from and pra scopes suffer. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 04:59: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 EAA13813 for ; Wed, 15 Sep 2004 04:59: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 i8F8QvHC033888; Wed, 15 Sep 2004 01:26: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 i8F8QvNM033887; Wed, 15 Sep 2004 01:26: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 i8F8QveY033863 for ; Wed, 15 Sep 2004 01:26:57 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id 17A03414C4; Wed, 15 Sep 2004 01:26:54 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Wed, 15 Sep 2004 01:26:54 -0700 (PDT) Message-ID: <1081.64.142.13.68.1095236814.squirrel@harry.mail-abuse.org> In-Reply-To: <4147DF3B.2060608@elvey.com> References: <41475F45.90707@elvey.com> <1095206014.29546.143.camel@ddev.mail-abuse.org> <4147DF3B.2060608@elvey.com> Date: Wed, 15 Sep 2004 01:26:54 -0700 (PDT) Subject: Re: HELO, IPR, A&R means new draft?; scope; Microsoft - (Re: DEPLOY- IP, HELO & touch count. ) From: "Douglas Otis" To: "Matthew Elvey" Cc: "Douglas Otis" , "IETF-MXCOMP" , "Carl Hutzler" , "John Leslie" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "Matthew Elvey" wrote: > On 9/14/2004 4:53 PM, Douglas Otis sent forth electrons to convey: >> On Tue, 2004-09-14 at 14:14, Matthew Elvey wrote: >>>=-=-=-=-= >>>On 8/25/2004 4:32 AM, Carl Hutzler sent forth electrons to convey: >>>> >>>> >>>>> Phrased differently: >>>>> .... >>>>> >>>> This is a VERY interesting approach. [...] >>>> >>>> This sounds really cool. But I am an engineer and must always ask, what >>>> is wrong with this and why has it not been thought of before? >> >> It has been considered and there is language within CSV that >> accommodates this approach. : ) >> > Right, it's not new. It just doesn't have Marketing Might behind it. > Of course now it has an encouraging nod from AOL...unofficially, of > course :) > >>>> Lets see, forwarding cases....might work here with some PRA/Submitter >>>> type changes. Not a huge problem. With the marid-mpr draft, there is no need to assert the list as comprehensive (closed) as it is not used to identify the MTA in any manner. As such, the typical implementation could treat this list as nominal to "color" the mail at the MUA and not force rejection of possible spoofing. There would be no forwarding issues in that case. > > >>>> I don't care whether a mail server is who he says he is, I care >>>> whether he's authorized to send the message he's trying to send. >> >> May I add that the marid-mpr draft can safely answer this question >> within a single DNS query and not require the potentially hundreds >> needed by Sender-ID or SPF. > > Cool, though to be fair: what's the upper limit on the number of DNS > queries marid-mpr might require, assuming a malicious sender attempting > a DoS? Unlike the 20 limit recursion in SPF or the 10 script records in Sender-ID that may then require hundreds of DNS queries to assemble these record sets, MPR would require one or two queries for a PTR list of EHLO domain names using the label _mp.smtp.mailbox.dom and a single A record query using the same _mp.smtp.mailbox.dom label. (None of this is using reverse DNS.) When the MAIL FROM and the From are the same, just a single list would be needed. With CSV done first, MPR queries are optional and will not negatively effect someone's reputation as a result of these MPR check not being made. Reputation would always be done using CSV and mail "coloring" could be done with MPR. >> >> >>>Andrew Newton wrote: >>>> On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote: >>>>> A HELO scope would be useful. >>>> That is already being covered by the CSV proposals. >>> >>> No, not even close. -protocol with CSV, and -protocol with a HELO scope >>> would be EXTREMELY different, can't believe you don't see this, Andy! >> >> Please consider the need for two steps in this process. One, >> authenticate and validate the authorization of the MTA EHLO name. Two, >> obtain a list of authorized EHLO names referenced by the mailbox domain >> being examined. This list can be either nominal or comprehensive >> without the nominal case inviting spoofing. In which case, CSV remains >> "as-is". MPR records are much simpler and easier to maintain and obtain >> than scripts for SPF or Sender-ID. > > Confusing paragraph, that. Currently both Sender-ID and SPF attempt to combine identifying the MTA and authorizing the sending of the mailbox domain message. An exploit these collapsed functions (bogus) authentication with mailbox-domain authorization create is when the authorization list is "open" (nominal authorized MTAs, as with ... ?all), this allows others to usurp the reputation of the mailbox domain by obtaining the bogus authentication. Closed records could be called "comprehensive" as they encompass the entire set. In the case of SPF or Sender-ID, closed records are an effort to "idiot proof" the mail but then creates problems with forwarding. With MPR, these functions are separate and do not allow the exploit. By "coloring" the message when outside the nominal mail channel and making the authenticated EHLO visible, there should be little need to close the list except for those domains that are typical targets of spoofing. I should note that marid-mpr allows for better "idiot proofing." >> I would suggest avoiding sequential TXT scripts needed with either SPF >> or Sender-ID as being unworkable. CSV used in combination with MPR and >> BATV provides all the features claimed by either SPF, SRS or Sender-ID >> without disrupting email to the same extent. >> >> There is another issue with either SPF or Sender-ID records. CSV and >> MPR are named based solutions that work within the natural scale of DNS >> and only require single non-sequential lookups. SPF or Sender-ID >> require either extensive iterative references to record names to obtain >> addresses, or the repeating of IP addresses in a script form. The >> maintenance of such a list will be high, or the relative overhead to use >> such a list will be high or both. > > Very efficient. >>... >> >>> In addition to/as part of the security review of SenderID: >>> I think it's necessary that a number of MAYs and SHOULD [NOT]s turn >>> into SHOULD [NOT]s and MUST [NOT]s. There is far too much waffling - >>> MUST [NOTs] MUST be used whereever there isn't a compelling reason not >>> to. IETF standards demand it. With respect to SPF or Sender-ID, there are optional modes that everyone seems to think are foolish to use, but are still in the draft such as +all. > Folks agree/disagree with that? (Applies only to SPF and SenderID.) > >>> Also, the way that Accredidation and Reputation services are to be used >>> is essential. It belongs in a BCP, which should specify BFP (Best >>> Future Practice) for how various tests should be interpreted and acted >>> upon. SPF claims to address the spam problem (according to text that >>> was on the spf.pobox.com home page) so the Accredidation and Reputation >>> services that are a necessary component to this solution must be >>> specified. An incomplete spec that lacks these things has no business >>> aspiring to be an Internet Standard. How can a spec that is grossly >>> incomplete be properly reviewed by us or the IESG? It can't! > > Folks agree/disagree that MARID specs should cover how they will work > with A&R services? > (IMO blacklists and whitelists ARE A&R services.) The result codes > from, e.g. sorbs - http://www.dnsbl.us.sorbs.net/using.shtml are more > than a binary result - some BLs provide bitmapped result codes. > Doug: What do you think? I think there is more to this than describing how things may work, but also must consider how these services will be effective at correcting problems. To move to a name based reputation or blacklisting, the name must be authenticated first-hand and not make assumptions about the mail channel integrity. In my view, this rules out MAIL FROM and any RFC2822 headers to be used for reputation purposes. I think much more needs to be provided in the reputation results with a minimum of time in existence and a complaint count that zeros when the domain administrator acknowledges the events. There can be flags that indicate opt-in only policy agreements, black-listed, unusual traffic change, size of domain, etc. I think there needs to be a move away from relative rating schemes. >> You will find that the marid-mpr draft does allow the protection of the >> From and the MAIL FROM and is a good alternative to the PRA approach. > > Indeed. I have. It's hell slogging through the acronyms though - MCAL, > MCNL, etc. I'll have to read it again in order to be clear on what goes > where - A vs PTR vs APL... It is a bit curt, but was intended just to illustrate how it could be done. I had more text, but I trimmed some of the narrative. I think feedback will help point out areas that need clarification. > Just read BATV - glad to see it! Perhaps it could pursue a standards > track - the 'Public Tagging' component means interoperability is > important so it should pursue standardization. Yes, I agree. Much better than the SRS concept in my view. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 06:05:50 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 GAA18558 for ; Wed, 15 Sep 2004 06:05:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F9NxJO055293; Wed, 15 Sep 2004 02:23: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 i8F9NxCX055292; Wed, 15 Sep 2004 02:23:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F9NwI7055236 for ; Wed, 15 Sep 2004 02:23:59 -0700 (PDT) (envelope-from SRS0+09fe345cccf7d91838b9+388+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7W10-0007L8-Fu for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 10:23:50 +0100 Subject: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: David Woodhouse To: MARID Content-Type: text/plain Message-Id: <1095240230.9144.1128.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 10:23:50 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Each of the mailfrom and pra scopes make flawed assumptions about forwarding practice, and it would be necessary for uninterested forwarding sites to modify their behaviour in accordance with any new RFC. Sites would need to modify the SMTP-reverse-path, or add a new header to conform with mailfrom/pra respectively. The use of '-all' in any such record makes the assumption that forwarding sites have _already_ upgraded. This is not realistic -- the date of publication would in effect be a 'flag day'. We should avoid such an occurrence. The first publication must prohibit ("MUST NOT") the use of '-all' in records of either scope until such time as it is later decided that the Internet as a whole is quorate with respect to whatever reverse-path/header modification is required for each. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 07:15: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 HAA22415 for ; Wed, 15 Sep 2004 07:15: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 i8FAh3i3084899; Wed, 15 Sep 2004 03:43:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FAh3YR084898; Wed, 15 Sep 2004 03:43:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FAh0oI084819 for ; Wed, 15 Sep 2004 03:43:02 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i8FAgpeC017701 for ; Wed, 15 Sep 2004 11:42:51 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i8FAgpt9017700; Wed, 15 Sep 2004 11:42:51 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. References: <1095240230.9144.1128.camel@imladris.demon.co.uk> From: Graham Murray Date: Wed, 15 Sep 2004 11:42:51 +0100 In-Reply-To: <1095240230.9144.1128.camel@imladris.demon.co.uk> (David Woodhouse's message of "Wed, 15 Sep 2004 10:23:50 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse writes: > We should avoid such an occurrence. The first publication must prohibit > ("MUST NOT") the use of '-all' in records of either scope until such > time as it is later decided that the Internet as a whole is quorate with > respect to whatever reverse-path/header modification is required for > each. I very strongly disagree. On the contrary, the use of -all should be encouraged as soon as possible. In the vast majority of cases (the exceptions being web sites such as greeting cards and 'email this news item') the forwarding is done by, or on behalf of, the recipient of the email. That the mail might be forwarded should not be of any concern to the sending domain which publishes -all MARID DNS entries. Do not forget that as far as the sender is concerned, the site doing the forwarding is the intended recipient of the email. So, it is the recipient's problem and responsibility to accept mail sent to addresses which are then forwarded to them. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 07:27:50 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 HAA23273 for ; Wed, 15 Sep 2004 07:27:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FAw8u3089453; Wed, 15 Sep 2004 03:58: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 i8FAw88j089452; Wed, 15 Sep 2004 03:58:08 -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 i8FAw7Bp089444 for ; Wed, 15 Sep 2004 03:58:07 -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 1C7XU8-0001kA-WC for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 05:58:06 -0500 To: "IETF MARID WG" References: <1095240230.9144.1128.camel@imladris.demon.co.uk> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 15 Sep 2004 05:58:00 -0500 In-Reply-To: <1095240230.9144.1128.camel@imladris.demon.co.uk> (David Woodhouse's message of "Wed, 15 Sep 2004 10:23:50 +0100") 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: DEPLOY: Permitting '-all' to be used immediately represents a flag day. 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.6 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 <1095240230.9144.1128.camel@imladris.demon.co.uk> David Woodhouse writes: > We should avoid such an occurrence. The first publication must prohibit > ("MUST NOT") the use of '-all' in records of either scope until such No. I own several domains that do not send email. Period. All such email claiming to be from them are forgeries. It makes no difference whether these emails have been forwarded or not, they are forgeries. Using "-all" is perfectly valid. Even in cases where a domain does send email, it should be up to the domain owners to decide whether they think that the problems with forwarders outweigh the problems with forgeries. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 07:47: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 HAA24633 for ; Wed, 15 Sep 2004 07:47:32 -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 i8FBHAIa091114; Wed, 15 Sep 2004 04:17:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FBHAGv091113; Wed, 15 Sep 2004 04:17:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FBH9dg091107 for ; Wed, 15 Sep 2004 04:17:10 -0700 (PDT) (envelope-from SRS0=ZczYekMW=ME=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8FBHASc006811 for ; Wed, 15 Sep 2004 13:17:10 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409151117.I8FBH9HA006801@asarian-host.net> Date: Wed, 15 Sep 2004 11:17:10 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. X-Trace: 6zjsvmunZUdY9t+XazfJaer66pt2UmiVPQQDgpXD1R52Y2aISX0rKl6OHm4FWlQStC20Oc8RdT3zPXJ06XkFuQ== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: References: <1095240230.9144.1128.camel@imladris.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUgktjFqW1BleBN9AQF9Lwf/Sj7XCw62c/EXUa1TXHUZBVzN6ZXzxIDp +bLySVc1QIaO+dPiBbuFN5invKqfsLQ3XU2qpA6XwX6mcX8uPUGbH4z1Ys8lW4jd wMtea9xt+wfz8188T8d4dZJP9f9uwPNjLAwO5DWYwriUMGJH5PqTefHosDOCiYoI tAiKCbRUbuBdE2JOFRdaMJP/hHGEYiZYmH0rZSglhET3ZN1nEHrP6SaGfJ+JnjZN stZ13euiivw0kSvoi6tRoZi6EoX9Q+W/bIf+/7I31JkERw20/PoKBpdkAmfTM3ip /2rt3dasJcjXDi4yVVz7HSA/CNuhTaJloPv8hleuY+gagyGYHvHhjw== =kwLY Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Murray wrote: > David Woodhouse writes: > >> We should avoid such an occurrence. The first publication must >> prohibit ("MUST NOT") the use of '-all' in records of either scope >> until such time as it is later decided that the Internet as a whole >> is quorate with respect to whatever reverse-path/header modification >> is required for each. > > I very strongly disagree. On the contrary, the use of -all should be > encouraged as soon as possible. I completely, and vehemently, agree with Graham, on both counts: people who have taken their time in the transitional phase (~all) should be actively encouraged to start using -all; and -all records SHOULD NOT be prohibited; not now, not ever. As I have pointed out earlier, interpreting SPF records is not obeying local policy, but REMOTE policy; namely, that of the domain owner. If the domain owner feels comfortable enough about his setup to use -all, then we SHOULD NOT break things by ignoring that policy; nor encourage people to revert to the "I am in the process of making up my mind/setting up my installation" stage, which ~all effectively is. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 07:57: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 HAA24994 for ; Wed, 15 Sep 2004 07:57:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FBWaF7092355; Wed, 15 Sep 2004 04:32:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FBWagK092354; Wed, 15 Sep 2004 04:32:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FBWZvM092348 for ; Wed, 15 Sep 2004 04:32:35 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7Y1b-0003Ej-Kq for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 12:32:36 +0100 Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: David Woodhouse To: IETF MARID WG In-Reply-To: References: <1095240230.9144.1128.camel@imladris.demon.co.uk> Content-Type: text/plain Message-Id: <1095247954.24547.369.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 12:32:35 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 05:58 -0500, wayne wrote: > I own several domains that do not send email. Period. All such email > claiming to be from them are forgeries. It makes no difference > whether these emails have been forwarded or not, they are forgeries. > > Using "-all" is perfectly valid. I agree that using "-all" by itself is valid. Rather, it is the use of ".* -all" which should be prohibited -- other records which permit mail, _followed_ by '-all'. > Even in cases where a domain does send email, it should be up to the > domain owners to decide whether they think that the problems with > forwarders outweigh the problems with forgeries. I disagree. We are supposed to be designing protocols for interoperation between sites; a scheme which actually works in practice. You cannot allow sites to merely disregard the way the real world works, to the detriment of others. Or would you also advocate permitting TCP implementations to do what they like with retries in the case where the link is congested? -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 08:02: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 IAA25320 for ; Wed, 15 Sep 2004 08:02: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 i8FBSvTi092019; Wed, 15 Sep 2004 04:28: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 i8FBSv6b092018; Wed, 15 Sep 2004 04:28:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FBShT4091979 for ; Wed, 15 Sep 2004 04:28:56 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7Xxr-0003Db-JW; Wed, 15 Sep 2004 12:28:44 +0100 Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: David Woodhouse To: Graham Murray Cc: ietf-mxcomp@imc.org In-Reply-To: References: <1095240230.9144.1128.camel@imladris.demon.co.uk> Content-Type: text/plain Message-Id: <1095247722.24547.363.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 12:28:42 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 11:42 +0100, Graham Murray wrote: > Do not forget that as far as the sender is concerned, the > site doing the forwarding is the intended recipient of the email. So, > it is the recipient's problem and responsibility to accept mail sent > to addresses which are then forwarded to them. That may be true, but it is the responsibility of this working group to propose a solution for this newly-imposed problem, and ensure that any necessary changes to current practice become widespread -- _before_ starting to rely on assumptions about it. I am not suggesting that '-all' should be permanently forbidden, merely that it must be forbidden in the first release of the new specification, and must remain so until such time as the proposed solutions are widespread. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 08:12:17 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 IAA26279 for ; Wed, 15 Sep 2004 08:12:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FBkAdw093318; Wed, 15 Sep 2004 04:46:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FBkA9E093317; Wed, 15 Sep 2004 04:46:10 -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 i8FBk9o9093309 for ; Wed, 15 Sep 2004 04:46: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 i8FBvqVJ029030; Wed, 15 Sep 2004 04:57:52 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8FBvpbI029026; Wed, 15 Sep 2004 04:57:51 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 15 Sep 2004 04:57:51 -0700 (PDT) From: "william(at)elan.net" To: Meng Weng Wong cc: Matthew Elvey , IETF-MXCOMP , , Carl Hutzler Subject: Re: HELO and Unified In-Reply-To: <20040915024151.GH23667@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 Tue, 14 Sep 2004, Meng Weng Wong wrote: > The unhappiness there seems to be with SPF Classic, and is > remedied by Unified. I would like to take this opportunity > to expand on some ideas for the working group's consideration. Instead of commenting directly on particular parts of Meng's post, I'm going to forward my post to MARID list way back from March 2004. My position has not changed - if we deploy one type of SMTP identity verification, we should probably deploy another one along with it and they both work better filing each other weeknesses. And still think that just one identity being is not enough to override negative from another, I believe that at least two identties must give postitive authentication results to override a negative (if I were to assign values to spf modifiers,it would be "-" = -2, "~" = -1, "?" = 0 and "+" = 1) and I do not believe that setting up PTR is such a problem as some believe (AOL requires all mail servers that connect to theirs have it for example). Now here goes my old post which is still quite relevent today: -------------------------------------------------------------- Date: Sun, 28 Mar 2004 20:33:17 -0800 (PST) From: "william(at)elan.net" To: Yakov Shafranovich Cc: IETF MXCOMP Subject: Re: Different identities for different problems? On Sun, 28 Mar 2004, Yakov Shafranovich wrote: > The goal of attacking hijacked machines is stated in the introduction of > the DRIP proposal. Bad idea - there is nothing that stops spammer from using domain with no dns record and it really does not help situation with zombies. All DRIP does is possibly help a little with forgeries seen in the end usually in the received header which help with tracking and that is all (but usually tracking is done by ip anyway). What does help is the record in reverse DNS (as in MTAMARK) indicating that no emails should be sent from this dial or dsl or corporate net and this MUST be done by ISP and not anybody else - they are the ones who control the ip block and know what is supposed to be there or not, however it needs to be more complex then MTAMARK as handle redirection and inclusion of user data properly (i.e. SPF or similar). There are also some issues with RFC2317 (which is in my opinion just a bad RFC that instead of proposing to do futher reverse subdelegation with NS, tried to get by with CNAMEs - bad, that means it will only work for PTR records and not anything else that might be in in-addr). But DRIP and/or RMX can be combined together with MTAMARK helping each other out. If ISP is not willing to (or what is more likely that its slow to act and) properly whitelist the IP of client machine then DRIP or RMX can come in and user can setup his email server to specifically whitelist this one ip (and only one or two but singular ips not ip range as not to give a hole for spammers to setup domains that whitelist entire world). Same true going back to RMX where airport kiosks annd forwarding server and similar (these are the biggest problems with RMX as far as who will suffer), their reverse ip can possily be whitelisted and then this will indicate that the mail server at that ip will send emails with RMX not matching 821 Mail-From (or 822 Mail-From if people on this list think that is better). My thinking is that all of these DRIP, RMX, MTA-MARK should be done together if people are willing to do even just one of them. Each one can serve its own purpose and at the same time when records are whitelisted by two of these and blacklisted by the last one, then the policy should be to let email through allowing to deal with either possible errors in setup or delibebetly when its appropriate in the situation. If people think it opens the hole for spammers, I can explain that in reality the hole is minor one and when using these holes spammers will expose themselve quite a bit (for example spammer that wants to whitelist his zombie proxy will have to setup domain with RMX and DRIP records for each proxy; this will allow to track proxy to specific spammer and also provides record of intent for law enforcement). If people are interested I'll write details on this, but I dont want to bother if there is not some initial support for it and if everyone just continues to argue and push their favorite proposal focusing on one single element (except SPF which at least tries to do things in more combined way focusing how to best accomodate different client implementations). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 08:43:49 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 IAA29009 for ; Wed, 15 Sep 2004 08:43:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FCA6kx095635; Wed, 15 Sep 2004 05:10: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 i8FCA6FQ095634; Wed, 15 Sep 2004 05:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FCA5VL095627 for ; Wed, 15 Sep 2004 05:10:05 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i8FCK6ga004547; Wed, 15 Sep 2004 08:20:06 -0400 From: To: "'David Woodhouse'" , "'Graham Murray'" Cc: Subject: RE: DEPLOY: Permitting '-all' to be used immediately represents aflag day. Date: Wed, 15 Sep 2004 08:04:36 -0400 Message-ID: <008101c49b1c$2c53de60$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <1095247722.24547.363.camel@hades.cambridge.redhat.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of David Woodhouse > Sent: Wednesday, September 15, 2004 7:29 AM > To: Graham Murray > Cc: ietf-mxcomp@imc.org > Subject: Re: DEPLOY: Permitting '-all' to be used immediately > represents > aflag day. > > > > On Wed, 2004-09-15 at 11:42 +0100, Graham Murray wrote: > > Do not forget that as far as the sender is concerned, the > > site doing the forwarding is the intended recipient of the > email. So, > > it is the recipient's problem and responsibility to accept mail sent > > to addresses which are then forwarded to them. > > That may be true, but it is the responsibility of this > working group to > propose a solution for this newly-imposed problem, and ensure that any > necessary changes to current practice become widespread -- _before_ > starting to rely on assumptions about it. There *is* a solution. If your domain does forwarding through SMTP servers that do not yet have the mechanism(s) necessary to work, then publish with ~all. For those domains who don't have/allow any forwarding and/or the known allowed forwarders have the necessary mechanisms in place, -all is perfectly acceptable. > > I am not suggesting that '-all' should be permanently > forbidden, merely > that it must be forbidden in the first release of the new > specification, > and must remain so until such time as the proposed solutions are > widespread. I have to 100% disagree: If the solution does not start working for at least *some* in the short term, then there will be reduced/zero perceived benefit which discourages buy-in from undecided fence sitters. > > -- > dwmw2 > Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 08:50: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 IAA29337 for ; Wed, 15 Sep 2004 08:50: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 i8FCLqr2096601; Wed, 15 Sep 2004 05:21: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 i8FCLqfr096600; Wed, 15 Sep 2004 05:21:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FCLqQK096594 for ; Wed, 15 Sep 2004 05:21:52 -0700 (PDT) (envelope-from alex@slot.hollandcasino.net) Received: by slot.hollandcasino.net (Postfix, from userid 500) id 7A70160244; Wed, 15 Sep 2004 14:19:27 +0200 (CEST) Date: Wed, 15 Sep 2004 14:19:27 +0200 From: Alex van den Bogaerdt To: IETF MARID WG Subject: Re: SPF abused by spammers Message-ID: <20040915121927.GA14802@slot.hollandcasino.net> Mail-Followup-To: IETF MARID WG References: <20040914220354.GA12575@slot.hollandcasino.net> <4B2FA436-06B5-11D9-8E48-000A95BC6A7E@margaretolson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2FA436-06B5-11D9-8E48-000A95BC6A7E@margaretolson.com> User-Agent: Mutt/1.4.1i X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 14, 2004 at 09:19:30PM -0400, Margaret Olson wrote: > >Accreditation: why would I care? > > > >By this I mean: can you give an example of how this would change my > >opinion based on their reputation? > > Very small senders won't have the volume to create a statistically > significant reputation. But if they are accredited ("this is a shoe > shop, established in 1985, uses good practices") and the reputation > data is essentially empty, then you know something. Basically what you're saying is that accreditation is a form of using someone else's reputation? IOW the number of reports on $shoeshop is too low to be of any value as far as reputation goes, but since $bigisp tells they're OK, I can see if I trust $bigisp to see if I want to trust $shoeshop? cheers, Alex From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 09:18: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 JAA01813 for ; Wed, 15 Sep 2004 09:18: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 i8FCk8t7098661; Wed, 15 Sep 2004 05:46: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 i8FCk8PS098659; Wed, 15 Sep 2004 05:46: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 i8FCk7p6098653 for ; Wed, 15 Sep 2004 05:46: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 i8FCw06S030497 for ; Wed, 15 Sep 2004 05:58:00 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8FCvx4i030494 for ; Wed, 15 Sep 2004 05:57:59 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 15 Sep 2004 05:57:59 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID List Subject: Re: FW: Microsoft's Updated Statement about IPR Claimed in and in Combination 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: I cound not find the patent at uspto.gov, can somebody help and give direct link or post copy of the patent text somewhere else? On Tue, 14 Sep 2004, Harry Katz wrote: > Today Microsoft filed the following disclosure statement with the IETF Secretariat regarding IPR claimed in relation to Sender ID. This statement does not mean that patents have been granted in any of the jurisdictions mentioned below, only that the patent applications themselves are due to be published shortly. > > ________________________________ > > Subject: Microsoft's Updated Statement about IPR Claimed in and in Combination > > Microsoft is aware of the existence of US, EP; JP; CN; KR; and IN patent applications that are likely to include claims that would necessarily be infringed when implementing the combination of the specifications entitled "Purported Responsible Address in E-mail Messages", file name draft-ietf-marid-pra-00.txt, and located at the following link on August 23, 2004, url: http://www.ietf.org/internet-drafts/draft-ietf-marid-pra-00.txt and the specification entitled "Sender ID: Authenticating E-mail", file name: draft-ietf-marid-core-03.txt, url: http://www.ietf.org/internet-drafts/draft-ietf-marid-core-03.txt. The patent applications are expected to be published by the respective patent offices on or around September 13, 2004. The relevant patent application information is: > > US - Title: "Reducing Unwanted And Unsolicited Electronic Messages By Preventing Connection Hijacking And Domain Spoofing", Serial no. 10/684020 > EP - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 04005644.2 > JP - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 2004-71769 > CN - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 200410028682.3 > KR - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 10-2004-16409 > IN - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 298/DEL/2004 > > A patent license with reasonable and non-discriminatory terms and conditions, with no fees or royalties is available at http://www.microsoft.com/mscorp/ip/standards/ or another public site that Microsoft may subsequently use to post the license. > From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 10:03: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 KAA05076 for ; Wed, 15 Sep 2004 10:03: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 i8FDSpow002637; Wed, 15 Sep 2004 06:28: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 i8FDSpVe002636; Wed, 15 Sep 2004 06:28:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8FDSovF002628 for ; Wed, 15 Sep 2004 06:28:50 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 25949 invoked from network); 15 Sep 2004 13:30:16 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 15 Sep 2004 13:30:16 -0000 In-Reply-To: <20040915121927.GA14802@slot.hollandcasino.net> References: <20040914220354.GA12575@slot.hollandcasino.net> <4B2FA436-06B5-11D9-8E48-000A95BC6A7E@margaretolson.com> <20040915121927.GA14802@slot.hollandcasino.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2D7C289F-071B-11D9-8E48-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Margaret Olson Subject: Re: SPF abused by spammers Date: Wed, 15 Sep 2004 09:28:49 -0400 To: Alex van den Bogaerdt 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 Sep 15, 2004, at 8:19 AM, Alex van den Bogaerdt wrote: > > On Tue, Sep 14, 2004 at 09:19:30PM -0400, Margaret Olson wrote: >>> Accreditation: why would I care? >>> >>> By this I mean: can you give an example of how this would change my >>> opinion based on their reputation? >> >> Very small senders won't have the volume to create a statistically >> significant reputation. But if they are accredited ("this is a shoe >> shop, established in 1985, uses good practices") and the reputation >> data is essentially empty, then you know something. > > Basically what you're saying is that accreditation is a form of > using someone else's reputation? > Yes. > IOW the number of reports on $shoeshop is too low to be of any value > as far as reputation goes, but since $bigisp tells they're OK, I can > see if I trust $bigisp to see if I want to trust $shoeshop? > Yes, although I think it's the accrediting agency you would decide if you trust and I doubt the accrediting agency would be an ISP over the long run. ISPs have a conflict of interest. You would decide if you trust the accrediting agency. This market is emerging - look at the IADB, the Verisign product, and many others. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 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 KAA07288 for ; Wed, 15 Sep 2004 10:25: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 i8FDqJqu004782; Wed, 15 Sep 2004 06:52:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FDqJih004781; Wed, 15 Sep 2004 06:52:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (mail.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FDqIr6004775 for ; Wed, 15 Sep 2004 06:52:19 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 09:52:20 -0400 Message-ID: <41484915.9010207@hepcoe.com> Date: Wed, 15 Sep 2004 09:52:21 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MARID Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. References: <1095240230.9144.1128.camel@imladris.demon.co.uk> In-Reply-To: <1095240230.9144.1128.camel@imladris.demon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Sep 2004 13:52:20.0503 (UTC) FILETIME=[38618270:01C49B2B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Add my name to those that disagree with you. I have "-all" in my SPF records because I am confident that all legitmate business related emails from my company will be sent from the servers specified in my SPF records and none others. If recipients are concerned about the possibility of missing some email due to greeting card companies and the like, they can use a whitelist for those. Otherwise, being in the banking industry, I am much more concerned about stopping forgeries than I am about permitting online greeting card emails. David Woodhouse wrote: >Each of the mailfrom and pra scopes make flawed assumptions about >forwarding practice, and it would be necessary for uninterested >forwarding sites to modify their behaviour in accordance with any new >RFC. > >Sites would need to modify the SMTP-reverse-path, or add a new header to >conform with mailfrom/pra respectively. > >The use of '-all' in any such record makes the assumption that >forwarding sites have _already_ upgraded. This is not realistic -- the >date of publication would in effect be a 'flag day'. > >We should avoid such an occurrence. The first publication must prohibit >("MUST NOT") the use of '-all' in records of either scope until such >time as it is later decided that the Internet as a whole is quorate with >respect to whatever reverse-path/header modification is required for >each. > > > From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 10:31: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 KAA08538 for ; Wed, 15 Sep 2004 10:31: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 i8FE21BZ006087; Wed, 15 Sep 2004 07:02: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 i8FE21xG006086; Wed, 15 Sep 2004 07:02:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FE21aA006059 for ; Wed, 15 Sep 2004 07:02:01 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [192.168.0.7] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id 979C03F409 for ; Wed, 15 Sep 2004 09:02:00 -0500 (CDT) Message-ID: <41484B54.6000207@ehsco.com> Date: Wed, 15 Sep 2004 10:01:56 -0400 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: DNS Record Types References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/14/2004 2:57 AM, Jim Lyon wrote: > On Monday, September 13, 2004 at 10:39 PM, Jonathan de Boyne-Pollard > said: > >>>The DNS resolver APIs on all Microsoft OS's don't let you >>>query for an unknown record type. >> >>Rubbish. >> > > If you're behind a firewall and you call this API with an unknown record > type, it will fail with INVALID_PARAMETER. That's completely different from the original statement, and is still insufficiently qualified -- the APIs let you do it, but Microsoft's firewall product in particular barfs up the failure. Users that are not behind a Microsoft firewall do not have this problem. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 10:33:54 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 KAA08923 for ; Wed, 15 Sep 2004 10:33:54 -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 i8FE4HmT006217; Wed, 15 Sep 2004 07:04:17 -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 i8FE4Hht006216; Wed, 15 Sep 2004 07:04:17 -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 i8FE4EJV006202 for ; Wed, 15 Sep 2004 07:04:17 -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 C5AD416CD2 for ; Wed, 15 Sep 2004 10:13:35 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Tue, 14 Sep 2004 15:23:11 PDT." <1095200590.29546.72.camel@ddev.mail-abuse.org> Date: Wed, 15 Sep 2004 10:13:35 -0400 Message-Id: <20040915141335.C5AD416CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > From the Latin authenticus- coming from the real author, of original or > first-hand authority. It would be a mistake to apply this term to a > second-hand authority, as is the case with SPF or Sender-ID. I thought we were discussing security terms, not Latin. > Rather, this mailbox domain has authorized second-hand parties to > act on their behalf and claim this authorization has been validated. No. The domain has published authentication information. The SMTP server then uses this information to decide if it wants to authorize the SMTP client. The SMTP server cannot authenticate the client, because it doesn't know who the client is. The DNS server holding the records obtained by the SMTP server cannot authorize the SMTP client, because the SMTP client isn't asking that DNS server for permission to do anything. Security guards authorize people. Corporate IT authenticates them. > It is not proper to claim an MTA, authorized to send messages with > my-small-business mailbox domain, is the same as being administered by > my-small-business.com. Which is why I never said that. > > then it would > > be imprudent to label *all* domains at that MTA "bad", just because > > you authenticated the MTA via EHLO. > > When the MTA administrator does not revoke access to abusive accounts, > why consider any message from this MTA to be valid? You're contradicting yourself. Previously in this thread, you were opposed to labelling people with a "broad brush". Now, you're claiming it's a good idea. Thanks. This lets me know your position isn't well-defined. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 10:40:04 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 KAA09465 for ; Wed, 15 Sep 2004 10:40: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 i8FE460w006195; Wed, 15 Sep 2004 07:04: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 i8FE461E006194; Wed, 15 Sep 2004 07:04:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FE45JS006187 for ; Wed, 15 Sep 2004 07:04:05 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:37953) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1C7aOB-0004UA-Ib (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 15:04:03 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7aOB-00035W-4T; Wed, 15 Sep 2004 15:04:03 +0100 Date: Wed, 15 Sep 2004 15:04:03 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: terry@ashtonwoodshomes.com cc: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Permitting '-all' to be used immediately represents aflag day. In-Reply-To: <008101c49b1c$2c53de60$2766f30a@development.greatgulfhomes.com> Message-ID: References: <008101c49b1c$2c53de60$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 terry@ashtonwoodshomes.com wrote: > > There *is* a solution. If your domain does forwarding through SMTP > servers that do not yet have the mechanism(s) necessary to work, then > publish with ~all. You do not understand the problem. The difficulty with forwarding occurs at the receiving sites, not the sending sites that publish Sender-ID records. If you use -all you must never send email to an alias-fowarding address -- but you have no way of knowing which addresses these are. Tony. -- f.a.n.finch http://dotat.at/ SELSEY BILL TO LYME REGIS: WEST OR NORTHWEST 4 OR 5, DECREASING 3, THEN BACKING SOUTHWEST 3 OR 4 OVERNIGHT. FAIR. GOOD. MODERATE BECOMING SLIGHT. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 10:53: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 KAA10281 for ; Wed, 15 Sep 2004 10:53: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 i8FEDSEu006935; Wed, 15 Sep 2004 07:13: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 i8FEDSRm006934; Wed, 15 Sep 2004 07:13:28 -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 i8FEDSdD006926 for ; Wed, 15 Sep 2004 07:13:28 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 15 Sep 2004 10:13:28 -0400 id 0015FA71.41484E08.00004CA3 In-Reply-To: References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Carl Hutzler , Meng Weng Wong , Matthew Elvey , IETF-MXCOMP From: Andrew Newton Subject: Re: HELO and Unified Date: Wed, 15 Sep 2004 10:13:25 -0400 To: Daniel Quinlan 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 Sep 15, 2004, at 1:24 AM, Daniel Quinlan wrote: > This cannot work since not all receivers can do SUBMITTER since > matching > SUBMITTER to the message is patent-encumbered How did you come to this conclusion? -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 11:25: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 LAA11885 for ; Wed, 15 Sep 2004 11:25: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 i8FEmdIJ009835; Wed, 15 Sep 2004 07:48: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 i8FEmdO2009834; Wed, 15 Sep 2004 07:48:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FEmQNE009801 for ; Wed, 15 Sep 2004 07:48:38 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7b52-0003t3-Ue; Wed, 15 Sep 2004 15:48:23 +0100 Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: David Woodhouse To: Kevin Peuhkurinen Cc: MARID In-Reply-To: <41484915.9010207@hepcoe.com> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <41484915.9010207@hepcoe.com> Content-Type: text/plain; charset=UTF-8 Message-Id: <1095259699.24547.496.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 15:48:20 +0100 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 2004-09-15 at 09:52 -0400, Kevin Peuhkurinen wrote: > Add my name to those that disagree with you. I have "-all" in my SPF > records because I am confident that all legitmate business related > emails from my company will be sent from the servers specified in my SPF > records and none others. Your confidence is misplaced. As an example -- if you ever send a mail to the address 'dwmw2@infradead.org', it's likely to get forwarded to wherever I happen to be reading my mail at the time, such as an email address at my current place of employment. Neither you nor the sysadmin at the final destination may have any idea about the arrangement, which is an established practice and which has worked for decades. Breaking this so abruptly would constitute a flag day. Your naïveté is a prime example of why such records should temporarily be prohibited, until such time as the rest of the world has adjusted. By immediately allowing the use of '-all' on domains which actually send mail, we would promote discord and harm interoperability. > Otherwise, being in the banking industry, I am much more concerned > about stopping forgeries than I am about permitting online greeting > card emails. Then you should be looking at a scheme which actually offers true end-to-end verification of identity. You could start by PGP-signing your output. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 11:35: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 LAA12353 for ; Wed, 15 Sep 2004 11:35: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 i8FF0YZb010866; Wed, 15 Sep 2004 08:00:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FF0YRn010865; Wed, 15 Sep 2004 08:00:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8FF0XoQ010858 for ; Wed, 15 Sep 2004 08:00:33 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 27064 invoked from network); 15 Sep 2004 15:02:00 -0000 Received: from unknown (HELO ?192.168.254.137?) (208.198.98.24) by ns1.hoster907.com with SMTP; 15 Sep 2004 15:02:00 -0000 In-Reply-To: <20040915015934.GG23667@dumbo.pobox.com> References: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> <20040915015934.GG23667@dumbo.pobox.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: IETF MARID WG From: Margaret Olson Subject: Re: Interpreting "v=spf1" Date: Wed, 15 Sep 2004 11:00:33 -0400 To: Meng Weng Wong 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 Sep 14, 2004, at 9:59 PM, Meng Weng Wong wrote: > > On Tue, Sep 14, 2004 at 08:17:51PM -0500, wayne wrote: > | > | "Records that begin with v=spf1 MUST be interpreted as > spf2.0/mailfrom,helo" > | > > I agree with the sentiment behind this suggestion. It might > even be more useful if v=spf1 records were defined to mean > > spf2.0/pra,mailfrom,helo,pra > > or perhaps > > spf2.0/pra,mailfrom,helo,pra,ptr > > and if a sender is uncomfortable with those semantics then > they should publish proper spf2.0 records that override the > v1 entries. No. If the standard supports spf1 then spf1 must mean *exactly* what it means today. Otherwise you are just introducing chaos. Margaret. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 12:03: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 MAA15817 for ; Wed, 15 Sep 2004 12:03: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 i8FFQPAm013422; Wed, 15 Sep 2004 08:26: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 i8FFQPJB013421; Wed, 15 Sep 2004 08:26:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FFQMk8013413 for ; Wed, 15 Sep 2004 08:26:23 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i8FFaEga021292; Wed, 15 Sep 2004 11:36:15 -0400 From: To: "'Tony Finch'" , Cc: Subject: RE: DEPLOY: Permitting '-all' to be used immediately representsaflag day. Date: Wed, 15 Sep 2004 11:20:32 -0400 Message-ID: <001001c49b37$8b5dbfa0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Tony Finch > Sent: Wednesday, September 15, 2004 10:04 AM > To: terry@ashtonwoodshomes.com > Cc: ietf-mxcomp@imc.org > Subject: RE: DEPLOY: Permitting '-all' to be used immediately > representsaflag day. > > > > On Wed, 15 Sep 2004 terry@ashtonwoodshomes.com wrote: > > > > There *is* a solution. If your domain does forwarding through SMTP > > servers that do not yet have the mechanism(s) necessary to > work, then > > publish with ~all. > > You do not understand the problem. The difficulty with > forwarding occurs > at the receiving sites, not the sending sites that publish Sender-ID > records. If you use -all you must never send email to an > alias-fowarding > address -- but you have no way of knowing which addresses these are. Valid point. With more thought, you are correct, sorry. I still support -all, because: Another way of looking at it is, if the receiver wants to forward other (valid) email address(es) to his/her actual email address, the onus is on the recipient to ensure that the MTA doing the forward on his/her behalf has the necessary mechanisms. If it does not then either accept the risk of rejected email OR strive to get the sender to send to the final email address directly. I prefer the latter, which under consideration: -if the sender a person, then an auto reply on the account saying (please now use my direct address to contact me) should suffice -if the sender is automated (such as mailing list) then the person should have updated their subscription/registration/whatever with the direct email address. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > > Tony. > -- > f.a.n.finch http://dotat.at/ > SELSEY BILL TO LYME REGIS: WEST OR NORTHWEST 4 OR 5, > DECREASING 3, THEN > BACKING SOUTHWEST 3 OR 4 OVERNIGHT. FAIR. GOOD. MODERATE > BECOMING SLIGHT. > From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 12:47:59 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 MAA19215 for ; Wed, 15 Sep 2004 12:47: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 i8FGCoqr017212; Wed, 15 Sep 2004 09:12:50 -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 i8FGCodS017211; Wed, 15 Sep 2004 09:12:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGCnmQ017202 for ; Wed, 15 Sep 2004 09:12:49 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:37076) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1C7cOm-0007vK-4h (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 17:12:48 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7cOm-0005Lz-0X; Wed, 15 Sep 2004 17:12:48 +0100 Date: Wed, 15 Sep 2004 17:12:48 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: terry@ashtonwoodshomes.com cc: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Permitting '-all' to be used immediately representsaflag day. In-Reply-To: <001001c49b37$8b5dbfa0$2766f30a@development.greatgulfhomes.com> Message-ID: References: <001001c49b37$8b5dbfa0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 terry@ashtonwoodshomes.com wrote: > > Another way of looking at it is, if the receiver wants to forward other > (valid) email address(es) to his/her actual email address, the onus is > on the recipient to ensure that the MTA doing the forward on his/her > behalf has the necessary mechanisms. Most recipients are not capable of doing so, and most forwarding sites do not have the necessary mechanisms. The necessary mechanisms either do not work adequately (in the case of /pra) or are problematic (in the case of /mailfrom). > If it does not then either accept the risk of rejected email OR strive > to get the sender to send to the final email address directly. The point of using a forwarding address is to have a stable email address independent of the final destination. It's a huge pain to have to update everyone's address books every year or two. > -if the sender a person, then an auto reply on the account saying > (please now use my direct address to contact me) should suffice Backscatter is part of the problem not part of the solution. Tony. -- f.a.n.finch http://dotat.at/ SOUTH FITZROY: NORTHEAST 4 OR 5 IN EAST, OCCASIONALLY 6 NEAR CAPE FINISTERRE, OTHERWISE VARIABLE 3 OR 4. FAIR. GOOD. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:11: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 NAA21075 for ; Wed, 15 Sep 2004 13:11: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 i8FGevFo019716; Wed, 15 Sep 2004 09:40: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 i8FGevNM019715; Wed, 15 Sep 2004 09:40:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net ([194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGeuWc019671 for ; Wed, 15 Sep 2004 09:40:56 -0700 (PDT) (envelope-from SRS0=ZczYekMW=ME=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8FGeTqH016580 for ; Wed, 15 Sep 2004 18:40:29 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409151640.I8FGESMV016570@asarian-host.net> Date: Wed, 15 Sep 2004 16:40:29 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: Permitting '-all' to be used immediately representsaflag day. X-Trace: KNHwMSfZhTlMnkEAUp5UDjT6TKhCwnUeKSs+eZkBSqpSwVEYfVcEmIzAi+SaJJx0Kf5KBr0yH3i/0bS7aHQ6Aw== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: References: <001001c49b37$8b5dbfa0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUhwfTFqW1BleBN9AQEymgf/XEBPdTuDOTy82FN26c4Cr4lNiWt9nstA xfswELKUk1QKTLOV6ih+zQls6ejY2xCUw+CBDKJ523/xmzo0FBkSfZXLzrwE6hAR p72dc79hAEwUOqWrdHW1UOT42ICrIllrWJjogyFmepiUDe3CZFTfe54VhLKpLDQw AK3DjW4oSLHskBLWXPqhjWobxiS7/trUaV1Rcyi2e9lKuvOPp6qGS2kyocjD30yF Gxj/iw1onXhhIbPboEM3O0xfzauKzsjvctkZqaHqI35vlRubcZ0yrHflNwVgh8Oc yoEglG91yKk/YBXAR6/aT7iQg/6UpaBNCbwgeYLh7/jwFiqjhqQItQ== =DiPc Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit terry@ashtonwoodshomes.com wrote: >> You do not understand the problem. The difficulty with >> forwarding occurs at the receiving sites, not the sending >> sites that publish Sender-ID records. There is no such thing as a "receiving site" here. Or rather, the term is used rather misguidedly to denote a site who forwards. If I send mail to a 'receiving' site, which forwards that mail, then that site is simply another hop in the sender chain. >> If you use -all you must never send email to an >> alias-fowarding address -- but you have no way >> of knowing which addresses these are. This 'problem' is hardly new; it is covered in section "Does SPF break email forwarding?" in the SPF FAQ, at: http://spf.pobox.com/faq-old.html The answer is given there, too. Worth quoting is this one: If you don't have procmail, the .forward could instead just say "|/usr/sbin/sendmail -oi -f nobody@intermediate-domain.com foo@bar.com" Professional forwarders should implement SRS. It does not suffice for them to be SPF compliant on the receiving end, yet to omit implementing the necessary rewriting scheme (or use SUBMITTER, once it comes into fashion) on the sending part of the equation. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:12: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 NAA21109 for ; Wed, 15 Sep 2004 13:12: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 i8FGSTTm018546; Wed, 15 Sep 2004 09:28:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGSTFU018545; Wed, 15 Sep 2004 09:28:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGSNNv018531 for ; Wed, 15 Sep 2004 09:28:28 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40417) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1C7cdr-0003rD-3M (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 17:28:23 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7cdq-0008Ie-GI; Wed, 15 Sep 2004 17:28:22 +0100 Date: Wed, 15 Sep 2004 17:28:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: David Woodhouse cc: Andrew Newton , IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: <1095200707.9144.376.camel@imladris.demon.co.uk> Message-ID: References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1095200707.9144.376.camel@imladris.demon.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 14 Sep 2004, David Woodhouse wrote: > > Therefore, the working group should abandon the 'mail from' and 'pra' > scopes and seek a _single_ scope which serves the purpose of identifying > the entity responsible for a given mail server. I agree. I also think that in this scenario the mechanism should be CSV rather than SPF, because CSV is vastly more efficient and less abusive of the DNS. Tony. -- f.a.n.finch http://dotat.at/ LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: WEST OR NORTHWEST BACKING SOUTHWEST 3 OR 4, INCREASING 5 TO 7 LATER. MAINLY FAIR. MAINLY GOOD. SLIGHT OR MODERATE, BECOMING ROUGH IN THE WEST. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:14:41 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 NAA21241 for ; Wed, 15 Sep 2004 13:14:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGeaYs019681; Wed, 15 Sep 2004 09:40:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGea9J019680; Wed, 15 Sep 2004 09:40:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGeN5m019661 for ; Wed, 15 Sep 2004 09:40:24 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C7cpO-00020F-00 for ; Wed, 15 Sep 2004 18:40:18 +0200 Received: from 141.84.224.27 ([141.84.224.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2004 18:40:18 +0200 Received: from claus by 141.84.224.27 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2004 18:40:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 Date: 14 Sep 2004 14:36:00 +0200 Lines: 29 Message-ID: <9Gs+YTGJcDD@gmane.3247.org> References: <1095079885.4995.213.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 141.84.224.27 User-Agent: OpenXP/3.9.8-cvs (Win32; Delphi) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse schrieb/wrote: > All we're doing is offering a way for sending mail hosts to offer an > arbitrary 'trust key' of their choice, which the recipient can then > look up in a database. > As long as there's a way of checking that the host in question really is > an authorised user of that 'trust key' it doesn't matter _what_ it is. This observation raises an important question: Why should building a database based on a 'trust key' reduce spam? The most obvious 'trust key' is the IP address of the sending MTA. Databases based on the IP address have already been built and are in production use. They do reduce spam but there is still a lot of spam that gets through. If Sender ID/SPF just changes the key from 'IP address' to something else, then I don't see how it can reduce spam UNLESS spammers can't change that key as easily as IP addresses. With domain-based keys, this is not the case: It's actually easier to register a throw-away domain name than to get a new block of IP addresses. Well, IP address-based databases have some problems on their own, which may or may not have hindered deployment (e.g. the server behind a DSL `dialup'' line). But SPF has similar problems. Claus -- http://www.faerber.muc.de From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:15: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 NAA21318 for ; Wed, 15 Sep 2004 13:15:45 -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 i8FGks9l020241; Wed, 15 Sep 2004 09:46:54 -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 i8FGkscr020240; Wed, 15 Sep 2004 09:46:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imladris.surriel.com (imladris.surriel.com [66.92.77.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGkrga020231 for ; Wed, 15 Sep 2004 09:46:53 -0700 (PDT) (envelope-from riel@surriel.com) Received: from localhost ([127.0.0.1]) by imladris.surriel.com with esmtp (Exim 4.22) id 1C7cvf-0004YG-Ss; Wed, 15 Sep 2004 12:46:47 -0400 Date: Wed, 15 Sep 2004 12:46:33 -0400 (EDT) From: Rik van Riel To: David Woodhouse cc: MARID Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. In-Reply-To: <1095240230.9144.1128.camel@imladris.demon.co.uk> Message-ID: References: <1095240230.9144.1128.camel@imladris.demon.co.uk> X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Received-SPF: imladris: localhost is always allowed. Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004, David Woodhouse wrote: > We should avoid such an occurrence. The first publication must prohibit > ("MUST NOT") the use of '-all' in records of either scope until such > time as it is later decided that the Internet as a whole is quorate with > respect to whatever reverse-path/header modification is required for > each. Agreed. In fact, there might just be too many email forwarding accounts out there to ever have a scheme like SPF work right. The validation of email really needs to be from the sender to the recipient, regardless of whether or not anybody else in-between handled the mail... Rik -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:17: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 NAA21390 for ; Wed, 15 Sep 2004 13:17:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGmnUu020429; Wed, 15 Sep 2004 09:48: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 i8FGmnQp020428; Wed, 15 Sep 2004 09:48:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGmmlq020421 for ; Wed, 15 Sep 2004 09:48:48 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43835) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1C7cxd-0004xL-F1 (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 17:48:49 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7cxd-0003QR-99; Wed, 15 Sep 2004 17:48:49 +0100 Date: Wed, 15 Sep 2004 17:48:49 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Andrew Newton cc: Meng Weng Wong , IETF-MXCOMP Subject: Re: HELO and Unified In-Reply-To: <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> Message-ID: References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004, Andrew Newton wrote: > On Sep 15, 2004, at 1:24 AM, Daniel Quinlan wrote: > > > This cannot work since not all receivers can do SUBMITTER since matching > > SUBMITTER to the message is patent-encumbered > > How did you come to this conclusion? It requires use of the PRA algorithm. Checking SUBMITTER against a Sender-ID record is equivalent to checking the PRA against a Sender-ID record, which is covered by M$'s vague IPR claims. Tony. -- f.a.n.finch http://dotat.at/ LANDS END TO ST DAVIDS HEAD INCLUDING THE BRISTOL CHANNEL: WEST OR NORTHWEST BACKING SOUTHWEST 3 OR 4, INCREASING 5 TO 7 LATER. MAINLY FAIR. GOOD, OCCASIONALLY MODERATE LATER. SLIGHT OR MODERATE, BECOMING ROUGH IN THE WEST. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:19: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 NAA21519 for ; Wed, 15 Sep 2004 13:19: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 i8FGlKIg020283; Wed, 15 Sep 2004 09:47:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGlKSn020282; Wed, 15 Sep 2004 09:47:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGlJFS020271 for ; Wed, 15 Sep 2004 09:47:19 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i8FGvJga028471; Wed, 15 Sep 2004 12:57:19 -0400 From: To: "'Tony Finch'" Cc: Subject: RE: DEPLOY: Permitting '-all' to be used immediately representsaflagday. Date: Wed, 15 Sep 2004 12:41:33 -0400 Message-ID: <004701c49b42$dc5dd420$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Tony Finch > Sent: Wednesday, September 15, 2004 12:13 PM > To: terry@ashtonwoodshomes.com > Cc: ietf-mxcomp@imc.org > Subject: RE: DEPLOY: Permitting '-all' to be used immediately > representsaflagday. > > > > On Wed, 15 Sep 2004 terry@ashtonwoodshomes.com wrote: > > > > Another way of looking at it is, if the receiver wants to > forward other > > (valid) email address(es) to his/her actual email address, > the onus is > > on the recipient to ensure that the MTA doing the forward on his/her > > behalf has the necessary mechanisms. > > Most recipients are not capable of doing so, and most > forwarding sites do > not have the necessary mechanisms. The necessary mechanisms > either do not > work adequately (in the case of /pra) or Agreed, I don't like PRA, it seems dumb perform tests on something that can be forged anyway. > are problematic (in the case of > /mailfrom). Problematic does not mean without resolution. I have heard solutions (although have not implemented any yet). > > > If it does not then either accept the risk of rejected > email OR strive > > to get the sender to send to the final email address directly. > > The point of using a forwarding address is to have a stable > email address Agreed, I have many email addresses, and I too will have to ensure the forwarding is done by compliant servers (or move the forwarding elsewhere). > independent of the final destination. It's a huge pain to > have to update > everyone's address books every year or two. I know. It's also a pain to be flooded with emails with forged from domain. > > > -if the sender a person, then an auto reply on the account saying > > (please now use my direct address to contact me) should suffice > > Backscatter is part of the problem not part of the solution. Agreed. I am already flooded with bounces and crap from failed delivery, viruses etc. PRA may cause some backscatter, but it has the potential to block a whole bunch (viruses usually include an SMTP engine so they don't need to relay through a real MTA, hence 1 hop, hence no backscatter on rejection before DATA). BTW I don't endorse PRA because (amongst other things) the backscatter issue. But I am voting for Classic SPF which does not have a backscatter issue (please correct me if I am wrong). Terry > > Tony. > -- > f.a.n.finch http://dotat.at/ > SOUTH FITZROY: NORTHEAST 4 OR 5 IN EAST, OCCASIONALLY 6 NEAR > CAPE FINISTERRE, > OTHERWISE VARIABLE 3 OR 4. FAIR. GOOD. > From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:20:24 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 NAA21661 for ; Wed, 15 Sep 2004 13:20:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGXR75018946; Wed, 15 Sep 2004 09:33:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGXRB5018945; Wed, 15 Sep 2004 09:33:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGXQ7i018935 for ; Wed, 15 Sep 2004 09:33:27 -0700 (PDT) (envelope-from csm@redhat.com) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8FGXRc4010112 for ; Wed, 15 Sep 2004 12:33:27 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8FGXRr11221 for ; Wed, 15 Sep 2004 12:33:27 -0400 Received: from [192.168.10.153] (vpn50-5.rdu.redhat.com [172.16.50.5]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i8FGXRNp006239 for ; Wed, 15 Sep 2004 12:33:27 -0400 Message-ID: <41486EC4.2070002@redhat.com> Date: Wed, 15 Sep 2004 12:33:08 -0400 From: Chuck Mead Organization: Red Hat, Inc. User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <41484915.9010207@hepcoe.com> <1095259699.24547.496.camel@hades.cambridge.redhat.com> In-Reply-To: <1095259699.24547.496.camel@hades.cambridge.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit David Woodhouse wrote: >On Wed, 2004-09-15 at 09:52 -0400, Kevin Peuhkurinen wrote: > > >>Add my name to those that disagree with you. I have "-all" in my SPF >>records because I am confident that all legitmate business related >>emails from my company will be sent from the servers specified in my SPF >>records and none others. >> >> > >Your confidence is misplaced. As an example -- if you ever send a mail >to the address 'dwmw2@infradead.org', it's likely to get forwarded to >wherever I happen to be reading my mail at the time, such as an email >address at my current place of employment. Neither you nor the sysadmin >at the final destination may have any idea about the arrangement, which >is an established practice and which has worked for decades. > >Breaking this so abruptly would constitute a flag day. Your naïveté >is a prime example of why such records should temporarily be prohibited, >until such time as the rest of the world has adjusted. > >By immediately allowing the use of '-all' on domains which actually send >mail, we would promote discord and harm interoperability. > Uhm... I object to the implication that -all should, or should not, be allowed. It is situationally dependent and the spec should bow to that possibility. Ex: moongroup.com uses -all right now and has for some time without any difficulties. I also recognize that other domains have different situations and for them -all would not be an efficacious choice. I think we should "allow" the use of -all or ~all as the domain administrators prefer based upon their own particular situation. -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:26:04 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 NAA21942 for ; Wed, 15 Sep 2004 13:26: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 i8FGpphd020731; Wed, 15 Sep 2004 09:51: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 i8FGppmY020730; Wed, 15 Sep 2004 09:51:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imladris.surriel.com (imladris.surriel.com [66.92.77.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGpoOi020724 for ; Wed, 15 Sep 2004 09:51:50 -0700 (PDT) (envelope-from riel@surriel.com) Received: from localhost ([127.0.0.1]) by imladris.surriel.com with esmtp (Exim 4.22) id 1C7d0T-00060l-MN; Wed, 15 Sep 2004 12:51:45 -0400 Date: Wed, 15 Sep 2004 12:51:45 -0400 (EDT) From: Rik van Riel To: David Woodhouse cc: Andrew Newton , IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: <1095200707.9144.376.camel@imladris.demon.co.uk> Message-ID: References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1095200707.9144.376.camel@imladris.demon.co.uk> X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Received-SPF: imladris: localhost is always allowed. Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 14 Sep 2004, David Woodhouse wrote: > The identity which is being checked at each hop would no longer be > directly related to the original sender of the mail, but merely serves > as a verified identifier for the entity which controls the mail server > in question, and can be used to determine a level of trust for that > server. > > Therefore, the 'mail from' and 'pra' scopes should be considered equal, > not as complementary forms of 'authentication'. Once the whole world has > upgraded, each scope provides merely an arbitrary handle by which to > classify the mail host which is submitting a given mail. Good point. Multiple scopes only really seem to make sense in a world where SPF isn't deployable ... Rik -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:29: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 NAA22211 for ; Wed, 15 Sep 2004 13:29:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FH0hLv021341; Wed, 15 Sep 2004 10:00: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 i8FH0hXr021340; Wed, 15 Sep 2004 10:00:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FH0OH3021306 for ; Wed, 15 Sep 2004 10:00:43 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7d8h-0004I2-SJ; Wed, 15 Sep 2004 18:00:16 +0100 Subject: RE: DEPLOY: Permitting '-all' to be used immediately representsaflag day. From: David Woodhouse To: terry@ashtonwoodshomes.com Cc: "'Tony Finch'" , ietf-mxcomp@imc.org In-Reply-To: <001001c49b37$8b5dbfa0$2766f30a@development.greatgulfhomes.com> References: <001001c49b37$8b5dbfa0$2766f30a@development.greatgulfhomes.com> Content-Type: text/plain Message-Id: <1095267614.24547.604.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 18:00:15 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 11:20 -0400, terry@ashtonwoodshomes.com wrote: > [ Tony Finch wrote: ] > > You do not understand the problem. The difficulty with > > forwarding occurs at the receiving sites, not the sending > > sites that publish Sender-ID records. If you use -all you > > must never send email to an alias-fowarding address -- > > but you have no way of knowing which addresses these are. > > Valid point. > With more thought, you are correct, sorry. Good. Some are rather disingenuously still claiming not even to see that. > I still support -all, because: > Another way of looking at it is, if the receiver wants to forward > other (valid) email address(es) to his/her actual email address, the > onus is on the recipient to ensure that the MTA doing the forward > on his/her behalf has the necessary mechanisms. Even assuming that the deployment of such mechanisms is acceptable, it will take _time_ for them to be deployed after the publication of the RFC which mandates them. It is the responsibility of this working group to enable interoperability between sites; we must not _simultaneously_ publish a requirement for such new mechanisms and permit sites to assume that the same mechanisms are _already_ deployed. That would be extremely irresponsible and foolish. For this reason, I believe that use of the '-all' record on domains which actually send mail could be described, but must be _temporarily_ prohibited, until such time as it is determined that a large enough proportion of the world has implemented these mechanisms of which you speak. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:34:04 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 NAA22617 for ; Wed, 15 Sep 2004 13:34:04 -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 i8FH0uDi021363; Wed, 15 Sep 2004 10:00: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 i8FH0uQL021362; Wed, 15 Sep 2004 10:00:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FH0tMY021355 for ; Wed, 15 Sep 2004 10:00:56 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45550) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1C7d9M-0000F3-2e (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 18:00:56 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7d9L-0005KX-Aw; Wed, 15 Sep 2004 18:00:55 +0100 Date: Wed, 15 Sep 2004 18:00:55 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "william(at)elan.net" cc: IETF-MXCOMP Subject: Re: MTAMARK and RFC 2317, was Re: HELO and Unified In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004, william(at)elan.net wrote: > There are also some issues with RFC2317 (which is in my opinion just a > bad RFC that instead of proposing to do futher reverse subdelegation > with NS, tried to get by with CNAMEs - bad, that means it will only work > for PTR records and not anything else that might be in in-addr). What makes you think that? To extend an example from RFC 2317: $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...) ;... 0/25 NS ns.A.domain. 1 CNAME 1.0/25.2.0.192.in-addr.arpa. $ORIGIN 0/25.2.0.192.in-addr.arpa. @ IN SOA ns.A.domain. hostmaster.A.domain. (...) @ NS ns.A.domain. 1 PTR host1.A.domain. TXT "ASRG.MTA=yes" The CNAME refers to the whole RR set, not any particular RR type. Tony. -- f.a.n.finch http://dotat.at/ FAEROES SOUTHEAST ICELAND: SOUTHEAST 4 OR 5 INCREASING 7 TO SEVERE GALE 9, VEERING SOUTH 6 OR 7 LATER. RAIN. GOOD BECOMING MODERATE OR POOR &NBSP;. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:35: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 NAA22744 for ; Wed, 15 Sep 2004 13:35: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 i8FH4faS021654; Wed, 15 Sep 2004 10:04: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 i8FH4fI0021653; Wed, 15 Sep 2004 10:04:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FH4eZr021645 for ; Wed, 15 Sep 2004 10:04:40 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46114) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1C7dCy-00071C-UP (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 18:04:40 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7dCy-0005u3-Ip; Wed, 15 Sep 2004 18:04:40 +0100 Date: Wed, 15 Sep 2004 18:04:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Permitting '-all' to be used immediately representsaflag day. In-Reply-To: <200409151640.I8FGESMV016570@asarian-host.net> Message-ID: References: <001001c49b37$8b5dbfa0$2766f30a@development.greatgulfhomes.com> <200409151640.I8FGESMV016570@asarian-host.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004, Mark wrote: > > terry@ashtonwoodshomes.com wrote: No he did not. Please attribute quotes correctly. > Worth quoting is this one: > > If you don't have procmail, the .forward could instead just say > "|/usr/sbin/sendmail -oi -f nobody@intermediate-domain.com foo@bar.com" Hey, why don't we just reject all email with a null return path? That'll solve the backscatter problem! Who cares about reliability anyway? Tony. -- f.a.n.finch http://dotat.at/ SHETLAND ISLES: NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4 THEN SOUTHEAST 6 OR 7, PERHAPS GALE 8 LATER. RAIN LATER. GOOD BECOMING MODERATE OR POOR. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH LATER. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13: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 NAA23092 for ; Wed, 15 Sep 2004 13:40:45 -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 i8FH9jXk022029; Wed, 15 Sep 2004 10:09: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 i8FH9jHX022028; Wed, 15 Sep 2004 10:09:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FH9iRa022019 for ; Wed, 15 Sep 2004 10:09:45 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (unknown [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id 301BD132CD1; Wed, 15 Sep 2004 13:07:37 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id DD5E2597; Wed, 15 Sep 2004 13:09:45 -0400 (EDT) Date: Wed, 15 Sep 2004 13:09:45 -0400 From: Meng Weng Wong To: Tony Finch Cc: IETF-MXCOMP Subject: Re: HELO and Unified Message-ID: <20040915170945.GJ23667@dumbo.pobox.com> References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 15, 2004 at 05:48:49PM +0100, Tony Finch wrote: | | It requires use of the PRA algorithm. Checking SUBMITTER against a | Sender-ID record is equivalent to checking the PRA against a Sender-ID | record, which is covered by M$'s vague IPR claims. | I wouldn't have a problem if somebody wanted to treat SUBMITTER as a first-class identity. The constraint that PRA == SUBMITTER could be left for patent-encumbered implementations to enforce. Implementations which do not wish to touch PRA could leave that constraint unenforced. Because we would subject the SUBMITTER identity to reputation/accreditation/local-whitelisting/policy checks before accepting the message, the risk of weakening protections for the other identities seems diminished. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:42: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 NAA23201 for ; Wed, 15 Sep 2004 13:42: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 i8FH6c3w021779; Wed, 15 Sep 2004 10:06: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 i8FH6cHV021778; Wed, 15 Sep 2004 10:06:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FH6bxG021770 for ; Wed, 15 Sep 2004 10:06:37 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46497) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1C7dEs-00019G-Ar (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 18:06:38 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7dEr-0006Fr-Ha; Wed, 15 Sep 2004 18:06:38 +0100 Date: Wed, 15 Sep 2004 18:06:37 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: terry@ashtonwoodshomes.com cc: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Permitting '-all' to be used immediately representsaflagday. In-Reply-To: <004701c49b42$dc5dd420$2766f30a@development.greatgulfhomes.com> Message-ID: References: <004701c49b42$dc5dd420$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 terry@ashtonwoodshomes.com wrote: > > I am already flooded with bounces and crap from failed delivery, viruses etc. Then what you want is BATV. Sender-ID and SPF will neither solve your problem completely nor quickly, whereas BATV will. Tony. -- f.a.n.finch http://dotat.at/ SHETLAND ISLES: NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4 THEN SOUTHEAST 6 OR 7, PERHAPS GALE 8 LATER. RAIN LATER. GOOD BECOMING MODERATE OR POOR. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH LATER. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:47:40 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 NAA23616 for ; Wed, 15 Sep 2004 13:47:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHBNgq022262; Wed, 15 Sep 2004 10:11:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FHBN4V022261; Wed, 15 Sep 2004 10:11:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (mail.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHBM3v022248 for ; Wed, 15 Sep 2004 10:11:23 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 13:11:23 -0400 Message-ID: <414877BC.60009@hepcoe.com> Date: Wed, 15 Sep 2004 13:11:24 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MARID Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <41484915.9010207@hepcoe.com> <1095259699.24547.496.camel@hades.cambridge.redhat.com> In-Reply-To: <1095259699.24547.496.camel@hades.cambridge.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Sep 2004 17:11:23.0847 (UTC) FILETIME=[072B2D70:01C49B47] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit David Woodhouse wrote: >On Wed, 2004-09-15 at 09:52 -0400, Kevin Peuhkurinen wrote: > > >>Add my name to those that disagree with you. I have "-all" in my SPF >>records because I am confident that all legitmate business related >>emails from my company will be sent from the servers specified in my SPF >>records and none others. >> >> > >Your confidence is misplaced. As an example -- if you ever send a mail >to the address 'dwmw2@infradead.org', it's likely to get forwarded to >wherever I happen to be reading my mail at the time, such as an email >address at my current place of employment. Neither you nor the sysadmin >at the final destination may have any idea about the arrangement, which >is an established practice and which has worked for decades. > >Breaking this so abruptly would constitute a flag day. Your naïveté >is a prime example of why such records should temporarily be prohibited, >until such time as the rest of the world has adjusted. > >By immediately allowing the use of '-all' on domains which actually send >mail, we would promote discord and harm interoperability. > > > To be brutally honest, unless you are an executive or member of our board of directors or an extremely important customer, I just don't care that much from a business perspective if you don't get my email. I'm not trying to put down your perspective any more than you are mine, but looking at it from a purely business rather than a techie point of view, it's just not my concern that you want to forward your mail AND have your end receiver do SPF checks as well. I'm just telling the world which servers are authorized to send email on behalf of my domains. It's your receiver that's dropping the email and if you are unhappy about not getting your mail, you should take it up with them. Now, if you could convince me that a large portion of our business contacts would have trouble with this, then I'd reconsider. >>Otherwise, being in the banking industry, I am much more concerned >>about stopping forgeries than I am about permitting online greeting >>card emails. >> >> > >Then you should be looking at a scheme which actually offers true >end-to-end verification of identity. You could start by PGP-signing your >output. > > > PGP signing my output would do next to nothing to stop phishing style forgeries. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:48: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 NAA23636 for ; Wed, 15 Sep 2004 13:48:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHEwvu022638; Wed, 15 Sep 2004 10:14: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 i8FHEwZI022637; Wed, 15 Sep 2004 10:14:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend1.messagingengine.com (frontend1.messagingengine.com [66.111.4.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHEvge022631 for ; Wed, 15 Sep 2004 10:14:57 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: ovT6hpAI6tQ0BghPit2q/w 1095268497 Received: from [192.168.0.4] (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by www.fastmail.fm (Postfix) with ESMTP id 73DE0C1557C; Wed, 15 Sep 2004 13:14:56 -0400 (EDT) Message-ID: <414878B8.9070401@elvey.com> Date: Wed, 15 Sep 2004 10:15:36 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Woodhouse Cc: MARID , william@elan.net Subject: A&R BCP & Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. References: <1095240230.9144.1128.camel@imladris.demon.co.uk> In-Reply-To: <1095240230.9144.1128.camel@imladris.demon.co.uk> 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 David Woodhouse wrote: >Each of the mailfrom and pra scopes make flawed assumptions about >forwarding practice, and it would be necessary for uninterested >forwarding sites to modify their behaviour in accordance with any new >RFC. > > This isn't a problem, because Tony's statement: >If you use -all you must never send email to an alias-fowarding >address > only applies in the mailfrom and pra scopes, and we're going to be checking HELO. If the HELO check (+ A&R check) passes, the forwarding problem GOES AWAY. BTW, apropos William Leibzon's post: I think an atomic scoring system, i.e. a system where a bunch of atomic tests are done and results of each assigned a score and the score summed is not optimal. This kind of issue is why I've been pushing for a BCP in this area. I'm thinking that instead, conditional logic is better, but I'm not sure. The SA rules that handle habeas are informative here; they have conditional logic: HABEAS_USER means "Has Habeas warrant mark and on User List" (This is conditional logic - it means: if H and U then score=score-8; else nothing.) HABEAS_INFRINGER means "Has Habeas warrant mark and on Infringer List" (which is conditional logic too) These are assigned the scores -8 and +16, respectively, by default, if they hit. No score is assigned for . No score is assigned for . This is the case in recent SA releases (2.6, 3.0). In 2.4, the tests were atomic, and it seems the conditional logic was a needed enhancement added later. 2.4: |score HABEAS_SWE -4.0 |score HABEAS_HIL 4.0 In 2.4 there was also |score HABEAS_VIOLATOR 8.0 |meta HABEAS_VIOLATOR (HABEAS_SWE && HABEAS_HIL) (Err. This is conditional logic too. My bad. Anyway, clearly it's important) If the HELO check (+ A&R check) passes, but the A&R check provides something other than a yes/no answer, then things get more complicated. Perhaps we should assume this is the case for the BCP. E.g. if the HELO A&R check results in what I'll call a 'weak pass', then further MARID checks would be useful, but if there's a strong pass, then don't do further tests, which would cause false positives, e.g. due to forwarders that don't do SRS or SUBMITTER. Is this complicated logic necesary, or would simple logic and HELO check (+ A&R check) test passes having a relatively large positive score be good enough? I'm pretty sure that the HELO check + A&R check should not be scored separately. http://old.spamassassin.org/full/3.0.x/dist/rules/50_scores.cf has sensible text for SPF followed by scores that are at odds with the text and are unreasonable: # # SPF # Note that the benefit for a valid SPF record is deliberately minimal; it's # likely that more spammers would quickly move to setting valid SPF records # otherwise. The penalties for an *incorrect* record, however, are large. ;) # ifplugin Mail::SpamAssassin::Plugin::SPF score SPF_PASS -0.001 score SPF_FAIL 0 0.974 0 0.875 score SPF_SOFTFAIL 0.500 score SPF_HELO_PASS -0.001 score SPF_HELO_FAIL 0 0.001 0 0.001 score SPF_HELO_SOFTFAIL 0 0.907 0 3.140 endif # Mail::SpamAssassin::Plugin::SPF From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:49:59 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 NAA23759 for ; Wed, 15 Sep 2004 13:49: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 i8FHBDIi022239; Wed, 15 Sep 2004 10:11:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FHBDjj022238; Wed, 15 Sep 2004 10:11:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHBB7R022218 for ; Wed, 15 Sep 2004 10:11:11 -0700 (PDT) (envelope-from SRS0=ZczYekMW=ME=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8FHBBXn017533 for ; Wed, 15 Sep 2004 19:11:11 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409151711.I8FHBB8P017523@asarian-host.net> Date: Wed, 15 Sep 2004 17:11:11 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: Permitting '-all' to be used immediately representsaflagday. X-Trace: 8QF+p495UKK9X1UlJ1VOWNb2slfIdlNvccgPCeWjp74sPiNq/hFzEbBW2ba2+jnoM1cnNpGoD4aeoI9/guutAQ== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: References: <001001c49b37$8b5dbfa0$2766f30a@asarian-host.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUh3rzFqW1BleBN9AQGmBAf/Qhi+7jonp37cfjTnmXJbw1/G0JpKTcDo HeaDJLC4Fv//gyo888/yM3XrKcUbEyTuAw+wN2mMHjdoO8v2gMs1Ib7SR//W0UIZ xrTePnWW69hJcBXUbz2B2+EJWl27OZ91aUii4VXlKHSIsBLBuC+zHneGcsXQUKB9 3uAXZRGNCU5lJTWwXRjn7Z50OMPvdrsoIXB7mGrRYVffNmgq3B1vYP4BGwKpOQCU ONXo1Sboy47aA/bBGsyfLiuizwu7Gn++ridXm3TCUxc+JihTUfia/0ZPDZHtJC+H jR9rQ4kpd0XsXOiOvBX2avhc75VTm7whvaXoQevYPmYuHfNf87IQEQ== =DxHI Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony Finch wrote: > On Wed, 15 Sep 2004, Mark wrote: >> >> terry@ashtonwoodshomes.com wrote: > > No he did not. Please attribute quotes correctly. Please, interpret posts correctly; the text I quoted had a double ">>", indicating I was quoting the poster Terry quoted. So, relative to "terry@ashtonwoodshomes.com wrote:", the ">>" was correct. >> Worth quoting is this one: >> >> If you don't have procmail, the .forward could instead just say >> "|/usr/sbin/sendmail -oi -f nobody@intermediate-domain.com >> foo@bar.com" > > Hey, why don't we just reject all email with a null return path? > That'll solve the backscatter problem! Who cares about reliability > anyway? Very silly remark, in otherwise very silly post. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:50: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 NAA23799 for ; Wed, 15 Sep 2004 13:50:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHBmSQ022289; Wed, 15 Sep 2004 10:11: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 i8FHBlRk022288; Wed, 15 Sep 2004 10:11:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHBlfP022278 for ; Wed, 15 Sep 2004 10:11:47 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 15 Sep 2004 10:10:40 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8FHAZPD018328; Wed, 15 Sep 2004 10:10:36 -0700 (PDT) Received: from fenton-w2k01.cisco.com (dhcp-128-107-178-82.cisco.com [128.107.178.82]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i8FHIofK001584; Wed, 15 Sep 2004 10:18:53 -0700 Message-Id: <4.3.2.7.2.20040915100035.03718cc0@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Sep 2004 10:10:29 -0700 To: Tony Finch , Andrew Newton From: Jim Fenton Subject: Re: HELO and Unified Cc: Meng Weng Wong , IETF-MXCOMP In-Reply-To: References: <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1095268733.450637"; x:"432000"; a:"rsa-sha1"; b:"nofws:1035"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"UVa1ZiHYavTN6ACSaaE7TtOq9twse0gSk4TZxdD5xSylQ0H5dcoU5vnWs6EEl" "+r0y0oVRAcoAcgniOpGJkaBBTwakgdAg/TNtWCjh0nP8u7NvXyd2HlbF7F0C/" "oZO+hOz+LHus7cBZj6xZc71s96sYrxyxSTmwdlvRuouBDkIaA="; c:"Date: Wed, 15 Sep 2004 10:10:29 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: HELO and Unified" IIM-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:48 PM 9/15/2004 +0100, Tony Finch wrote: >On Wed, 15 Sep 2004, Andrew Newton wrote: >> On Sep 15, 2004, at 1:24 AM, Daniel Quinlan wrote: >> >> > This cannot work since not all receivers can do SUBMITTER since matching >> > SUBMITTER to the message is patent-encumbered >> >> How did you come to this conclusion? > >It requires use of the PRA algorithm. Checking SUBMITTER against a >Sender-ID record is equivalent to checking the PRA against a Sender-ID >record, which is covered by M$'s vague IPR claims. Of course, this assumes that SUBMITTER is being checked. In past discussions on SUBMITTER, it hasn't been clear (to me) that this would always be done. Which makes me wonder how much value SUBMITTER has, since it can then be spoofed to anything that works. On the other hand, perhaps if the SUBMITTER address is checked against (just) the From address, and if different the From address is rewritten to make the SUBMITTER address that was used visible to the recipient, it might be useful. -Jim From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:54: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 NAA24193 for ; Wed, 15 Sep 2004 13:54: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 i8FHSnpt023801; Wed, 15 Sep 2004 10:28: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 i8FHSn2l023800; Wed, 15 Sep 2004 10:28:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHSnNh023794 for ; Wed, 15 Sep 2004 10:28:49 -0700 (PDT) (envelope-from csm@moongroup.com) Received: by server1.moongroup.com (Postfix, from userid 48) id 8445E1182400F; Wed, 15 Sep 2004 13:28:49 -0400 (EDT) Received: from 38.116.3.196 (SquirrelMail authenticated user csm); by www.moongroup.com with HTTP; Wed, 15 Sep 2004 13:28:49 -0400 (EDT) Message-ID: <33746.38.116.3.196.1095269329.squirrel@38.116.3.196> In-Reply-To: References: <1095240230.9144.1128.camel@imladris.demon.co.uk> Date: Wed, 15 Sep 2004 13:28:49 -0400 (EDT) Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: "Chuck Mead" To: "Rik van Riel" Cc: "David Woodhouse" , "MARID" User-Agent: SquirrelMail/1.4.3a-0.e3.1 X-Mailer: SquirrelMail/1.4.3a-0.e3.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Rik van Riel said: > > On Wed, 15 Sep 2004, David Woodhouse wrote: > >> We should avoid such an occurrence. The first publication must prohibit >> ("MUST NOT") the use of '-all' in records of either scope until such >> time as it is later decided that the Internet as a whole is quorate with >> respect to whatever reverse-path/header modification is required for >> each. > > Agreed. In fact, there might just be too many email forwarding > accounts out there to ever have a scheme like SPF work right. Again I say... this is situationally dependent. Using "MUST NOT" in the spec is sending the wrong message. The right message is that the domain admin "MAY USE" -all if they chose based on their individual domain situation. -- csm@moongroup.com Chief Tech and Bottle Washer From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 13:59:54 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 NAA24687 for ; Wed, 15 Sep 2004 13:59:54 -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 i8FHTLe1023848; Wed, 15 Sep 2004 10:29:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FHTLJx023847; Wed, 15 Sep 2004 10:29:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHTKM6023839 for ; Wed, 15 Sep 2004 10:29:20 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: Qc7ZvryucIGLvFUSGDdFEA 1095269360 Received: from [192.168.0.4] (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by www.fastmail.fm (Postfix) with ESMTP id 24FD44E7CFA; Wed, 15 Sep 2004 13:29:19 -0400 (EDT) Message-ID: <41487C1A.8020008@elvey.com> Date: Wed, 15 Sep 2004 10:30:02 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MARID Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. References: <004701c49b42$dc5dd420$2766f30a@development.greatgulfhomes.com> In-Reply-To: <004701c49b42$dc5dd420$2766f30a@development.greatgulfhomes.com> 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 -all is perfectly OK now. The spec should make clear the issue David raised, to the extent it remains an issue, given pending changes. That's all. >> If you don't have procmail, the .forward could instead just say >> "|/usr/sbin/sendmail -oi -f nobody@intermediate-domain.com foo@bar.com" > Yuck. A lame solution like this should be fixed or removed from the site. terry@ashtonwoodshomes.com wrote: >But I am voting for Classic SPF which does not have a backscatter issue (please correct me if I am >wrong). > It does; the spec doesn't even say not to bounce in case of 'fail'. The authors were too timid to make ANY concrete statements about what to do with the result of the SPF checks. It does mandate SRS, so it MIGHT cause a net reduction in backscatter. PS Folks, please email me if you think I'm posting too often; I'd like to know. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:00:34 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 OAA24801 for ; Wed, 15 Sep 2004 14:00:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHUouo024146; Wed, 15 Sep 2004 10:30:50 -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 i8FHUoUG024145; Wed, 15 Sep 2004 10:30:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHUni8024139 for ; Wed, 15 Sep 2004 10:30:49 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7dcJ-0004PJ-4M; Wed, 15 Sep 2004 18:30:52 +0100 Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 From: David Woodhouse To: Claus =?ISO-8859-1?Q?F=E4rber?= Cc: ietf-mxcomp@imc.org In-Reply-To: <9Gs+YTGJcDD@gmane.3247.org> References: <1095079885.4995.213.camel@localhost.localdomain> <9Gs+YTGJcDD@gmane.3247.org> Content-Type: text/plain; charset=UTF-8 Message-Id: <1095269449.24547.625.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 18:30:50 +0100 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 2004-09-14 at 14:36 +0200, Claus Färber wrote: > This observation raises an important question: Why should building a > database based on a 'trust key' reduce spam? > > The most obvious 'trust key' is the IP address of the sending MTA. > Databases based on the IP address have already been built and are in > production use. They do reduce spam but there is still a lot of spam > that gets through. > > If Sender ID/SPF just changes the key from 'IP address' to something > else, then I don't see how it can reduce spam UNLESS spammers can't > change that key as easily as IP addresses. With domain-based keys, this > is not the case: It's actually easier to register a throw-away domain > name than to get a new block of IP addresses. > > Well, IP address-based databases have some problems on their own, which > may or may not have hindered deployment (e.g. the server behind a DSL > `dialup'' line). But SPF has similar problems. All this is true, but people still seem to rabidly want SPF/SenderID. Partly I think this stems from a lack of realisation that in the presence of SRS or the Resent-From:^WForwarded-For: header addition, SPF and SenderID are still only capable of providing a way of determining who claims to be responsible for the individual mail server in question, rather than being a true end-to-end validation that the mail in question really did come from the user from whom it claims to come. But partly it does make some sense. Databases based on IP addresses are not entirely perfect, and some improvement could be obtained by using an alternative 'trust key' to identify the party responsible for the server in question. Not only can the problem of false positives and false negatives due to dynamic IP be avoided, but by using a key which covers _groups_ of servers, such as a domain name or the signer of a TLS certificate, we get to reduce the size of the database dramatically. What does _not_ make sense is to allow people to think that the use of a 'domain name' as the key actually gives any secure indication that the mail really did come from the domain it claims to come from. There are other groups working on such end-to-end authentication, and that is an orthogonal issue. Or at least it _should_ be; but some people seem confused. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:02:09 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 OAA24892 for ; Wed, 15 Sep 2004 14:02: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 i8FHOaSM023559; Wed, 15 Sep 2004 10:24:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FHOa9L023558; Wed, 15 Sep 2004 10:24:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHOZva023550 for ; Wed, 15 Sep 2004 10:24:35 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i8FHOJt5018450 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Sep 2004 10:24:19 -0700 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i8FHOJt5018450 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=Go8JjEJ0jzcEYLqKmcSUuVSLnFbEDBfDM51ckfllDdUpIE3/gyhzGyO6fjYFd42kz qw7Wp/4kdyfoJLwyU359QMiqos5PsbyK5V62oVzdBKFD+uQaQ+EoB3YQTlgBHrtuH6r nuutKPCi1Oc3wrg58pbhZqYUHN1M8DV0rEjJilA= Date: Wed, 15 Sep 2004 10:24:19 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Tony Finch cc: David Woodhouse , Andrew Newton , IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: Message-ID: References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1095200707.9144.376.camel@imladris.demon.co.uk> 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, 15 Sep 2004, Tony Finch wrote: > I agree. I also think that in this scenario the mechanism should be CSV > rather than SPF, because CSV is vastly more efficient and less abusive of > the DNS. And less abusive of the forwarders. My worry about the current direction to standardize a mailfrom scope is that there hasn't been a lot of technical discussion about the implication of changing the return paths by the group. -Rand From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:12:24 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 OAA25604 for ; Wed, 15 Sep 2004 14:12: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 i8FHe7YC024979; Wed, 15 Sep 2004 10:40: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 i8FHe7Zg024978; Wed, 15 Sep 2004 10:40:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHe64U024971 for ; Wed, 15 Sep 2004 10:40:07 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7dlJ-0004RJ-6a; Wed, 15 Sep 2004 18:40:10 +0100 Subject: Re: A&R BCP & Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: David Woodhouse To: Matthew Elvey Cc: MARID , william@elan.net In-Reply-To: <414878B8.9070401@elvey.com> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <414878B8.9070401@elvey.com> Content-Type: text/plain Message-Id: <1095270008.24547.635.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 18:40:08 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 10:15 -0700, Matthew Elvey wrote: > David Woodhouse wrote: > > Each of the mailfrom and pra scopes make flawed assumptions... > This isn't a problem, because Tony's statement [...] only applies in > the mailfrom and pra scopes, and we're going to be checking HELO. Er, OK -- I agree with the logic of that statement as it stands: the flawedness of the mailfrom and pra scopes isn't a problem if we don't actually _use_ them. That's fine by me. So let's not define them, and let's banish them entirely from our minds. But I don't quite understand what you're saying -- can you confirm precisely whom you mean by 'we' in your statement above? -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:12: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 OAA25646 for ; Wed, 15 Sep 2004 14:12:32 -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 i8FHhdv2025263; Wed, 15 Sep 2004 10:43: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 i8FHhd7C025262; Wed, 15 Sep 2004 10:43:39 -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 i8FHhdmN025254 for ; Wed, 15 Sep 2004 10:43:39 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 15 Sep 2004 13:43:40 -0400 id 0015FA7C.41487F4C.0000656F In-Reply-To: References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF-MXCOMP WG From: Andrew Newton Subject: Re: HELO and Unified Date: Wed, 15 Sep 2004 13:43:38 -0400 To: Tony Finch 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 Sep 15, 2004, at 12:48 PM, Tony Finch wrote: > Checking SUBMITTER against a > Sender-ID record is equivalent to checking the PRA against a Sender-ID > record, which is covered by M$'s vague IPR claims. Considering that there is no patent claim against the -submitter draft, I find this really hard to believe. If you believe this, then you might as well believe that checking MAIL FROM against a DNS record is covered by their claims. -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:17: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 OAA26136 for ; Wed, 15 Sep 2004 14:17: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 i8FHlJnr025531; Wed, 15 Sep 2004 10:47:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FHlJU5025530; Wed, 15 Sep 2004 10:47:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHlJ2V025524 for ; Wed, 15 Sep 2004 10:47:19 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7dsH-0004TF-Mx; Wed, 15 Sep 2004 18:47:22 +0100 Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: David Woodhouse To: Chuck Mead Cc: ietf-mxcomp@imc.org In-Reply-To: <41486EC4.2070002@redhat.com> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <41484915.9010207@hepcoe.com> <1095259699.24547.496.camel@hades.cambridge.redhat.com> <41486EC4.2070002@redhat.com> Content-Type: text/plain Message-Id: <1095270440.24547.646.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 18:47:21 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 12:33 -0400, Chuck Mead wrote: Ex: moongroup.com uses -all right now and has for some time without any difficulties. > I think we should "allow" the use of -all or ~all as the domain > administrators prefer based upon their own particular situation. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:18: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 OAA26181 for ; Wed, 15 Sep 2004 14:18: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 i8FHoi9Y025781; Wed, 15 Sep 2004 10:50: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 i8FHoiCU025780; Wed, 15 Sep 2004 10:50:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHoio7025773 for ; Wed, 15 Sep 2004 10:50:44 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7dva-0004U0-Mk; Wed, 15 Sep 2004 18:50:47 +0100 Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: David Woodhouse To: Chuck Mead Cc: ietf-mxcomp@imc.org In-Reply-To: <41486EC4.2070002@redhat.com> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <41484915.9010207@hepcoe.com> <1095259699.24547.496.camel@hades.cambridge.redhat.com> <41486EC4.2070002@redhat.com> Content-Type: text/plain Message-Id: <1095270645.24547.651.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 18:50:45 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Apologies for the previous empty post. I slipped while editing my quotation. At least I _do_ edit my quotations ;) On Wed, 2004-09-15 at 12:33 -0400, Chuck Mead wrote: > Ex: moongroup.com uses -all right now and has for some time without any > difficulties. > > I also recognize that other domains have different situations and for > them -all would not be an efficacious choice. > > I think we should "allow" the use of -all or ~all as the domain > administrators prefer based upon their own particular situation. My situation is that I am on the Earth, in 2004. In my situation, I can neither publish nor obey a record ending in ' -all' with a reasonable expectation that I would not be causing valid email to be rejected. I know not how the situation is different for you. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:18: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 OAA26202 for ; Wed, 15 Sep 2004 14:18:45 -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 i8FHk4TT025434; Wed, 15 Sep 2004 10:46: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 i8FHk4pf025433; Wed, 15 Sep 2004 10:46:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHk30j025427 for ; Wed, 15 Sep 2004 10:46:04 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7dr3-0004Sy-Sn; Wed, 15 Sep 2004 18:46:06 +0100 Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: David Woodhouse To: Kevin Peuhkurinen Cc: MARID In-Reply-To: <414877BC.60009@hepcoe.com> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <41484915.9010207@hepcoe.com> <1095259699.24547.496.camel@hades.cambridge.redhat.com> <414877BC.60009@hepcoe.com> Content-Type: text/plain Message-Id: <1095270364.24547.643.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 18:46:05 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 13:11 -0400, Kevin Peuhkurinen wrote: > To be brutally honest, unless you are an executive or member of our > board of directors or an extremely important customer, I just don't care > that much from a business perspective if you don't get my email. That's perfectly reasonable. I understand your perspective. But that is not an acceptable perspective for this working group, which must concern itself with interoperability of the system as a worldwide whole. Without meaning disrespect by the precise choice of words in my paraphrasing of your sentiment -- it is not acceptable for this working group to codify a scheme whereby everyone can retreat into a corner and say "I don't care if you don't get my mail, and I don't care that I don't get yours". -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:30: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 OAA26830 for ; Wed, 15 Sep 2004 14:30: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 i8FHwgwN026874; Wed, 15 Sep 2004 10:58:42 -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 i8FHwghh026873; Wed, 15 Sep 2004 10:58:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHwfqg026867 for ; Wed, 15 Sep 2004 10:58:42 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7e3I-0004Vt-BT; Wed, 15 Sep 2004 18:58:45 +0100 Subject: Re: DEPLOY: Permitting '-all' to be used immediately representsaflagday. From: David Woodhouse To: Mark Cc: ietf-mxcomp@imc.org In-Reply-To: <200409151711.I8FHBB8P017523@asarian-host.net> References: <001001c49b37$8b5dbfa0$2766f30a@asarian-host.net> <200409151711.I8FHBB8P017523@asarian-host.net> Content-Type: text/plain Message-Id: <1095271123.24547.660.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 18:58:43 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 17:11 +0000, Mark wrote: > Tony Finch wrote: > > On Wed, 15 Sep 2004, Mark wrote: > >> > >> terry@ashtonwoodshomes.com wrote: > > > > No he did not. Please attribute quotes correctly. > > Please, interpret posts correctly; the text I quoted had a double ">>", > indicating I was quoting the poster Terry quoted. So, relative to > "terry@ashtonwoodshomes.com wrote:", the ">>" was correct. Strictly speaking, I suppose Terry did indeed write that, and the original fault is indeed with him for not attributing correctly, and not including an attribution line which you in turn could include. But perhaps Mark you could have cleaned it up when you replied? It would have helped. I really do wish people would behave a little better in their use of email -- if we can't manage a little bit of decorum even in a forum where we discuss technical matters related to email, surely we might as well all just give up on netiquette entirely? > > Hey, why don't we just reject all email with a null return path? > > That'll solve the backscatter problem! Who cares about reliability > > anyway? > > Very silly remark, in otherwise very silly post. You _do_ understand that this idea was the logical conclusion of your suggestion to use '-f nobody@...', and hence prevent the sender of the mail from getting any resulting bounces -- right? -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:32:11 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 OAA26949 for ; Wed, 15 Sep 2004 14:32:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHxYfH026935; Wed, 15 Sep 2004 10:59:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FHxYEx026934; Wed, 15 Sep 2004 10:59:34 -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 i8FHxXPl026925 for ; Wed, 15 Sep 2004 10:59:33 -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 i8FIBGa4009137; Wed, 15 Sep 2004 11:11:17 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8FIBGVc009134; Wed, 15 Sep 2004 11:11:16 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 15 Sep 2004 11:11:16 -0700 (PDT) From: "william(at)elan.net" To: Tony Finch cc: IETF-MXCOMP Subject: Re: MTAMARK and RFC 2317, was Re: HELO and Unified 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, 15 Sep 2004, Tony Finch wrote: > On Wed, 15 Sep 2004, william(at)elan.net wrote: > > > There are also some issues with RFC2317 (which is in my opinion just a > > bad RFC that instead of proposing to do futher reverse subdelegation > > with NS, tried to get by with CNAMEs - bad, that means it will only work > > for PTR records and not anything else that might be in in-addr). > > What makes you think that? To extend an example from RFC 2317: 1. Answering as to why I think RFC2317 is bad will take quite a number of bits and is probably absolutely off-topic to this list. If you're interested I'll answer answer in private. 2. RFC2317 may well be depreciated in the future and replaced with DNAME for dns forwarding of reverse dns zones. RFC2317 style delegation is not widely used today anyway. 3. The CNAME from PTR did not work on some of the servers I have. The problem is resolevers and not strictly standard, it appear some resolvers will simply not do query on txt when asked about ip address - but you can still force it manually by asking txt on reverse-ip.in-addr.arpa. Its not a big deal. 4. The point I made back is no longer important because, by May 04, I came up with idea to not bother putting TXT records directly in IN-ADDR zone but to put them in forward zone of PTR dns name pointed from IN-ADDR zone (see example later in this post): That works much better as far as deployment is concerned: 1. Most mail servers already look up PTR name of incoming client 2. If there is no PTR name, why bother asking for TXT 3. ISPs are relactant to give its customers access to INADDR and most ISPs are unwilling to do redeligation like RFC2317 suggests (I can explain why, but it would take quite a bit of text). But at the same time ISPs are usually willing to set inaddr to to dns names that their dedicated-level customers want; once this is done customer has full control of what to enter for mail policy record (like SPF) and does not need to bother contacting ISP if he needs to make changes to the policy. 4. For many mail servers, reverse dns points to the correct forward name of the mail server which is very often also used for EHLO As such for many systems, one policy record can cover both EHLO and PTR scopes For reference here is example of how PTR record can be entered: $ORIGIN 2.0.192.in-addr.arpa. 1 PTR mail1.example.com. $ORIGIN example.com. mail1 CNAME "v=spf1 ptr -all" mail1 CNAME "SPF2.0/PTR ptr -all" mail1 A 192.0.2.1 > The CNAME refers to the whole RR set, not any particular RR type. In fact strictly speaking you're not supposed to be able to enter any other type of dns record for host if you enter CNAME there. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:32:14 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 OAA26967 for ; Wed, 15 Sep 2004 14:32: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 i8FI0Ybq027029; Wed, 15 Sep 2004 11:00:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FI0Yjw027028; Wed, 15 Sep 2004 11:00:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (mail.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FI0XNc027022 for ; Wed, 15 Sep 2004 11:00:34 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 14:00:37 -0400 Message-ID: <41488345.4070402@hepcoe.com> Date: Wed, 15 Sep 2004 14:00:37 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MARID Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <41484915.9010207@hepcoe.com> <1095259699.24547.496.camel@hades.cambridge.redhat.com> <414877BC.60009@hepcoe.com> <1095270364.24547.643.camel@hades.cambridge.redhat.com> In-Reply-To: <1095270364.24547.643.camel@hades.cambridge.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Sep 2004 18:00:37.0362 (UTC) FILETIME=[E799CD20:01C49B4D] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Woodhouse wrote: >On Wed, 2004-09-15 at 13:11 -0400, Kevin Peuhkurinen wrote: > > >>To be brutally honest, unless you are an executive or member of our >>board of directors or an extremely important customer, I just don't care >>that much from a business perspective if you don't get my email. >> >> > >That's perfectly reasonable. I understand your perspective. But that is >not an acceptable perspective for this working group, which must concern >itself with interoperability of the system as a worldwide whole. > >Without meaning disrespect by the precise choice of words in my >paraphrasing of your sentiment -- it is not acceptable for this working >group to codify a scheme whereby everyone can retreat into a corner and >say "I don't care if you don't get my mail, and I don't care that I >don't get yours". > > > Agreed, but I also don't think it acceptable to say that nobody is allowed to make that choice either. A RECOMMENDED wording, in my mind, would be much more fitting. If you were to use a MUST NOT, what sort of limitation on it would you propose? "Implementors MUST NOT use '-all' until the IETF has determined that 80% of all forwarders are compatible with the specification"? How would you make that determination? From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:34: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 OAA27105 for ; Wed, 15 Sep 2004 14: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 i8FIAdcZ027786; Wed, 15 Sep 2004 11:10: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 i8FIAdSV027785; Wed, 15 Sep 2004 11:10:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIAdrT027777 for ; Wed, 15 Sep 2004 11:10:39 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54251) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1C7eEo-0005dm-VU (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 19:10:38 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7eEo-0007GV-PE; Wed, 15 Sep 2004 19:10:38 +0100 Date: Wed, 15 Sep 2004 19:10:38 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Andrew Newton cc: Tony Finch , IETF-MXCOMP WG Subject: Re: HELO and Unified In-Reply-To: Message-ID: References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004, Andrew Newton wrote: > On Sep 15, 2004, at 12:48 PM, Tony Finch wrote: > > > Checking SUBMITTER against a Sender-ID record is equivalent to > > checking the PRA against a Sender-ID record, which is covered by M$'s > > vague IPR claims. > > Considering that there is no patent claim against the -submitter draft, I find > this really hard to believe. My comment is not about which drafts are covered by the patent claims but about why an implementation that checks SUBMITTER necessarily infringes on the IPR. The IPR claim is against using -core and -pra in combination. -core defines a system for checking the PRA against a -protocol record. If you instead check the SUBMITTER against a -protocol record, -submitter requires that you ensure that the SUBMITTER is the PRA. Thus, you are checking the PRA against a -protocol record, which is covered by the IPR claim. Tony. -- f.a.n.finch http://dotat.at/ LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: WEST OR NORTHWEST BACKING SOUTHWEST 3 OR 4, INCREASING 5 TO 7 LATER. MAINLY FAIR. MAINLY GOOD. SLIGHT OR MODERATE, BECOMING ROUGH IN THE WEST. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:38: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 OAA27405 for ; Wed, 15 Sep 2004 14:37: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 i8FHuE7q026357; Wed, 15 Sep 2004 10:56: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 i8FHuERw026356; Wed, 15 Sep 2004 10:56:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FHuDiX026348 for ; Wed, 15 Sep 2004 10:56:13 -0700 (PDT) (envelope-from SRS0=ZczYekMW=ME=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8FHuGYR019060 for ; Wed, 15 Sep 2004 19:56:16 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409151756.I8FHUFYE019050@asarian-host.net> Date: Wed, 15 Sep 2004 17:56:16 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: Permitting '-all' to be used immediatelyrepresentsaflag day. X-Trace: 3Q0HKm9BF5KcvQVmqzJlPddbp6nt3m5AadwfKX7P29JOuHRYPAE5Hj76Sh4JycIoN7gRzs5tEcYgr9beZcGwFA== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: References: <001001c49b37$8b5dbfa0$2766f30a@development.greatgulfhomes.com> <1095267614.24547.604.camel@hades.cambridge.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUiCQDFqW1BleBN9AQFhLQf/ayQL7DBCPpmilEczTo4d18ojm/KCM+1B k7dz0kyF0JHxonOk7U2u2D5pcxwPbSUU634QRYoish3HKrTT99I85o+8qwAGLCn+ UOUXwX3krnOoTjoAUzNJG5nyGu0VQ6w37tVrrGYPe6C4wBoubdT03hAThaGIMNc6 WV2PS6A/G89Do1dX3ie85RN+KVdT3M1mtcZXznEdNakBhR5NVeDy8yXFfWwp0ge3 MOnpnhY2TfCk6mcHcEJUTvqKzGOgOsDbxznh05KVbQBo8Vmn59A/A4TVjU1S1hPX sc5NHkwfRwvMEU4qVWFWw4dOL/ng4JSS/rjiV/ou5gxpYGw60Ea16A== =//fe Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Woodhouse wrote: > On Wed, 2004-09-15 at 11:20 -0400, terry@ashtonwoodshomes.com wrote: >> Valid point. >> With more thought, you are correct, sorry. > > Good. Some are rather disingenuously still claiming not even to see > that. If on the eve of global SPF adoption you suddenly want to 'reinvent' the forwarding problem, which has existed and has been well documented from day one, then be my guest; but please do not ask me to play along. > It is the responsibility of this working group to enable > interoperability between sites; we must not _simultaneously_ publish a > requirement for such new mechanisms and permit sites to assume that > the same mechanisms are _already_ deployed. That would be extremely > irresponsible and foolish. A solid argument. But it is also putting the cart before the horse: you cannot wait for the world to improve until you jump aboard yourself. You must be the change you want to be in the world, as the Mahatma would say. And I can tell you this much: with everyone publishing ~all policies, and no forwarding ever breaking anywhere as a result (nor ever have any fake mail "fail" anywhere), no one, anywhere, will ever implement the necessary rewriting schemes, either. There must, at some point, be an incentive to change, lest you be dealt out of the game. What you propose, is taking away that incentive. And I propose to decline. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:42:26 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 OAA27623 for ; Wed, 15 Sep 2004 14:42:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIFtIE028231; Wed, 15 Sep 2004 11:15:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIFtiU028230; Wed, 15 Sep 2004 11:15:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIFs9p028224 for ; Wed, 15 Sep 2004 11:15:55 -0700 (PDT) (envelope-from SRS0+82fb7337a0e7a66877bc+388+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7eJo-0004aH-KM; Wed, 15 Sep 2004 19:15:49 +0100 Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 From: David Woodhouse To: Rand Wacker Cc: Tony Finch , Andrew Newton , IETF MARID WG In-Reply-To: References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1095200707.9144.376.camel@imladris.demon.co.uk> Content-Type: text/plain Message-Id: <1095272147.24547.677.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 19:15:47 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 10:24 -0700, Rand Wacker wrote: > On Wed, 15 Sep 2004, Tony Finch wrote: > > > I agree. I also think that in this scenario the mechanism should be CSV > > rather than SPF, because CSV is vastly more efficient and less abusive of > > the DNS. > > And less abusive of the forwarders. > > My worry about the current direction to standardize a mailfrom scope is > that there hasn't been a lot of technical discussion about the implication > of changing the return paths by the group. The rewriting using SRS or the Resent-From:^WForwarded-For: header has been bolted on almost as an afterthought, to patch up the bits where the original assumptions of the mailfrom or pra scopes respectively don't quite match reality. You seem to be correct that there hasn't been much discussion about how they affect the operation of the overall scheme. In fact I think there hasn't even been a lot of _thought_ about the implications. Having considered the implications myself, I believe that the mere _possibility_ of SRS or the header addition means that each of the mailfrom and pra scopes becomes nothing more than a way to determine the trustworthiness of the _individual_ mail host which is submitting the mail in question. There are better ways to determine the trustworthiness of a mail host, without the requirement for the whole world to be 'upgraded'. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:44:24 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 OAA27762 for ; Wed, 15 Sep 2004 14:44: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 i8FIFv4R028241; Wed, 15 Sep 2004 11:15: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 i8FIFv6A028240; Wed, 15 Sep 2004 11:15:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIFud5028234 for ; Wed, 15 Sep 2004 11:15:56 -0700 (PDT) (envelope-from SRS0=ZczYekMW=ME=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8FIFxQ5019699 for ; Wed, 15 Sep 2004 20:15:59 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409151815.I8FIFW8J019689@asarian-host.net> Date: Wed, 15 Sep 2004 18:15:59 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: Permitting '-all' to be used immediatelyrepresentsaflagday. X-Trace: WZGE6jTPTaP+JdDpQ1RFo5hWPBVTBQPDGuM7OyO8wRTPbbH9BRs8552oaPTusCCeW8PRRe2HrgmUwXM44D4Bdg== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: References: <001001c49b37$8b5dbfa0$2766f30a@asarian-host.net> <1095271123.24547.660.camel@hades.cambridge.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUiG3zFqW1BleBN9AQHdBAgAkeVGFyoW+VFcDKFPpQvyFD8H5X5Fm2Tr +UB/c7SwAfUDeAPB3k4NxQFZ/ollF/4I9Taqw1ntijC+KQ1P7wqsGzBOXYkfpXV1 bxCAvoV2UoFiBOzAlcd/xMG9qrKM8wq8x5U6PvkYWF92W6yy2/yISrN8Szhfb1nW sY+okbTmxdjEhjm69b9qU7gYSWukPj8JqVjCgXDcnhKY5yGOBOhJOiGi7GfLtfzX 7ZgcPU1QG1wXkkZuhSXTDcOuhP/SSQj/sjOTeGlqjovn04Jwq8nBdbZ1mFEHAcMI 5DbLpq0D7EbXF6NW4LEu5njsAyyoPk3JpWD3KN5gARHKvnYNtBU+cg== =dF9o Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Woodhouse wrote: >> Please, interpret posts correctly; the text I quoted had a double >> ">>", indicating I was quoting the poster Terry quoted. So, relative >> to "terry@ashtonwoodshomes.com wrote:", the ">>" was correct. > > Strictly speaking, I suppose Terry did indeed write that, and the > original fault is indeed with him for not attributing correctly, and > not including an attribution line which you in turn could include. > > But perhaps Mark you could have cleaned it up when you replied? Yes, I could have. Will do. >>> Hey, why don't we just reject all email with a null return path? >>> That'll solve the backscatter problem! Who cares about reliability >>> anyway? >> >> Very silly remark, in otherwise very silly post. > > You _do_ understand that this idea was the logical conclusion of your > suggestion to use '-f nobody@...', and hence prevent the sender of the > mail from getting any resulting bounces -- right? I quoted that suggestion from the spf.pobox FAQ. :) I said I quoted it, but had not put additional quotation marks around it. N.B. I do not think Meng really meant to litterally use "nobody@" in his example. He was, I believe, just demonstrating how one can easily change a ..forward file, to achieve the necessary rewriting, without having to implement SRS. P.S. I apologize for my somwhat crabby tone in my earlier posts today. Since you have been with SPF from a very early date too, I believe, I failed to see why the topic suddenly needed rehashing. But I had my say; I will step back a bit now, and let others have theirs. Cheers, - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:52:14 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 OAA28250 for ; Wed, 15 Sep 2004 14:52: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 i8FIJO6I028565; Wed, 15 Sep 2004 11:19: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 i8FIJOUo028564; Wed, 15 Sep 2004 11:19:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIJNqb028539 for ; Wed, 15 Sep 2004 11:19:23 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i8FITRga002906; Wed, 15 Sep 2004 14:29:27 -0400 From: To: "'David Woodhouse'" , "'Chuck Mead'" Cc: Subject: RE: DEPLOY: Permitting '-all' to be used immediately represents aflag day. Date: Wed, 15 Sep 2004 14:13:21 -0400 Message-ID: <006101c49b4f$b7777f00$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <1095270645.24547.651.camel@hades.cambridge.redhat.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of David Woodhouse > Sent: Wednesday, September 15, 2004 1:51 PM > To: Chuck Mead > Cc: ietf-mxcomp@imc.org > Subject: Re: DEPLOY: Permitting '-all' to be used immediately > represents > aflag day. > > > > Apologies for the previous empty post. I slipped while editing my > quotation. At least I _do_ edit my quotations ;) > > On Wed, 2004-09-15 at 12:33 -0400, Chuck Mead wrote: > > Ex: moongroup.com uses -all right now and has for some time > without any > > difficulties. > > > > I also recognize that other domains have different > situations and for > > them -all would not be an efficacious choice. > > > > I think we should "allow" the use of -all or ~all as the domain > > administrators prefer based upon their own particular situation. > > My situation is that I am on the Earth, in 2004. In my > situation, I can > neither publish nor obey a record ending in ' -all' with a reasonable > expectation that I would not be causing valid email to be rejected. > > I know not how the situation is different for you. I have many "pointer" domains, used for marketing (websites and advertising) but for which emails are never actually sent from. It is *very* valid to use -all for those domains, as any email from anywhere claiming to be from someone at one of those domains is definitely forged. Publishing -all for those domains alone will save me some forgeries and bounce crap and virused messages. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > > -- > dwmw2 > From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:52: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 OAA28277 for ; Wed, 15 Sep 2004 14:52:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIMmgN029063; Wed, 15 Sep 2004 11:22: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 i8FIMmYi029062; Wed, 15 Sep 2004 11:22:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIMlGe029056 for ; Wed, 15 Sep 2004 11:22:47 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i8FIMl7f005186 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Sep 2004 11:22:47 -0700 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i8FIMl7f005186 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=MCD4iCgbxIgLP/TOswPdF0KFtN2OnWsUhKJSIKnsrRFOdrhFDgU9pnD/fP64Rc3tw z4D+NtelFx7HD/hAwI/P/377z9jp1hsWTB863awzWraoCzvuPcu+YyjnLyMALsVFW/I VClDjnlXa1zWFPCDQFHzbJfcLl9ldCf71p7PwN4= Date: Wed, 15 Sep 2004 11:22:47 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: David Woodhouse cc: Tony Finch , Andrew Newton , IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: <1095272147.24547.677.camel@hades.cambridge.redhat.com> Message-ID: References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1095200707.9144.376.camel@imladris.demon.co.uk> <1095272147.24547.677.camel@hades.cambridge.redhat.com> 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, 15 Sep 2004, David Woodhouse wrote: > Having considered the implications myself, I believe that the mere > _possibility_ of SRS or the header addition means that each of the > mailfrom and pra scopes becomes nothing more than a way to determine the > trustworthiness of the _individual_ mail host which is submitting the > mail in question. Right. When you add SRS in to the equation, SPF Classic essentially "degrades" in to CSV-like functionality. -Rand From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 14:53: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 OAA28384 for ; Wed, 15 Sep 2004 14:53:45 -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 i8FIKqP9028724; Wed, 15 Sep 2004 11:20: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 i8FIKq0l028723; Wed, 15 Sep 2004 11:20:52 -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 i8FIKpiO028716 for ; Wed, 15 Sep 2004 11:20:51 -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 i8FIUZTA009678; Wed, 15 Sep 2004 11:30:35 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8FIUX5J009674; Wed, 15 Sep 2004 11:30:33 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 15 Sep 2004 11:30:33 -0700 (PDT) From: "william(at)elan.net" To: Jim Fenton cc: Tony Finch , Andrew Newton , Meng Weng Wong , IETF-MXCOMP Subject: Re: HELO and Unified In-Reply-To: <4.3.2.7.2.20040915100035.03718cc0@mira-sjc5-1.cisco.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 Wed, 15 Sep 2004, Jim Fenton wrote: > Of course, this assumes that SUBMITTER is being checked. In past > discussions on SUBMITTER, it hasn't been clear (to me) that this would > always be done. Which makes me wonder how much value SUBMITTER has, > since it can then be spoofed to anything that works. > > On the other hand, perhaps if the SUBMITTER address is checked against > (just) the From address, and if different the From address is rewritten > to make the SUBMITTER address that was used visible to the recipient, it > might be useful. I'll remind that I posted a set of ideas to extend SUBMITTER in similar way - http://www.imc.org/ietf-mxcomp/mail-archive/msg04726.html I'd like to receive more comments about this as far its only been one public comment and 4 private ones (but all positive ones!). Also it would be good if we had an answer from Pete Resnick regarding interpretation of RFC2822 and how it applies to the the current marid-core draft and its use of Resent-From headers by different types of forwarders and by mail lists. Such interpretation would help in deciding what the next steps should be in regards to the SenderID and Submitter. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 15:05: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 PAA29511 for ; Wed, 15 Sep 2004 15:05:04 -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 i8FIc05R030419; Wed, 15 Sep 2004 11:38:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIc0tK030418; Wed, 15 Sep 2004 11:38:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIbxUS030410 for ; Wed, 15 Sep 2004 11:38:00 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57538) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1C7efI-0005ZP-P7 (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 15 Sep 2004 19:38:00 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C7efI-0002Kz-Nq; Wed, 15 Sep 2004 19:38:00 +0100 Date: Wed, 15 Sep 2004 19:38:00 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Permitting '-all' to be used immediatelyrepresentsaflagday. In-Reply-To: <200409151815.I8FIFW8J019689@asarian-host.net> Message-ID: References: <001001c49b37$8b5dbfa0$2766f30a@asarian-host.net> <1095271123.24547.660.camel@hades.cambridge.redhat.com> <200409151815.I8FIFW8J019689@asarian-host.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004, Mark wrote: > > N.B. I do not think Meng really meant to litterally use "nobody@" in his > example. He was, I believe, just demonstrating how one can easily change a > ..forward file, to achieve the necessary rewriting, without having to > implement SRS. Whatever local part at the forwarding site is chosen, it will be wrong. Changing the return path to some address at a site that the recipient doesn't use is not a solution. Either the sender or the recipient needs to be informed of any problems with email delivery; if the recipient's address doesn't work the sender must be informed. Tony. -- f.a.n.finch http://dotat.at/ LOUGH FOYLE TO CARLINGFORD LOUGH: SOUTH 4 INCREASING 5 TO 7, PERHAPS GALE 8 LATER. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR LATER. SLIGHT OR MODERATE BECOMING ROUGH. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 15:05:09 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 PAA29534 for ; Wed, 15 Sep 2004 15:05: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 i8FIdhwM030511; Wed, 15 Sep 2004 11:39: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 i8FIdhGx030510; Wed, 15 Sep 2004 11:39:43 -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 i8FIdfJH030490 for ; Wed, 15 Sep 2004 11:39:42 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 58293 invoked by uid 1013); 15 Sep 2004 18:39:30 -0000 Date: Wed, 15 Sep 2004 20:39:30 +0200 From: Markus Stumpf To: David Woodhouse Cc: MARID Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. Message-ID: <20040915183930.GF37562@Space.Net> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095240230.9144.1128.camel@imladris.demon.co.uk> 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, Sep 15, 2004 at 10:23:50AM +0100, David Woodhouse wrote: > The use of '-all' in any such record makes the assumption that > forwarding sites have _already_ upgraded. This is not realistic -- the > date of publication would in effect be a 'flag day'. Why all the hassle. Let the people/market decide. - if someone publishes -all and gets important mail bounced s/he can still decide to remove/change -all - if someone uses forwards and doesn't receive emails any longer, s/he can o remove the forward o ask the next next hop/destination to switch of SPF checks o implement something as clumsy as SRS This is something the users must decide and it will influence the success of SPF, SRS or any other method like them. They break the Internet mail infrastructure as it existed for more than 20 years, we'll see how it will work out. \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 Sep 15 15:22:54 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 PAA02065 for ; Wed, 15 Sep 2004 15:22: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 i8FInXTu031180; Wed, 15 Sep 2004 11:49:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FInX8N031179; Wed, 15 Sep 2004 11:49:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FInW54031173 for ; Wed, 15 Sep 2004 11:49:33 -0700 (PDT) (envelope-from csm@redhat.com) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8FInYje019792 for ; Wed, 15 Sep 2004 14:49:34 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8FInYr26010 for ; Wed, 15 Sep 2004 14:49:34 -0400 Received: from [192.168.10.153] (vpn50-5.rdu.redhat.com [172.16.50.5]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i8FInXNp029933 for ; Wed, 15 Sep 2004 14:49:34 -0400 Message-ID: <41488EAB.40103@redhat.com> Date: Wed, 15 Sep 2004 14:49:15 -0400 From: Chuck Mead Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040914 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: MARID Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <41484915.9010207@hepcoe.com> <1095259699.24547.496.camel@hades.cambridge.redhat.com> <414877BC.60009@hepcoe.com> <1095270364.24547.643.camel@hades.cambridge.redhat.com> <41488345.4070402@hepcoe.com> In-Reply-To: <41488345.4070402@hepcoe.com> Content-Type: text/plain; charset=us-ascii; 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 Kevin Peuhkurinen wrote: > > David Woodhouse wrote: > >> On Wed, 2004-09-15 at 13:11 -0400, Kevin Peuhkurinen wrote: >> >> >>> To be brutally honest, unless you are an executive or member of our >>> board of directors or an extremely important customer, I just don't >>> care that much from a business perspective if you don't get my email. >> >> >> That's perfectly reasonable. I understand your perspective. But that is >> not an acceptable perspective for this working group, which must concern >> itself with interoperability of the system as a worldwide whole. >> >> Without meaning disrespect by the precise choice of words in my >> paraphrasing of your sentiment -- it is not acceptable for this working >> group to codify a scheme whereby everyone can retreat into a corner and >> say "I don't care if you don't get my mail, and I don't care that I >> don't get yours". >> >> >> > Agreed, but I also don't think it acceptable to say that nobody is > allowed to make that choice either. A RECOMMENDED wording, in my mind, > would be much more fitting. > > If you were to use a MUST NOT, what sort of limitation on it would you > propose? "Implementors MUST NOT use '-all' until the IETF has > determined that 80% of all forwarders are compatible with the > specification"? How would you make that determination? Exactly... and since many domains could safely use -all right now how would saying "MUST NOT" advance the use of the protocol towards an eventual "flag day"? I expect that answer would be short. It won't. For this reason I respectfully encourage the group to not choose the wording "MUST NOT" and "MAY NOT" with respect to implementation of -all. There has to be another way to make it clear that this *could* cause problems for domains choosing it as an option and yet still suggesting that once those problems are solved -all is suggested! -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 15:53: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 PAA03976 for ; Wed, 15 Sep 2004 15:53:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJQKgo034064; Wed, 15 Sep 2004 12:26:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJQKTY034063; Wed, 15 Sep 2004 12:26:20 -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 i8FJQI2b034054 for ; Wed, 15 Sep 2004 12:26:19 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 61657 invoked by uid 1013); 15 Sep 2004 19:26:22 -0000 Date: Wed, 15 Sep 2004 21:26:22 +0200 From: Markus Stumpf To: Mark Cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Permitting '-all' to be used immediatelyrepresentsaflagday. Message-ID: <20040915192622.GG37562@Space.Net> References: <1095271123.24547.660.camel@hades.cambridge.redhat.com> <200409151815.I8FIFW8J019689@asarian-host.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409151815.I8FIFW8J019689@asarian-host.net> 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, Sep 15, 2004 at 06:15:59PM +0000, Mark wrote: > N.B. I do not think Meng really meant to litterally use "nobody@" in his > example. He was, I believe, just demonstrating how one can easily change a > ..forward file, to achieve the necessary rewriting, without having to > implement SRS. s/easily/brokenly/ I seen hundreds of mail loops where customers configure their Exchange to pop3 their Mailboxes and then users have forwards to other domains. Exchange rewrites to 2921.MAILFROM to the address of the user and forwards the email through a outgoing relay (well behaved, use the mailserver of your provider) Funny things happen as soon as the destination host encounters an error (mailbox full, message too large, ...) and a bounce is generated. Yeah, this can be fixed by adding bounce Mailboxes for each and every user and changing all existing software and have users query the double number of mailboxes and then they will automate it and we'll start from the beginning. We could also just write a completely new mail system, maybe it would be lesser hassle and deploy faster and be less broken ... \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 Sep 15 15:55:26 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 PAA04129 for ; Wed, 15 Sep 2004 15:55:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJMujH033805; Wed, 15 Sep 2004 12:22: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 i8FJMuhT033804; Wed, 15 Sep 2004 12:22:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJMt0A033794 for ; Wed, 15 Sep 2004 12:22:55 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C7fMe-00058d-00; Wed, 15 Sep 2004 12:22:48 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16712.38535.993231.29658@proton.pathname.com> Date: Wed, 15 Sep 2004 12:22:47 -0700 To: Andrew Newton Cc: Daniel Quinlan , Carl Hutzler , Meng Weng Wong , Matthew Elvey , IETF-MXCOMP Subject: Re: HELO and Unified In-Reply-To: <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel Quinlan wrote: >> This cannot work since not all receivers can do SUBMITTER since >> matching SUBMITTER to the message is patent-encumbered Andrew Newton writes: > How did you come to this conclusion? The submitter can put whatever value they want in the SUBMITTER field. The receiver needs some way to associate the SUBMITTER value with the RFC 2822 message or the check is not meaningful. The method for associating SUBMITTER is PRA and PRA is patent-encumbered. Since Meng presented two options and one can be used for everyone and other cannot be used by everyone, the latter therefore doesn't satisfy the requirement presented by Meng. The associated requirement is that whatever non-PRA methods we define (mail-from and helo, for example), we need some RFC 2822 header(s) that MTAs can add so later stages (like MDA-based or MUA-based filters) have access to the envelope data and, if it has already been done, the result. Daniel -- Daniel Quinlan ApacheCon! 13-17 November (3 SpamAssassin http://www.pathname.com/~quinlan/ http://www.apachecon.com/ sessions & more) From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 16:09:50 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 QAA05125 for ; Wed, 15 Sep 2004 16:09:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJbli4034970; Wed, 15 Sep 2004 12:37:47 -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 i8FJbl66034969; Wed, 15 Sep 2004 12:37:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJbXL8034940 for ; Wed, 15 Sep 2004 12:37:46 -0700 (PDT) (envelope-from SRS0+09fe345cccf7d91838b9+388+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7fai-0008FO-Q4; Wed, 15 Sep 2004 20:37:20 +0100 Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 From: David Woodhouse To: Rand Wacker Cc: Tony Finch , Andrew Newton , IETF MARID WG In-Reply-To: References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1095200707.9144.376.camel@imladris.demon.co.uk> <1095272147.24547.677.camel@hades.cambridge.redhat.com> Content-Type: text/plain Message-Id: <1095277040.9144.1783.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 20:37:20 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 11:22 -0700, Rand Wacker wrote: > On Wed, 15 Sep 2004, David Woodhouse wrote: > > > Having considered the implications myself, I believe that the mere > > _possibility_ of SRS or the header addition means that each of the > > mailfrom and pra scopes becomes nothing more than a way to determine the > > trustworthiness of the _individual_ mail host which is submitting the > > mail in question. > > Right. When you add SRS in to the equation, SPF Classic essentially > "degrades" in to CSV-like functionality. That's twice you've said this of only 'mailfrom' scope, and it doesn't seem to have been an accident. It should be noted that the 'pra' scope, with the forwarders able to add an arbitrary domain in whatever header is used in place of the 'Resent-From:' header, has precisely the same characteristics. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 16:10:40 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 QAA05212 for ; Wed, 15 Sep 2004 16:10:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJbeVs034960; Wed, 15 Sep 2004 12:37:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJbeja034959; Wed, 15 Sep 2004 12:37:40 -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 i8FJbdjx034949 for ; Wed, 15 Sep 2004 12:37:39 -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 E7578414C8; Wed, 15 Sep 2004 12:37:41 -0700 (PDT) Subject: Re: HELO and Unified From: Douglas Otis To: Andrew Newton Cc: Tony Finch , IETF-MXCOMP WG In-Reply-To: References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <68E97F30-0721-11D9-A0A2-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1095277061.30159.161.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Sep 2004 12:37:41 -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 Wed, 2004-09-15 at 10:43, Andrew Newton wrote: > On Sep 15, 2004, at 12:48 PM, Tony Finch wrote: > > > Checking SUBMITTER against a > > Sender-ID record is equivalent to checking the PRA against a Sender-ID > > record, which is covered by M$'s vague IPR claims. > > Considering that there is no patent claim against the -submitter draft, > I find this really hard to believe. If you believe this, then you > might as well believe that checking MAIL FROM against a DNS record is > covered by their claims. Submitter information is not within a specific header. Safe use of the Submitter parameter requires the assertion affirmed (by way of the PRA algorithm). -Doug From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 17:01: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 RAA13767 for ; Wed, 15 Sep 2004 17:01: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 i8FKVfMi042032; Wed, 15 Sep 2004 13:31: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 i8FKVfUa042030; Wed, 15 Sep 2004 13:31:41 -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 i8FKVfqJ042024 for ; Wed, 15 Sep 2004 13:31:41 -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 9F10F414C5; Wed, 15 Sep 2004 13:31:45 -0700 (PDT) Subject: Re: SPF abused by spammers From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040915141335.C5AD416CD2@mail.nitros9.org> References: <20040915141335.C5AD416CD2@mail.nitros9.org> Content-Type: text/plain Message-Id: <1095280305.30159.217.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Sep 2004 13:31:45 -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 Wed, 2004-09-15 at 07:13, Alan DeKok wrote: > Douglas Otis wrote: > > From the Latin authenticus- coming from the real author, of original or > > first-hand authority. It would be a mistake to apply this term to a > > second-hand authority, as is the case with SPF or Sender-ID. > > I thought we were discussing security terms, not Latin. We are discussing the difference between send control lists and authentication. > > Rather, this mailbox domain has authorized second-hand parties to > > act on their behalf and claim this authorization has been validated. > > No. The domain has published authentication information. The > SMTP server then uses this information to decide if it wants to > authorize the SMTP client. The domain has not published authentication information, as this information is often not for hosts within their domain. Should the domain administrator wish mail forwarding to continue to operate, then these send control lists must encompass the entire Internet. How can this list be described as authenticating anything? In this case, it would authenticate the entire Internet being within a domain! This is abusing the concept of authentication. > The SMTP server cannot authenticate the client, because it doesn't > know who the client is. The SMTP server knows the SMTP client has claimed to be the EHLO name. I would think this would be a good starting point. > The DNS server holding the records obtained by the SMTP server > cannot authorize the SMTP client, because the SMTP client isn't asking > that DNS server for permission to do anything. The SMTP client is asking to send a message. > Security guards authorize people. Corporate IT authenticates them. Send control lists authorize SMTP routes without authenticating the identity permitted traversal. Sender-ID or SPF offer an expensive forms of routing constraints using address based send control lists. When 1000 identities are authorized to traverse an SMTP route, a transaction may safely carry identification of any of those authorized, depending upon the unknown configuration of each MTA or the unknown nature of the send control list. As there are potentially many send control lists which apply, even the total number of possible identities remains unknown. Constraining traversal in no way offers authentication of identity. None what so ever! > > It is not proper to claim an MTA, authorized to send messages with > > my-small-business mailbox domain, is the same as being administered by > > my-small-business.com. > > Which is why I never said that. > > > > then it would > > > be imprudent to label *all* domains at that MTA "bad", just because > > > you authenticated the MTA via EHLO. > > > > When the MTA administrator does not revoke access to abusive accounts, > > why consider any message from this MTA to be valid? > > You're contradicting yourself. Previously in this thread, you were > opposed to labeling people with a "broad brush". Now, you're > claiming it's a good idea. To refresh this point: http://www.imc.org/ietf-mxcomp/mail-archive/msg04648.html |> Shared services means shared accountability. If the recipient is |> unable to distinguish between a "good" party on a shared MTA and a |> "bad" party, then by definition, both parties fall into the same |> classification. | | Sharing an MTA is a highly effective method used by ISPs to abate abuse. | Reserve painting this technique with such a broad brush. This wide | brush never uncovers an MTA that may be compromised or poorly | administered. Holding those unable to take immediate corrective action | accountable will cause a most unwelcome backlash. The party that must | be held accountable is the entity administrating policies of the MTA. | That party is only identified by an authenticated EHLO domain or the IP | address. You are advocating Sender-ID or SPF identities are authenticated. I still claim this is a misuse of the term authenticate as this presumes the integrity of the mail channel and the nature of the list. I noted the hazard making this assumption would cause with respect to harming reputations of those that, through no action on their part, receive negative assertions. There are valid reasons people share an MTA server. I do not think it is wise to suggest any message which traverses an MTA authorized for a particular mailbox-domain should claim this MTA is (or is within) "mailbox-domain." Nor, when the message is spam, treat this event "as-if" mailbox-domain had actually been authenticated. This accountability must be seen as a hierarchy. It is not fair or effective to give mailbox domains a bad reputation when an MTA administrator fails to check send control lists, or has an MTA that becomes compromised. Blocking the spoofed mailbox domain does not correct the problem, but instead makes worse problems for those not in control of the MTA causing the problem. This would allow a spoofer to single out a few domains at a time while not disrupting general use of the problematic MTA. The only recourse for those harmed in this fashion would be through litigation. The problematic MTA is never blocked. > Thanks. This lets me know your position isn't well-defined. At least it is not understood. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 17:05: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 RAA13928 for ; Wed, 15 Sep 2004 17:05:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FKZexn042339; Wed, 15 Sep 2004 13:35:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FKZeI1042338; Wed, 15 Sep 2004 13:35:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imladris.surriel.com (imladris.surriel.com [66.92.77.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FKZdpt042329 for ; Wed, 15 Sep 2004 13:35:39 -0700 (PDT) (envelope-from riel@surriel.com) Received: from localhost ([127.0.0.1]) by imladris.surriel.com with esmtp (Exim 4.22) id 1C7gV7-0004Yv-67; Wed, 15 Sep 2004 16:35:37 -0400 Date: Wed, 15 Sep 2004 16:35:36 -0400 (EDT) From: Rik van Riel To: Chuck Mead cc: David Woodhouse , MARID Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. In-Reply-To: <33746.38.116.3.196.1095269329.squirrel@38.116.3.196> Message-ID: References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <33746.38.116.3.196.1095269329.squirrel@38.116.3.196> X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Received-SPF: imladris: localhost is always allowed. Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004, Chuck Mead wrote: > Again I say... this is situationally dependent. Using "MUST NOT" in the > spec is sending the wrong message. The right message is that the domain > admin "MAY USE" -all if they chose based on their individual domain > situation. Would a SHOULD NOT be acceptable, with an appropriate note explaining the pitfalls and why people need to be extremely careful with the use of -all ? Rik -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 17:14:24 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 RAA14732 for ; Wed, 15 Sep 2004 17:14:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FKf2RE042672; Wed, 15 Sep 2004 13:41: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 i8FKf2nU042671; Wed, 15 Sep 2004 13:41:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FKf0ok042660 for ; Wed, 15 Sep 2004 13:41:01 -0700 (PDT) (envelope-from SRS0+09fe345cccf7d91838b9+388+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C7gaO-0008N1-4u; Wed, 15 Sep 2004 21:41:04 +0100 Subject: Re: DEPLOY: Permitting '-all' to be used immediatelyrepresentsaflagday. From: David Woodhouse To: Mark Cc: ietf-mxcomp@imc.org In-Reply-To: <200409151815.I8FIFW8J019689@asarian-host.net> References: <001001c49b37$8b5dbfa0$2766f30a@asarian-host.net> <1095271123.24547.660.camel@hades.cambridge.redhat.com> <200409151815.I8FIFW8J019689@asarian-host.net> Content-Type: text/plain Message-Id: <1095280863.9144.1851.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 15 Sep 2004 21:41:03 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 18:15 +0000, Mark wrote: > > But perhaps Mark you could have cleaned it up when you replied? > > Yes, I could have. Will do. Thank you. I appreciate it's hard to maintain a coherent conversation in a forum where people insist on top-posting, omitting and mangling attributions, and omitting References: headers. But we can only do our best maintain an element of sanity. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 17:17: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 RAA14924 for ; Wed, 15 Sep 2004 17:17: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 i8FKkIFT043006; Wed, 15 Sep 2004 13:46: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 i8FKkI3A043005; Wed, 15 Sep 2004 13:46:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FKkHsO042998 for ; Wed, 15 Sep 2004 13:46:17 -0700 (PDT) (envelope-from csm@moongroup.com) Received: by server1.moongroup.com (Postfix, from userid 48) id BF5BC1182400F; Wed, 15 Sep 2004 16:46:21 -0400 (EDT) Received: from 38.116.3.196 (SquirrelMail authenticated user csm); by www.moongroup.com with HTTP; Wed, 15 Sep 2004 16:46:21 -0400 (EDT) Message-ID: <34398.38.116.3.196.1095281181.squirrel@38.116.3.196> In-Reply-To: References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <33746.38.116.3.196.1095269329.squirrel@38.116.3.196> Date: Wed, 15 Sep 2004 16:46:21 -0400 (EDT) Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: "Chuck Mead" To: "Rik van Riel" Cc: "David Woodhouse" , "MARID" User-Agent: SquirrelMail/1.4.3a-0.e3.1 X-Mailer: SquirrelMail/1.4.3a-0.e3.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Rik van Riel said: > On Wed, 15 Sep 2004, Chuck Mead wrote: > >> Again I say... this is situationally dependent. Using "MUST NOT" in the >> spec is sending the wrong message. The right message is that the domain >> admin "MAY USE" -all if they chose based on their individual domain >> situation. > > Would a SHOULD NOT be acceptable, with an appropriate note > explaining the pitfalls and why people need to be extremely > careful with the use of -all ? I see no reason why not. That sounds reasonable. In fact it's *MUCH* more reasonable a statement than "MUST NOT" when the "MUST NOT" is so dependent on a domain's individual technical situation. -- csm@moongroup.com Chief Tech and Bottle Washer From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 17:53: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 RAA17661 for ; Wed, 15 Sep 2004 17:53: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 i8FLIJQt047447; Wed, 15 Sep 2004 14:18:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FLIJNf047446; Wed, 15 Sep 2004 14:18:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FLIIRY047439 for ; Wed, 15 Sep 2004 14:18:18 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i8FLIKEI026252 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Sep 2004 14:18:21 -0700 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i8FLIKEI026252 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=aEoMub1398f8Ix04+mscXGVjEz7yKa6532nY1/YDYHN7+22Svjkf5o7jKdPumYfCi gDX9ZNWTpC0B1wU9eN4rN+BbX/UXsmF9ZOgOvG7VAOGQXFy4pacQlWmIAj7PG/jhgo+ 3dPIouc77bRTcFNraC9x2BCFlT1pQm5NGZwDVhE= Date: Wed, 15 Sep 2004 14:18:20 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: David Woodhouse cc: IETF MARID WG Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-Reply-To: <1095277040.9144.1783.camel@imladris.demon.co.uk> Message-ID: References: <46385749-041C-11D9-B751-000A95B3BA44@hxr.us> <1095200707.9144.376.camel@imladris.demon.co.uk> <1095272147.24547.677.camel@hades.cambridge.redhat.com> <1095277040.9144.1783.camel@imladris.demon.co.uk> 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, 15 Sep 2004, David Woodhouse wrote: > > Right. When you add SRS in to the equation, SPF Classic essentially > > "degrades" in to CSV-like functionality. > > That's twice you've said this of only 'mailfrom' scope, and it doesn't > seem to have been an accident. > > It should be noted that the 'pra' scope, with the forwarders able to add > an arbitrary domain in whatever header is used in place of the > 'Resent-From:' header, has precisely the same characteristics. Not arbitrary, forwarders can only add domains they are authorized to add in the Resent-From: header (if the receiver is checking the PRA). The difference between adding headers and using SRS is that in order to avoid blowing 64-byte localpart limit, SRS advocates that secondary forwarding hops (anyone doing an SRS rewrite on an SRS0 address) remove the interim hop information, so you really only do know the first hop a message purported to take and the last hop it really did take. By adding Resent-From headers you can get some idea of the full path that a message took, and if you trust different hops along the path to add the proper checks then you can do some work to determine where a message came from before it started along a chain you trust. Of course, this is ludicrously complex, difficult to implement and manage, and probably subject to creative spoofing somewhere. If we want to admit that none of the IP-based schemes can safely give us any assurance beyond the most recent hop, then we should be working on systems that admit that and don't try to reach beyond what they can really do by changing a fundamentally important piece of envelope information like the bounce address. I personally believe that Sender ID gives a positive benefit in that its going to allow people to positively identify a user-visible piece of messages coming from certain sources for a large majority of real internet traffic (direct site-to-site, no interim hops). The IP-based solutions won't allow many of us to outright reject forgeries at the border because the risk of false positives introduced by forwarding and mail lists is just too high, but they will allow us to remove uncertainty about the legitimacy of messages that came directly to us. To get end-to-end security we will have to use crypto, and I think everyone here would agree with that. -Rand From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 18:38:34 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 SAA21929 for ; Wed, 15 Sep 2004 18:38:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FM9b0R052053; Wed, 15 Sep 2004 15:09:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FM9bXD052052; Wed, 15 Sep 2004 15:09:37 -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 i8FM9WCU052045 for ; Wed, 15 Sep 2004 15:09:37 -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 64C2816CD2 for ; Wed, 15 Sep 2004 18:18:49 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Permitting '-all' to be used immediately representsaflag day. In-Reply-To: Your message of "Wed, 15 Sep 2004 17:12:48 BST." Date: Wed, 15 Sep 2004 18:18:49 -0400 Message-Id: <20040915221849.64C2816CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tony Finch wrote: > On Wed, 15 Sep 2004 terry@ashtonwoodshomes.com wrote: > > > > Another way of looking at it is, if the receiver wants to forward other > > (valid) email address(es) to his/her actual email address, the onus is > > on the recipient to ensure that the MTA doing the forward on his/her > > behalf has the necessary mechanisms. That sounds reasonable to me. > Most recipients are not capable of doing so, and most forwarding sites do > not have the necessary mechanisms. It's probably easier to deploy fixes to forwarding sites than to deploy SPF/Sender-Id to the whole net. In all the discussion about multi-hop message forwarding, I never understood why it was a good thing for the final recipient to bypass all of the intermediate hops for any bounce. I would say that deploying fixes to forwarding sites, so that they properly forward messages, is outside of the scope of MARID, but none the less is a topic which should be explored. Once those sites are fixed, many current objections to MARID protocols & deployment would disappear. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 18:40: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 SAA22060 for ; Wed, 15 Sep 2004 18:40: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 i8FM6MkE051866; Wed, 15 Sep 2004 15:06:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FM6MXE051865; Wed, 15 Sep 2004 15:06:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FM6Lx5051848 for ; Wed, 15 Sep 2004 15:06:21 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i8FM6Kw3013995; Wed, 15 Sep 2004 15:06:20 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7641A56E-0763-11D9-B38F-000A95CA7FAE@dbc.mtview.ca.us> Content-Transfer-Encoding: 7bit Cc: Andrew Newton From: Marshall Rose Subject: reminder: 3 message/day limit Date: Wed, 15 Sep 2004 15:06:15 -0700 To: "'IETF MARID WG'" 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 just a friendly reminder from the co-chairs: if you're sending more than three emails a day to this mailing list, then you need to start using flow control. there are, of course, exceptions to every rule; however, in the last week, there have been far too many people operating in burst mode... /mtr From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 19:02: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 TAA22916 for ; Wed, 15 Sep 2004 19:02: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 i8FMaNRM054112; Wed, 15 Sep 2004 15:36:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FMaNBl054111; Wed, 15 Sep 2004 15:36:23 -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 i8FMaNFs054105 for ; Wed, 15 Sep 2004 15:36:23 -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 8005A414C5; Wed, 15 Sep 2004 15:36:28 -0700 (PDT) Subject: Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: Douglas Otis To: Chuck Mead Cc: MARID In-Reply-To: <41488EAB.40103@redhat.com> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <41484915.9010207@hepcoe.com> <1095259699.24547.496.camel@hades.cambridge.redhat.com> <414877BC.60009@hepcoe.com> <1095270364.24547.643.camel@hades.cambridge.redhat.com> <41488345.4070402@hepcoe.com> <41488EAB.40103@redhat.com> Content-Type: text/plain Message-Id: <1095287788.30159.264.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Sep 2004 15:36:28 -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 Wed, 2004-09-15 at 11:49, Chuck Mead wrote: > Kevin Peuhkurinen wrote: > > David Woodhouse wrote: > >> On Wed, 2004-09-15 at 13:11 -0400, Kevin Peuhkurinen wrote: > >> > >>> To be brutally honest, unless you are an executive or member of our > >>> board of directors or an extremely important customer, I just don't > >>> care that much from a business perspective if you don't get my email. > >> > >> That's perfectly reasonable. I understand your perspective. But that is > >> not an acceptable perspective for this working group, which must concern > >> itself with interoperability of the system as a worldwide whole. > >> > >> Without meaning disrespect by the precise choice of words in my > >> paraphrasing of your sentiment -- it is not acceptable for this working > >> group to codify a scheme whereby everyone can retreat into a corner and > >> say "I don't care if you don't get my mail, and I don't care that I > >> don't get yours". > > > > Agreed, but I also don't think it acceptable to say that nobody is > > allowed to make that choice either. A RECOMMENDED wording, in my mind, > > would be much more fitting. > > > > If you were to use a MUST NOT, what sort of limitation on it would you > > propose? "Implementors MUST NOT use '-all' until the IETF has > > determined that 80% of all forwarders are compatible with the > > specification"? How would you make that determination? > > Exactly... and since many domains could safely use -all right now how > would saying "MUST NOT" advance the use of the protocol towards an > eventual "flag day"? I expect that answer would be short. It won't. > > For this reason I respectfully encourage the group to not choose the > wording "MUST NOT" and "MAY NOT" with respect to implementation of -all. > There has to be another way to make it clear that this *could* cause > problems for domains choosing it as an option and yet still suggesting > that once those problems are solved -all is suggested! Review the marid-mpr draft. http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt With MPR, not asserting a restrictive list (exclusive source) does not invite spoofing as a means of usurping a domain's reputation, as would be a problem with such lists in either Sender-ID or SPF. MPR depends upon the initial step of using CSV to establish a truly authenticated MTA name. From this point, it becomes a simple matter of creating a name list of EHLO names which normally send mail for mailbox.dom. (This takes advantage of built-in name compression and does not need to double enter addresses or perform added queries to obtain an address.) _mp.smtp.mailbox.dom. IN PTR mailbox.dom. _mp.smtp.mailbox.dom. IN PTR our-access-provider.com. _mp.smtp.mailbox.dom. IN PTR ads-r-us.com. This would need a single DNS lookup to obtain the EHLO name list and NO MTA addresses are required! A message sent from the MTA EHLO=mx003.bulkmail.ads-r-us.com would be seen as authorized to send mail for mailbox.dom. By using the CSV authenticated MTA name for reputation services and assertions, this does not burden the mailbox domain MTA send control lists with a danger of being exploited. It also does not require an indeterminate number of DNS queries to resolve. MPR however allows big-bank.com to constrain their list of EHLO names for RFC2822 From: xxxx@big-bank.com to be the exclusive source of their mail. The receiving MTA or MUA could use this information to either "color" the mail, or in the case of the exclusivity assertion, then these agents may even reject the message. I would expect this rejection behavior would need to a user based option. This reintroduces protection once only somewhat available with Sender-ID and the PRA algorithm. The major different between MPR and the PRA algorithm is that the field selection is both better authenticated and better defined. In the case of MPR, the authenticated EHLO should be visible to the user within the MUA to avoid phishing and spoofing as an additional precaution in newer MUAs. (If only Outlook would forward mail without stripping the headers, and then there would also be a simple means to report spam.) Instead of using BATV, the EHLO name list could be defined as the exclusive source for RFC2821 MAIL FROM. I feel BATV remains a better solution, but offered this to show how the SPF type of operation could be implemented using this approach. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 19:06: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 TAA23132 for ; Wed, 15 Sep 2004 19:06: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 i8FMSKoG053495; Wed, 15 Sep 2004 15:28:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FMSK5I053494; Wed, 15 Sep 2004 15:28:20 -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 i8FMSJgt053485 for ; Wed, 15 Sep 2004 15:28:19 -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 6B8F516CD2 for ; Wed, 15 Sep 2004 18:37:44 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Wed, 15 Sep 2004 13:31:45 PDT." <1095280305.30159.217.camel@ddev.mail-abuse.org> Date: Wed, 15 Sep 2004 18:37:44 -0400 Message-Id: <20040915223744.6B8F516CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > > I thought we were discussing security terms, not Latin. > > We are discussing the difference between send control lists and > authentication. Side-lines into :atin, and what words meant 2000 years ago aren't helpful. If they were, we wouldn't be using the letter "j", and we would be pronouncing "v" as "w". > To refresh this point: > http://www.imc.org/ietf-mxcomp/mail-archive/msg04648.html My point then, as now is: - Entities who have information should use it to make decisions. - Entities who do not have information cannot use it to make decisions. > You are advocating Sender-ID or SPF identities are authenticated. I > still claim this is a misuse of the term authenticate as this presumes > the integrity of the mail channel and the nature of the list. It presumes that the entities publishing those records have read the specification of the protocol they're implementing, and understand it's costs and benefits. The meaning of those records is as defined in the specifications, nothing more, or less. > I noted the hazard making this assumption would cause with respect > to harming reputations of those that, through no action on their > part, receive negative assertions. Again, your focus is on reputations and negative assertions. Mine is not. http://www.imc.org/ietf-mxcomp/mail-archive/msg04818.html Your response to that message didn't acknowledge that my goals are different from yours. While I understand very well your concerns about negative reputations, I do not see reputations as the primary goal of SPF, Sender-ID, or the MARID WG. Instead, what's important is the ability of a domain to publish a list of authentic outgoing MTA's. Reputation systems are secondary to the primary goal, and are piggy-backed on top of it. I don't see a need to discuss MARID-based reputation systems until such time as we have a clear specification of not only an MTA authentication system using DNS, but also the costs and benefits of using such a system. If that MTA authentication system is correct and useful, then reputation systems can be built on top of it. If the MTA authentication system is not correct or useful, then any reputation systems which depend on it will be likewise useless. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 19:48: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 TAA25073 for ; Wed, 15 Sep 2004 19:48: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 i8FNHXeK058019; Wed, 15 Sep 2004 16:17:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FNHXsJ058018; Wed, 15 Sep 2004 16:17:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FNHTCN058008 for ; Wed, 15 Sep 2004 16:17:30 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C7j1q-00066U-00 for ; Thu, 16 Sep 2004 01:17:34 +0200 Received: from du-001-249.access.de.clara.net ([212.82.227.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2004 01:17:34 +0200 Received: from nobody by du-001-249.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2004 01:17:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: HELO and Unified Date: Thu, 16 Sep 2004 01:16:32 +0200 Organization: Lines: 12 Message-ID: <4148CD50.56F0@xyzzy.claranet.de> References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <4147ED67.1040301@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-249.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Matthew Elvey wrote: >> we have been asked by the DNS people to refrain from putting >> additional load on the PTR system if possible. > Oh, I missed that request. A pointer and/or quote would be > appreciated if it wasn't made on this list. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 21:19: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 VAA01263 for ; Wed, 15 Sep 2004 21:19:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G0rHX9067084; Wed, 15 Sep 2004 17:53:17 -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 i8G0rHn5067083; Wed, 15 Sep 2004 17:53:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G0rFrL067076 for ; Wed, 15 Sep 2004 17:53:16 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C7kWW-0008Jf-00 for ; Thu, 16 Sep 2004 02:53:20 +0200 Received: from du-001-249.access.de.clara.net ([212.82.227.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2004 02:53:20 +0200 Received: from nobody by du-001-249.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2004 02:53:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Interpreting "v=spf1" Date: Thu, 16 Sep 2004 02:50:41 +0200 Organization: Lines: 23 Message-ID: <4148E361.1891@xyzzy.claranet.de> References: <9BE025E8-0662-11D9-B753-000393A56BB6@glyphic.com> <20040915015934.GG23667@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-249.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Margaret Olson wrote: > No. If the standard supports spf1 then spf1 must mean > *exactly* what it means today. Otherwise you are just > introducing chaos. Seconded. There is no "PRA" in all existing "v=spf1" policies. There is a "HELO" in draft-mengwong-spf-01.txt Partially optional on the side of the receiver, if I read this correctly. But no nonsense on the side of the sender (or rather the domain owner = author of the v=spf1 policy). One of our co-chairs proposed that we shouldn't discuss CSV and HELO before we are ready with spf2.0/mailfrom. In that stage an old v=spf1 policy can be handled as spf2.0/mailfrom. If a HELO scope is added later, and if it's still essentially the same as in v=spf1, then a v=spf1 policy could be handled as spf2.0/mailfrom,helo. But not as PRA. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 21:49:14 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 VAA02736 for ; Wed, 15 Sep 2004 21:49: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 i8G1DZeP068909; Wed, 15 Sep 2004 18:13: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 i8G1DZuN068908; Wed, 15 Sep 2004 18:13:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-m20.mx.aol.com (imo-m20.mx.aol.com [64.12.137.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G1DYTR068882 for ; Wed, 15 Sep 2004 18:13:34 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-m20.mx.aol.com (mail_out_v37_r3.7.) id s.fd.152adab (16110) for ; Wed, 15 Sep 2004 21:13:19 -0400 (EDT) Received: from [192.168.1.101] (pcp02139011pcs.reston01.va.comcast.net [68.48.28.80]) by air-id12.mx.aol.com (v101_r1.4) with ESMTP id MAILINID122-3eee4148e8ada0; Wed, 15 Sep 2004 21:13:18 -0400 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 15 Sep 2004 21:13:17 -0400 Subject: FTC Email Authentication Summit Nov 9,10 Washington DC From: Carl Hutzler To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-AOL-IP: 68.48.28.80 X-Mailer: Unknown (No Version) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8G1DYTR068899 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit FEDERAL TRADE COMMISSION Email Authentication Summit AGENCIES: The Federal Trade Commission (ŒŒFTC¹¹ or the ŒŒCommission¹¹) and the National Institute of Standards and Technology (ŒŒNIST¹¹), United States Department of Commerce. ACTION: Notice announcing email authentication summit, request for comments, and solicitation of requests to participate. DATES: The Email Authentication Summit will be held on November 9­10, 2004, from 8:30 a.m. to 5:30 p.m. at the Federal Trade Commission, Satellite Building, 601 New Jersey Ave., NW., Washington, DC 20001. The event is open to the public, and there is no fee for attendance. Pre-registration is not required. Details are below which are a lot easier to read in PDF document available on: http://cdhutzler.myphotos.cc/~hutz/FTCSenderAUTH.pdf Comments: Written comments should be submitted on or before September 30, 2004. For further information, please see the ŒŒRequest for Comments¹¹ section of this Notice. Participants: Written Requests to Participate in the Email Authentication Summit must be filed by September 30, 2004. For further information, please see the ŒŒRequests to Participate¹¹ section of this Notice. Parties submitting Requests to Participate will be notified by October 15, 2004, if they have been selected. ADDRESSES: Written comments should be identified as ŒŒEmail Authentication Summit-Comments,¹¹ and written requests to participate in the Email Authentication Summit should be identified as ŒŒEmail Authentication Summit-Request to Participate.¹¹ Written Comments and Requests to Participate should be submitted to: Secretary, Federal Trade Commission, Room 159­ H (Annex V), 600 Pennsylvania Ave., NW., Washington, DC 20580. If submitting in paper form, parties must submit an original and three copies of each document. The FTC requests that any comment filed in paper form be sent by courier or overnight service, since U.S. postal mail in the Washington area and at the Commission is subject to delay due to heightened security precautions. In the alternative, parties may email Comments and Requests to Participate to authenticationsummit@ftc.gov. To ensure that the Commission considers an electronic comment, you must file it with the FTC at this email address. For further requirements concerning the filing of Comments and Requests to Participate, please see the Request for Comments and Requests to Participate sections of this Notice. FORFURTHERINFORMATIONCONTACT: Sana D. Coleman, Attorney, (202) 326­ 2249. A detailed agenda and additional information on the Email Authentication Summit will be posted on the FTC¹s Website, http:// www.ftc.gov, by November 7, 2004. SUPPLEMENTARYINFORMATION: Section A. Introduction In the Commission¹s June 15, 2004 National Do Not Email Registry Report to Congress, the Commission explained that significant security, enforcement, practical, and technical challenges rendered a registry an ineffective solution to the spam problem.1The Report, however, identified domainlevel authentication as a promising technological development that would enable Internet Service Providers (ŒŒISPs¹¹) and other domain holders to better filter spam, and that would provide law enforcement with a potent tool for locating and identifying spammers. The Report concluded that the Commission could play an active role in spurring the market¹s development, testing, evaluation, and deployment of domain-level authentication systems. As a first step, the Report explained that the Commission, with other relevant government agencies, would host an Email Authentication Summit in the Fall of 2004. This Federal Register Notice explains that the Commission and the Department of Commerce¹s National Institute of Standards and Technology (ŒŒNIST¹¹) will be hosting the Summit on November 9­10, 2004, asks for comments on a number of issues concerning email authentication standards, and solicits requests to participate in the Summit. Section B. Background The Simple Mail Transfer Protocol (ŒŒSMTP¹¹), the Internet protocol for the email system, allows information to travel freely with relative anonymity and ease. SMTP facilitates the proliferation of spam by making it possible and cost-efficient for illegitimate marketers to send spam to billions of email accounts worldwide, while allowing them to hide their identities and the origins of their email messages. Spammers use many techniques to hide, including ŒŒspoofing,¹¹ open relays, open proxies, and ŒŒzombie drones,¹¹ including ŒŒzombie nets.¹¹ First, spammers use spoofing to falsify header information and hide their identities. This technique disguises an email to make it appear to come from an address other than the one from which it actually comes. A spammer can falsify portions of the header or the entire header. The SMTP system facilitates this practice because it does not require accurate routing information except for the intended recipient of the email. By failing to require accurate sender identification, SMTP allows spammers to send email without accountability, often disguised as personal email. A spammer can send out millions of spoofed messages, but any bounced messages‹messages returned as undeliverable‹or complaints stemming from the spoofed emails will only go to the person whose address was spoofed. The spammer never has to deal with them. As a result, an innocent email user¹s inbox may become flooded with undeliverable messages and angry, reactive email, and the innocent user¹s Internet service may be shut off due to the volume of complaints. Second, many spammers use open relays to disguise the origin of their email. A computer must be connected to a mail server to send or receive mail. When someone sends an email message using an email server that is ŒŒsecure,¹¹ the mail server¹s software checks to make sure that the sender¹s computer and email account are authorized to use that server. If this authorization is in order, then the server sends the email. If the computer and email account are not listed as authorized, the server refuses to accept and send the email message. On the other hand, if a mail server is not secure, i.e., some of its settings allow it to stay open, it will forward email even though the sender is not an authorized user of that server. An open server is called an open relay because it will accept and transfer email on behalf of any user anywhere. Spammers who use open relays effectively bypass the email servers to which their computers are connected. Once the spam passes through an open relay, a routing header from that server is added to the email. Thus, the email will appear as if it originated from the relay mail server. This allows spammers to obscure their tracks, making it difficult to trace the path their message takes from sender to recipient. Third, many spammers use ŒŒopen proxies.¹¹ They began doing this after ISPs and other mail server operators realized the negative impact of open relays and made efforts to identify and close them. Most organizations have multiple computers on their networks, but have a smaller number of proxy servers that are the only machines on the network that directly interact with the Internet. This system provides more efficient web browsing for the users within that organization and secures the organization¹s network against unauthorized Internet users from outside the organization. If the proxy is not configured properly, it is considered to be ŒŒopen,¹¹ and may allow an unauthorized Internet user to connect through it to other hosts (computers that control communications in a network or administer databases) on the Internet. Fourth, the most recent escalation in this cat-and-mouse game involves the exploitation of millions of home 2SMTP, its abuse by spammers, and the benefits of domain-level authentication are discussed in detail in the Commission¹s June 2004 National Do Not Email Registry Report to Congress, available at http://www.ftc.gov/reports/dneregistry/report.pdf. computers, using malicious viruses, worms, or ŒŒTrojans.¹¹ These infections, often sent via spam, turn any computer into an open or compromised proxy called ŒŒzombie drones.¹¹ When large collections of zombie drones are under centralized command, they are called ŒŒzombie nets.¹¹ Once a computer is infected with one of these programs, a spammer can remotely hijack and send spam from that computer. Spammers target home computers with high speed Internet connections, such as DSL or cable modem lines, that are poorly secured. Spam sent via zombie drones will appear to originate (and actually will originate) from these infected computers. This practice is all the more pernicious because users often do not know that their home computers are infected. The outgoing spam does not show up in their outbox. Once an ISP realizes spam is coming from one of its customer¹s machines, the ISP must shut off the customer¹s Internet service even though the customer had no knowledge that the spammer was using his or her machine. Obfuscatory techniques such as spoofing, open relays, open proxies, and zombie drones make it more difficult for ISPs to locate spammers. When ISPs and domain holders implement technologies designed to stop one exploitative technique, spammers quickly adapt, finding new methods to avoid detection. If the cloak of anonymity were removed, however, spammers could not operate with impunity. ISPs and domain holders could filter spam more effectively, and the government and ISPs could more effectively identify and prosecute spammers who violate the Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003 (the ŒŒCAN­SPAM Act¹¹), 15 U.S.C. 7708, or other statutes.2 To remove this cloak of anonymity, ISPs and others involved with the email system have proposed domain-level authentication systems‹systems that would enable a receiving mail server to verify that an email message actually came from the sender¹s purported domain. In other words, if a message claimed to be from abc@ftc.gov, the private market authentication proposals would authenticate that the message came from the domain ŒŒftc.gov,¹¹ but would not authenticate that the message came from the particular email address ŒŒabc¹¹ at this domain. There are two well-publicized private market authentication proposals, ŒŒSender ID¹¹ and ŒŒDomainKeys.¹¹ Sender ID, a combination of an earlier proposed authentication standard called SPF (ŒŒsender policy framework¹¹) and Microsoft¹s ŒŒCaller ID for Email,¹¹ would require senders of email to list the IP addresses from which they send email in the domain name system (the ŒŒDNS system¹¹). Receiving servers would compare the IP addresses listed in a message¹s header with those listed in the DNS system to determine if the message was coming from an authenticated IP address. DomainKeys uses public key/private key cryptography to authenticate email messages. A domain that sends email would create a public/private key pair and post the public key in the DNS system. For each message, the sending domain would generate a digital signature by applying the private key algorithm to the entire message. The sending domain would then add the digital signature in the message¹s header. The receiving mail server would then use the public key to verify that the digital signature was generated by the matching private key. While Sender ID and DomainKeys are the best known of the proposed authentication standards, other participants in the email system have proposed or intend to propose other domain-level authentication standards. For example, this Fall, the Internet Engineering Task Force, the Internet¹s standards setting body, is expected to forward an SPF-modeled authentication standard to one of its internal committees, the Internet Engineering Steering Group, which will decide whether to accept any such SPF-based model as a proposed or experimental standard or send it back for revision. To encourage the development, testing, evaluation and implementation of domain-level authentication systems, the Commission will conduct a two-day Email Authentication Summit. This Summit will be co-sponsored with NIST. The Summit will be held on November 9­10, 2004 in Washington, DC. The purpose of the Summit is to facilitate a discussion among technologists from ISPs, businesses and individuals who operate their own mail servers, computer scientists, and other interested parties regarding technological challenges of the various authentication proposals, the ability of small ISPs and domain holders to participate in the authentication systems, the costs associated with the various proposals, the international implications associated with the proposals, and other issues that impact the time frame for and viability and effectiveness of wide-scale adoption of domain-level authentication systems for email. Section C. Request for Comments Parties who wish to submit written comments addressing the Email Authentication Summit must do so by September 30, 2004. Written comments may be filed in either paper or electronic form. Written comments should refer to ŒŒEmail Authentication Summit‹Comments, (Matter Number P044411)¹¹ to facilitate the organization of comments. A comment filed in paper form should include this reference both in the text and on the envelope, and the original and three copies should be mailed or delivered to the following address: Federal Trade Commission/ Office of the Secretary, Room 159­H (Annex V), 600 Pennsylvania Avenue, NW., Washington, DC 20580. If the comment contains any material for which confidential treatment is requested, it must be filed in paper (rather than electronic) form, and the first page of the document must be clearly labeled ŒŒConfidential.¹¹ The FTC is requesting that any comment filed in paper form be sent by courier or overnight service, if possible, because U.S. postal mail in the Washington area and at the Commission is subject to delay due to heightened security precautions. Comments filed in electronic form (except comments containing any confidential material) should be sent to the following email box: authenticationsummit@ftc.gov. Written comments may address the issues identified below and any other issues in connection with the adoption and implementation of any of the proposed authentication standards. 1. Whether any of the proposed authentication standards (either alone or in conjunction with other existing technologies) would result in a significant decrease in the amount of spam received by consumers. 2. Whether any of the proposed authentication standards would require modification of the current Internet protocols and whether any such modification would be technologically and practically feasible. 3. Whether any of the proposed authentication standards would function with the software and hardware currently used by senders and recipients of email and operators of sending and receiving email servers. If not, what additional software or hardware would the sender and recipient need, how much it would cost, whether it would be required or optional, and where it would be obtained. 4. How operators of receiving email servers are likely to handle unauthenticated messages. 5. Whether any of the proposed authentication standards could result in email being incorrectly labeled as authenticated or unauthenticated (false negatives and false positives), and the steps that could be taken to limit such occurrences. 6. Whether the authentication standards are mutually exclusive or interoperable. Whether any of the proposed authentication standards would integrate with any other standards. For example, if Mail Server A is using standard X, will it accept email easily from Mail Server B that is using standard Y? 7. Whether any of the proposed authentication standards would have to be an open standard (i.e., a standard with specifications that are public). 8. Whether any of the proposed authentication standards are proprietary and/or patented. 9. Whether any of the proposed authentication standards would require the use of goods or services protected by intellectual property laws. 10. How any of the proposed authentication standards would treat email forwarding services. 11. Whether any of the proposed authentication standards would have any implications for mobile users (e.g., users who may be using a laptop computer, an email-enabled mobile phone, or other devices, and who legitimately send email from email addresses that are not administratively connected with their home domain). 12. Whether any of the proposed authentication standards would have any implications for roving users (i.e., users who are obliged to use a thirdparty submission service when unable to connect to their own submission service). 13. Whether any of the proposed authentication standards would affect the use of mailing lists. 14. Whether any of the proposed authentication standards would have any implications for outsourced email services. 15. Whether any of the proposed authentication standards would have an impact on multiple apparent responsible identities (e.g., in cases where users send email using their Internet Service Provider¹s SMTP network but have their primary email account elsewhere). 16. Whether any of the proposed authentication standards would have an impact on web-generated email. 17. Whether the proposed authentication standards are scalable. Whether the standards are computationally difficult such that scaling over a certain limit becomes technologically impractical. Whether the standards are monetarily expensive due to hardware and resource issues so that scaling over a certain limit becomes impractical. 18. Identify any costs that would arise as a result of implementing any of the proposed authentication standards, and identify who most likely would bear these costs (e.g., large ISPs, small ISPs, consumers, or email marketers). 19. Whether ISPs that do not participate in an authentication regime would face any challenges providing email services. If so, what types of challenges these ISPs would face and whether these challenges would in any way prevent them from continuing to be able to provide email services. 20. Whether an Internet-wide authentication system could be adopted within a reasonable amount of time. Description of industry and standardsetting efforts, whether there is an implementation schedule in place and, if so, the time frames of the implementation schedule. 21. Whether any of the authentication standards would delay current email transmission times, burden current computer mechanisms, or otherwise adversely affect the ease of email use by consumers. 22. Whether any of the proposed authentication standards would impact the ability of consumers to engage in anonymous political speech. 23. Whether any safeguards are necessary to ensure that the adoption of an industry-wide authentication standard does not run afoul of the antitrust laws. 24. Whether a spammer or hacker could compromise any of the proposed authentication standards by using, for example, zombie drones, spoofing of originating IP addresses, misuse of public/private key cryptography, or other means. 25. Whether any of the proposed authentication systems would prevent ŒŒphishing,¹¹ a form of online identity theft. 26. Whether the operators of small ISPs and business owners would have the technical capacity to use any of the proposed authentication standards. Whether any of the authentication standards could be reasonably implemented by smaller ISPs. 27. Whether any of the proposed authentication standards would have cross-border implications. 28. Whether any of the proposed authentication standards would require an international civil cryptographic standard or other internationally adopted standard and, if so, the implications of this requirement. 29. Description of how the Email Authentication Summit can support industry or standard-setting efforts. 30. Assuming a domain-level authentication system is established in the near term, future measures that the private market should develop and implement in order to combat spam. Section D. Requests To Participate Parties who wish to participate in the Email Authentication Summit must notify the FTC and NIST in writing of their interest by September 30, 2004 either by mail to the Secretary of the FTC or by email to authenticationsummit@ftc.gov. The Request to Participate must include a statement setting forth the requesting party¹s expertise in or knowledge of any or all of the issues identified in the Request for Comments section of this Notice and their contact information, including a telephone number, facsimile number, and email address (if available), to enable the FTC to notify them if they are selected. Requests to participate as a panelist should be captioned ŒŒEmail Authentication Summit‹Request to Participate, (Matter Number P044411), and should be filed in the same manner as prescribed for written comments in the ŒŒRequest for Comments¹¹ section. For requests filed in paper form, an original and three copies of each document should be provided. Panelists will be notified on or before October 15, 2004, whether they have been selected. Using the following criteria, the FTC and NIST staff will select a limited number of participants: 1. The party submitted a complete Request to Participate by September 30, 2004. 2. The party has expertise in or knowledge of some or all of the issues that are the focus of the Summit. 3. The party¹s participation would promote the representation of a balance of interests at the Summit. If it is necessary to limit the number of participants, parties who request to participate but are not selected may be afforded an opportunity, if at all possible, to present statements during a limited time period. The time allotted for these statements will be based on the amount of time necessary for discussion of the issues by the selected parties and on the number of persons wishing to make statements. Section E. Availability of Comments and Requests To Participate as Panelists The FTC Act and other laws the Commission administers permit the collection of public comments and requests to participate as panelists, to consider and use in this proceeding as appropriate. All timely and responsive public comments and requests to participate, whether filed in paper or electronic form, will be considered by the Commission, and will be available to the public on the FTC website, to the extent practicable, at http://www.ftc.gov. As a matter of discretion, the FTC makes every effort to remove home contact information for individuals from the public comments and requests to participate it receives before placing those comments on the FTC website. More information, including routine uses permitted by the Privacy Act, may be found in the FTC¹s privacy policy, at http://www.ftc.gov/ftc/privacy.htm. By direction of the Commission. Donald S. Clark, Secretary. [FR Doc. 04­20839 Filed 9­14­04; 8:45 am] BILLING CODE 6750­01­P provider payment rates or coverage policy. DATES: September 24, 2004, 8 a.m.­3 p.m. e.d.t. ADDRESSES: The meeting will be held at HHS headquarters at 200 Independence Ave., SW., 20201, Room 425A. Comments: The meeting will allocate time on the agenda to hear public comments. In lieu of oral comments, formal written comments may be submitted for the record to Andrew Cosgrove, OASPE, 200 Independence Ave., SW., 20201, Room 443F.8. Those submitting written comments should identify themselves and any relevant organizational affiliations. FORFURTHERINFORMATIONCONTACT: Andrew Cosgrove (202) 205­8681, andrew.cosgrove@hhs.gov. Note: Although the meeting is open to the public, procedures governing security procedures and the entrance to Federal buildings may change without notice. Those wishing to attend the meeting should call or e-mail Mr. Cosgrove by September 17, 2004, so that their name may be put on a list of expected attendees and forwarded to the security Dated: September 8, 2004. Michael J. O¹Grady, Assistant Secretary for Planning and Evaluation. [FR Doc. 04­20736 Filed 9­14­04; 8:45 am] BILLING CODE 4150­05­P -- Carl Hutzler Director, AntiSpam Operations America Online Mail Operations cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Wed Sep 15 22:53: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 WAA17891 for ; Wed, 15 Sep 2004 22:53:45 -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 i8G2JeOt077062; Wed, 15 Sep 2004 19:19:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G2JeLb077061; Wed, 15 Sep 2004 19:19:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G2Jd50077050 for ; Wed, 15 Sep 2004 19:19:39 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C7ls9-0001bc-00 for ; Thu, 16 Sep 2004 04:19:45 +0200 Received: from du-001-249.access.de.clara.net ([212.82.227.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2004 04:19:45 +0200 Received: from nobody by du-001-249.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2004 04:19:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 Date: Thu, 16 Sep 2004 04:14:38 +0200 Organization: Lines: 46 Message-ID: <4148F70E.2F28@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-249.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jim Lyon wrote: [2822 interpretation of Resent-*] > This sense of "forwarding" is normally activated by a user > pressing a "Forward" button in a UI (or similar action.) I > completely agree that "Resent-From" has no place in this > sense of forwarding. That covers MIME types like message/rfc822, multipart/digest, or maybe the proposed application/mbox, where original mails are "forwarded" as part of the body, as complete as possible. It's not exactly the sense of "forward" in Outlook, which is IMHO no "forward" at all. And that might be the explanation for the Resent-* headers: These headers already existed before MIME, in RfC 822. So my guess is that they were used in situations where today anybody (minus Outlook and pre-MIME MUAs) uses message/rfc822: [Std 11, 4.7] | Some systems permit mail recipients to forward a message, | retaining the original headers, by adding some new fields. | This standard supports such a service, through the "Resent-" | prefix to field names. | Whenever the string "Resent-" begins a field name, the field | has the same semantics as a field whose name does not have | the prefix. However, the message is assumed to have been | forwarded by an original recipient who attached the | "Resent-" field. This new field is treated as being more | recent than the equivalent, original field. For | example, the "Resent-From", indicates the person that | forwarded the message, whereas the "From" field indicates the | original author. > It would probably be a good idea for Pete Resnick (editor of > RFC 2822) to chime in on this interpretation. Maybe it's just a case of RfC 2822 trying to fix something in Std 11, and the result is not always clearer than the original text. We have the author of RfC 822 here, he won't let us stray too far away from the real meaning of Resent-* headers. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 01:28:11 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 BAA27057 for ; Thu, 16 Sep 2004 01: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 i8G4sXus087116; Wed, 15 Sep 2004 21:54:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G4sXnR087115; Wed, 15 Sep 2004 21:54:33 -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 i8G4sX16087109 for ; Wed, 15 Sep 2004 21:54:33 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8G4sehq013374 for ; Wed, 15 Sep 2004 21:54:40 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <84432E72-079C-11D9-B862-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: AOL on Sender I.D.. Date: Wed, 15 Sep 2004 21:54:39 -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 I gather this is a "no" vote?: "AOL Dumps Sender ID" http://www.internetnews.com/xSP/article.php/3408601 " AOL (Quote, Chart) has withdrawn its support for Microsoft's controversial Sender ID technology and is falling back on Sender Policy Framework (SPF), internetnews.com has learned. "Given recent concerns expressed by the Internet Engineering Task Force (IETF), coupled with the tepid support for Sender ID in the open source community, AOL has decided to move forward with SPF," Nicholas Graham, AOL spokesperson, told internetnews.com via e-mail. Microsoft was not available for comment at press time. Despite the bombshell decision, the world's top ISP isn't completely severing its ties to Sender ID: The company still will publish Sender ID files so its users' e-mails are compliant with Sender ID-enabled servers and applications. But it's enough of a vote of no confidence in Microsoft's e-mail authentication strategy to warrant concern for Sender ID proponents." Full story at link above. Anne From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 03:47: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 DAA19762 for ; Thu, 16 Sep 2004 03:47:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G7BQEZ041259; Thu, 16 Sep 2004 00:11:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G7BQUL041257; Thu, 16 Sep 2004 00:11:26 -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 i8G7BQCK041251 for ; Thu, 16 Sep 2004 00:11:26 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8G7BPDb005433 for ; Thu, 16 Sep 2004 00:11:26 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <2D7C289F-071B-11D9-8E48-000A95BC6A7E@margaretolson.com> References: <20040914220354.GA12575@slot.hollandcasino.net> <4B2FA436-06B5-11D9-8E48-000A95BC6A7E@margaretolson.com> <20040915121927.GA14802@slot.hollandcasino.net> <2D7C289F-071B-11D9-8E48-000A95BC6A7E@margaretolson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9EC17CFE-07AF-11D9-B862-000A95AC5778@isipp.com> Content-Transfer-Encoding: 7bit From: "Anne P. Mitchell, Esq." Subject: Re: SPF abused by spammers Date: Thu, 16 Sep 2004 00:11:24 -0700 To: IETF MARID WG 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 >>> Very small senders won't have the volume to create a statistically >>> significant reputation. But if they are accredited ("this is a shoe >>> shop, established in 1985, uses good practices") and the reputation >>> data is essentially empty, then you know something. >> >> Basically what you're saying is that accreditation is a form of >> using someone else's reputation? >> > Yes. > That is certainly one aspect of accreditation, and an important one. For example, small publishers of newsletters often have problems in this regard because they simply are below the radar, which isn't always a good thing in this context. Cf. Lockergnome and This Is True as examples of newsletter publishers who are listed in IADB, but simply aren't big enough to have created a widespread reputation on their own - or to afford to play with the big boy in being listed in Habeas or Bonded Sender. But that isn't even the primary benefit of a system like IADB. Relying solely on reputation doesn't really get a lot of receivers where they want to be, although it certainly does get some where they want to be. For one thing, if someone isn't listed in Habeas or Bonded Sender, and isn't listed in a blocklist - or you don't use an external blocklist (as many ISPs now don't) then you know _nothing_ about the sender. Even if they are listed with Habeas or Bonded Sender, you still don't know anything about them other than that either they signed a contract saying they wouldn't send non-compliant email through the listed IPs (Habeas), or they met Bonded Sender's requirements and were willing to put up $ against any spam complaint. In short, what you know about the sender is once-removed - you only know what their relationship with the reputation agency is, not anything in particular about the sender. With an accreditation database, you have the ability to learn factual information *about the sender*. Is their mailing list email from this IP address all confirmed opt-in? Opt-out? Do they publish SPF records? Are they listed with Bonded Sender or Habeas (in IADB that becomes another datapoint - but not a "vouch" for them - i.e. it is additional information which, coupled with all the other information available, helps you to have a better picture of the sender). And then IADB2 takes all this information and rolls it into one aggregate score, so if you prefer a weighted single score to individual bits of data, you can have that too. It's kind of like having DNS access to the Consumer Reports of email senders. Again, if you haven't, before you judge based on preconceived notions, please read http://www.isipp.com/iadb.php http://www.isipp.com/codes.php and http://www.isipp.com/codelist.php Anne From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 04: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 EAA22028 for ; Thu, 16 Sep 2004 04:28:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G7fseZ051687; Thu, 16 Sep 2004 00:41:54 -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 i8G7fsGo051686; Thu, 16 Sep 2004 00:41:54 -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 i8G7fswD051646 for ; Thu, 16 Sep 2004 00:41:54 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 3C6B140D8 for ; Thu, 16 Sep 2004 00:41: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: IETF MARID WG From: Mark Lentczner Subject: New drafts Date: Thu, 16 Sep 2004 00:41:46 -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 - I've submitted two drafts: draft-ietf-marid-protocol-03 Major Changes * scopes added (replacing ver-ext) * RR Type logic reversed to -00 rules: - compliant publish can publish either or both - if both are published must be identical - compliant receivers can query for either - if both are returned, then SPF must be used * Fixed RFC 2119 language and usage * RR name changed from SPF2 to SPF * DNS query results are now referenced by RCODE (From RFC 1045) Descriptive Changes * New title: "The SPF Record Format and Sender-ID Protocol" - yes, now it really DOES describe a protocol! * New abstract * New introduction that sets out the SenderID framework Minor Changes * Removed 'p' from deprecated list of macros, 'cause it's not * CIDR length defaulting text clarified (section 4.6) * Clarifications in the text about DNS lookups for PTR and MX mechanisms * Minor changes to the ABNF (no changes to legal parses) * Various grammar and spelling fixes draft-ietf-marid-mailfrom-00 This describes using the Sender-ID protocol with a 2821 Mail From scope. From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 08:21:41 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 IAA06924 for ; Thu, 16 Sep 2004 08:21:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GACL3h005213; Thu, 16 Sep 2004 03:12:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GACLZV005211; Thu, 16 Sep 2004 03:12:21 -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 i8GACIGN005177 for ; Thu, 16 Sep 2004 03:12:20 -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 i8GAOG0a031931; Thu, 16 Sep 2004 03:24:16 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8GAOGvn031926; Thu, 16 Sep 2004 03:24:16 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 16 Sep 2004 03:24:15 -0700 (PDT) From: "william(at)elan.net" To: Frank Ellermann cc: ietf-mxcomp@imc.org, Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 In-Reply-To: <4148F70E.2F28@xyzzy.claranet.de> 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, 16 Sep 2004, Frank Ellermann wrote: > That covers MIME types like message/rfc822, multipart/digest, > or maybe the proposed application/mbox, where original mails > are "forwarded" as part of the body, as complete as possible. > > It's not exactly the sense of "forward" in Outlook, which is > IMHO no "forward" at all. And that might be the explanation > for the Resent-* headers: > > These headers already existed before MIME, in RfC 822. So my > guess is that they were used in situations where today anybody > (minus Outlook and pre-MIME MUAs) uses message/rfc822: Are you saying use of these headers is supposed to have been depreciated by now and that they carry mostly historic meaning? > Maybe it's just a case of RfC 2822 trying to fix something in > Std 11, and the result is not always clearer than the original > text. We have the author of RfC 822 here, he won't let us > stray too far away from the real meaning of Resent-* headers. Ok. Can we then have author of RFC822 comment if use of Resent-From header is appropriate per STD11 for cases of Mail List and different types of forwarders as is being recomendated in marid-core? And then comment if RFC2822 was supposed to change original STD11 in case of the Resent-??? headers or not. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 09:56: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 JAA12178 for ; Thu, 16 Sep 2004 09:56:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GDE5su035242; Thu, 16 Sep 2004 06:14: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 i8GDE5iw035241; Thu, 16 Sep 2004 06:14:05 -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 i8GDDqJU035173 for ; Thu, 16 Sep 2004 06:14:05 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 4D3DE26C091; Thu, 16 Sep 2004 15:13:41 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 1837E26C076; Thu, 16 Sep 2004 15:13:40 +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 i8GDDd8q843265; Thu, 16 Sep 2004 15:13:40 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id C529CFB6E; Thu, 16 Sep 2004 15:13:39 +0200 (CEST) Date: Thu, 16 Sep 2004 15:13:39 +0200 From: Stephane Bortzmeyer To: Mark Lentczner Cc: IETF MARID WG Subject: Re: New drafts Message-ID: <20040916131339.GA22545@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 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 Thu, Sep 16, 2004 at 12:41:46AM -0700, Mark Lentczner wrote a message of 36 lines which said: > I've submitted two drafts: They do not appear on http://www.ietf.org/internet-drafts/ (yet?). Any alternative source in the mean time? From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 12:57: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 MAA26844 for ; Thu, 16 Sep 2004 12:57: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 i8GG8bRS048840; Thu, 16 Sep 2004 09:08:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GG8b5b048839; Thu, 16 Sep 2004 09:08:37 -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 i8GG8bNY048833 for ; Thu, 16 Sep 2004 09:08: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 i8GGKfCo006492; Thu, 16 Sep 2004 09:20:41 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8GGKfGm006489; Thu, 16 Sep 2004 09:20:41 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 16 Sep 2004 09:20:41 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID List cc: spf-discuss@v2.listbox.com Subject: Re: FW: Microsoft's Updated Statement about IPR Claimed in and in Combination 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 Tue, 14 Sep 2004, Harry Katz wrote: > > Today Microsoft filed the following disclosure statement with the IETF > Secretariat regarding IPR claimed in relation to Sender ID. This > statement does not mean that patents have been granted in any of the > jurisdictions mentioned below, only that the patent applications > themselves are due to be published shortly. ... > US - Title: "Reducing Unwanted And Unsolicited Electronic Messages By > Preventing Connection Hijacking And Domain Spoofing", Serial no. 10/684020 This patent got published today, to see it try using this url: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=684020.APN.&OS=APN/684020&RS=APN/684020 If does not work go to http://appft1.uspto.gov/netahtml/PTO/search-bool.html and type 684020 for Application Serial Number in field1. It contains a lot lot more then just things related to MARID and understanding everything is difficult because of this "patent language", but from what I see of the MARID specific parts, the patent does cover RFC2821 Mail-From (which Microsoft calls "Reverse-Path" in their patent application) as well as RFC2822 headers and it many times mentions RMX records as well. I'm also concerned that they way patent is written (as well as together with another patent I found) it maybe designed to cover comprehensive checks on multiple identities (eg universal spf or alike), but that maybe an exaduration on my part. Please see below for more information on the MARID specific text: ---------------------------------------------------------------------------- [0067] A purported sending domain can be identified from parameter values contained in an electronic message. For example, messaging server 317 can identify domain 305 from parameter values contained in electronic message 371 (e.g., from spoofed domain name 372). The purported sending domain can be identified from the domain portion (e.g., characters after the "@" character) of the purported sending entity. Other parameter values in an electronic message can include the actual sending network address. For example, an actual sending network address can be included in a Reverse-Path of an electronic message (which may be referred to as the envelope From address). A Reverse-Path can be included in an electronic message as a result of a sending computer system issuing an SMTP "MAIL FROM" command. Thus, messaging server 371 can examine this parameter values for electronic message 371 to attempt to identify an actual sending network address (e.g., the actual IP address of the messaging server 316). [0068] However, it may also be that an actual sending network address is included in a first Resent-Sender header of an electronic message, in a first mailbox in the Resent-From header of an electronic message, in a Sender header of an electronic message, or in a first mailbox of the From header of an electronic message. Accordingly, messaging server 371 can also examine each of these parameters values (either separately or in combination with examining a Reverse-Path parameter value) for electronic message 371 to attempt to identify an actual sending network address (e.g., the actual IP address of the messaging server 316). Since a number of different portions of an electronic message are examined, there is increased likelihood that the actual sending network address of the electronic message can be identified. Some electronic mail implementations require that electronic mail messages be sent with an empty Reverse-Path. Embodiments of the present invention can be advantageous for identifying an actual sending address when an electronic message does not include a Reverse-Path parameter value. [0069] Based on spoofed domain name 372, messaging server 317 may identify domain 305 as the purported sending domain for electronic message 371. Electronic messages that do not contain a Reverse-Path or at least one of the listed headers may be considered unwanted and/or unsolicited. Considering such electronic messages as unwanted and/or unsolicited reduces the likelihood of an entity intentionally omitting a Reverse-Path and all of the headers to defeat a message classification module. [0070] The method 400 includes an act of examining a plurality of parameters values of the electronic message to attempt to identify an actual sending side network address corresponding to the sending computer system (act 402). Act 402 can include a receiving side computer system identifying an actual sending side network address corresponding to the sending computer system. The receiving side computer system can identify an actual sending side network address, for example, from one or more of a Reverse-Path, a first Resent-Sender header, a first mailbox in the Resent-From header, a Sender header of an electronic message, or a first mailbox of the From header, of electronic message 371. Messaging server 317 can identify that an actual sending side IP address corresponds to messaging server 316. Method 200 can be utilized to decrease the likelihood of an IP address being spoofed. [0071] The method 400 includes an act of querying a name server for a list of network addresses authorized to send electronic messages for the sending side domain (act 403). Act 403 can include the receiving computer system querying a name server for a list of network addresses authorized to send electronic messages for the sending side domain. For example, messaging server 317 can cause domain 307 to issue name service message 375, which includes authorized servers query 379, to name server 308. Name service message 375 can include an identifier that identifies domain 305. [0072] Name server 308 can receive name service message 375 and process authorized servers query 379 accordingly. At name server 308, entry 376 may be a DNS entry that corresponds to domain 305. Entry 376 can contain one or more records (e.g., RMX and/or TXT records) for domain 305, including authorized servers record 336. Received TXT records can include XML instructions. Authorized servers record 336 can contain network addresses (e.g., IP addresses) corresponding to messaging servers that are authorized to send electronic messages for domain 105. From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 13:07:57 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 NAA27540 for ; Thu, 16 Sep 2004 13:07: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 i8GGMxfo050027; Thu, 16 Sep 2004 09:22: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 i8GGMx9D050026; Thu, 16 Sep 2004 09:22:59 -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 i8GGMxou050017 for ; Thu, 16 Sep 2004 09:22:59 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 16 Sep 2004 12:23:00 -0400 id 002135BA.4149BDE4.000072B4 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <84432E72-079C-11D9-B862-000A95AC5778@isipp.com> References: <84432E72-079C-11D9-B862-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: AOL on Sender I.D.. Date: Thu, 16 Sep 2004 12:22:57 -0400 To: IETF-MXCOMP WG 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 Before discussion goes much further on this topic, we ask the working group not to give press releases and news articles much elaboration. This is not because their content is unimportant, but because this is a discussion list and it is hard to conduct a discussion with a press release. We do welcome any statements directly from AOL or any network operations group regarding their plans for Sender ID or CSV. However, we ask that they respect the fact that this is a discussion list and be prepared to answer any technical questions that may arise from their statements. -andy, MARID co-chair From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 14:37:36 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 OAA02843 for ; Thu, 16 Sep 2004 14:37: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 i8GHuDjM059549; Thu, 16 Sep 2004 10:56:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GHuDXI059548; Thu, 16 Sep 2004 10:56:13 -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 i8GHuDWW059538 for ; Thu, 16 Sep 2004 10:56:13 -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 i8GI8Jka019482; Thu, 16 Sep 2004 11:08:19 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8GI8J6E019479; Thu, 16 Sep 2004 11:08:19 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 16 Sep 2004 11:08:19 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: spf-discuss@v2.listbox.com, IETF MARID List Subject: Re: Microsoft's Updated Statement about IPR Claimed in and in Combination 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 Thu, 16 Sep 2004, Andrew Newton wrote: > On Sep 16, 2004, at 12:20 PM, william(at)elan.net wrote: > > > It contains a lot lot more then just things related to MARID and > > understanding > > everything is difficult because of this "patent language", but from > > what > > I see of the MARID specific parts, the patent does cover RFC2821 > > Mail-From > > (which Microsoft calls "Reverse-Path" in their patent application) as > > well as RFC2822 headers and it many times mentions RMX records as well. > > IANAL, but my limited understanding of these thing is that you must > look at the claims. Somebody correct me if I'm off-base, which is > quite possible considering IANAL. That is certainly true and because IANAL the language in claims is difficult to make out. I'm posting here the claims that I believe relate to the MARID portion of that patent application, perhaps you'll understand it better. P.S. For the authors of this patent reading the list, I'll note that I found it funny that patent mentions taking first address of the From header. The RFC2822 is very clear that if From header is group of addresses, then Sender header MUST be present and that is where info is to be looked at (if its not, one can probably discard the message as not RFC compliant). I simply did not expect such a stupid mistake as far as email standars are concerned to be part of the patent text. Claims -------------------------------------------------------------------------------- What is claimed and desired secured by United States Letters Patent is ... 22. In a receiving domain that is network connectable to one or more sending domains, the receiving domain including one or more receiving messaging servers configured to receive electronic messages from sending domains, a method for determining if a sending messaging server is authorized to send electronic messages for a sending domain, the method comprising: an act of receiving an electronic message purportedly sent from the sending domain; an act of examining a plurality of parameter values of the electronic message to attempt to identify an actual sending side network address corresponding to a sending computer system; an act of querying a name server for a list of network addresses authorized to send electronic messages for the sending domain; an act of determining if the actual sending side network address is authorized to send electronic messages for the sending domain; and an act of providing results of the determination to an message classification module such that the message classification module can make a more reliable decision as to classifying the received electronic message. 23. The method as recited in claim 22, wherein the act of receiving an electronic message purportedly sent from the sending side domain comprises an act of receiving an electronic mail message. 24. The method as recited in claim 22, wherein an act of receiving an electronic message purportedly sent from the sending domain comprises an act of receiving an electronic message that does not include a Reverse-Path parameter value. 25. The method as recited in claim 22, wherein an act of examining a plurality of parameter values of the electronic message to attempt to identify an actual sending side network address comprises an act of identifying an Internet Protocol address corresponding to the sending computer system. 26. The method as recited in claim 22, wherein an act of examining a plurality of parameter values of the electronic message to attempt to identify an actual sending side network address comprises an act of examining a plurality of parameter values wherein at least one of the plurality of parameter values is selected from among a first Resent-Sender header value, a first mailbox value in the Resent-From header, a Sender header value, or a first mailbox value in the From header. 27. The method as recited in claim 22, wherein the act of querying a name server for a list of network addresses authorized to send electronic messages for the sending domain comprises an act of querying a Domain Name Services server for a list of network addresses authorized to send electronic messages for the sending domain 28. The method as recited in claim 27, wherein the act of querying a Domain Name Services server for a list of network addresses authorized to send electronic messages for the sending domain comprises the act of querying a Domain Name Services for a list of Internet Protocol addresses authorized to send electronic mail message for the sending domain. 29. The method as recited in claim 22, further comprising: an act of receiving a list of network addresses that are authorized to send electronic messages for the sending domain. 30. The method as recited in claim 29, wherein an act of receiving a list of network addresses that are authorized to send electronic messages comprises an act of receiving one or more DNS TXT records. 31. The method as recited in claim 30, wherein an act of receiving a list of network addresses that are authorized to send electronic messages comprises an act of receiving one or more DNS TXT records that encode the list of network addresses in XML instructions. 32. The method as recited in claim 31, wherein an act of receiving one or more DNS TXT records that encode the list of network addresses in XML instructions comprises an act of receiving electronic messaging configuration information that spans across a plurality DNS TXT records such that the electronic message configuration information can be concatenated into an XML instance. 33. The method as recited in claim 32, wherein the act of receiving electronic messaging configuration information that spans across a plurality DNS TXT records such that the electronic message configuration information can be concatenated into an XML instance comprises an act of receiving a plurality of DNS TXT records that include ordering data indicating how the XML instructions contained in the DNS TXT records are to be ordered. 34. The method as recited in claim 33, further comprising: an act of concatenating the XML instructions according to the ordering data to generate an XML instance. 35. The method as recited in claim 22, wherein the act of determining if the actual sending side network address is authorized to send electronic messages for the sending domain comprises an act of determining that the actual sending side network address is contained in a received list of authorized network addresses. 36. The method as recited in claim 22, wherein the act of determining if the actual sending side network address is authorized to send electronic messages for the sending domain comprises an act of determining that the actual sending side network address is not contained in a received list of authorized network addresses. 37. The method as recited in claim 22, wherein the act of an act of providing results of the determination to an message classification module comprises an act of indicating to the message classification module that the actual sending side network address is authorized to send electronic messages for the sending domain. 38. The method as recited in claim 22, wherein the act of an act of providing results of the determination to an message classification module comprises an act of indicating to the message classification module that the actual sending side network address is not authorized to send electronic messages for the sending domain. From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 14:49: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 OAA04303 for ; Thu, 16 Sep 2004 14:49: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 i8GHanP3057149; Thu, 16 Sep 2004 10:36: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 i8GHanPq057148; Thu, 16 Sep 2004 10:36:49 -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 i8GHanTQ057132 for ; Thu, 16 Sep 2004 10:36:49 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 16 Sep 2004 13:36:50 -0400 id 002135A9.4149CF32.00007944 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: spf-discuss@v2.listbox.com, IETF MARID List From: Andrew Newton Subject: Re: Microsoft's Updated Statement about IPR Claimed in and in Combination Date: Thu, 16 Sep 2004 13:36:48 -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: Content-Transfer-Encoding: 7bit On Sep 16, 2004, at 12:20 PM, william(at)elan.net wrote: > It contains a lot lot more then just things related to MARID and > understanding > everything is difficult because of this "patent language", but from > what > I see of the MARID specific parts, the patent does cover RFC2821 > Mail-From > (which Microsoft calls "Reverse-Path" in their patent application) as > well as RFC2822 headers and it many times mentions RMX records as well. IANAL, but my limited understanding of these thing is that you must look at the claims. Somebody correct me if I'm off-base, which is quite possible considering IANAL. -andy From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 15:47: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 PAA09995 for ; Thu, 16 Sep 2004 15:47: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 i8GJ2ifq065490; Thu, 16 Sep 2004 12:02: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 i8GJ2isM065489; Thu, 16 Sep 2004 12:02:44 -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 i8GJ2iU7065483 for ; Thu, 16 Sep 2004 12:02: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 85CAA414C4; Thu, 16 Sep 2004 12:02:43 -0700 (PDT) Subject: Re: SPF abused by spammers From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040915223744.6B8F516CD2@mail.nitros9.org> References: <20040915223744.6B8F516CD2@mail.nitros9.org> Content-Type: text/plain Message-Id: <1095361363.30902.140.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Sep 2004 12:02:43 -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 Wed, 2004-09-15 at 15:37, Alan DeKok wrote: > Douglas Otis wrote: > > > I thought we were discussing security terms, not Latin. > > > > We are discussing the difference between send control lists and > > authentication. > > Side-lines into Latin, and what words meant 2000 years ago aren't > helpful. If they were, we wouldn't be using the letter "j", and we > would be pronouncing "v" as "w". But through this period, the word has not changed meaning. > > To refresh this point: > > http://www.imc.org/ietf-mxcomp/mail-archive/msg04648.html > > My point then, as now is: > > - Entities who have information should use it to make decisions. The goal of this effort should also include providing essential information to enable locating and correcting problems. This would be together with the other goal of detecting spoofed addresses. > - Entities who do not have information cannot use it to make decisions. Ignorance is bliss? : ) > > You are advocating Sender-ID or SPF identities are authenticated. I > > still claim this is a misuse of the term authenticate as this presumes > > the integrity of the mail channel and the nature of the list. > > It presumes that the entities publishing those records have read the > specification of the protocol they're implementing, and understand > it's costs and benefits. The meaning of those records is as defined > in the specifications, nothing more, or less. I see a conflict even within the specification. Jim Lyon has already indicated any domain publishing an "open" record, requesting forwarded mail receive a "Pass" assessment, will receive the bad reputation they deserve. The specification does not warn of this problem. There is another problem with any "open" record, even those that only request a "Neutral" assessment. SPF and Sender-ID use DNS records for the double purpose of "authenticating" the MTA in conjunction with listing MTAs authorized to send messages for a specific mailbox domain. This provides the MTA with the extremely weak identity of the mailbox domain. When the record is "open" for SPF or Sender-ID, this invites spoofing of the mailbox domain to obtain "authentication." This invited spoofing is very much counter to the goal of stopping the spoofing! By first performing CSV to authenticate and authorize the MTA, and then obtaining an authorization list of names referenced by the mailbox domain, this will specifically prevent spoofing. This two step approach can not be exploited for the purpose of "authentication" to usurp the reputation of the domain. The weak "authentication" of Sender-ID or SPF may be accomplished by simply asserting the mailbox domain in some cases. marid-mpr was to illustrate solutions for those interested in: a) Stopping spoofing b) Not breaking mail c) Providing fairly applied reputations d) Locating abusive MTAs e) Using lightweight and deterministic overhead f) Retaining network integrity g) Retaining DNS integrity h) Optional assertions on RFC2822 From that are not superseded > > I noted the hazard making this assumption would cause with respect > > to harming reputations of those that, through no action on their > > part, receive negative assertions. > > Again, your focus is on reputations and negative assertions. Mine > is not. My focus encompasses your concerns. If you review the marid-mpr draft and consider how it can work, you will find it actually provides better protections than SPF or Sender-ID, but without the overhead and the IPR problems. > http://www.imc.org/ietf-mxcomp/mail-archive/msg04818.html > > Your response to that message didn't acknowledge that my goals are > different from yours. While I understand very well your concerns > about negative reputations, I do not see reputations as the primary > goal of SPF, Sender-ID, or the MARID WG. Instead, what's important is > the ability of a domain to publish a list of authentic outgoing MTA's. The goal of authorizing the MTA is defined in the charter and made somewhat explicit in the WG acronym. By first identifying the MTA, independent of any authorization, offers a few important benefits- a) Stronger identity for asserting reputations b) Deterministic structure based upon names for authorization c) Location of a problematic MTA d) Prevention of record exploit and improved spoof prevention e) Thwarting phishing when making the validated MTA identity visible f) Retained mail functionality with safe "open" lists g) A phase-in with open lists only "coloring" mail, not rejecting it > Reputation systems are secondary to the primary goal, and are > piggy-backed on top of it. I don't see a need to discuss MARID-based > reputation systems until such time as we have a clear specification of > not only an MTA authentication system using DNS, but also the costs > and benefits of using such a system. There should be some consideration given this, as you have indicated your own expectation the results of this scheme will be used for establishing reputations. As Sender-ID and SPF provide such incredibly weak identities, these identities will actually become more vulnerable to harm caused by spoofing, but now from reputation services. This will happen due to an understanding SPF or Sender-ID strengthened these identities. As this is going from zero strength, the slight increase and the surrounding hype make inappropriate reliance on these identities far more likely. > If that MTA authentication system is correct and useful, then > reputation systems can be built on top of it. If the MTA > authentication system is not correct or useful, then any reputation > systems which depend on it will be likewise useless. There are fundamental flaws with the SPF or Sender-ID scheme. A list may be "open" but such an open list is not made apparent to the receiving MTA in all cases. A sending MTA may be shared, but such sharing is not apparent to the receiving MTA. The Sending MTA may not have made SPF or Sender-ID record checks upon receipt of the message being sent, but this also is not apparent to the receiving MTA. As a result, there is validation promotion moving through these shared MTA clients. Essentially any domain accepted by the client MTA, may spoof any other domain that also shares the client MTA and is using an "open" list or where the sending MTA did not make the needed checks. Even with full compliance to the specification, spoofing remains possible. This is creating a new danger where, had it been understood not to trust the mailbox domain identity, there would be less risk. The hype used to promote these schemes suggests such identities can be trusted. Of course there are many ways to inject mail into the mail channel that may bypass the needed checks, but where such an event can not be detected using SPF or Sender-ID. Both Sender-ID and SPF are trusting the integrity of both the sending and receiving administrative realms, but where there is no means to verify such assumption. Sender-ID and SPF are ideal mechanisms for the confidence artist. There have been some that suggest any shared MTA should become a thing of the past as a result of these flaws of Sender-ID or SPF. These shared MTA strategies, sometimes forced by blocking ports or by way of transparent interception, are effective at curtailing abuse originating within a providers networks and allows the provider to protect the use of their IP address space. This largely requires the examination of the SMTP logs and finding too many nonexistent recipient errors. This shared MTA can also direct abuse@ messages to assist in the effort to curtail abuse as well. I am not suggesting curtailing spoofing not be done. I am simply advocating a better, safer, cleaner approach. And yes, it also makes reputations safer as well. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 16:04:23 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 QAA12918 for ; Thu, 16 Sep 2004 16:04:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GJYTiY067844; Thu, 16 Sep 2004 12:34:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GJYTCY067843; Thu, 16 Sep 2004 12:34:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-d22.mx.aol.com (imo-d22.mx.aol.com [205.188.144.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GJYSjL067833 for ; Thu, 16 Sep 2004 12:34:29 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-d22.mx.aol.com (mail_out_v37_r3.7.) id s.1ce.2b61bdfc (15888); Thu, 16 Sep 2004 15:34:22 -0400 (EDT) Received: from [192.168.1.101] (dhcp180-190-228.office.aol.com [10.180.190.228]) by air-id08.mx.aol.com (v101_r1.4) with ESMTP id MAILINID83-3e104149eabe203; Thu, 16 Sep 2004 15:34:22 -0400 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 16 Sep 2004 15:34:20 -0400 Subject: Re: AOL on Sender I.D.. From: Carl Hutzler To: Andrew Newton , IETF-MXCOMP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AOL-IP: 10.180.190.228 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > We do welcome any statements directly from AOL or any network > operations group regarding their plans for Sender ID or CSV. However, > we ask that they respect the fact that this is a discussion list and be > prepared to answer any technical questions that may arise from their > statements. > > -andy, MARID co-chair We remain committed to sender identity technologies. We intend to begin beta testing SPF on our inbound systems very soon (weeks from now). SPF is low hanging fruit that will benefit AOL and many other domains although it will not work for 100% of the mail we receive. But it will work for >80% of the mail we receive and that is good enough for a first strike. We also believe that the best way to secure the 822 FROM address is a content signing approach which is out of the scope of this working group. We hope to see a new group formed to tackle the issues in this arena. DomainKeys, IIM and TEOS are all reasonable technologies in this arena. We are sure their will be more which is a good thing for a working group :-) We remain committed to other IP based approaches and see a lot of benefit to the "newer" CSV idea. AOL already gets >85% of our spam from other ISPs main outbound MTAs. SPF, SenderID, and Domainkeys will not change that as this mail also uses the legit domain of that local ISP in the 821/822 headers. CSV and certain best practice documents (BCPs) shift the responsibility to the sending organization for the mess they create through their insecure networks and insecure practices (like lack of SMTP AUTH of any form, lack of any outbound controls, inability to suspend accounts, insecure web servers, etc). -Carl -- Carl Hutzler Director, AntiSpam Operations America Online Mail Operations cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 16:11:57 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 QAA14166 for ; Thu, 16 Sep 2004 16:11: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 i8GJdqxj068380; Thu, 16 Sep 2004 12:39: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 i8GJdqos068379; Thu, 16 Sep 2004 12:39:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GJdpCs068373 for ; Thu, 16 Sep 2004 12:39:51 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09325; Thu, 16 Sep 2004 15:39:53 -0400 (EDT) Message-Id: <200409161939.PAA09325@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-protocol-03.txt Date: Thu, 16 Sep 2004 15:39:53 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : The SPF Record Format and Sender-ID Protocol Author(s) : M. Wong, M. Lentczner Filename : draft-ietf-marid-protocol-03.txt Pages : 42 Date : 2004-9-16 This document defines a protocol for the authorization of Internet hosts to use domain names in the sender mailbox of mail that those hosts send. Authorization records are published in DNS for domain names that may be used as part of sender mailboxes. Mail receivers then perform a check against those records to see if a client host submitting a piece of mail is actually authorized. Since there are several different concepts of sender mailbox, this protocol is generic and can be applied to one or more of such "scopes". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-03.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-ietf-marid-protocol-03.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-ietf-marid-protocol-03.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" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-16155129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-16155129.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 16: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 QAA16517 for ; Thu, 16 Sep 2004 16: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 i8GJvB3t070153; Thu, 16 Sep 2004 12:57: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 i8GJvBXJ070152; Thu, 16 Sep 2004 12:57: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 i8GJvBns070142 for ; Thu, 16 Sep 2004 12:57:11 -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 i8GK9HXm024823; Thu, 16 Sep 2004 13:09:17 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8GK9HCV024820; Thu, 16 Sep 2004 13:09:17 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 16 Sep 2004 13:09:17 -0700 (PDT) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: ietf-mxcomp@imc.org Subject: RE: [spf-discuss] Re: Microsoft's Updated Statement about IPR Claimed in and in Combination 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 Thu, 16 Sep 2004, Seth Goodman wrote: > IANAL either, but I do have my name on a number of patents. From what I see > of the claims you posted, independent claim 22 plus dependent claims 27, 28, > 29, 30, 35, 36 37 and 38 describe SPF classic. That was my reading as well. And I then looked at description to see if they specifically mentioned envelope Mail From and indeed they did! This is the kind if indication that shows the intent. > If those claims are allowed, we may need a license to use SPF, which MS > is not even compelled to offer and can set any terms they wish, i.e. > implementing PRA and/or using XML. Lets remember that we do have an option of disregarding their patent. They thereafter have to bring claim of patent infringement and the defence of prior art is a valid one. If court grants the defense it means invalidation of the patent. But it is costly to fight things like this in court no matter who brings the motion forward. Another this is that, as has been mentioned, intentional filing of patent claims that author knows is covered by prior art maybe considered a fraud (IANAL, so correct me if that is not right). This is something for authorities to deal with once brought to their attention. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 16:33: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 QAA18689 for ; Thu, 16 Sep 2004 16:33: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 i8GJdkDO068363; Thu, 16 Sep 2004 12:39: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 i8GJdkBe068362; Thu, 16 Sep 2004 12:39:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GJdj9R068355 for ; Thu, 16 Sep 2004 12:39:46 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09298; Thu, 16 Sep 2004 15:39:47 -0400 (EDT) Message-Id: <200409161939.PAA09298@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-mailfrom-00.txt Date: Thu, 16 Sep 2004 15:39:47 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Authorizing Use of Domains in MAIL FROM Author(s) : M. Lentczner, M. Wong Filename : draft-ietf-marid-mailfrom-00.txt Pages : 11 Date : 2004-9-16 Mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction in what a sending host can use as the reverse-path of a message. This document describes a protocol whereby a domain can explicitly authorize the hosts that are allowed to use its domain name in a reverse-path, and a way for receiving hosts to check such authorization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-mailfrom-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-ietf-marid-mailfrom-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-ietf-marid-mailfrom-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" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-16155119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-mailfrom-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-mailfrom-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-16155119.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 17:00:51 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 RAA21198 for ; Thu, 16 Sep 2004 17:00:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GKNJUC073724; Thu, 16 Sep 2004 13:23:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GKNJJc073723; Thu, 16 Sep 2004 13:23:19 -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 i8GKNGu7073712 for ; Thu, 16 Sep 2004 13:23:19 -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 C800616CD2 for ; Thu, 16 Sep 2004 16:32:42 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Thu, 16 Sep 2004 12:02:43 PDT." <1095361363.30902.140.camel@ddev.mail-abuse.org> Date: Thu, 16 Sep 2004 16:32:42 -0400 Message-Id: <20040916203242.C800616CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > I see a conflict even within the specification. Jim Lyon has already > indicated any domain publishing an "open" record, requesting forwarded > mail receive a "Pass" assessment, will receive the bad reputation they > deserve. The specification does not warn of this problem. The goal of specifications should not be to anticipate all possible uses or abuses, of the specification. To ask this of a specification is to guarantee that it will fail to achieve consensus. > By first performing CSV to authenticate and authorize the MTA, and then > obtaining an authorization list of names referenced by the mailbox > domain, this will specifically prevent spoofing. I do not believe that there is enough consensus as to what "EHLO" checking means, or "MAIL FROM" checking means. Without that consensus, we have no quantitative way of comparing proposals, or for deciding if a proposal meets our requirements. > There should be some consideration given this, as you have indicated > your own expectation the results of this scheme will be used for > establishing reputations. That is a matter for a follow-up WG, or a re-charter of this WG, once this WG finishes its current work. Until then, I see no point in discussing the benefits or impacts of reputation systems. > I am not suggesting curtailing spoofing not be done. I am simply > advocating a better, safer, cleaner approach. And yes, it also makes > reputations safer as well. I'm not sure how any "MAIL FROM" checking can prevent spoofing on a shared MTA. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 17:26:22 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 RAA22895 for ; Thu, 16 Sep 2004 17:26:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GKm517075327; Thu, 16 Sep 2004 13:48: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 i8GKm5gj075326; Thu, 16 Sep 2004 13:48:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GKm50P075319 for ; Thu, 16 Sep 2004 13:48:05 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C83An-0008R7-00 for ; Thu, 16 Sep 2004 13:48:09 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16713.64521.588061.380843@proton.pathname.com> Date: Thu, 16 Sep 2004 13:48:09 -0700 To: ietf-mxcomp@imc.org Subject: IANAL and neither are you X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit (well, except for Anne) All you non-lawyers should consult with your attorney before reading patents because most non-lawyers (like me) don't know much about patents. I'm guessing some of you don't have a lawyer you can consult with because he or she probably would have kicked your ass already. http://www.kuro5hin.org/comments/2002/4/8/22291/81741/27#27 I have yet to meet a lawyer *anywhere* who would disagree with the sentiment expressed in that post. Daniel -- Daniel Quinlan ApacheCon! 13-17 November (3 SpamAssassin http://www.pathname.com/~quinlan/ http://www.apachecon.com/ sessions & more) From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 18:06: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 SAA25147 for ; Thu, 16 Sep 2004 18:06: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 i8GLNfr7077615; Thu, 16 Sep 2004 14:23: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 i8GLNfrH077614; Thu, 16 Sep 2004 14:23:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8GLNeUp077607 for ; Thu, 16 Sep 2004 14:23:40 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 70907 invoked from network); 16 Sep 2004 21:23:42 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 16 Sep 2004 21:23:42 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: Subject: RE: SPF abused by spammers Date: Thu, 16 Sep 2004 17:23:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) In-Reply-To: <20040916203242.C800616CD2@mail.nitros9.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Alan DeKok > Sent: Thursday, September 16, 2004 4:33 PM > To: ietf-mxcomp@imc.org > Subject: Re: SPF abused by spammers > I'm not sure how any "MAIL FROM" checking can prevent spoofing on a > shared MTA. > > Alan DeKok. I don't think it can. That's why I give shared MTAs that I use a NEUTRAL vice PASS result in my SPF records unless there are local restrictions to prevent other customers of the MTA from using my "MAIL FROM". What I can do with "MAIL FROM" checking is tell the world which MTAs are not authorized through -all. Personally, I would love to see some synergy between "MAIL FROM" and SUBMITTER. If shared MTA operators would add SUBMITTER and an appropriate 2822 header field, then the result would be: "MAIL FROM" - NEUTRAL (based on my domain) SUBMITTER - PASS (based on the ISP domain). This would mean, the domain owner says that the message is not certainly forged and the MTA operator says it is accepting responsibility for the message. I would think that most people would accept this combination. I also think this is appropriate for shared MTAs because it is, in the end, the operator of the MTA that is responsible for forgery it allows to happen. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 18:21: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 SAA25990 for ; Thu, 16 Sep 2004 18:21: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 i8GLoHpC079615; Thu, 16 Sep 2004 14:50:17 -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 i8GLoHT9079614; Thu, 16 Sep 2004 14:50:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GLoGeh079605 for ; Thu, 16 Sep 2004 14:50:17 -0700 (PDT) (envelope-from SRS0=zEx9ibYR=MF=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8GLoEaZ011209 for ; Thu, 16 Sep 2004 23:50:14 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409162150.I8GLOETD011199@asarian-host.net> Date: Thu, 16 Sep 2004 21:50:14 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: SPF abused by spammers X-Trace: JoZU/dS7AdbyCyTTadLswFpFyRiAdlll9EQDFrN40zBhdl5XingKxF4YPg0H6PrXaywWINqcEOFhSoeo0pJLAg== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQUoKljFqW1BleBN9AQFqgAf/WztN+ugZmftXDAANQx6FNn9cfwlFWQfl jT7oRLFj1H2swfGZ8pHImgFQbAr6Lh4EfXhA3y+LddMWd/Xblzq2SMlGvQj4zgir u6ynDFfTY2NCANfYefsxiY/gMPYiOKHfvF7gZfakJOUoSfn4qPfaptWdqRH12Rcl ArN6G/7qO0ewBJ2NK0wdrG9l2UsjF0aKK6ChmYiEMPymQoUgOY1HXCLEeELmAZXn SNrsubzFVyn2qozMJprO/LfsJ+sonmsCcS7rplWmq02uOPz0AFLvyTfXn/7D7QQW MtBw3kEMst+5p5ZoXTWNYTZ0HwcaXJ7mWq1pjjm7tKYgwt4VZ77Y4w== =/+io Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Scott Kitterman wrote: > What I can do with "MAIL FROM" checking is tell the world which MTAs > are not authorized through -all. > > Personally, I would love to see some synergy between "MAIL FROM" and > SUBMITTER. If shared MTA operators would add SUBMITTER and an > appropriate 2822 header field, then the result would be: > > "MAIL FROM" - NEUTRAL (based on my domain) > SUBMITTER - PASS (based on the ISP domain). I still stand by my earlier posted idea to use ENVID for this purpose, when I wrote: > I was more than happy even using the existing ENVID for this purpose. > ;) Something like: > > Mail from: ENVID= > > Then we could have all used it tomorrow. I know, that is not what RFC > 1891, section 5.4, meant it for; but it would have been fine by me. :) Seriously, is there anyone out there who has ENVID currently in use? It just sits here, so unused. :) Cheers, - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 19:28:57 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 TAA29456 for ; Thu, 16 Sep 2004 19:28: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 i8GMqCaA084296; Thu, 16 Sep 2004 15:52: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 i8GMqCQc084295; Thu, 16 Sep 2004 15:52:12 -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 i8GMqCOl084288 for ; Thu, 16 Sep 2004 15:52:12 -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 79876414C4; Thu, 16 Sep 2004 15:52:15 -0700 (PDT) Subject: Re: SPF abused by spammers From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040916203242.C800616CD2@mail.nitros9.org> References: <20040916203242.C800616CD2@mail.nitros9.org> Content-Type: text/plain Message-Id: <1095375135.30902.266.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Sep 2004 15:52:15 -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-09-16 at 13:32, Alan DeKok wrote: > Douglas Otis wrote: > > I see a conflict even within the specification. Jim Lyon has already > > indicated any domain publishing an "open" record, requesting forwarded > > mail receive a "Pass" assessment, will receive the bad reputation they > > deserve. The specification does not warn of this problem. > > The goal of specifications should not be to anticipate all possible > uses or abuses, of the specification. To ask this of a specification > is to guarantee that it will fail to achieve consensus. This still leaves anticipating the use of "open" lists provided by the draft and its effect of "inviting" spoofing. This aspect should be within the scope of a draft that purports to solve a spoofing problem. > > By first performing CSV to authenticate and authorize the MTA, and then > > obtaining an authorization list of names referenced by the mailbox > > domain, this will specifically prevent spoofing. > > I do not believe that there is enough consensus as to what "EHLO" > checking means, or "MAIL FROM" checking means. Without that > consensus, we have no quantitative way of comparing proposals, or for > deciding if a proposal meets our requirements. There must be an exchange of ideas and concepts to arrive at a consensus. Announcing Caller-ID as the WG draft did not invite much reflection other than largely the eventual removal of XML. It would seem a foregone conclusion more than consensus. Publishing a draft helps, but answering questions should provide clarity or offer a perspective of the trade-offs considered. As example, there were several serious issues never addressed. The most I heard with respect to network congestion avoidance, actually the lack of avoidance, was "That would be bad." The latest draft still retains a required 10 script processing within 20 seconds minimum each. The time limit was added after it was pointed out valid record sets may take more than a hour to resolve even with no packet loss. The addition of the time limit then fails to address a potential loss of network integrity that may dramatically affect long haul links, or a potential for flooding the network with UDP traffic. A 3-5% packet-loss of UDP packets is common but clearly not accommodated. Ignoring this does not make the problem go away. Network considerations should be within scope for a network protocol. Plays well with others should be a requirement. > > There should be some consideration given this, as you have indicated > > your own expectation the results of this scheme will be used for > > establishing reputations. > > That is a matter for a follow-up WG, or a re-charter of this WG, > once this WG finishes its current work. Until then, I see no point in > discussing the benefits or impacts of reputation systems. At the same time this group was declaring Last Call, there were reputation services based upon the identities provided. Statements of being able to trust Sender-ID or SPF identities will not make these identities trustworthy however. There should be consideration given the expectations created by hyperbola. > > I am not suggesting curtailing spoofing not be done. I am simply > > advocating a better, safer, cleaner approach. And yes, it also makes > > reputations safer as well. > > I'm not sure how any "MAIL FROM" checking can prevent spoofing on a > shared MTA. The stronger the validation of a name associated with a message, the less likely this validation will be spoofed. As shown with Microsoft's PRA algorithm, the name validated does not need to be the RFC2822 From address. Spoofing a Sender-ID or SPF check may only require asserting a mailbox domain depending upon the nature of the list or the entry point of the message. CSV is not as easily spoofed, nor does it assault DNS with a phalanx of variable records types to be resolved which may open up other security risks as with SPF and Sender-ID. Making this validated MTA name visible along with the RFC2822 From will alert users to unexpected sources of the From mailbox domain based upon the user becoming familiar with these identities during their normal correspondents. Unlike SPF or Sender-ID, the marid-mpr draft offers a means for the domain administrator to specify these normal sources for either the RFC2821 MAIL FROM or RFC2822 From mailbox domains that can not be superseded as with Sender-ID. The validation of the MTA name does not "invite" the spoofing of the mailbox domain. Use of a MAIL FROM constraint or the use of BATV will also dissuade spoofing of this mailbox domain. Institutions that find themselves being phished or spoofed, should not employ outbound MTAs outside their administrative realm and use a consistent identity for their MTA names. Unlike Sender-ID however, MPR can thwart spoofing of the RFC2822 From as well as the RFC2821 MAIL FROM. Such institutions would need to alert their customers of this limitation, if their mail is forwarded. As MPR safely allows "open" lists, there can be a graceful transition in making this restriction without "inviting" trouble. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 20:43:26 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 UAA04480 for ; Thu, 16 Sep 2004 20:43: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 i8H0A9gn090103; Thu, 16 Sep 2004 17:10: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 i8H0A9PN090102; Thu, 16 Sep 2004 17:10:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H0A5PW090087 for ; Thu, 16 Sep 2004 17:10:06 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C86KD-0000s8-00 for ; Fri, 17 Sep 2004 02:10:05 +0200 Received: from 212.82.251.243 ([212.82.251.243]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Sep 2004 02:10:05 +0200 Received: from nobody by 212.82.251.243 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Sep 2004 02:10:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd) Date: Fri, 17 Sep 2004 02:06:53 +0200 Organization: Lines: 53 Message-ID: <414A2A9D.1DA4@xyzzy.claranet.de> References: <41425D56.6E83@xyzzy.claranet.de> <20040913174322.A98830@protagonist.smi.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.243 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Murray S. Kucherawy wrote: > sender-id, SPF and DomainKeys are only done at the border > inbound but an internal message was injected for which the > client authenticated using SMTP AUTH, I felt that fact > should be relayed should the MUA or LDA wish to make a > decision based on it. Sure, I was only confused because in your example the very same host did both (MSA auth stuff + MX SPF tests). Maybe split it in two headers. That would also demonstrate cases where spammers could send forged Authentication-Results. Out of curiosity, I use an MSA enforcing a valid MAIL FROM. This MSA uses SMTP-after-POP (and before you laugh, that's not much worse than insecure PLAIN or LOGIN). What are the corresponding Authentication-Results ? Here's my guess: | Authentication-Results: mail2.hamburg.example | return-path=m-e@hamburg.example; auth=pass (pop3) Is that the idea ? Or should the MSA match the POP3 mechanism to a corresponding SMTP AUTH, (login) in my example. But IIRC "login" isn't documented in any RfC. And officially "plain" isn't allowed without TLS. SMTP-after-APOP would be better than "login" or "plain", so maybe you need some additional keywords like "tls", "login" or "apop" for auth. Actually you don't need the "pass" for auth, let alone any other weird SPF results, auth=apop or auth=cram-md5 should be good enough. For SPF the tested header at the moment implicitly defines the tested scope. Return-path is always spf2.0/mailfrom, helo is always spf2.0/helo. Anything else (from, sender, resent-*) is always spf2.0/pra. Therefore you could simply use header=mailbox spf=result for spf2.0/helo, spf2.0/mailfrom, and spf2.0/pra. "Helo" is no header, but it fits in your "headerspec" syntax, if you define "headerspec" in the next draft ;-) This simplification won't work for Wayne's spf2.0/from, because then a tested "from" either corresponds to a PRA or to Wayne's draft. IMHO you don't need a list of SPF results, that's defined in protocol-03, and rather useless for "auth". You could add a section how MUAs can try to auto-detect the support of this header by their MDAs (Outlook uses test messages for similar purposes). Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Sep 16 22:51: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 WAA10579 for ; Thu, 16 Sep 2004 22:51: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 i8H2HI7F099946; Thu, 16 Sep 2004 19:17: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 i8H2HIUB099945; Thu, 16 Sep 2004 19:17:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H2HHFB099938 for ; Thu, 16 Sep 2004 19:17:17 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id 0E65C132CD1; Thu, 16 Sep 2004 22:15:05 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 526735AD; Thu, 16 Sep 2004 22:17:20 -0400 (EDT) Date: Thu, 16 Sep 2004 22:17:20 -0400 From: Meng Weng Wong To: IETF MARID List , spf-discuss@v2.listbox.com Subject: Patent Application 683624 Message-ID: <20040917021720.GK23667@dumbo.pobox.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 16, 2004 at 09:20:41AM -0700, william(at)elan.net wrote: | > US - Title: "Reducing Unwanted And Unsolicited Electronic Messages By | > Preventing Connection Hijacking And Domain Spoofing", Serial no. 10/684020 | | This patent got published today, to see it try using this url: | http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=684020.APN.&OS=APN/684020&RS=APN/684020 | If does not work go to http://appft1.uspto.gov/netahtml/PTO/search-bool.html | and type 684020 for Application Serial Number in field1. Application Serial Number 10/683624 may also be of interest to this working group. "Reducing Unwanted and Unsolicited Electronic Messages by Exchanging Electronic Message Transmission Policies and Solving and Verifying Solutions to Computational Puzzles" cheers meng From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 00:10:51 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 AAA17464 for ; Fri, 17 Sep 2004 00:10: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 i8H3ZslX005986; Thu, 16 Sep 2004 20:35:54 -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 i8H3ZsKF005985; Thu, 16 Sep 2004 20:35:54 -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.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8H3ZdZb005885 for ; Thu, 16 Sep 2004 20:35:39 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Thu, 16 Sep 2004 23:40:41 -0400 Received: from ([65.10.105.81]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 1562839843; Thu, 16 Sep 2004 23:40:40 -0400 Message-ID: <004e01c49c66$f2b54620$6401a8c0@hdev1> From: "Hector Santos" To: "Alan DeKok" , References: <20040916203242.C800616CD2@mail.nitros9.org> Subject: Re: SPF abused by spammers - Fixing RFC 2821 issues Date: Thu, 16 Sep 2004 23:32:21 -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 ----- Original Message ----- From: "Alan DeKok" To: Sent: Thursday, September 16, 2004 4:32 PM Subject: Re: SPF abused by spammers > I do not believe that there is enough consensus as to what "EHLO" > checking means, or "MAIL FROM" checking means. Without that > consensus, we have no quantitative way of comparing proposals, or for > deciding if a proposal meets our requirements. Alan, One of the key reasons I stayed away for the most part from this discussion is because I don't think much progress will be made until RFC 2821 functional specification are modified to allow for enforcement and for proper operations in a reduced and managed "spam world." What is being proposed has many legal and operational ramifications and until the RFC 2821 is modified, compliant legacy systems will continue to be problematic, both technically and legally. There are three (3) problems as I see it based on product operations: 1) The forwarding issue as we all know it, 2) US EPCA related issues regarding privacy, and 3) Malpractice and Bandwidth issues with Dynamic vs. Post SMTP analysis. The industry has had two decades of standard email operational precedence that 100% addressed #2 and #3. Systems were designed and engineered with the corresponding ECPA laws in the books in mind. It is my strong belief based on 20+ years of exclusive telecommunications and electronic mail design and production, that Microsoft SenderID proposal hits smack against the tradition with a major risk of creating many new legal issues. To summary the concerns: The SUBMITTER concept will enforce SUBMITTER compliant ISP to operate in a mode were users are no longer allowed to use alias email addresses. This has already been proved to be the case when the SPF compliant ISP has users using alias email addresses and it failed at the SPF compliant MDA. Microsoft's SUBMITTER will raise privacy concerns because the ISP must send the user's main account with the mail transaction, an action the user many not want. The PRA concept will break optimized operations using dynamic SMTP operations. It will enforce payload transmissions which has three critical issues with it: 1) Risk operating in a mode where failure to delivery mail runs against the US EPCA user rights for delivery expectations. 2) Introduces higher network bandwidth across all PRA compliant points. 3) Introduces higher and unnecessary bounce mail operations which is a major factor in the distribution of malicious electronic mail. It is for these key reasons, Santronics can not support the Microsoft proposals based on its technical merits. This does not take away the fact that we made be forced to do so based on customer and market pressures, but it is not something we wish to spend resources on. I firmly believe there are better solutions and in my opinion, it begins with getting all the issues with SMTP specifications squared away. Once the industry, the world, has a new basis for SMTP operations, then all the authentication and validations ideas make more sense and work more reliably. All future SMTP products will have "new rules" to work and more importantly remains legal with the current laws in the books. In my view, the following effort should be done: 1) SMTP specification refinement to clear all the ambiguities and specify the new enforcement issues. 2) At a minimum, introduce 2 new ESMTP commands: TOPIC (or SUBJ to keep with the 4 letter standard) HEAD Both items solves the following: 1) It address optimized support for CANSPAM at the transport level 2) It address optimized support for Header Analysis at the transport level. 3) It helps the Microsoft PRA proposal. 4) It eliminates the payload problem. 5) It keeps the operation legal with no conflicts with the current EPCA related laws in the books. Note, none of this takes away from SPF or MARID, but currently what is being proposed does not help the process for all parties. Since change is required at some level for the SMTP server and receiver, we might as get it right with the minimum requirements to address spam/spoofing. Thanks Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 00:59: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 AAA20376 for ; Fri, 17 Sep 2004 00:59:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H4L2a7008787; Thu, 16 Sep 2004 21:21: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 i8H4L2rH008786; Thu, 16 Sep 2004 21:21:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8H4L1Mt008779 for ; Thu, 16 Sep 2004 21:21:02 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Fri, 17 Sep 2004 00:26:13 -0400 Received: from ([65.10.105.81]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 1565572109; Fri, 17 Sep 2004 00:26:13 -0400 Message-ID: <005801c49c6d$4f30c0e0$6401a8c0@hdev1> From: "Hector Santos" To: , "Frank Ellermann" References: <41425D56.6E83@xyzzy.claranet.de> <20040913174322.A98830@protagonist.smi.sendmail.com> <414A2A9D.1DA4@xyzzy.claranet.de> Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd) Date: Fri, 17 Sep 2004 00:17:47 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 ----- Original Message ----- From: "Frank Ellermann" To: Sent: Thursday, September 16, 2004 8:06 PM Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd) > Out of curiosity, I use an MSA enforcing a valid MAIL FROM. > This MSA uses SMTP-after-POP (and before you laugh, that's > not much worse than insecure PLAIN or LOGIN). What are the > corresponding Authentication-Results ? Here's my guess: I don't understand this reason for this. The problem is :Final Destination mail from Anonymous Senders." Local ISP users who are "malicious" and/or "abusive" is an administrative problem. You can probably add technical logic such as limits, but overall the authenticated ISP user is not the problem the world is facing with abusive final destination anonymous senders. Remember what the standard mode of SMTP is: 1) Authenticated or IP allowed clients can send local and remote mail. 2) No authentication is required for final destination mail (local). In other words, anonymous senders can not send remote mail. So the anti-spam technological pressure point is at #2. Not #1. This is a key factor most people seem to forget. RFC 2821 has provided us a DOOR to help solve the problem and also run in a more optimized mode with a method that none of the MARID proposals use or consider. See RFC 2821 section "3.3 Mail Transactions" Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. What it says is this: You have 3 states points in SMTP: EHLO/HELO MAIL FROM RCPT TO: Everyone is worry about the first two states before RCPT TO is known. They are proposing changes to SMTP receivers where overhead is added to check the first two states. A blind check with total disregard to establishing the critical information of final destination or remote mail. The section 3.3 suggestion is to simply delay the "overhead" authentication/validation logic for EHLO/HELO and MAIL FROM until RCPT TO is known. In practice, it works wonderfully. You can save a tremendous amount of your ANTI-SPAM overhead using this key method. Remember again, if RCPT TO is not a local user, then the transaction becomes a RELAY, thus the client IP and/or MAIL FROM must be authenticated using standard SMTP technology already in place. However, if RCPT TO is a local user, then SMTP says that you must accept the mail regardless of the sender. That is the golden rule and also the reason for the SPAM problem. So in short, this is a Final Destination Anonymous Sender issue. I don't see a need for MARID or anti-spoof overhead if the client is authenticated. Thanks Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 01:28: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 BAA22169 for ; Fri, 17 Sep 2004 01:28: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 i8H4uC3k011863; Thu, 16 Sep 2004 21:56: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 i8H4uC2X011862; Thu, 16 Sep 2004 21:56:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H4uBQv011856 for ; Thu, 16 Sep 2004 21:56:11 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: pFL9pW3pihzfb0hsZF3kqA 1095396976 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 2C68B56D3BE; Fri, 17 Sep 2004 00:56:15 -0400 (EDT) Message-ID: <414A6EE6.6030801@elvey.com> Date: Thu, 16 Sep 2004 21:58:14 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: ANNOUNCE: I-D draft-ietf-marid-SPF3-00, etc. References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <4147ED67.1040301@elvey.com> <4148CD50.56F0@xyzzy.claranet.de> In-Reply-To: <4148CD50.56F0@xyzzy.claranet.de> 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 Well, draft-ietf-marid-protocol-03.txt was very disappointing, so I went ahead and did what needed doing. I made some edits and made a new Internet-Draft based on it: SPF3. I summarize the changes as follows: s/typos/corrections/ s/Most of 6.2 Processing Limits/ s/mail from or PRA/HELO/ s/mfrom,pra/helo/ s/spf2.0/spf3.0/ s/Mark,Meng/me/ s/SenderID/SPF3/ Some tweaks to the Abstract. Allow SPF1 records to be used. Strangely, draft-ietf-marid-protocol-03.txt didn't allow this! The effort put into the edit may have produced something of lesser quality than one expects from Microsoft. Comparison of SPF3 and CSV+MPR: Organizationally, it's superior, in that it leverages the existing base of SPF1 records. It's easier to understand, includes examples, and it's easier to create TXT records - of bind, GoDaddy and ZoneEdit, only BIND supports what CSV requires. Technically, it's inferior, in that its usage of DNS is less efficient and less standards-based. MPR also has the cool bitmapped fields for explicit protection of 2822.From:, etc. This could be added to SPF3. Comparison of SPF3 and SPF1 or SenderID: It's superior, in that it doesn't break forwarding, is much more efficient, and can't be tricked by forged or misleading headers, requires about 99% less effort to implement, on a global basis, is based on an algorithm that predates M$' patent filing, and provides something that can be better accredited. =-=-=-=-= Rest of this post: Re: HELO and Unified ; new scope? ; Microsoft oops; BCP On 9/15/2004 12:58 AM, David Woodhouse sent forth electrons to convey: > >My suggestion is that we should go forward with an entirely _different_ >scope, not just unify on either mail-from or whatever the unencumbered >pra replacement would be. > >There are many possibilities which would offer us some 'handle' on the >owner of the mail server in question, without all the problems which >both mail-from and pra scopes suffer. > > The 'handle' needs to be something non-free, otherwise spammers will make an infinite number of them. Domains are a good choice. A domain with a valid SSL cert would be another choice. Spamhaus.org's .mail proposal would be another good choice. Unsigned certs or signed thawte freemail certs would not be acceptable. =-=-=-=-= There's a false statement in Microsoft's previous IPR disclosure statement: >VIII. Other Notes: ** A license to implement these specifications >will be made available at http://www.microsoft.com/mscorp/standards on >or before September 15, 2004. > http://www.microsoft.com/mscorp/ip/standards/ has it. =-=-=-=-= On 9/15/2004 4:16 PM, Frank Ellermann sent forth electrons to convey: >Matthew Elvey wrote: > > > >>>we have been asked by the DNS people to refrain from putting >>>additional load on the PTR system if possible. >>> >>> (And the mess of mis/unattributed quotes continues. I didn't write that.) >>Oh, I missed that request. A pointer and/or quote would be >>appreciated if it wasn't made on this list. >> >> > > > > Thanks. An interesting thread. It suggests that the RIRs have little to worry about. If MARID is halfway successful, the load on their servers is likely to go way DOWN. PTR lookups are already the norm. MARID should cut mail volumes are cut by more than half (most mail is spam), so PTR lookups can be expected to go down as well. BTW, RIR gross failure to address their responsibilities, as evidenced by http://www.spamhaus.org/sbl/listings.lasso?isp=APNIC , (not to mention http://www.spamhaus.org/sbl/listings.lasso?isp=ARIN ) well, umm... I... They're knowingly providing Spam Support Services... =-=-=-=-= With respect to being able to outright reject forgeries without breaking forwarding: With HELO checks + A&R, I can see this becoming reasonable BCP. Here's how: Forwarders (and mailing list hosts) will be expected to be runnning MARID on their MTA. If they are too lazy to do so, then they will be found to be forwarding on obvious (to anyone using MARID) forgeries, and thus their reputations will (justifiably) suffer. It will probably not be fair to blame 'em for all spam they forward, but it will be fair to blame them for forwarding on obvious forgeries. The responsible forwarders running MARID can be expected to have good HELO reputations. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 01:54: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 BAA23779 for ; Fri, 17 Sep 2004 01:54: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 i8H5K5QO019721; Thu, 16 Sep 2004 22:20: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 i8H5K5mM019720; Thu, 16 Sep 2004 22:20:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H5K4n8019705 for ; Thu, 16 Sep 2004 22:20:04 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id DF7C6132CD1; Fri, 17 Sep 2004 01:17:54 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id DA5A75A3; Fri, 17 Sep 2004 01:20:10 -0400 (EDT) Date: Fri, 17 Sep 2004 01:20:10 -0400 From: Meng Weng Wong To: spf-discuss@v2.listbox.com, ietf-mxcomp@imc.org Subject: Re: "include" directive in -03 SPF draft Message-ID: <20040917052010.GV334@dumbo.pobox.com> References: <20040917043748.GT21223@piias899.ms.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040917043748.GT21223@piias899.ms.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: forwarded by request of Victor Duchovni, who is a respected contributor to the Postfix project among other things. On Fri, Sep 17, 2004 at 12:37:48AM -0400, Victor Duchovni wrote: | | [ Please recirculate as appropriate, even if you disagree, I hope that | this point of view will at least get a fair hearing. Perhaps it has | already and I am beating a dead horse, if so sorry... ] | | I would like to humbly suggest that the "include" directive is unwise. It | makes zone administration easier at the cost of much more complex, | recursive possibly looping query requirements on clients. This is IMHO | the wrong tradeoff. Configuration of identical SPF data in multiple zones | should be entirely the responsibility of the zone file administrator who | can use "include" directives, macros, scripts, and many other tools to | ensure consistency of SPF data accross multiple domains. | | If we are to learn anything from Dan Bernstein's less than politically | correct, but without a doubt insightful observations on DNS, it is | than all features that shift the cost of indirection onto the resolver | are bad. He rightly rails against A6 records, which are deprecated, | he corrrectly encourages always "in-bailiwick" NS records (which are | now the norm since Verisign no longer requires a unique hostname for | each glue IP). He correctly suggests that indeed were DNS redesigned, | the burden of converting NS->IP should have been on the server, with | the on the wire syntax IP valued and names only used as administrative | convenience in zone files. | | Not all of this universally accepted dogma, but I is IMHO reasonable to | give this point of view due consideration. Please reconsider the decision | to burden the standard with client visile "include" directives, this | should not I think be exposed outside the owners zone management tools. | | -- | | /"\ ASCII RIBBON NOTICE: If received in error, | \ / CAMPAIGN Victor Duchovni please destroy and notify | X AGAINST IT Security, sender. Sender does not waive | / \ HTML MAIL Morgan Stanley confidentiality or privilege, | and use is prohibited. | From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 02:22: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 CAA08942 for ; Fri, 17 Sep 2004 02:22:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H5tC2I037018; Thu, 16 Sep 2004 22:55: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 i8H5tCAP037017; Thu, 16 Sep 2004 22:55:12 -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 i8H5tCRn037008 for ; Thu, 16 Sep 2004 22:55:12 -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 i8H5srZp026338 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 16 Sep 2004 22:55:17 -0700 Subject: Re: Patent Application 683624 From: Douglas Otis To: Meng Weng Wong Cc: IETF MARID List , spf-discuss@v2.listbox.com In-Reply-To: <20040917021720.GK23667@dumbo.pobox.com> References: <20040917021720.GK23667@dumbo.pobox.com> Content-Type: text/plain Message-Id: <1095400303.2695.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 16 Sep 2004 22:51:44 -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-09-16 at 19:17, Meng Weng Wong wrote: > On Thu, Sep 16, 2004 at 09:20:41AM -0700, william(at)elan.net wrote: > | > US - Title: "Reducing Unwanted And Unsolicited Electronic Messages By > | > Preventing Connection Hijacking And Domain Spoofing", Serial no. 10/684020 > | > | This patent got published today, to see it try using this url: > | http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=684020.APN.&OS=APN/684020&RS=APN/684020 > | If does not work go to http://appft1.uspto.gov/netahtml/PTO/search-bool.html > | and type 684020 for Application Serial Number in field1. > > Application Serial Number 10/683624 may also be of interest > to this working group. > > "Reducing Unwanted and Unsolicited Electronic Messages by > Exchanging Electronic Message Transmission Policies and > Solving and Verifying Solutions to Computational Puzzles" >From their presentation, the concept was to impose about a 16 second additional CPU message burden for the sender. Their statement was such additional overhead doubled the cost of equipment for the sender. This does not consider that many abusive senders control millions of Window machines with hidden Trojan proxies and never pay for their use. Instead of deploying 50,000 machines, this puzzle may require 100,000. With each machine costing them $0.00, even doubling CPUs will not affect the abuser's costs of sending to the same extent it will for legitimate senders. It does bring up the issue of cost for a maximal 200 second receiver burden for resolving Sender-ID or SPF records. With a common spammer technique of using random sub-domains, this will keep filters guessing and the DNS resolvers scrambling for records. It would seem illegitimate senders win in any war of escalated overheads. If only these innovators would properly handle a temp error, we could slow unknown senders without punishing legitimate senders. ; ) -Doug From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 03:03:57 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 DAA11157 for ; Fri, 17 Sep 2004 03:03: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 i8H6T3Zp051904; Thu, 16 Sep 2004 23:29:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H6T37A051903; Thu, 16 Sep 2004 23:29:03 -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 i8H6T2wf051892 for ; Thu, 16 Sep 2004 23:29: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 i8H6fB7K021840; Thu, 16 Sep 2004 23:41:11 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8H6fBeN021837; Thu, 16 Sep 2004 23:41:11 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 16 Sep 2004 23:41:11 -0700 (PDT) From: "william(at)elan.net" To: Douglas Otis cc: IETF MARID List Subject: Re: Patent Application 683624 In-Reply-To: <1095400303.2695.50.camel@localhost.localdomain> 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, 16 Sep 2004, Douglas Otis wrote: > From their presentation, the concept was to impose about a 16 second > additional CPU message burden for the sender. Their statement was such > additional overhead doubled the cost of equipment for the sender. This > does not consider that many abusive senders control millions of Window > machines with hidden Trojan proxies and never pay for their use. And besides, the CPU costs are rapidly going down with twice as fast CPUs being released every one or two years. You simply can't rely on this technique - the hardware cost even for spammer that does not use zombie machines is likely to be low percentage for cost of his operation - its the cost of hosting of such machine on "spam tolerant" network that is high. > It does bring up the issue of cost for a maximal 200 second receiver > burden for resolving Sender-ID or SPF records. With a common spammer > technique of using random sub-domains, this will keep filters guessing > and the DNS resolvers scrambling for records. I note that the same problem exists with absolutly every proposal before MARID. And in reality its not really proper concern for this group, we need to worry how to properly identify GOOD senders and how to make sure THEIR domains are not forged. That spammers can still buy new domains for almost nothing ($6) or use subdomains which are technically free to them and then publish MARID records there is outside the scope of this group - it is something to be addressed by reputation. > It would seemi illegitimate senders win in any war of escalated > overheads. If only these innovators would properly handle a temp error, > we could slow unknown senders without punishing legitimate senders. ; ) I did not understand how handling temp error would help. Can you explain or give example? --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 03:34: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 DAA12589 for ; Fri, 17 Sep 2004 03:34:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H752Co064288; Fri, 17 Sep 2004 00:05: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 i8H752IK064287; Fri, 17 Sep 2004 00:05:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8H7517W064275 for ; Fri, 17 Sep 2004 00:05:02 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Fri, 17 Sep 2004 03:10:06 -0400 Received: from ([65.10.105.81]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 1575404093; Fri, 17 Sep 2004 03:10:05 -0400 Message-ID: <00b101c49c84$33448080$6401a8c0@hdev1> From: "Hector Santos" To: References: <200409161939.PAA09298@ietf.org> Subject: TECH-DOC: Re: I-D ACTION:draft-ietf-marid-mailfrom-00.txt Date: Fri, 17 Sep 2004 03:01:42 -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 have a few some comments regarding: http://www.ietf.org/internet-drafts/draft-ietf-marid-mailfrom-00.txt In "2.4 Interpreting the Result," add a summary of the possible results for better reading: | 2.4 Interpreting the Result | | The check_host() function returns one of seven (eight?) following results, some with | additional information: | | Neutral | Pass | Fail | SoftFail | None | TempError | PermError | | This section describes how software that | performs the authorization must interpret the results. If the check | is being performed during the SMTP mail transaction, it also | describes how to respond. Relaxed Provisions: I have mentioned this a few times. I believe that SPF is partially defeating the purpuse of its goal by having unrestricted relaxed provisions for Neutral and SoftFail results with no functional specification on how to deal with it. In my opinion, this will plaque SPF until inevitably the problems it present is better recognized in mass practice and it is finally addressed in the future. Unfortunately, by then it might be too late as there will be far too many legacy systems in place. Lets not close current SMTP shortcomings by opening new ones. The key issue is that the relaxed provisions should be limited in usage. Although, section 2.4.4 states: "This value (softfail) is used by domains as an intermediate state during roll-out of publishing records." I believe the options opens a hole in SPF that should not be there in the first place. While a good intention system my play by the rules and eventually gets its SPF setup right when rollout is complete, I see this being abused and will become a source for SPF spoofers. I don't think we need a technical method to control this. Rather what is simply required is a functional description with strong statement for usage limitations with a strong indication that SPF clients MAY implement expiration concepts. Suggested addition/changes to document regarding Neutral and SoftFail: | 2.4.1 Neutral | | A Neutral result MUST be treated exactly like a None result. | | See "2.5 Handling Relaxed Provisions (Neutral and SoftFail)" | 2.4.4 SoftFail | | A SoftFail result should be treated as somewhere between a Fail and a | Neutral. This value is used by domains as an intermediate state | during roll-out of publishing records. The domain believes the host | isn't authorized but isn't willing to make that strong of a | statement. Receiving software SHOULD NOT reject the message based on | this result, but MAY subject the message to closer scrutiny. | | See "2.5 Handling Relaxed Provisions (Neutral and SoftFail)" | 2.5 Handling Relaxed Provisions (Neutral and SoftFail) | | The relaxed SPF results, Neutral and SoftFail, are considered | temporary and time limited domain policies. They are intended to be | used as intermediate states during roll-out periods. | | Once the roll-out is complete, the policy result should be changed | to provide strong pass or fail results. | | Since this is an area where possible exploitable may occurred, SPF | offers implementators the option to impose expiration periods for | continued usage of relaxed provisions or results. | | The expiration period starts with the first usage of the SPF domain | resulting with a relaxed provision. | | The recommended time period is: 3-6 months. | | SPF clients who wish to implement an expiration method could | use a simple database to record the first time usage. Subsequent | mail transactions with relaxed SPF results can be checked for | expiration. | | | Example pseudo code with example expiration responses: | | spf-result = check_host() | | if spf-result in [Neutral, SoftFail] then | | Expired = record_check_host_expiration() | | if Expired then | | 550-SPF Mail From check failed: Expired | 550 The domain example.com usage SPF relaxed results has expired. | | else | | 250 Temporary SPF acceptance. Expiration Date: get_expiration_date() | What is important to understand is that serious SPF domains will take this usage with the added knowledge that it will be temporary, thus they must work at getting their SPF policy and network operations in order. Without a specific specification addressing relaxed provisions, it will provided irresponsible and unrestricted usage and worst, provide a real loophole for SPF spoofers to exploit. Thanks Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 04:13: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 EAA14751 for ; Fri, 17 Sep 2004 04:13: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 i8H7eqMm076678; Fri, 17 Sep 2004 00:40: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 i8H7epxo076677; Fri, 17 Sep 2004 00:40:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H7epbm076667 for ; Fri, 17 Sep 2004 00:40:51 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C8DMO-0000mU-00; Fri, 17 Sep 2004 00:40:48 -0700 To: Meng Weng Wong Cc: spf-discuss@v2.listbox.com, ietf-mxcomp@imc.org Subject: Re: "include" directive in -03 SPF draft References: <20040917043748.GT21223@piias899.ms.com> <20040917052010.GV334@dumbo.pobox.com> From: Daniel Quinlan Date: 17 Sep 2004 00:40:48 -0700 In-Reply-To: Meng Weng Wong's message of "Fri, 17 Sep 2004 01:20:10 -0400" Message-ID: Lines: 21 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> Not all of this universally accepted dogma, but I is IMHO reasonable to >> give this point of view due consideration. Please reconsider the decision >> to burden the standard with client visile "include" directives, this >> should not I think be exposed outside the owners zone management tools. I think that's a good point, but the "include" directive allows semantics not possible otherwise. Removing it removes functionality from SPF and ignores the complexities involved in managing DNS and how email authority is often delegated to different companies and parts of an organization. SPF clients also have to watch out for excessive DNS queries resulting from evaluation of SPF records, so the burden of include via other mechanisms is just not all that significant. I would, however, be in favor of more well-defined (and somewhat lower) DNS query limits than the current ones. Daniel -- Daniel Quinlan ApacheCon! 13-17 November (3 SpamAssassin http://www.pathname.com/~quinlan/ http://www.apachecon.com/ sessions & more) From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 08:07: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 IAA28763 for ; Fri, 17 Sep 2004 08:07: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 i8HBWgVo053381; Fri, 17 Sep 2004 04:32:42 -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 i8HBWgDb053380; Fri, 17 Sep 2004 04:32:42 -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 i8HBWS0Z053361 for ; Fri, 17 Sep 2004 04:32:41 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 1D8D026C093 for ; Fri, 17 Sep 2004 13:32:30 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 0882726C0A1 for ; Fri, 17 Sep 2004 13:32:29 +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 i8HBWN8q566054 for ; Fri, 17 Sep 2004 13:32:28 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id AF8A4FACE; Fri, 17 Sep 2004 13:32:23 +0200 (CEST) Date: Fri, 17 Sep 2004 13:32:23 +0200 From: Stephane Bortzmeyer To: IETF MARID WG Subject: Re: by the numbers Message-ID: <20040917113223.GA12713@nic.fr> References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> 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: Content-Transfer-Encoding: 8bit On Tue, Sep 14, 2004 at 12:06:52PM -0400, Andrew Newton wrote a message of 155 lines which said: > Attached you will find a survey that Marcos Sanz and I did of com, net, > and de. Here are the results for ".fr" : Total Number of Domains In Zone(s): 267 657 Total Number of Domains Processed : 67 393 ... TXT Records : 1 038 Wildcard TXT Record : 26 ( 2,50%) TXT Records at Zone Apex : 983 ( 94,70%) CNAME'd TXT Records at Zone Apex : 0 ( 0,00%) TXT with SPF Content : 89 ( 8,57%) TXT with Caller-ID Content : 3 ( 0,29%) TXT with _ep Prefix : 29 ( 2,79%) TXT with _ep Prefix and No Caller-ID Content: 26 ( 2,50%) TXT with _ep Prefix and Caller-ID Content : 3 ( 0,29%) TXT with _ep Prefix and SPF Content : 4 ( 0,39%) Wildcard TXT with SPF Content : 4 ( 0,39%) Wildcard TXT with Caller-ID Content : 0 ( 0,00%) TXT at Zone Apex with SPF Content : 81 ( 7,80%) TXT at Zone Apex with Caller-ID Content : 0 ( 0,00%) ... Domains with SPF : 81 ( 0,12%) Domains with Caller-ID : 3 ( 0,00%) Domains with both SPF and Caller-ID : 3 ( 0,00%) Domains with SPF and Wildcard TXT : 4 ( 0,01%) Domains with SPF in Wildcard TXT : 4 ( 0,01%) Domains with SPF and Wildcard TXT but not Both : 0 ( 0,00%) Domains with SPF and Other Content in Wildcard TXT : 0 ( 0,00%) Domains with SPF at Zone Apex : 81 ( 0,12%) Domains with SPF '+all' : 0 ( 0,00%) Domains with SPF '-all' : 28 ( 0,04%) Domains with SPF '?all' : 6 ( 0,01%) Domains with SPF '~all' : 3 ( 0,00%) Domains with Caller-ID and Wildcard TXT : 0 ( 0,00%) Domains with Caller-ID in Wildcard TXT : 0 ( 0,00%) Domains with Caller-ID and Wildcard TXT but not Both : 0 ( 0,00%) Domains with Caller-ID and Other Content in Wildcard TXT: 0 ( 0,00%) From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 11:03:51 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 LAA11252 for ; Fri, 17 Sep 2004 11:03: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 i8HEMq34072239; Fri, 17 Sep 2004 07:22:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HEMqvS072238; Fri, 17 Sep 2004 07:22:52 -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 i8HEMpJv072209 for ; Fri, 17 Sep 2004 07:22:51 -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 i8HEMpUR027969; Fri, 17 Sep 2004 07:22:51 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Sep 2004 07:22:51 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'David Woodhouse'" , IETF MARID WG Subject: Moving on from the train wreck Date: Fri, 17 Sep 2004 07:22:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49CC1.CC97FB30" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C49CC1.CC97FB30 Content-Type: text/plain; charset="utf-8" Given the cacophony of verbiage you guys are throwing up I am not replying to individual emails point be point, instead I am following the repeated directions of the chair and I am collecting my points into one post. I am not going to use a different email client to post to this list, the references field is NOT mandatory. And a RIM device is in any case not going to support anything other than top posting. And in any case RFC 2822 is NOT an IETF standard while RFC 822 is. I have a standards compliant email client, folk who demand support for Draft standards will be ignored. When I said I agreed with the position raised by Andy that is exactly what I meant. And yes we are re-opening discussions that were previously closed. That is a consequence of having train wreck. I find it very difficult to see at this point any area in which the work in the group has improved the specifications over the input documents. We seem to have even less consensus and industry support than we started with. People need to decide who they are working for. Are they trying to build something that will benefit the wider community or are they only interested in developing systems that benefit themseves? There is a reason I use commercial Internet software rather than niche applications for techies, it isn't for my benefit, it is because it is the only way I can understand problems from the perspective of the average user. > -----Original Message----- > From: David Woodhouse [ mailto:dwmw2@infradead.org ] > Sent: Wednesday, September 15, 2004 3:59 AM > To: IETF MARID WG > Subject: Re: co-chair judgment of consensus related to last > call period > of 23-Aug-2004 to 10-Sept-2004 > > > > On Tue, 2004-09-14 at 20:35 -0500, wayne wrote: > > [top quoting fixed, extra words deleted, and the Reference: header > > restored. All due to brain-dead mail software.] > > Thanks for fixing that; it's amazing how poorly people will behave in > public fora. Personally, I configure my mailing lists to > reject any mail > with 'Re:' in the Subject: header but neither References: nor > In-Reply-To: headers. Philip, you really ought to invest in some > non-broken mail software if you want to use it in public. > > > "Hallam-Baker, Phillip" writes: > > > David Woodhouse [ mailto:dwmw2@infradead.org ] wrote: > > >> I strongly disagree with this opinion. I believe that it > does not make > > >> sense to have multiple scopes, and certainly not to plan > to add even > > >> more scopes later. I shall explain my reasoning: > > > > > > I agree with Andy. > > > > No, apparently you agree with David Woodhouse. It is easy to get > > confused when you don't use proper quoting. > > > > > I thought we should have done this all along. > > > > Yes, I know. This was discussed long ago. The rough consensus was > > against your opinion. I thought that while there should be multiple > > scopes, we could have one record that covered them all. The rough > > consensus was against my opinion. > > > > Now, can we *PLEASE* stop re-raising old issues everything > someone new > > comes into this working group? > > Maybe I have indeed missed the discussion on this precise topic, but I > suspect you might both have missed my point -- and in either case I > apologise. Philip might be used to upside-down email and have thought > that my first paragraph was in fact my conclusion, but I didn't expect > that of you so it's probably my fault for not being concise enough in > the first place. > > I was not saying that we should ditch either pra or mail-from > scope and > continue with only one or the two, which I know is an opinion > which has > been voiced before. > > I was saying that we should ditch _both_ pra and mail-from scopes and > continue with something more appropriate. > > The point was that the mail-from and pra scopes are _both_ only useful > for determining a trust level for a given mail server, by determining > whom it belongs to. The 'domain' we use becomes nothing more than an > arbitrary 'trust handle' which isn't even seen by most users > anyway, as > it's hidden in the Return-Path: or > Resent-From:^WForwarded-For: headers. > > The mailfrom/pra scopes are not useful as end-to-end validation that a > given mail really did come from the person from whom it > claims to come. > A mailfrom/pra 'PASS' is neither necessary nor sufficient to make that > judgement reliably. There are both false positives and false negatives > if one were to inadvisedly use it for such a purpose. > > Yet the very nature of the scopes makes it easy for the naïve user or > admin to believe that they can be used that way. Therefore, it is > actually counterproductive -- because it encourages a mistaken belief > that this provides real end-to-end authentication when it cannot. > > My suggestion is that we should go forward with an entirely > _different_ > scope, not just unify on either mail-from or whatever the unencumbered > pra replacement would be. > > There are many possibilities which would offer us some 'handle' on the > owner of the mail server in question, without all the problems which > both mail-from and pra scopes suffer. > > -- > dwmw2 > > ------_=_NextPart_001_01C49CC1.CC97FB30 Content-Type: text/html; charset="utf-8"

Given the cacophony of verbiage you guys are throwing up I am not replying to individual emails point be point, instead I am following the repeated directions of the chair and I am collecting my points into one post.

I am not going to use a different email client to post to this list, the references field is NOT mandatory. And a RIM device is in any case not going to support anything other than top posting. And in any case RFC 2822 is NOT an IETF standard while RFC 822 is. I have a standards compliant email client, folk who demand support for Draft standards will be ignored.


When I said I agreed with the position raised by Andy that is exactly what I meant. And yes we are re-opening discussions that were previously closed. That is a consequence of having train wreck.
 
I find it very difficult to see at this point any area in which the work in the group has improved the specifications over the input documents. We seem to have even less consensus and industry support than we started with.
 
People need to decide who they are working for. Are they trying to build something that will benefit the wider community or are they only interested in developing systems that benefit themseves? There is a reason I use commercial Internet software rather than niche applications for techies, it isn't for my benefit, it is because it is the only way I can understand problems from the perspective of the average user.
 
 


> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Wednesday, September 15, 2004 3:59 AM
> To: IETF MARID WG
> Subject: Re: co-chair judgment of consensus related to last
> call period
> of 23-Aug-2004 to 10-Sept-2004
>
>
>
> On Tue, 2004-09-14 at 20:35 -0500, wayne wrote:
> > [top quoting fixed, extra words deleted, and the Reference: header
> > restored.  All due to brain-dead mail software.]
>
> Thanks for fixing that; it's amazing how poorly people will behave in
> public fora. Personally, I configure my mailing lists to
> reject any mail
> with 'Re:' in the Subject: header but neither References: nor
> In-Reply-To: headers. Philip, you really ought to invest in some
> non-broken mail software if you want to use it in public.
>
> > "Hallam-Baker, Phillip" <pbaker@verisign.com> writes:
> > > David Woodhouse [mailto:dwmw2@infradead.org] wrote:
> > >> I strongly disagree with this opinion. I believe that it
> does not make
> > >> sense to have multiple scopes, and certainly not to plan
> to add even
> > >> more scopes later. I shall explain my reasoning:
> > >
> > > I agree with Andy.
> >
> > No, apparently you agree with David Woodhouse.  It is easy to get
> > confused when you don't use proper quoting.
> >
> > > I thought we should have done this all along.
> >
> > Yes, I know.  This was discussed long ago.  The rough consensus was
> > against your opinion.  I thought that while there should be multiple
> > scopes, we could have one record that covered them all.  The rough
> > consensus was against my opinion.
> >
> > Now, can we *PLEASE* stop re-raising old issues everything
> someone new
> > comes into this working group?
>
> Maybe I have indeed missed the discussion on this precise topic, but I
> suspect you might both have missed my point -- and in either case I
> apologise. Philip might be used to upside-down email and have thought
> that my first paragraph was in fact my conclusion, but I didn't expect
> that of you so it's probably my fault for not being concise enough in
> the first place.
>
> I was not saying that we should ditch either pra or mail-from
> scope and
> continue with only one or the two, which I know is an opinion
> which has
> been voiced before.
>
> I was saying that we should ditch _both_ pra and mail-from scopes and
> continue with something more appropriate.
>
> The point was that the mail-from and pra scopes are _both_ only useful
> for determining a trust level for a given mail server, by determining
> whom it belongs to. The 'domain' we use becomes nothing more than an
> arbitrary 'trust handle' which isn't even seen by most users
> anyway, as
> it's hidden in the Return-Path: or
> Resent-From:^WForwarded-For: headers.
>
> The mailfrom/pra scopes are not useful as end-to-end validation that a
> given mail really did come from the person from whom it
> claims to come.
> A mailfrom/pra 'PASS' is neither necessary nor sufficient to make that
> judgement reliably. There are both false positives and false negatives
> if one were to inadvisedly use it for such a purpose.
>
> Yet the very nature of the scopes makes it easy for the naïve user or
> admin to believe that they can be used that way. Therefore, it is
> actually counterproductive -- because it encourages a mistaken belief
> that this provides real end-to-end authentication when it cannot.
>
> My suggestion is that we should go forward with an entirely
> _different_
> scope, not just unify on either mail-from or whatever the unencumbered
> pra replacement would be.
>
> There are many possibilities which would offer us some 'handle' on the
> owner of the mail server in question, without all the problems which
> both mail-from and pra scopes suffer.
>
> --
> dwmw2
>
>
------_=_NextPart_001_01C49CC1.CC97FB30-- From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 11:29: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 LAA12669 for ; Fri, 17 Sep 2004 11:29: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 i8HErDuf074982; Fri, 17 Sep 2004 07:53:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HErDwd074981; Fri, 17 Sep 2004 07:53:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HErC9v074975 for ; Fri, 17 Sep 2004 07:53:13 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39510) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1C8K6q-0005tH-VQ (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Fri, 17 Sep 2004 15:53:12 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C8K6i-0005dX-0y; Fri, 17 Sep 2004 15:53:04 +0100 Date: Fri, 17 Sep 2004 15:53:04 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040916203242.C800616CD2@mail.nitros9.org> Message-ID: References: <20040916203242.C800616CD2@mail.nitros9.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004, Alan DeKok wrote: > > I'm not sure how any "MAIL FROM" checking can prevent spoofing on a > shared MTA. For a rough outline, see http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/cam.txt In summary: users submit email using SMTP AUTH. They are prevented from using a bounce address that belongs to someone else (which is reasonably easy to do with Exim). Their bounce address is modified according to BATV or a similar scheme; the tag provides a guarantee that the message was submitted by the authenticated user identified in the bounce address. Each time a message is passed through the system for unauthenticated relaying the bounce address is checked: if it's a local address it must be correctly modified according to BATV. Tony. -- f.a.n.finch http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: SOUTHERLY 5 OR 6, DECREASING 4 FOR A TIME, BUT BACKING SOUTHEASTERLY AND INCREASING 6 TO GALE 8 OVERNIGHT. RAIN LATER. GOOD BECOMING MODERATE. MODERATE OR ROUGH, OCCASIONALLY SLIGHT IN THE MORAY FIRTH. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 11:47: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 LAA13766 for ; Fri, 17 Sep 2004 11:47: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 i8HFGZUb076537; Fri, 17 Sep 2004 08:16: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 i8HFGZIt076536; Fri, 17 Sep 2004 08:16:35 -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 i8HFGY6f076530 for ; Fri, 17 Sep 2004 08:16:34 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 6B35126C091; Fri, 17 Sep 2004 17:16:36 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 3726726C084; Fri, 17 Sep 2004 17:16: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 i8HFGZ8q624277; Fri, 17 Sep 2004 17:16:35 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 0E730FACE; Fri, 17 Sep 2004 17:16:35 +0200 (CEST) Date: Fri, 17 Sep 2004 17:16:35 +0200 From: Stephane Bortzmeyer To: "Hallam-Baker, Phillip" Cc: "'David Woodhouse'" , IETF MARID WG Subject: Re: Moving on from the train wreck Message-ID: <20040917151635.GA3361@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 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 Fri, Sep 17, 2004 at 07:22:44AM -0700, Hallam-Baker, Phillip wrote a message of 233 lines which said: > We seem to have even less consensus and industry support than we > started with. It is often the case in working groups. Sometimes, problems are more complicated than they seem at the first glance and work done in common help to push asides half-baked ideas. Hardly a failure. [Below this point, we are off-topic.] > There is a reason I use commercial Internet software rather than > niche applications for techies, it isn't for my benefit, it is > because it is the only way I can understand problems from the > perspective of the average user. Walk two or three miles to get water, instead of turning the tap, and you will understand problems from the perspective of the average African woman. Interesting idea. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 12:02:17 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 MAA15312 for ; Fri, 17 Sep 2004 12:02: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 i8HFU0Fm077381; Fri, 17 Sep 2004 08:30:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HFU0cO077380; Fri, 17 Sep 2004 08:30:00 -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 i8HFTxvw077374 for ; Fri, 17 Sep 2004 08:29:59 -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 i8HFU0Xu005419; Fri, 17 Sep 2004 08:30:00 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Sep 2004 08:30:00 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'william(at)elan.net'" , Andrew Newton Cc: spf-discuss@v2.listbox.com, IETF MARID List Subject: RE: Microsoft's Updated Statement about IPR Claimed in and in Combination Date: Fri, 17 Sep 2004 08:29:55 -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: william(at)elan.net [mailto:william@elan.net] > P.S. For the authors of this patent reading the list, I'll > note that I > found it funny that patent mentions taking first address of the From > header. The RFC2822 is very clear that if From header is group of > addresses, then Sender header MUST be present and that is where info > is to be looked at (if its not, one can probably discard the message > as not RFC compliant). I simply did not expect such a stupid > mistake as > far as email standars are concerned to be part of the patent text. The email system in use has never been fully RFC compliant. RFC 2822 was an attempt to rectify that problem, twenty years after the fact. If you are writing a patent you are well advised to make claims with respect to both theory and practice. Specifications only become standards if the authors can persuade people to implement and deploy. There is no automatic right that this group or any other has to have the advice it gives to the Internet community acted upon. Nobody ever elected us to make decisions on their behalf. We are not accountable to the Internet community. Those who do not accept accountability cannot hold others accountable. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 12:58: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 MAA20152 for ; Fri, 17 Sep 2004 12:58: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 i8HG1acl080042; Fri, 17 Sep 2004 09:01:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HG1akp080041; Fri, 17 Sep 2004 09:01:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HG1ai1080033 for ; Fri, 17 Sep 2004 09:01:36 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Existing implementation of SPF1 for Exchange 2000? X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 17 Sep 2004 11:01:36 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> Thread-Topic: Existing implementation of SPF1 for Exchange 2000? Thread-Index: AcScz729cT/Bn/p9Tnab7PczpofU3A== From: "Gordon Fecyk" To: "IETF MXCOMP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8HG1ai1080035 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I know Meng and crew went nuts developing a stack of libraries to support SPF v1 (yes v1, the same thing that AOL's using to check incoming mail). I'd like to know if someone's developed an event sink for Exchange 2000 or 2003 yet among that stack. I refer to event sinks because these seem to be the favoured way to act on SMTP events on Exchange 2K. You can trigger an event during a RFC 2821 conversaion or after the message is received, and in the case of receiving after the fact it can trigger a VBS script. A really clever add-on could even automatically insert records into the DNS through dynamic update when the Exchange server starts. What would really impress me further is a replacement routing DLL for Exchange 5.5. And no, I don't have the time to code all this, not anymore anyway. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 13:20: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 NAA21670 for ; Fri, 17 Sep 2004 13:19: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 i8HGGM9u081215; Fri, 17 Sep 2004 09:16:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HGGM3u081214; Fri, 17 Sep 2004 09:16:22 -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 i8HGGLHh081207 for ; Fri, 17 Sep 2004 09:16:21 -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 i8HGSctU016399; Fri, 17 Sep 2004 09:28:38 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8HGSbhZ016394; Fri, 17 Sep 2004 09:28:37 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 17 Sep 2004 09:28:37 -0700 (PDT) From: "william(at)elan.net" To: "Hallam-Baker, Phillip" cc: IETF MARID List Subject: RE: Microsoft's Updated Statement about IPR Claimed in and in Combination 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, 17 Sep 2004, Hallam-Baker, Phillip wrote in : >The email system in use has never been fully RFC compliant.RFC 2822 was >an attempt to rectify that problem, twenty years after the fact. I agree with above, but I note that it seems to contradict same author's earlier statement (below). Either we truly agrees that supporting RFC2822 (no matter if its "proposed" or "draft" statement right now) is important towards fixing problems with email non-comliance or we continue to be in the 80s world with positions like this: On Fri, 17 Sep 2004, Hallam-Baker, Phillip wrote in : >I am not going to use a different email client to post to this list, the >references field is NOT mandatory. And a RIM device is in any case not >going to support anything other than top posting. And in any case RFC >2822 is NOT an IETF standard while RFC 822 is. I have a standards >compliant email client, folk who demand support for Draft standards >will be ignored. P.S. As a frequent top-poster myself, I note that it is inappropriate to critisize this practice simply because one does not use it. The practice is not against any standards and as frequent readers of the email list are expected to have already read message being replied to they cat actually benefit from not having to scroll through bunch of ">>>" first. Top-posting also allows to designate when you're replying to entire email as opposed to when replying to specific parts of the email in which case buttom-posting is more favorable to clearly designate the part being replied to. Both conventions have their own use in email world. --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 13:39:04 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 NAA22767 for ; Fri, 17 Sep 2004 13:39:04 -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 i8HGukYo084089; Fri, 17 Sep 2004 09:56: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 i8HGukY5084088; Fri, 17 Sep 2004 09:56:46 -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 i8HGuf3a084061 for ; Fri, 17 Sep 2004 09:56:45 -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 528A516CD2 for ; Fri, 17 Sep 2004 13:06:01 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Fri, 17 Sep 2004 15:53:04 BST." Date: Fri, 17 Sep 2004 13:06:01 -0400 Message-Id: <20040917170601.528A516CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tony Finch wrote: > On Thu, 16 Sep 2004, Alan DeKok wrote: > > > > I'm not sure how any "MAIL FROM" checking can prevent spoofing on a > > shared MTA. > > For a rough outline, see http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/cam.txt Quoting that sentence out of context, I can understand your response. Your system describes a method for a shared MTA to guarantee that any message it forwards is truly from the claimed originator. That's nice, but not useful to anyone else in the network. My repeated, and explicit, comments in this thread have described the problems faced by the recipient who is sent the message from the shared MTA. That recipient has no way to verify that the message is not spoofed by another domain using the shared MTA. Any method which permits the recipient to verify the "MAIL FROM" must involve the originator. The shared MTA can claim that it is forwarding the message, but because it is not the originator, it cannot authenticate the message as truly coming from the originator. The shared MTA can use special/local information in order to authenticate to it's own satisfaction the "true" origin of the message. That information is not available to others in the network, so they cannot perform the same authentication to satisfy themselves as to the true origin of the message. And they cannot take the word of the shared MTA, as it may be compromised. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 13:58:50 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 NAA24021 for ; Fri, 17 Sep 2004 13:58:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HHMaK5086171; Fri, 17 Sep 2004 10:22:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HHMaG1086170; Fri, 17 Sep 2004 10:22:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HHMZVY086160 for ; Fri, 17 Sep 2004 10:22:36 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id BC8D1132CD1; Fri, 17 Sep 2004 13:22:37 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 64EF45C7; Fri, 17 Sep 2004 13:22:38 -0400 (EDT) Date: Fri, 17 Sep 2004 13:22:38 -0400 From: Meng Weng Wong To: David Woodhouse Cc: IETF MARID WG Subject: migration strategy for "-all" Message-ID: <20040917172238.GL23667@dumbo.pobox.com> References: <1095435974.17821.348.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095435974.17821.348.camel@hades.cambridge.redhat.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 17, 2004 at 04:46:14PM +0100, David Woodhouse wrote: | | 1. The use of '-all' on domains which do actually send mail should be | forbidden in both mailfrom and pra scopes, until a later date when it is | decided that enough of the world has upgraded to cope with this. | isn't that why the standards track is a standards track and not a standards point? if we expect it will take 1 to 3 years for the world to upgrade, maybe we can take 1 to 3 years to move from proposed standard to draft standard to standard. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 14:02:51 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 OAA24264 for ; Fri, 17 Sep 2004 14:02:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HHbaNI087523; Fri, 17 Sep 2004 10:37:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HHbaBF087522; Fri, 17 Sep 2004 10:37:36 -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 i8HHbZSh087515 for ; Fri, 17 Sep 2004 10:37: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 54ECF414C4; Fri, 17 Sep 2004 10:37:39 -0700 (PDT) Subject: Re: Patent Application 683624 From: Douglas Otis To: "william(at)elan.net" Cc: IETF MARID List In-Reply-To: References: Content-Type: text/plain Message-Id: <1095442659.30902.314.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 10:37:39 -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-09-16 at 23:41, william(at)elan.net wrote: > On Thu, 16 Sep 2004, Douglas Otis wrote: > > > From their presentation, the concept was to impose about a 16 second > > additional CPU message burden for the sender. Their statement was such > > additional overhead doubled the cost of equipment for the sender. This > > does not consider that many abusive senders control millions of Window > > machines with hidden Trojan proxies and never pay for their use. > > And besides, the CPU costs are rapidly going down with twice as fast CPUs > being released every one or two years. You simply can't rely on this > technique - the hardware cost even for spammer that does not use zombie > machines is likely to be low percentage for cost of his operation - its > the cost of hosting of such machine on "spam tolerant" network that is high. Increased overhead burdens legitimate mail disproportionately more than it does for illegitimate senders. Higher overhead moves toward a system that does not achieve the needed scale and that becomes more fragile or prone. > > It does bring up the issue of cost for a maximal 200 second receiver > > burden for resolving Sender-ID or SPF records. With a common spammer > > technique of using random sub-domains, this will keep filters guessing > > and the DNS resolvers scrambling for records. > > I note that the same problem exists with absolutely every proposal before > MARID. And in reality its not really proper concern for this group, we > need to worry how to properly identify GOOD senders and how to make sure > THEIR domains are not forged. The focus should be centered upon establishing a basis for accountability with low overhead (i.e. CSV). The marid-mpr draft was to show once a reasonably strong name or identity is established, to then include mailbox domain constraints only requires a name list. There is then no need for "includes", "redirects" or various other subsequent record lookups. Your point is on point, however. > That spammers can still buy new domains for almost nothing ($6) or use > subdomains which are technically free to them and then publish MARID > records there is outside the scope of this group - it is something to be > addressed by reputation. You are right, obtaining a new domain becomes just another cost of doing business for the spammer. I see some sites, in efforts to bypass filters, pickup several domains a day. > > It would seemi illegitimate senders win in any war of escalated > > overheads. If only these innovators would properly handle a temp error, > > we could slow unknown senders without punishing legitimate senders. ; ) > > I did not understand how handling temp error would help. Can you explain > or give example? Although a good list may be relatively complete, there will always be new users and legitimate domains that will need to enter the system. Rather than tar-pitting, a friendlier method may be to cap these obscure domains until there is a history established. Capping could be done by issuing a temp error. There will still need to be a clearing house to note the good domains that have "gone bad" and perhaps help identity the new domains from the older well behaved. Microsoft innovations have overlooked some basic elements to grapple with the spam problem. Forwarding the message should include all headers to make submitting a complaint something an average user would be able to do. Handling of temp errors should cause a sizable delay before the delivery is retried. Some sites require the use of DoS blocking techniques to handle poor behavior. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 14:05:57 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 OAA24471 for ; Fri, 17 Sep 2004 14:05: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 i8HHdiUo087717; Fri, 17 Sep 2004 10:39: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 i8HHdiE0087716; Fri, 17 Sep 2004 10:39:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HHdivr087710 for ; Fri, 17 Sep 2004 10:39:44 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40377) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1C8Mi1-0003ML-63 (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Fri, 17 Sep 2004 18:39:45 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C8Mhw-0008EU-I9; Fri, 17 Sep 2004 18:39:40 +0100 Date: Fri, 17 Sep 2004 18:39:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: <20040917170601.528A516CD2@mail.nitros9.org> Message-ID: References: <20040917170601.528A516CD2@mail.nitros9.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004, Alan DeKok wrote: > > Your system describes a method for a shared MTA to guarantee that > any message it forwards is truly from the claimed originator. That's > nice, but not useful to anyone else in the network. My setup's a bit odd in that the MX, MSA, and general-purpose relay are different functions of the same system. This means care is required when thinking about the various functions. Although you can set up BATV on an outgoing relay in the manner that you rightly criticise, if you set it up on an authenticated MSA and the corresponding MDA you do get the guarantees that you want. > Any method which permits the recipient to verify the "MAIL FROM" > must involve the originator. Agreed. > The shared MTA can claim that it is forwarding the message, but because > it is not the originator, it cannot authenticate the message as truly > coming from the originator. In my case I can because the shared MTA is also the MSA and the final delivery system for the domain in question. It is therefore authoritative regarding which addresses are valid at that domain. If a message is submitted other than via the MSA, or without a username and password corresponding to the bounce address, it'll be rejected. > That information is not available to others in the network, so they > cannot perform the same authentication to satisfy themselves as to the > true origin of the message. At the moment you can use callback verification to acheive this. We hope to have more lightweight alternatives in the future. Note that if intermediate MTA relays do CBV then the MSA/MDA for the domain don't have to be directly accessible to the Internet: CBV is transitive. > And they cannot take the word of the shared MTA, as it may be > compromised. At that point you have to rely on reputation systems. Authentication is not the whole of the solution. A domain with poor authentication is a spammer-friendly domain. Tony. -- f.a.n.finch http://dotat.at/ COLWYN BAY TO THE MULL OF GALLOWAY INCLUDING THE ISLE OF MAN: SOUTH OR SOUTHWEST 4 OR 5, INCREASING 6 TO GALE 8 FOR A TIME, VEERING WEST 5 OR 6 LATER. RAIN THEN SHOWERS. MODERATE OR GOOD, PERHAPS POOR FOR A TIME. ROUGH. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 14:17:36 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 OAA25370 for ; Fri, 17 Sep 2004 14:17: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 i8HHjpRH088400; Fri, 17 Sep 2004 10:45: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 i8HHjpWp088399; Fri, 17 Sep 2004 10:45:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HHjnsY088387 for ; Fri, 17 Sep 2004 10:45:50 -0700 (PDT) (envelope-from pk@TechFak.Uni-Bielefeld.DE) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i8HHjjSd012831 for ; Fri, 17 Sep 2004 19:45:46 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i8HHjjl01524 for ; Fri, 17 Sep 2004 19:45:45 +0200 (MEST) Message-Id: <200409171745.i8HHjjl01524@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: "IETF MARID WG" Subject: Re: co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004 In-reply-to: Your message of "Mon, 13 Sep 2004 22:28:28 CDT." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1520.1095443144.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Fri, 17 Sep 2004 19:45:45 +0200 From: Peter Koch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: {apologies for the delay} > For example, you say that 2% of TXT records are used for SPF. This > may well be true, but at the spot in the domain hierarchy where SPF > records are likely to be checked (the email domain names), I found 19% email domain names as in '2nd level domain names' or 'owners of MX RRs'? There's still some hierarchy in the DNS and as an example I found a single zone with nearly 300 SPF RRs "v=spf1 -all" without an MX RR at the same owner. > Can you give me a pointer to this survey that you are referring to? It's based on the raw data collected during the RIPE DNS hostcount for the DE toplevel domain. > Can you explain the differences between the 2% you quote and the 36% I > found? The hostcount works by examining every zone at every level it can get hold of. Let's take further discussion of the survey mechanics off list, please. My point was that neither are TXT RRs mostly used for SPF nor is the deployment broad enough to give a pressing need to stick with TXT RRs. Dealing with transition in the spec is OK, but that should be done in an appendix or an informational document. -Peter From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 14:57: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 OAA27561 for ; Fri, 17 Sep 2004 14:57: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 i8HIOHpk091750; Fri, 17 Sep 2004 11:24:17 -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 i8HIOHAv091749; Fri, 17 Sep 2004 11:24:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.duncanthrax.net (root@foobar.duncanthrax.net [217.115.139.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HIOG5j091729 for ; Fri, 17 Sep 2004 11:24:16 -0700 (PDT) (envelope-from tom@duncanthrax.net) Received: from p5480fcee.dip.t-dialin.net ([84.128.252.238] helo=[192.168.0.195]) by mail.duncanthrax.net with asmtp (Exim 4.41) id 1C8NOz-0002UL-QJ; Fri, 17 Sep 2004 20:24:10 +0200 Message-ID: <414B2BCB.2050509@duncanthrax.net> Date: Fri, 17 Sep 2004 20:24:11 +0200 From: Tom Kistner User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'David Woodhouse'" , IETF MARID WG Subject: Re: Moving on from the train wreck References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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 Hallam-Baker, Phillip wrote: > I am not going to use a different email client to post to this list, the > references field is NOT mandatory. And a RIM device is in any case not > going to support anything other than top posting. And in any case RFC > 2822 is NOT an IETF standard while RFC 822 is. I have a standards > compliant email client, folk who demand support for Draft standards will > be *ignored*. As some folks will ignore you after your public outing as an antisocial. This does not exactly bolster your credibility as a contributor to this group. Somehow this fits in very well with the behaviour of your current employer. > I find it very difficult to see at this point any area in which the work > in the group has improved the specifications over the input documents. > We seem to have even less consensus and industry support than we started > with. > > People need to decide who they are working for. Are they trying to build > something that will benefit the wider community or are they only > interested in developing systems that benefit themseves? There is a > reason I use commercial Internet software rather than niche applications > for techies, it isn't for my benefit, it is because it is the only way I > can understand problems from the perspective of the average user. So you imply that the industry is representing the largest part of the community. Corporations represent their shareholders, not their customers. This is why Microsoft is not willing to give up on its patent claim, even if it would also benefit their users to do so. regards, /tom From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 14:57: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 OAA27635 for ; Fri, 17 Sep 2004 14:57:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HIT3Bl092096; Fri, 17 Sep 2004 11:29:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HIT3jx092095; Fri, 17 Sep 2004 11:29:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HISoec092063 for ; Fri, 17 Sep 2004 11:29:03 -0700 (PDT) (envelope-from SRS0+4accd74db7714a56ae55+390+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8NTU-0004je-Ai; Fri, 17 Sep 2004 19:28:49 +0100 Subject: Re: migration strategy for "-all" From: David Woodhouse To: Meng Weng Wong Cc: IETF MARID WG In-Reply-To: <20040917172238.GL23667@dumbo.pobox.com> References: <1095435974.17821.348.camel@hades.cambridge.redhat.com> <20040917172238.GL23667@dumbo.pobox.com> Content-Type: text/plain; charset=UTF-8 Message-Id: <1095445727.17821.463.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 17 Sep 2004 19:28:47 +0100 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 2004-09-17 at 13:22 -0400, Meng Weng Wong wrote: > isn't that why the standards track is a standards track and > not a standards point? > > if we expect it will take 1 to 3 years for the world to > upgrade, maybe we can take 1 to 3 years to move from > proposed standard to draft standard to standard. An excellent idea. Then shall we settle upon the following: While SRS is not officially documented or is merely a proposed standard, the language should be that you 'MUST NOT' publish a record ending in '-all' for a domain which does actually send mail.¹ When SRS becomes part of a draft standard _and_ is widely implemented, that can be relaxed to 'SHOULD NOT'. Finally when SRS becomes part of a real standard, the restriction can be relaxed entirely. That's my preference -- to save unnecessary amounts of email being traded back and forth, let me save time and draw up a table of what I'll admit up-front that I'll reluctantly fall back to under pressure :) SRS status Preference Acceptable -------------------------------------------- I-D or less MUST NOT MUST NOT RFC MUST NOT SHOULD NOT Proposed Std. MUST NOT SHOULD NOT Draft Std. MUST NOT SHOULD NOT Draft++ SHOULD NOT MAY Standard. MAY MAY Note the 'Draft++' state indicates a state where SRS is both a Draft Standard and _also_ is found to have widespread implementation. Also note that the same set of requirements is appropriate for PRA w.r.t. the addition of whatever replaces the Resent-From: header. However -- unless I'm mistaken, the MARID drafts don't actually document SRS, while they do document the requirement to add a header when forwarding. So the language in the marid-pra draft would be tied to its _own_ progression through the standards-track, while the language in the marid-mailfrom draft would be tied to the progress of something else which does not yet exist. While that's unfixed, we remain on the first line of my table above. I consider the lack of documentation of SRS (or indeed of any other mechanism which must be implemented to correct the flawed assumptions of the original SPF) to be a serious technical omission in the current marid-mailfrom draft. The PRA folks have documented the required fix for _their_ flawed assumptions, and once the choice of header is fixed it's not so onerous, so it stands a reasonable chance of getting deployed and hence fixing their assumptions. The mailfrom folks desperately need to catch up. -- dwmw2 ¹ I'd also accept qualifying this with "unless the previous mechanisms do not depend on the deployment of SRS". For example, if I were using a stunt DNS server in conjunction with the 'exists' mechanism and my existing BATV implementation, or if I were using marid-mailfrom simply to publish a list of 'acceptable' localparts for my domain without any IP-based restrictions, then the use of '-all' would make sense even today. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 15:51:17 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 PAA02120 for ; Fri, 17 Sep 2004 15:51:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HJLMvW096305; Fri, 17 Sep 2004 12:21:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HJLMH3096304; Fri, 17 Sep 2004 12:21:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HJLLUf096295 for ; Fri, 17 Sep 2004 12:21:21 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1C8OIO-000JK1-00 for ietf-mxcomp@imc.org; Fri, 17 Sep 2004 20:21:24 +0100 Message-ID: <024b01c49ceb$281f6410$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <20040917170601.528A516CD2@mail.nitros9.org> Subject: Re: SPF abused by spammers Date: Fri, 17 Sep 2004 20:18:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "Alan DeKok" declared: > > My repeated, and explicit, comments in this thread have described > the problems faced by the recipient who is sent the message from the > shared MTA. That recipient has no way to verify that the message is > not spoofed by another domain using the shared MTA. > > Any method which permits the recipient to verify the "MAIL FROM" > must involve the originator. The shared MTA can claim that it is > forwarding the message, but because it is not the originator, it > cannot authenticate the message as truly coming from the originator. > > The shared MTA can use special/local information in order to > authenticate to it's own satisfaction the "true" origin of the > message. That information is not available to others in the network, > so they cannot perform the same authentication to satisfy themselves > as to the true origin of the message. And they cannot take the word > of the shared MTA, as it may be compromised. > My understanding is that SPF records declare the policy of the _sender_. If the sender trusts the shared MTA to verify all originators and to prevent cross-customer spoofing, then the sender can use something like '+mx -all' and the receiver should respect the sender's trust in the shared MTA s/he uses. If the sender does not trust the shared MTA, the s/he will be ill-advised to publish such a self-confident policy. If the sender's trust in the shared MTA is misplaced, IMHO that's an issue for the sender, not for the receiver. I think the more pressing issue in this area is a deployment one: How many MTA 'products' are there today which would let a well-intentioned MTA service provider implement and operate such a shared MTA? How many service operators have now, or have plans for, such a service? When this question was asked recently asked in 'another place' - one very interested in SPF - there were two declarations of intent to offer what I would term an 'alpha-grade' service in a few weeks time. No one could identify any production-grade services or technology. I'd be delighted to see evidence to the contrary. This lack of a suitable shared-server technology could limit the rate of market deployment of whatever scheme we chose - particularly for those many domains unable / unwilling to run their own dedicated outbound servers. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 16:27: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 QAA05367 for ; Fri, 17 Sep 2004 16:27: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 i8HK2DA3000302; Fri, 17 Sep 2004 13:02:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HK2DFJ000301; Fri, 17 Sep 2004 13:02:13 -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 i8HK2Cct000295 for ; Fri, 17 Sep 2004 13:02:13 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i8HK2CMM023971; Fri, 17 Sep 2004 13:02:12 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Sep 2004 13:02:12 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Douglas Otis'" , "william(at)elan.net" Cc: IETF MARID List Subject: RE: Patent Application 683624 Date: Fri, 17 Sep 2004 13:02:07 -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: The computational puzzles approach is outside the scope of this wg, so why are we having a prolonged discussion of it here as opposed to ASRG? > -----Original Message----- > From: Douglas Otis [mailto:dotis@mail-abuse.org] > Sent: Friday, September 17, 2004 1:38 PM > To: william(at)elan.net > Cc: IETF MARID List > Subject: Re: Patent Application 683624 > > > > On Thu, 2004-09-16 at 23:41, william(at)elan.net wrote: > > On Thu, 16 Sep 2004, Douglas Otis wrote: > > > > > From their presentation, the concept was to impose about > a 16 second > > > additional CPU message burden for the sender. Their > statement was such > > > additional overhead doubled the cost of equipment for the > sender. This > > > does not consider that many abusive senders control > millions of Window > > > machines with hidden Trojan proxies and never pay for their use. > > > > And besides, the CPU costs are rapidly going down with > twice as fast CPUs > > being released every one or two years. You simply can't > rely on this > > technique - the hardware cost even for spammer that does > not use zombie > > machines is likely to be low percentage for cost of his > operation - its > > the cost of hosting of such machine on "spam tolerant" > network that is high. > > Increased overhead burdens legitimate mail disproportionately > more than > it does for illegitimate senders. Higher overhead moves > toward a system > that does not achieve the needed scale and that becomes more > fragile or > prone. > > > > It does bring up the issue of cost for a maximal 200 > second receiver > > > burden for resolving Sender-ID or SPF records. With a > common spammer > > > technique of using random sub-domains, this will keep > filters guessing > > > and the DNS resolvers scrambling for records. > > > > I note that the same problem exists with absolutely every > proposal before > > MARID. And in reality its not really proper concern for > this group, we > > need to worry how to properly identify GOOD senders and how > to make sure > > THEIR domains are not forged. > > The focus should be centered upon establishing a basis for > accountability with low overhead (i.e. CSV). The marid-mpr > draft was to > show once a reasonably strong name or identity is established, to then > include mailbox domain constraints only requires a name list. > There is > then no need for "includes", "redirects" or various other subsequent > record lookups. Your point is on point, however. > > > That spammers can still buy new domains for almost nothing > ($6) or use > > subdomains which are technically free to them and then > publish MARID > > records there is outside the scope of this group - it is > something to be > > addressed by reputation. > > You are right, obtaining a new domain becomes just another > cost of doing > business for the spammer. I see some sites, in efforts to bypass > filters, pickup several domains a day. > > > > It would seemi illegitimate senders win in any war of escalated > > > overheads. If only these innovators would properly > handle a temp error, > > > we could slow unknown senders without punishing > legitimate senders. ; ) > > > > I did not understand how handling temp error would help. > Can you explain > > or give example? > > Although a good list may be relatively complete, there will always be > new users and legitimate domains that will need to enter the system. > Rather than tar-pitting, a friendlier method may be to cap > these obscure > domains until there is a history established. Capping could > be done by > issuing a temp error. There will still need to be a clearing house to > note the good domains that have "gone bad" and perhaps help > identity the > new domains from the older well behaved. > > Microsoft innovations have overlooked some basic elements to grapple > with the spam problem. Forwarding the message should include all > headers to make submitting a complaint something an average user would > be able to do. Handling of temp errors should cause a sizable delay > before the delivery is retried. Some sites require the use of DoS > blocking techniques to handle poor behavior. > > -Doug > From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 17:08: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 RAA09863 for ; Fri, 17 Sep 2004 17:08: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 i8HKj7um005038; Fri, 17 Sep 2004 13:45: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 i8HKj719005037; Fri, 17 Sep 2004 13:45:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKj4hL005022 for ; Fri, 17 Sep 2004 13:45:07 -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 DFA2116CD2 for ; Fri, 17 Sep 2004 16:54:30 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Fri, 17 Sep 2004 20:18:45 BST." <024b01c49ceb$281f6410$0200000a@ringo> Date: Fri, 17 Sep 2004 16:54:30 -0400 Message-Id: <20040917205430.DFA2116CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Chris Haynes" wrote: > My understanding is that SPF records declare the policy of the > _sender_. If the sender trusts the shared MTA to verify all > originators and to prevent cross-customer spoofing, then the sender > can use something like '+mx -all' and the receiver should respect > the sender's trust in the shared MTA s/he uses. In that case, the recipient has checked with the originator, and has information by which to decide whether or not to trust the shared MTA. And yes, "originator trusts the shared MTA" still may mean that "the message may be spoofed". This indicates a weakness in any MAIL FROM authentication. when shared MTA's are used. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 17:14:26 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 RAA10064 for ; Fri, 17 Sep 2004 17:14:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HFkFji078251; Fri, 17 Sep 2004 08:46:15 -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 i8HFkFU6078250; Fri, 17 Sep 2004 08:46:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HFkEuE078242 for ; Fri, 17 Sep 2004 08:46:15 -0700 (PDT) (envelope-from SRS0+4accd74db7714a56ae55+390+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8KwB-0004ED-J0; Fri, 17 Sep 2004 16:46:16 +0100 Subject: Re: Moving on from the train wreck From: David Woodhouse To: "Hallam-Baker, Phillip" Cc: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1095435974.17821.348.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 17 Sep 2004 16:46:14 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-09-17 at 07:22 -0700, Hallam-Baker, Phillip wrote: > Given the cacophony of verbiage you guys are throwing up I am not > replying to individual emails point be point, instead I am following > the repeated directions of the chair and I am collecting my points > into one post. I did send a lot of email and for that I have already apologised to the co-chairs after the three message guideline was mentioned to me. Now that I am posting anyway, I offer my apology to the other participants too. I shall limit my posting in future. I made three main technical points which I then argued in support of; none of which you appear to have addressed directly. They were: 1. The use of '-all' on domains which do actually send mail should be forbidden in both mailfrom and pra scopes, until a later date when it is decided that enough of the world has upgraded to cope with this. Others said that this should be a site-specific policy, but we as a group are here to co-ordinate _interoperability_ rather than preside over a system which degenerates into chaos. By publishing RFCs we set up rules which are to be followed to ensure compatibility -- an RFC 'MUST NOT' is a rule which should be followed to ensure interoperability, not a law which we would jail you for disobeying. As a compromise I suppose I would accept Rik van Riel's suggestion of a SHOULD NOT. Others who vehemently opposed my suggestion of 'MUST NOT' were also amenable to that. 2. The reuse of the Resent-From: header is not in accordance with current practice, and not in accordance with many interpretations of RFC2822. Although the latter point has been disputed, the former has not -- and no reason has been put forward for the choice of 'Resent-From:' instead of the introduction of a new and unambiguous header. Therefore I assume that consensus has been reached, and this will be changed in the next draft which describes the pra scope. As a straw man, I propose the use of 'Forwarded-For:' in replacement. 3. The ability of forwarders to use SRS or the Forwarded-For: header to change the 'responsible' domain renders the 'trust question' into simply a matter of how much we trust the (owner of) the individual mail server which is offering the mail. We are _not_ offering true end-to-end authentication of messages, and it would be counterproductive for us to give the illusion of doing so; there are other working groups looking at real answers to that problem. Thus, the odious requirements which are made of forwarders by the mailfrom and pra scopes are unnecessary. We should look for alternative 'trust keys', rather than the domain in the RFC2821 MAIL FROM or RFC2822 headers respectively, which serve merely to identify the entity which is responsible for the server in question. Rand Wacker stated that he is concerned about the current direction, because there hasn't been a lot of technical discussion about the implications of changing the return-paths. With the note that this applies just as much to the pra scope as the mailfrom scope, I agree wholeheartedly with his opinion. The use of SRS and Forwarded-For: to 'take responsibility' for forwarded email seems to have been bolted on as an afterthought, without much thought given to the implications. > I find it very difficult to see at this point any area in which the > work in the group has improved the specifications over the input > documents. We seem to have even less consensus and industry support > than we started with. That in itself is useful information and should be considered deeply. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 17:21:41 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 RAA10544 for ; Fri, 17 Sep 2004 17:21:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKvKxS006607; Fri, 17 Sep 2004 13:57:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HKvK95006606; Fri, 17 Sep 2004 13:57:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKvJXu006599 for ; Fri, 17 Sep 2004 13:57:19 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5) for ; Fri, 17 Sep 2004 15:57:29 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <4148F70E.2F28@xyzzy.claranet.de> <1095097912.3377.11.camel@tuxtop> References: <4148F70E.2F28@xyzzy.claranet.de> <1095097912.3377.11.camel@tuxtop> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Fri, 17 Sep 2004 15:57:20 -0500 To: From: Pete Resnick Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry for my delay in responding. It's been one of those months. (Maybe one of those quarters. *sigh*). I had a read through the DRUMS archive (boy, was that unpleasant) and some personal mail on the topic. Let me attempt to answer a few things. I don't know if this is going to help: 1. Yes, the reason we called out "forwarding" as distinct from use of the Resent-* fields was in part because 822 (and a good number of people for many years) conflated "forwarding" with "redirecting" and "resending" and a host of other labels. So we defined the two senses of forwarding ((a) including a previous message in an entirely new message and (b) relaying from the MTA level) and said that Resent-* fields were not to be used in either case. 2. The use of .forward files is a horrible canonical example of anything. The problem is that .forward files were historically implemented using exactly the same MTA mechanism as alias files used in relaying. In both of those cases, the original MAIL FROM was preserved by the MTA and therefore was clearly not a case of "delivered and then resent." I definitely had some discussion with folks about whether or not Resent-* fields would be desirable in the .forward case and we didn't come to a strong conclusion. 3. The fact of the matter is that historically .forward files did not generate Resent-* and that's part of why we said not to put Resent-* fields on forwarded messages. With all due deference to Jim, you do *not* read IETF standards like a lawyer. IETF standards are, for most intents and purposes, de facto standards: We are documenting what's out there (or what we expect to be out there) so that everyone can do it the same and interoperate well together, and we're trying to be as precise as possible so that programmers can do what they need to do. We're not trying to write laws that people should interpret as best they can. We're trying to write down exactly what everyone is (and should be) doing. Occasionally, we don't do as well as we'd like. 4. I don't think there is anything inconsistent with 2822 in implementing an "automatic resend" function and putting Resent-* fields on those messages. But in that case, I would expect the bounce (MAIL FROM) address to be identical to the Resent-From/Resent-Sender address and that the resender would be able to receive and act on those bounces. Semantically, I see resending as making the *content* of the message appear end-to-end from original sender to resent recipient, but that has nothing to do with making the *transport* of the message appear end-to-end between original sender and resent recipient. MTA-level relaying makes the transport appear end-to-end even though there is this "forwarding" step in the middle, and IMO that shouldn't be using Resent-* fields. My read is that the intent of SenderID is to eliminate all MTA-level relaying and require it to be changed to automatic resending instead. That may be OK, but understand that this is what you are doing. Does that help? -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 18:18:17 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 SAA14631 for ; Fri, 17 Sep 2004 18:18: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 i8HLeOHD009533; Fri, 17 Sep 2004 14:40: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 i8HLeOqO009532; Fri, 17 Sep 2004 14:40:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost4.mail.uk.easynet.net (smarthost4.mail.uk.easynet.net [212.135.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HLeLZS009523 for ; Fri, 17 Sep 2004 14:40:24 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost4.mail.uk.easynet.net with smtp (Exim 4.10) id 1C8QSv-000COP-00 for ietf-mxcomp@imc.org; Fri, 17 Sep 2004 22:40:25 +0100 Message-ID: <02d701c49cfe$93c2a610$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <20040917205430.DFA2116CD2@mail.nitros9.org> Subject: Re: SPF abused by spammers Date: Fri, 17 Sep 2004 22:37:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "Alan DeKok" replied: > > "Chris Haynes" wrote: > > My understanding is that SPF records declare the policy of the > > _sender_. If the sender trusts the shared MTA to verify all > > originators and to prevent cross-customer spoofing, then the sender > > can use something like '+mx -all' and the receiver should respect > > the sender's trust in the shared MTA s/he uses. > > In that case, the recipient has checked with the originator, and has > information by which to decide whether or not to trust the shared MTA. Yes - that's the way SPF works as it uses Mail-From. > > And yes, "originator trusts the shared MTA" still may mean that "the > message may be spoofed". This indicates a weakness in any MAIL FROM > authentication. when shared MTA's are used. > When I say "originator trusts the shared MTA" I mean "trusts the shared MTA to have authenticated and identified the sender of each message (using SMTP AUTH or equivalent), and to have applied whatever logic is needed to prevent spoofing, i.e. to ensure, for every message, that the sender is authorised to use the 'Mail-From' of that message". If the originator's trust in the MTA' s ability to prevent spoofing is well-founded, than the message cannot be spoofed, and Mail-From can be trusted. (barring IP address spoofing, DNS penetration, physical penetration of MTA etc. etc. - which are factors to be listed in the "Security Considerations"). I can't understand the basis of your concern about a "weakness in any MAIL FROM..." . Chris From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 18:57: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 SAA16802 for ; Fri, 17 Sep 2004 18:57:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HMGMBv012584; Fri, 17 Sep 2004 15:16:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HMGMkA012582; Fri, 17 Sep 2004 15:16:22 -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 i8HMGMPn012559 for ; Fri, 17 Sep 2004 15:16:22 -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 2DE61414C4; Fri, 17 Sep 2004 15:16:27 -0700 (PDT) Subject: Re: ANNOUNCE: I-D draft-ietf-marid-SPF3-00, etc. From: Douglas Otis To: Matthew Elvey Cc: MXCOMP In-Reply-To: <414A6EE6.6030801@elvey.com> References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <4147ED67.1040301@elvey.com> <4148CD50.56F0@xyzzy.claranet.de> <414A6EE6.6030801@elvey.com> Content-Type: text/plain Message-Id: <1095459386.30902.430.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 15:16:27 -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-09-16 at 21:58, Matthew Elvey wrote: > Comparison of SPF3 and CSV+MPR: > Of bind, GoDaddy and ZoneEdit, only BIND supports what CSV requires. > Technically, it's inferior, in that its usage of DNS is less efficient > and less standards-based. MPR also has the cool bit-mapped fields for > explicit protection of 2822.From:, etc. This could be added to SPF3. Are you referring to web-based GUI interfaces for DNS entries to support services? Looking at their documentation, it was not clear that it was possible to enter a TXT record either. I would imagine do-it-yourself providers will offer needed interfaces for elements supporting their service once it becomes prevalently needed. CSV is simple enough to have it defined without any user intervention other than selecting the host. It is not clear what was being compared in this sentence. I will assume you were saying CSV is inferior. : ) The SRV record is used extensively by Microsoft and acts as a replacement for their WINS. On some older versions of Bind, the name checking is disabled to allow the underscore. Use of the SRV record does not require a text parser to interpret the record. The SRV record also automatically assembles relevant address records reported in the additional data section. Use of a TXT record which encodes other domains, users, error messages, hostnames, addresses, settings, macros, and is extensible will require a forever evolving parser. With more and more flavors of TXT records employed due to the example made by SPF, as well as adopting a practice of using wildcards, any use of an extensible text script is not without risk. Unlike other DNS records with content defined by the record type, the TXT record should assume opaque text strings. Unlike SPF, names are consistently used and do not require the double entry of host addresses as SPF may. The alternative to replicate address entry when using SPF, is to use record references and then cause subsequent DNS lookups to then obtain the addresses for each reference. SPF is neither more standard or efficient. The MPR name lists also removes the need for subsequent lookups which are the bane of the SPF approach. The MPR lists, being a separate from the MTA authentication and authorization, avoids the problems of "open" lists that invite spoofing. MPR can be deployed with an "open" list as a SHOULD without any exploit concerns. By marking or "coloring" the mail as being outside the nominal mail channel, this should offer better consumer protection than that achieved with Sender-ID's PRA algorithm yet not breaking mail forwarding. > =-=-=-=-= > With respect to being able to outright reject forgeries without breaking > forwarding: > With HELO checks + A&R, I can see this becoming reasonable BCP. Here's how: > Forwarders (and mailing list hosts) will be expected to be running > MARID on their MTA. If they are too lazy to do so, then they will be > found to be forwarding on obvious (to anyone using MARID) forgeries, and > thus their reputations will (justifiably) suffer. It will probably not > be fair to blame 'em for all spam they forward, but it will be fair to > blame them for forwarding on obvious forgeries. The responsible > forwarders running MARID can be expected to have good HELO reputations. Is this in reference to CSV? -Doug From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 19:22:36 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 TAA17689 for ; Fri, 17 Sep 2004 19:22:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HMjArQ014189; Fri, 17 Sep 2004 15:45:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HMjA0Y014188; Fri, 17 Sep 2004 15:45:10 -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 i8HMj9Oq014180 for ; Fri, 17 Sep 2004 15:45: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 i8HMvQv6000812; Fri, 17 Sep 2004 15:57:26 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8HMvQaw000809; Fri, 17 Sep 2004 15:57:26 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 17 Sep 2004 15:57:26 -0700 (PDT) From: "william(at)elan.net" To: Pete Resnick cc: ietf-mxcomp@imc.org Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 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: I'm reading Pete's answer right, then adding Resent-From is ok in some forwarding cases but not in others and that in particular: 1. Its not ok with .forward forwarding (specifically mentioned). This is very very common in the deployed base. 2. Its not ok with any forwarding where RFC2821 Mail From remains the same as it was before forwarding (most of the forwarding systems deployed on the net are like this) 3. Its not ok if message is changed (this would include Mail Lists). If this is correct I see that most of the cases where marid-core recomends adding Resent-From is incompabile with RFC2822. If that is so then SenderID core algorithm has a fundamental technical error and current drafts should not move forward and we should review our situation and look for alternative technologies/algorithms that can meet our requirements. On Fri, 17 Sep 2004, Pete Resnick wrote: > > Sorry for my delay in responding. It's been one of those months. > (Maybe one of those quarters. *sigh*). I had a read through the DRUMS > archive (boy, was that unpleasant) and some personal mail on the > topic. Let me attempt to answer a few things. I don't know if this is > going to help: > > 1. Yes, the reason we called out "forwarding" as distinct from use of > the Resent-* fields was in part because 822 (and a good number of > people for many years) conflated "forwarding" with "redirecting" and > "resending" and a host of other labels. So we defined the two senses > of forwarding ((a) including a previous message in an entirely new > message and (b) relaying from the MTA level) and said that Resent-* > fields were not to be used in either case. > > 2. The use of .forward files is a horrible canonical example of > anything. The problem is that .forward files were historically > implemented using exactly the same MTA mechanism as alias files used > in relaying. In both of those cases, the original MAIL FROM was > preserved by the MTA and therefore was clearly not a case of > "delivered and then resent." I definitely had some discussion with > folks about whether or not Resent-* fields would be desirable in the > .forward case and we didn't come to a strong conclusion. > > 3. The fact of the matter is that historically .forward files did not > generate Resent-* and that's part of why we said not to put Resent-* > fields on forwarded messages. With all due deference to Jim, you do > *not* read IETF standards like a lawyer. IETF standards are, for most > intents and purposes, de facto standards: We are documenting what's > out there (or what we expect to be out there) so that everyone can do > it the same and interoperate well together, and we're trying to be as > precise as possible so that programmers can do what they need to do. > We're not trying to write laws that people should interpret as best > they can. We're trying to write down exactly what everyone is (and > should be) doing. Occasionally, we don't do as well as we'd like. > > 4. I don't think there is anything inconsistent with 2822 in > implementing an "automatic resend" function and putting Resent-* > fields on those messages. But in that case, I would expect the bounce > (MAIL FROM) address to be identical to the Resent-From/Resent-Sender > address and that the resender would be able to receive and act on > those bounces. Semantically, I see resending as making the *content* > of the message appear end-to-end from original sender to resent > recipient, but that has nothing to do with making the *transport* of > the message appear end-to-end between original sender and resent > recipient. MTA-level relaying makes the transport appear end-to-end > even though there is this "forwarding" step in the middle, and IMO > that shouldn't be using Resent-* fields. > > My read is that the intent of SenderID is to eliminate all MTA-level > relaying and require it to be changed to automatic resending instead. > That may be OK, but understand that this is what you are doing. > > Does that help? From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 19:35:50 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 TAA18305 for ; Fri, 17 Sep 2004 19:35:45 -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 i8HNAYkP015754; Fri, 17 Sep 2004 16:10:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HNAYFC015753; Fri, 17 Sep 2004 16:10:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HNAX9u015746 for ; Fri, 17 Sep 2004 16:10:34 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id 7E138132CF8; Fri, 17 Sep 2004 19:10:36 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 5917D5FA; Fri, 17 Sep 2004 19:10:38 -0400 (EDT) Date: Fri, 17 Sep 2004 19:10:38 -0400 From: Meng Weng Wong To: Gordon Fecyk Cc: "IETF MXCOMP (E-mail)" Subject: Re: Existing implementation of SPF1 for Exchange 2000? Message-ID: <20040917231038.GM23667@dumbo.pobox.com> References: <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 17, 2004 at 11:01:36AM -0500, Gordon Fecyk wrote: | | I know Meng and crew went nuts developing a stack of libraries to support SPF | v1 (yes v1, the same thing that AOL's using to check incoming mail). I'd | like to know if someone's developed an event sink for Exchange 2000 or 2003 | yet among that stack. does http://sourceforge.net/projects/spf-event-sink/ count? From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 19:42: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 TAA18496 for ; Fri, 17 Sep 2004 19:42: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 i8HNEKaf016522; Fri, 17 Sep 2004 16:14:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HNEKcA016521; Fri, 17 Sep 2004 16:14:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailserver.corp.mailfrontier.com (blackcomb.mailfrontier.com [209.144.181.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HNEJSX016505 for ; Fri, 17 Sep 2004 16:14:19 -0700 (PDT) (envelope-from nleon@mailfrontier.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: minor comments on draft-ietf-marid-protocol-03.txt Date: Fri, 17 Sep 2004 16:14:18 -0700 Message-ID: <42FE9417C0B0374B9D4234DC867819AC1F0594@mailserver.corp.mailfrontier.com> Thread-Topic: minor comments on draft-ietf-marid-protocol-03.txt Thread-Index: AcScKXiNmTCCFouwSiiGrX0XEXOlkwARSPJQ From: "Nate Leon" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8HNEJSX016515 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit First, thanks to the authors of the docs for all of their hard work! Sorry if this is too picky, but I think RFCs (which is hopefully where we are headed :) should be as close to perfect as possible since they will be around for a long time. And now, on with the nit-picking... Section 1.2 ----------- drop the "a"? use the Sender-ID checks as part of the a larger set Should be "are"? While the tests as a whole or optional Insert "as"? it must as performed specified Section 1.3 ----------- Should be "ensures" (i.e. plural) This ensure that Section 2 --------- Drop "to" SPF records to declare Should be "a scope of pra and mfrom" ? spf2.0/mfrom,pra +mx +a:colo.example.com/28 -all This record has a version of "spf2.0", a scope of "pra", and ... Section 2.1 ----------- Drop "with" or "via" When published with via the SPF RR type Section 2.1.5 ------------- Should be "then that record" then record MUST be treated Section 2.1.8 ------------- should probably get moved up to appear after 2.1.2 Section 3.5 ----------- maybe briefly define "terms" here? i.e. it is used in the ABNF but not defined until 3.6.1 which will leave a new reader wondering Section 3.6.1 ------------- Same as above. Maybe include something here like: domain-spec : See Section 3.8 macro-string : See Section 7.1 Section 4 --------- Should be "addresses" a set of address In general, it is confusing to read this section and distinguish between: - the IP address of the host under test and An IP Address returned by DNS lookup triggered by an SPF record directive Maybe that could be clarified a little further? Should be "a comparison" mechanisms that perform an comparison "CIDR-length" is used here for the first time without being defined anywhere Section 4.3 ----------- "dual-cidr-length" isn't defined anywhere until Appendix A Section 4.4 ----------- Maybe should specify "a DNS A record query" for clarity and consistency with Section 4.7 Section 4.5 ----------- Extra ";" if the and a validated hostname; are the same Section 4.7 ----------- Maybe this: The domain-spec is expanded as per Section 7 should be: The is macro expanded (see Section 7) and becomes the to be clear/consistent. (e.g. Section 5.2) Actually, I'd be OK with just saying "target-name" since that is already defined back in Section 3.8. :-) (this happens several times thru the doc) Should be "enables" This mechanism enable queries Section 5 --------- Maybe provide an example of the deprecated "default" modifier so we know what to ignore. :-) Section 5.2 ----------- Should be "TXT or SPF" The DNS TXT record Section 6.2 ----------- Insert "of" keep the number include directives Section 7.1 ----------- Maybe "on their mechanisms and modifiers" on their arguments The difference between these two: o = domain of d = is not well defined. Furthermore, I don't think "d" is described at all in the following paragraphs. Section 8 --------- Pick one :-) is assumed to be correct true Should be "might be" since this is probably not a valid assumption Since this message is eventually shown to a user Section 12.2 ------------ Include reference to DNS (1035) and/or CIDR (1519?) RFCs here? Appendix A ---------- I think we have an extra "/" for the ip6-cidr-length scenario: dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] ip4-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT e.g. unless "//128" would be correct? I don't think "name" should be defined in the middle of "macro-char" Probably after "scope-id" would be more appropriate. Appendix B.1 ------------ I think this should be "192.0.2.140/30 passes" spf2.0/mfrom,pra mx/30 mx:example.org/30 -all -- any sending host in 192.0.2.128/30 or 192.168.2.140/30 passes i.e. "0" instead of "168" Respectfully, Nate From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 20:01: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 UAA19284 for ; Fri, 17 Sep 2004 20:01: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 i8HNXZvV017576; Fri, 17 Sep 2004 16:33: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 i8HNXZTE017575; Fri, 17 Sep 2004 16:33: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 i8HNXZVX017569 for ; Fri, 17 Sep 2004 16:33: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 BC088414C6; Fri, 17 Sep 2004 16:33:38 -0700 (PDT) Subject: Re: SPF abused by spammers From: Douglas Otis To: Chris Haynes Cc: IETF MARID WG In-Reply-To: <02d701c49cfe$93c2a610$0200000a@ringo> References: <20040917205430.DFA2116CD2@mail.nitros9.org> <02d701c49cfe$93c2a610$0200000a@ringo> Content-Type: text/plain Message-Id: <1095464018.30902.501.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 16:33: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-09-17 at 14:37, Chris Haynes wrote: > "Alan DeKok" replied: > > > "Chris Haynes" wrote: > > > My understanding is that SPF records declare the policy of the > > > _sender_. If the sender trusts the shared MTA to verify all > > > originators and to prevent cross-customer spoofing, then the sender > > > can use something like '+mx -all' and the receiver should respect > > > the sender's trust in the shared MTA s/he uses. > > > > In that case, the recipient has checked with the originator, and has > > information by which to decide whether or not to trust the shared MTA. > > Yes - that's the way SPF works as it uses Mail-From. > > > And yes, "originator trusts the shared MTA" still may mean that "the > > message may be spoofed". This indicates a weakness in any MAIL FROM > > authentication. when shared MTA's are used. > > When I say "originator trusts the shared MTA" I mean "trusts the shared MTA to > have authenticated and identified the sender of each message (using SMTP AUTH or > equivalent), and to have applied whatever logic is needed to prevent spoofing, > i.e. to ensure, for every message, that the sender is authorized to use the > 'Mail-From' of that message". > > If the originator's trust in the MTA' s ability to prevent spoofing is > well-founded, than the message cannot be spoofed, and Mail-From can be trusted. > (barring IP address spoofing, DNS penetration, physical penetration of MTA etc. > etc. - which are factors to be listed in the "Security Considerations"). > > I can't understand the basis of your concern about a "weakness in any MAIL > FROM..." . When the SPF list is not terminated with "-all" but rather "?all" to ensure forwarded mail receives a "Neutral" assessment and is not lost, then even a shared MTA checking incoming mail for compliance with SPF records allows a different domain with access to have their spoofing message promoted to a "Pass" assessment. In this case, the MTA provider is in full compliance with the SPF specification, but "Pass" level spoofing only requires a simple assertion of the mailbox domain. An "open" list allows mail to continue normal functionality. Until public versions of digitally signed mail, such as IIM, DomainKeys, or BATV are available, there is nothing to fill the gap to assure the sender their mail will not be rejected based upon policies that describe their nominal outbound mail but then make no other allowance. Many providers will not want their customer's mail rejected and cause a disruption in service. Their customer support efforts will be large and likely met with an attrition. Forcing use of a mailbox domain is also counter to consumer protection as this needlessly ties them to a provider. Beyond digital signatures, there is nothing to avoid this "closed" list problem. The marid-mpr mechanism, instead of Sender-ID, stops inviting >From spoofing as a means of obtaining a false reputation. The use of BATV also stops inviting the spoofing of MAIL FROM as a means to avoid access blocking. The weakness in using either MAIL FROM or the PRA for establishing an identity used in a reputation system is caused through the ease of spoofing this identity. In addition, this identity fails to locate the problem as a means to curtail abuse from either the sender's or receiver's perspective. By using the stronger MTA name for performing reputation services, a compromised or poorly administered MTA is located and blocked. This imposes a responsibility on the providers to monitor their outbound SMTP logs and respond to abuse@ complaints. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 20:21: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 UAA20768 for ; Fri, 17 Sep 2004 20:21: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 i8HNpcRv018561; Fri, 17 Sep 2004 16:51: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 i8HNpcFr018560; Fri, 17 Sep 2004 16:51:38 -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 i8HNpbmi018554 for ; Fri, 17 Sep 2004 16:51:38 -0700 (PDT) (envelope-from sb0-0678dfb79b-johnl@iecc.com) Received: (qmail 24406 invoked by uid 100); 17 Sep 2004 23:51:42 -0000 Date: 17 Sep 2004 23:51:42 -0000 Message-ID: <20040917235142.24405.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: IPR: analysis of Microsoft patent applications Organization: I.E.C.C., Trumansburg NY USA Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have read the two Microsoft patent applications published yesterday and analyzed the claims. I'm not a patent lawyer or patent agent, but I have read enough patents over the years that I think I can do an adequate job of figuring out what their claims cover. Visit http://appft1.uspto.gov/netahtml/PTO/search-bool.html and search for 60/454517, the serial number of the provisional application from which they both derive, or you can download PDF versions from my web site at http://www.taugh.com/20040181571.pdf and http://www.taugh.com/20040181585.pdf Patents consist of a narrative description of the invention, followed by claims. A claim can be independent, standing on its own, or dependent, based on a previous claim. Dependent claims are generally minor tweaks to independent claims, so I'll look at each independent claim and all of its dependent claims as a group. * Application 20040181571 This application is the less troublesome of the two. About 2/3 of it deals with methods of detecting IP spoofing, which aren't relevant here (or, if you ask me, anywhere else since TCP stacks started randomizing sequence numbers.) The rest describes what is essentially Caller ID. Claims 1-8 and 10-21 cover anti-IP-spoofing techniques. (There's no claim 9. Oops.) Claims 22-38 cover Caller ID. Claim 22 says: 22. In a receiving domain that is network connectable to one or more sending domains, the receiving domain including one or more receiving messaging servers configured to receive electronic messages from sending domains, a method for determining if a sending messaging server is authorized to send electronic messages for a sending domain, the method comprising: an act of receiving an electronic message purportedly sent from the sending domain; an act of examining a plurality of parameter values of the electronic message to attempt to identify an actual sending side network address corresponding to a sending computer system; an act of querying a name server for a list of network addresses authorized to send electronic messages for the sending domain; an act of determining if the actual sending side network address is authorized to send electronic messages for the sending domain; and an act of providing results of the determination to an message classification module such that the message classification module can make a more reliable decision as to classifying the received electronic message. Note the word "plurality" in clause 3, which is patent-speak for "more than one". I believe that SPF classic, which only checks a single message parameter, the bounce address, isn't covered here. SPF may also check the HELO domain, but that's not a parameter of the message, it's a parameter of the connection. Yes, this is hair-splitting. Welcome to the wonderful world of patents. Claims 39-41 and 42-45 cover anti-IP-spoofing. Claims 46-49 cover Caller ID again, phrased in a different way. They also refer to a "plurality of parameter values of the electronic message". * Application 20040181585 The claims in this application are breathtakingly broad. Along with a lot of computational puzzles, which we don't care about, they cover a wide class of sender verifications and, as an afterthought, scoring spam filters. Claims 1-18 cover sender verification. Claim 1 is extremely broad: 1. In a receiving domain that is network connectable to one or more sending domains, the receiving domain including one or more receiving messaging servers configured to receive electronic messages from sending domains, a method for determining a sending domain's electronic message transmission policies, the method comprising: an act of receiving an electronic message from the sending domain; an act of receiving one or more electronic message transmission policies corresponding to the sending domain; an act of parsing relevant electronic message transmission policies from the one or more received electronic message transmission policies; and an act of providing the relevant electronic message transmission policies to a message classification module such that the message classification module can make a more reliable decision when classifying the received electronic message. To me, that covers SPF, Caller ID, Sender ID, and any plausible variation on them that calls back to the message domain for advice on handling the message. By some readings it might also cover CSV, but from the narrative text it's clear that they're talking about message domains, not host domains. Paul Vixie's original domain verification proposal was published in May 2002 and he said it wasn't new at that time, so I have my doubts about the novelty of this claim. Claims 19-20 roughly restate claim 1. Claims 21-35 and 36-44 cover puzzles. Claim 45 is similar to claim 1. Claims 46 and 47 are about puzzles. Claims 48-49 come out of left field and cover scoring spam filters: 48. A computer program product for use in a receiving domain that is network connectable to one or more sending domains, the receiving domain including one or more receiving messaging servers configured to receive electronic messages from the sending domains, the computer program product for implementing a method for generating inputs to be provided to a message classification module, the computer program product comprising one or more computer-readable media having stored thereon computer executable instructions that, when executed by a processor, cause the receiving domain to perform the following: receive an electronic message; utilize one or more of a plurality of different mechanisms for attempting to determine if the received electronic message is an unwanted or an unsolicited electronic message; and provide results of each of the one or more different mechanisms to a message classification module such that the message classification module can make a more reliable decision when classifying the received electronic message. Since Spamassassin 1.0 was published in Sept 2001 and did exactly this, classify messages based on several criteria, I find it hard to understand how they'd claim this as new in a 2003 patent application. Surely they are familiar with Spamassassin. * Summary Keep in mind that these are just applications, and we don't know whether the USPTO will issue a patent and if so which if any of the claims would be allowed. I assume that their other applications are similar, and we don't know what if anything will issue in other countries. The issue that concerns me most is that the claims in these applications, particularly in '585, are much broader than what Microsoft's IPR disclosed. Note that since the IPR documents are written by lawyers, not techs, I'm not faulting any of the MS employees who have been participating in MARID and don't get to set their employer's policies. If '585 issues as a patent in anything like its current form and Microsoft's license doesn't change, it would make SPF or any other similiar system legally very risky since the MS license only lets you implement Sender-ID, not other things that are like Sender-ID. Regardless of what the MS IPR said, their patent rights depend on what's in the patent, and if you look at cases where patents were broader than the IPR disclosure in the standards process, the results can be really ugly. Google for RAMBUS JEDEC for a notorious example. At this point, I see a variety of unappetizing alternatives. One is to wait and see what patents issue, but that could take years. Another is to standardize only what MS is willing to license. Or we could decide that the '585 claims are implausible and ignore them, at our peril. My personal inclination is to say that none of the domain/IP verification schemes are good enough to be worth this much heartburn, put them all back on the shelf, do CSV and BATV, and turn our attention to MASS. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly. From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 20:49: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 UAA22677 for ; Fri, 17 Sep 2004 20:49: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 i8I03TWQ019287; Fri, 17 Sep 2004 17:03:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I03TUg019286; Fri, 17 Sep 2004 17:03:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sasl.smtp.pobox.com (puzzle.sasl.smtp.pobox.com [207.8.226.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I03SaU019280 for ; Fri, 17 Sep 2004 17:03:29 -0700 (PDT) (envelope-from McQuilWP@pobox.com) Received: from localhost.localdomain (localhost [127.0.0.1]) by puzzle.pobox.com (Postfix) with ESMTP id 0557F138F50; Fri, 17 Sep 2004 20:03:33 -0400 (EDT) Received: from MCQWP2 (ip68-7-159-196.sd.sd.cox.net [68.7.159.196]) by puzzle.pobox.com (Postfix) with ESMTP id 36F88138F09; Fri, 17 Sep 2004 20:03:32 -0400 (EDT) Date: Fri, 17 Sep 2004 17:03:27 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <63352482.20040917170327@pobox.com> To: MARID Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-09-17, william(at)elan.net wrote: > I'm reading Pete's answer right, then adding Resent-From is ok in some > forwarding cases but not in others and that in particular: > 1. Its not ok with .forward forwarding (specifically mentioned). This > is very very common in the deployed base. > 2. Its not ok with any forwarding where RFC2821 Mail From remains the same > as it was before forwarding (most of the forwarding systems deployed > on the net are like this) > 3. Its not ok if message is changed (this would include Mail Lists). I'm sorry. I must be dense. When *IS* it OK to use Resent-From? What is it intended to mean? -- Bill McQuillan From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 21:22: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 VAA25479 for ; Fri, 17 Sep 2004 21:22:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I0jqku021997; Fri, 17 Sep 2004 17:45: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 i8I0jqLk021996; Fri, 17 Sep 2004 17:45:52 -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 i8I0jpkZ021989 for ; Fri, 17 Sep 2004 17:45:51 -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 i8I0wErO007051; Fri, 17 Sep 2004 17:58:14 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8I0wESZ007047; Fri, 17 Sep 2004 17:58:14 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 17 Sep 2004 17:58:14 -0700 (PDT) From: "william(at)elan.net" To: Bill McQuillan cc: MARID Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 In-Reply-To: <63352482.20040917170327@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, 17 Sep 2004, Bill McQuillan wrote: > I'm sorry. I must be dense. When *IS* it OK to use Resent-From? > What is it intended to mean? My reading is it is ok when email is reintroduced into system by SMTP server in the way similar to relaying it but as part of normal relay process email session and other parameters are never change, but in this case relaying involves change in envelope parameters Mail From and RCPT TO. Think of it as relay with change of envelope and possibly change of address headers (Sender, From, To, CC). It is also probably ok for message to have been introduced after certain wait period (in emailqueue presumably) triggered by certain event (i.e. like ETRN). But I maybe wrong, so perhaps it would be better if Pete answers this question. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Sep 17 22:22:09 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 WAA29411 for ; Fri, 17 Sep 2004 22:22: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 i8I1qV3G026771; Fri, 17 Sep 2004 18:52:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I1qV5t026770; Fri, 17 Sep 2004 18:52:31 -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 i8I1qVow026764 for ; Fri, 17 Sep 2004 18:52:31 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8I1qb0A000451 for ; Fri, 17 Sep 2004 18:52:37 -0700 Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <69C195B8-0915-11D9-B862-000A95AC5778@isipp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: IPR: analysis of Microsoft patent applications (Safe to Read Even If You Are Avoiding Reading the Patents) Date: Fri, 17 Sep 2004 18:52:35 -0700 X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8I1qVow026765 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit First, for what it's worth, I concur with John's analysis, although while IAAL, I should add that I am not a patent lawyer. > If '585 issues as a patent in anything like its current form and > Microsoft's license doesn't change, it would make SPF or any other > similiar system legally very risky since the MS license only lets you > implement Sender-ID, not other things that are like Sender-ID. > Regardless of what the MS IPR said, their patent rights depend on > what's in the patent, and if you look at cases where patents were > broader than the IPR disclosure in the standards process, the results > can be really ugly.  Google for RAMBUS JEDEC for a notorious example. > > At this point, I see a variety of unappetizing alternatives.  One is > to wait and see what patents issue, but that could take years. > Another is to standardize only what MS is willing to license.  Or we > could decide that the '585 claims are implausible and ignore them, at > our peril. > Actually there are a few other alternatives. In the first instance, anyone who has already developed processes which these patents arguably cover, and most especially anyone who has already patented such a process, can send that information (by registered mail to provide proof of receipt) to the Microsoft attorneys. Beyond that, for anyone who has in fact obtained a patent, or for anyone who has filed a patent or who does file a patent during the pendancy of these patent applications (i.e. before they are granted), they can file an "interference action" with the PTO. To quote a colleague of mine who does do patent work, "An interference is a proceeding, conducted before the Board of Patent Appeals and Interferences, to determine priority of invention between a pending application and one or more pending applications and/or one or more unexpired patents." I should note here that interference actions are very unusual, and extremely expensive (but then so is infringement litigation). I should also say that I have no personal opinion for or against such an action, and am not recommending (or disrecommending) such an action. Finally, I would like to take this opportunity to address the advice which has been making the rounds regarding how one should not read patents so that one won't be prosecuted for willful infringement. There _are_ situations in which it's best not to look at patents. For example, if you are an inventor, and you have _zero_ idea about what's out there, and there is no way you could know, and then you go traipsing through the patents, and you find a patent which makes claims identical to your invention, and then you go forward with your invention, then yes, you *could* be found guilty of willful infringement. However, according to my (very highly placed patent litigation partner in a big patent firm, and highly experienced litigator in another big IP firm) sources, you have to try Really Hard to be found guilty of willful infringement - willful means, well, willful. It has to pretty much border on malfeasance. On the other hand, if you are already on notice, if you have _reason_ to believe that your code may possibly infringe on a patent..such as, oh, say, the MS patent - if it's been discussed in forums in which you participate, or if it's been all over the press...then you can be found to have been on notice, in which case _not_ reading the patent can be seen as not exercising reasonable care and due diligence. There is "had no idea, and NO WAY could have known", and there is "absolutely knew and did the infringing act anyways with full knowledge and malice", and then there's everything in between. And everything in between is a grey area. However, the above scenario, where the issue of whether the MS patent covers SPF and other sorts of authentication technologies are being discussed wide and far, and is in the press, you are more likely to get in trouble for failure to do due diligence, as you are on notice. Indeed, instead of protecting you, it may damn you. I should point out that, as in all grey areas, reasonable minds can differ. So it's entirely possible that another similarly highly placed source may say something quite different. The bottom line is - you know, if you think that it's going to be infringing - don't do it. Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy Professor of Law, Lincoln Law School of SJ Committee Member, Asilomar Microcomputer Workshop From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 00:10: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 AAA04790 for ; Sat, 18 Sep 2004 00:10: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 i8I3fTXY033377; Fri, 17 Sep 2004 20:41:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I3fTXL033376; Fri, 17 Sep 2004 20:41:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend1.messagingengine.com (frontend1.messagingengine.com [66.111.4.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I3fQ7B033367 for ; Fri, 17 Sep 2004 20:41:28 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: 90BA4ctMCNmqwK1zlOJ5Fw 1095478889 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend1.messagingengine.com (Postfix) with ESMTP id 59806C15659; Fri, 17 Sep 2004 23:41:28 -0400 (EDT) Message-ID: <414BAEE0.80305@elvey.com> Date: Fri, 17 Sep 2004 20:43:28 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis , MXCOMP Subject: SPF Archive?, Re: ANNOUNCE: I-D draft-ietf-marid-SPF3-00, etc. References: <41475F45.90707@elvey.com> <20040915024151.GH23667@dumbo.pobox.com> <4147ED67.1040301@elvey.com> <4148CD50.56F0@xyzzy.claranet.de> <414A6EE6.6030801@elvey.com> <1095459386.30902.430.camel@ddev.mail-abuse.org> In-Reply-To: <1095459386.30902.430.camel@ddev.mail-abuse.org> 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 First: Have any of the folks who've done surveys of the DNS for SPF records archived the actual records they found? I hope so; they may turn out to be useful down the road. On 9/17/2004 3:16 PM, Douglas Otis sent forth electrons to convey: >On Thu, 2004-09-16 at 21:58, Matthew Elvey wrote: > > > >>Comparison of SPF3 and CSV+MPR: >> >> > > > >>Of bind, GoDaddy and ZoneEdit, only BIND supports what CSV requires. >>Technically, it's inferior, in that its usage of DNS is less efficient >>and less standards-based. MPR also has the cool bit-mapped fields for >>explicit protection of 2822.From:, etc. This could be added to SPF3. >> >> > >Are you referring to web-based GUI interfaces for DNS entries to support >services? > ASPs providing DNS services. (Same thing said differently?) >Looking at their documentation, it was not clear that it was >possible to enter a TXT record either. > They support TXT records. > I would imagine do-it-yourself >providers will offer needed interfaces for elements supporting their >service once it becomes prevalently needed. CSV is simple enough to >have it defined without any user intervention other than selecting the >host. > > In the case of SPF1, coming up with reasonable data to feed the wizard at pobox.com is the main stumbling block. Given a good result from the wizard and raw access to TXT, it's easy to put the former into the latter. But again, the data required for a good SPF1 record (e.g that doesn't have ?0/0) is often difficult to determine. CSV is simpler, so if raw access to the required RR type is available, we'd be good; with a wizard, we'd be great. It would be a bit of a 'stub' wizard- one or two questions, tops. >It is not clear what was being compared in this sentence. I will assume >you were saying CSV is inferior. : ) > > Uh, no. I was saying SPF3 is inferior in certain tecnical respects in comparison to CSV+MPR! It was clearer when it was in context. >The SRV record is used extensively... > >Use of a TXT record which encodes other >domains, users, error messages, hostnames, addresses, settings, macros, >and is extensible will require a forever evolving parser. > > >With more and more flavors of TXT records employed due to the example >made by SPF, as well as adopting a practice of using wildcards, any use >of an extensible text script is not without risk. Unlike other DNS >records with content defined by the record type, the TXT record should >assume opaque text strings. > > Right; there's a risk-benefit evaluation to me made. I'm sensing most people prefer to take the risk and get the benefit; but I wouldn't call it a rough consensus yet. >Unlike SPF, names are consistently used and do not require the double >entry of host addresses as SPF may. The alternative to replicate >address entry when using SPF, is to use record references and then cause >subsequent DNS lookups to then obtain the addresses for each reference. >SPF is neither more standard or efficient. The MPR name lists also >removes the need for subsequent lookups which are the bane of the SPF >approach. > > Yes, SPF is neither more standard or efficient, etc. In SPF3, domains are consistently used, and it's more efficent than SPF/SPF1 or SenderID/SPF2. >The MPR lists, being a separate from the MTA authentication and >authorization, avoids the problems of "open" lists that invite >spoofing. MPR can be deployed with an "open" list as a SHOULD without >any exploit concerns. By marking or "coloring" the mail as being >outside the nominal mail channel, this should offer better consumer >protection than that achieved with Sender-ID's PRA algorithm yet not >breaking mail forwarding. > > This would be so greatly clarified by specific sample M.A.R.I.D. illustrating such open lists failing! > > >>=-=-=-=-= >>With respect to being able to outright reject forgeries without breaking >>forwarding: >>With HELO checks + A&R, I can see this becoming reasonable BCP. Here's how: >>Forwarders (and mailing list hosts) will be expected to be running >>MARID on their MTA. If they are too lazy to do so, then they will be >>found to be forwarding on obvious (to anyone using MARID) forgeries, and >>thus their reputations will (justifiably) suffer. It will probably not >>be fair to blame 'em for all spam they forward, but it will be fair to >>blame them for forwarding on obvious forgeries. The responsible >>forwarders running MARID can be expected to have good HELO reputations. >> >> > >Is this in reference to CSV? > > It's in reference to any MARID scheme relying heavily on HELO, such as CSV, or SPF3. I'd wager you're in agreement. I put SPF3 up here: http://elvey.com/it/sieve/draft-ietf-marid-spf3-00.txt as it's not up at iietf.org/internet-drafts yet. To save folks time, I put up http://asrg.sp.am/wiki?action=history&id=Spf3 . Folks may want to look at that to see a quick diff showing the "*Substantive Changes*" between my draft and draft-ietf-marid-prococol-03. From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 06:47:17 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 GAA09568 for ; Sat, 18 Sep 2004 06:47:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IAKbTv054701; Sat, 18 Sep 2004 03:20:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IAKbwY054699; Sat, 18 Sep 2004 03:20:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IAKaPY054669 for ; Sat, 18 Sep 2004 03:20:37 -0700 (PDT) (envelope-from SRS0+19bad5fc43a4758fd958+391+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8cKY-00049w-SW; Sat, 18 Sep 2004 06:20:35 -0400 Subject: Re: IPR: analysis of Microsoft patent applications From: David Woodhouse To: John Levine Cc: ietf-mxcomp@imc.org In-Reply-To: <20040917235142.24405.qmail@xuxa.iecc.com> References: <20040917235142.24405.qmail@xuxa.iecc.com> Content-Type: text/plain Date: Sat, 18 Sep 2004 11:15:38 +0100 Message-Id: <1095502538.5065.81.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-09-17 at 23:51 +0000, John Levine wrote: > My personal inclination is to say that none of the domain/IP > verification schemes are good enough to be worth this much heartburn, > put them all back on the shelf, do CSV and BATV, and turn our > attention to MASS. I was violently in agreement with that assessment even _without_ the patent issues, which I personally am more than happy to ignore (at my peril, as you say). When considered holistically, the domain/IP verification schemes don't actually manage to achieve anything more than CSV does -- they only give a way to determine how much to trust the individual mail server which is offering the mail. Thus, the heartburn of requiring ubiquitous deployment of SRS and the addition of the Forwarded-For: header was too much for me, even without the patent. There are better answers. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 08:01:44 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 IAA13450 for ; Sat, 18 Sep 2004 08:01:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IBYNsV072806; Sat, 18 Sep 2004 04:34:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IBYN21072805; Sat, 18 Sep 2004 04:34:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IBYL9Q072799 for ; Sat, 18 Sep 2004 04:34:22 -0700 (PDT) (envelope-from roy+dated+1098099254.889f20@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i8IBYY9K045311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 18 Sep 2004 11:34:40 GMT (envelope-from roy+dated+1098099254.889f20@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i8IBYEed071553 for ; Sat, 18 Sep 2004 12:34:14 +0100 (BST) (envelope-from roy+dated+1098099254.889f20@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i8IBYELU071552 for ietf-mxcomp@imc.org; Sat, 18 Sep 2004 12:34:14 +0100 (BST) (envelope-from roy+dated+1098099254.889f20@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 18 Sep 2004 12:34:13 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16716.7477.80423.26426@giles.gnomon.org.uk> Date: Sat, 18 Sep 2004 12:34:13 +0100 To: David Woodhouse Cc: John Levine , ietf-mxcomp@imc.org Subject: Re: IPR: analysis of Microsoft patent applications In-Reply-To: <1095502538.5065.81.camel@localhost.localdomain> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "David" == David Woodhouse writes: David> When considered holistically, the domain/IP verification David> schemes don't actually manage to achieve anything more than David> CSV does -- they only give a way to determine how much to David> trust the individual mail server which is offering the David> mail. I don't think that's true. The domain/IP verification schemes directly address forgery, in a way that CSV doesn't. Think about Sender ID as a tool for senders who (for whatever reason) want to be able to prevent others from sending forged mail claiming to be from them. As a tool for recipients, Sender ID and CSV both provide a hook on which to hang reputation and accreditation systems, and I'm agnostic as to which will work better in the real world, though my feeling is that they may in fact turn out to be complementary. -roy From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 08:20: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 IAA14628 for ; Sat, 18 Sep 2004 08:20:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IBu1aL073889; Sat, 18 Sep 2004 04:56: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 i8IBu1Su073888; Sat, 18 Sep 2004 04:56:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IBu0vZ073881 for ; Sat, 18 Sep 2004 04:56:01 -0700 (PDT) (envelope-from SRS0+19bad5fc43a4758fd958+391+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8doq-0004GS-5a; Sat, 18 Sep 2004 07:55:56 -0400 Subject: Re: IPR: analysis of Microsoft patent applications From: David Woodhouse To: Roy Badami Cc: John Levine , ietf-mxcomp@imc.org In-Reply-To: <16716.7477.80423.26426@giles.gnomon.org.uk> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> Content-Type: text/plain Date: Sat, 18 Sep 2004 12:50:58 +0100 Message-Id: <1095508258.5065.116.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2004-09-18 at 12:34 +0100, Roy Badami wrote: > I don't think that's true. The domain/IP verification schemes > directly address forgery, in a way that CSV doesn't. Think about > Sender ID as a tool for senders who (for whatever reason) want to be > able to prevent others from sending forged mail claiming to be from > them. I do not think of Sender ID in that way. There are true end-to-end schemes which address that problem reliably through multiple hops, and without requiring that the world at large upgrade to make their flawed assumptions come true. To offer Sender ID as a true solution to the problem of forgery is disingenuous. It is not a general solution to that problem. > As a tool for recipients, Sender ID and CSV both provide a hook on > which to hang reputation and accreditation systems, and I'm agnostic > as to which will work better in the real world, though my feeling is > that they may in fact turn out to be complementary. I agree that the various reputation and accreditation systems, maintained by different people with different criteria, will be complementary. We've already seen that with the various IP-based systems. However my feeling is that the availability of different _keys_ into such databases would be purely redundant. While the use of IP addresses has its problems, I feel that _any_ key which we can _reliably_ tie to the owner of the MTA in question would suffice as a replacement. In fact, I feel that the presence of redundant schemes for identifying such 'keys' would be counterproductive, because it would lead to the separate implementation of different databases which have the _same_ criteria for listings, but different keys. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 10:57:57 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 KAA24674 for ; Sat, 18 Sep 2004 10:57: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 i8IEUGob083343; Sat, 18 Sep 2004 07:30: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 i8IEUGve083342; Sat, 18 Sep 2004 07:30:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IEUCOo083330 for ; Sat, 18 Sep 2004 07:30:15 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i8IEU59M000862; Sat, 18 Sep 2004 16:30:05 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i8IETsN9021497; Sat, 18 Sep 2004 16:29:54 +0200 From: Hadmut Danisch Date: Sat, 18 Sep 2004 16:29:54 +0200 To: "Anne P. Mitchell, Esq." Cc: IETF MARID WG Subject: Re: IPR: analysis of Microsoft patent applications (Safe to Read Even If You Are Avoiding Reading the Patents) Message-ID: <20040918142954.GA20851@danisch.de> References: <69C195B8-0915-11D9-B862-000A95AC5778@isipp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69C195B8-0915-11D9-B862-000A95AC5778@isipp.com> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 17, 2004 at 06:52:35PM -0700, Anne P. Mitchell, Esq. wrote: > > Actually there are a few other alternatives. In the first instance, > anyone who has already developed processes which these patents arguably > cover, and most especially anyone who has already patented such a > process, can send that information (by registered mail to provide proof > of receipt) to the Microsoft attorneys. I'd like to do that. Unfortunately I'm not familiar with US patent law, so every hint and advice is welcome. Where do I have to send this? Just to Microsoft Corporation One Microsoft Way Redmond, WA 98052 US ? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 11:16:34 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 LAA25401 for ; Sat, 18 Sep 2004 11:16:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IEpL38084616; Sat, 18 Sep 2004 07:51:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IEpLkc084615; Sat, 18 Sep 2004 07:51:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IEpKqV084600 for ; Sat, 18 Sep 2004 07:51:20 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Sat, 18 Sep 2004 09:51:25 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <63352482.20040917170327@pobox.com> References: <63352482.20040917170327@pobox.com> X-Mailer: Eudora [Macintosh version 6.2a9] Date: Sat, 18 Sep 2004 09:51:15 -0500 To: Bill McQuillan From: Pete Resnick Subject: Re: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822 Cc: MARID Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 9/17/04 at 5:03 PM -0700, Bill McQuillan wrote: >On Fri, 2004-09-17, william(at)elan.net wrote: > >>I'm reading Pete's answer right, then adding Resent-From is ok in >>some forwarding cases but not in others and that in particular: Let's be careful here about "ok" and "not ok". I'd say "intended for". Standards are supposed to be more descriptive than prescriptive of use. >> 1. Its not ok with .forward forwarding (specifically mentioned). >>This is very very common in the deployed base. I think it would match the semantics more if the MAIL FROM was not preserved. The current deployment of .forward I agree doesn't match the semantics of 2822. But that deployment could be changed. >> 2. Its not ok with any forwarding where RFC2821 Mail From remains >>the same as it was before forwarding (most of the forwarding >>systems deployed on the net are like this) Again, they don't have to be deployed that way. And there might be a good argument for them not to be: If there is an error getting the mail to beyond the forwarder, should that really be reported back to the original sender? Maybe, maybe not. >> 3. Its not ok if message is changed (this would include Mail Lists). It has not traditionally been used with mailing lists because mailing lists act more like gateways than simple resenders. (That includes, but is not limited to, changing the message headers.) I'd prefer to use a different mechanism for mailing lists (like the List-* fields: perhaps a List-ID could be used if it followed the domain convention). >I'm sorry. I must be dense. When *IS* it OK to use Resent-From? >What is it intended to mean? It means, "The person in the Resent-From/Resent-Sender of this message received this message and redirected it to you. You should treat the message as if it went from the original sender directly to you." The Resent-* fields give you information about the resending event. Several MUAs have resend or redirect commands. The Resent-* fields are to be used when that function is executed. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 11:53:36 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 LAA27491 for ; Sat, 18 Sep 2004 11:53:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IFS289086909; Sat, 18 Sep 2004 08:28: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 i8IFS2kd086908; Sat, 18 Sep 2004 08:28:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IFS1wC086900 for ; Sat, 18 Sep 2004 08:28:02 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPR: analysis of Microsoft patent applications X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sat, 18 Sep 2004 10:28:02 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D05540F@srv1.pan-am.ca> Thread-Topic: IPR: analysis of Microsoft patent applications (Safe to Read Even If You Are Avoiding Reading the Patents) Thread-Index: AcSdJvjhFSzZtTaWRaiEaJtYV2up+QAbJz/Q From: "Gordon Fecyk" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8IFS2wC086903 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > The bottom line is - you > know, if you think that it's going to be infringing - don't do it. Thus ended a potentially useful application to prevent forgery. It joins its brothers and sisters in the Graveyard of Good Ideas such as The Electric Car, inexpensive solar energy, among others, in the name of corporate greed. Thanks, Microsoft. This must be what RMS meant when he says software patents are dangerous. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 11:56: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 LAA27588 for ; Sat, 18 Sep 2004 11:56: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 i8IFWGuh087167; Sat, 18 Sep 2004 08:32: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 i8IFWGVJ087166; Sat, 18 Sep 2004 08:32: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 i8IFVwho087150 for ; Sat, 18 Sep 2004 08:31:58 -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 1E18616CD2 for ; Sat, 18 Sep 2004 11:41:24 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: SPF abused by spammers In-Reply-To: Your message of "Fri, 17 Sep 2004 22:37:46 BST." <02d701c49cfe$93c2a610$0200000a@ringo> Date: Sat, 18 Sep 2004 11:41:24 -0400 Message-Id: <20040918154124.1E18616CD2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Chris Haynes" wrote: > When I say "originator trusts the shared MTA" I mean "trusts the > shared MTA to have authenticated and identified the sender of each > message (using SMTP AUTH or equivalent), The recipient can verify that the originator intends the shared MTA to use "MAIL FROM" it's domain. The recipient cannot tell if any individual message sent by that shared MTA is actually from the alleged originating domain. The "trust" you mention above includes two separate trust relationships, only one of which can be verified by the recipient. To me, this means we should talk about the trust relationships in isolation, and not together. It also means that a binary trust value for the shared MTA is inadequate. A "trusted" value can be used for MTA's you control, an "untrusted" value for MTA's you don't like, and a "maybe" value could be used for shared MTA's. As noted earlier, this is being done today with SPF. > I can't understand the basis of your concern about a "weakness in any MAIL > FROM..." . I'm looking at it from the view of the recipient, and from an examination of what information is available, and what things are being trusted. We can say that publishing a "MAIL FROM" authentication record has the meaning you intend, but that meaning contains pieces ("trusted" message origin) that contains claims by the originator which cannot be verified by the recipient. In contrast, the "trusted to use MAIL FROM with my name" claim CAN be verified by the recipient: he has a connection where the shared MTA is using MAIL FROM with that name. My method is a bit reductionist: divide everything into small pieces, and examine how those pieces are used, and how they're put togther. Only when we understand the pieces can we be confident that a system built on those pieces does what we want. The alternative is to build a "house of sand". It's pretty, but with no foundations. It will collapse as soon as one of the unspoken assumptions is questioned, or proven wrong. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 12:17: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 MAA28868 for ; Sat, 18 Sep 2004 12:17: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 i8IFnUQR088181; Sat, 18 Sep 2004 08:49: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 i8IFnUqC088180; Sat, 18 Sep 2004 08:49:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IFnTGW088173 for ; Sat, 18 Sep 2004 08:49:29 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id EF601132D6A; Sat, 18 Sep 2004 11:49:24 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id B31F953F; Sat, 18 Sep 2004 11:49:28 -0400 (EDT) Date: Sat, 18 Sep 2004 11:49:28 -0400 From: Meng Weng Wong To: Roy Badami Cc: John Levine , ietf-mxcomp@imc.org Subject: Why we should authenticate multiple identities Message-ID: <20040918154928.GN23667@dumbo.pobox.com> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16716.7477.80423.26426@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A patent application is not a patent; I understand that nowadays applications are filed containing many claims that the filer doesn't actually expect to be approved, but if they are approved, bonus! So let's look at which claims we can realistically expect to survive into patent form, and do our best to educate the patent office about the rest. The ones that do make it into the patent may not turn out to be an encumbrance after all, or if they are an encumbrance at least we have a solid idea of how to route around them. On Sat, Sep 18, 2004 at 12:34:13PM +0100, Roy Badami wrote: | | I don't think that's true. The domain/IP verification schemes | directly address forgery, in a way that CSV doesn't. Think about | Sender ID as a tool for senders who (for whatever reason) want to be | able to prevent others from sending forged mail claiming to be from | them. | I agree that the anti-fraud aspects of SPF/Sender ID are stronger than CSV, and should not be abandoned just yet. CSV alone is not sufficient because it has a weaker deployment driver than SPF / Sender ID. To wit: Suppose we have lazy.example.com. We want to encourage lazy.example.com to deploy whatever we come up with. But they're lazy, so they naturally want to know the consequences of noncompliance. "If I don't publish CSV records, what have I got to lose?" "Spammers might spoof with your HELO domain name." "Will people reject my mail simply because I have no CSV record?" "Considering that lots of MTAs don't even HELO with a resolvable hostname, and we seem resigned to that, frankly I'd have to say they're not going to reject your mail." "Then why should I bother?" "Because it makes life easier for other people who'd be victimized by spoofing --- we aim to get CSV records on every legitimate HELO hostname in the world so we can close that loophole." The SPF story goes like this: "If I don't publish SPF records, what have I got to lose?" "Spammers might spoof with your domain name in the return-path or the headers." "Will people reject my mail simply because I have no SPF record?" "Considering that lots of domains have no SPF record, that day is pretty far off. Though you never know how aggressive some people might get." "Then why should I bother?" "Because when people forge your domain name in the return-path or the headers, you get the bounces, and your users get phished. Is that a problem for you?" "Oh, then yes, that is a problem." So it seems to me that the average domain owner has a more compelling case to do SPF than CSV. I'm not saying nobody will do CSV: I fully expect ESPs and ISPs to do CSV on their MTAs, but you're not going to see uninterested parties putting negative CSV assertions on all the other hostnames that could be HELO'ed by MTAs. By contrast, I expect many more people to put SPF records on their domains because the benefits are more immediate and more apparent. | As a tool for recipients, Sender ID and CSV both provide a hook on | which to hang reputation and accreditation systems, and I'm agnostic | as to which will work better in the real world, though my feeling is | that they may in fact turn out to be complementary. I agree that they will be complementary. In the same way that restaurants offer a variety of eating options to satisfy different needs, we should aim to offer a variety of authentication options to accommodate the market better. I have been observing a pattern of fallacious debate which can perhaps be called "winner takes all". In this pattern, when you are given a choice of N options, you are allowed to pick only one: so proponents fight tooth and nail for their favourite choice. This happens a lot because winning feels good; many of us are trained to try very hard to win; and besides, people who do not subscribe to this pattern of living tend to be interest themselves in things other than IETF working groups. Very often, though, in the real world, we end up with a blend of multiple inputs, or we end up going with a plurality of the choices that lie before us. Yesterday at lunch we ordered the chocolate cake *and* the key lime pie. There's nothing inherently wrong with getting two desserts instead of one. There are some operational considerations, of course: it costs more, and we certainly didn't want to order every single dessert on the menu just to have a taste. In the same way, we probably don't want to tell the Internet to have to do 512 different things; if we can limit our recommendations to a small set of four or five they'll probably find that livable. Any reasonable person who hears "this is the one and only thing you have to do" will probably think was a bit of a hard sell. The silly sort of "winner takes all" debate ends up looking like: "Children, what is your favourite colour?" - "I like yellow!" - "I like blue!" - "No you don't!" - "Yes I do!" I am implementing a next-generation system based on the Aspen model of authentication, reputation, accreditation. In that system, I'll check authentication on SPFv1, SPFv2, CSV, and Domain Keys. I'll check Spamhaus and Cloudmark Rating and the VDL. Two heads are better than one, and yellow and blue go very nicely together. From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 12:43: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 MAA29958 for ; Sat, 18 Sep 2004 12:43: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 i8IGC3gV089718; Sat, 18 Sep 2004 09:12:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IGC3Qi089717; Sat, 18 Sep 2004 09:12:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IGC2FD089710 for ; Sat, 18 Sep 2004 09:12:03 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id 25AAD132D80; Sat, 18 Sep 2004 12:12:00 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 5D2285A8; Sat, 18 Sep 2004 12:12:05 -0400 (EDT) Date: Sat, 18 Sep 2004 12:12:05 -0400 From: Meng Weng Wong To: Gordon Fecyk Cc: IETF MARID WG Subject: Re: IPR: analysis of Microsoft patent applications Message-ID: <20040918161205.GO23667@dumbo.pobox.com> References: <700EEF5641B7E247AC1C9B82C05D125D05540F@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D05540F@srv1.pan-am.ca> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 18, 2004 at 10:28:02AM -0500, Gordon Fecyk wrote: | | Thanks, Microsoft. | | This must be what RMS meant when he says software patents are dangerous. | There are certainly a lot of people who feel disgruntled at this latest turn of events: these people might think to themselves: "Your Potential. Our Patent." But my advice to those people would be: let's try to keep moving in a positive direction, and deal with this in the best possible way, rather than succumbing to the politics of blame, which is ultimately unproductive. Before we jump to conclusions, I think we should methodically figure out which claims in the patents are overbroad, and which claims actually overlap with what we want to achieve. We should try to educate the patent office about the former, and creatively explore alternatives to the latter. It's not Microsoft's fault for manoeuvering to gain every possible advantage; that is how the game is played. It is the responsibility of the rest of the industry to learn the rules and respond. As one scientist, inventor, postmaster and postmaster once said: We must all hang together. Part of playing the game means spending money to protect the commons. The patent system is broken: this is not news. We can complain that it is broken, and we can excoriate anyone who takes advantage of it. But we can also, if we wish, patent our own inventions and dedicate them to the public domain. True, that costs money: money which, to date, nobody has found for the common inventions we have made together. But maybe that will change soon. Maybe large corporations with free cash flow will see that what's good for the Internet is good for them; and maybe their PR departments will realize some value in acting in the public interest, and then the dollars might begin to flow. If the dollars don't flow, why, then, it is no-one's fault but our own, and assuredly we shall all hang separately. From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 13:45: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 NAA05606 for ; Sat, 18 Sep 2004 13:45: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 i8IH923K093288; Sat, 18 Sep 2004 10:09: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 i8IH926h093287; Sat, 18 Sep 2004 10:09:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IH91af093280 for ; Sat, 18 Sep 2004 10:09:02 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1C8ihs-0009CU-00 for ietf-mxcomp@imc.org; Sat, 18 Sep 2004 18:09:04 +0100 Message-ID: <046101c49da1$b5296160$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <20040918154124.1E18616CD2@mail.nitros9.org> Subject: Re: SPF abused by spammers Date: Sat, 18 Sep 2004 18:05:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "Alan DeKok" responded: > > "Chris Haynes" wrote: > > When I say "originator trusts the shared MTA" I mean "trusts the > > shared MTA to have authenticated and identified the sender of each > > message (using SMTP AUTH or equivalent), > > The recipient can verify that the originator intends the shared MTA > to use "MAIL FROM" it's domain. The recipient cannot tell if any > individual message sent by that shared MTA is actually from the > alleged originating domain. > The recipient is invited to accept that the message _is_ from the purported domain because the Sender's Policy says he should - she has declared that shared MTA trustworthy. It's her message, her policy, her choice of shared MTA. When the recipient is offered the message he extracts the domain of the Mail-From and consults the DNS for that domain to get the policy. He then applies the policy 'algorithm' to the IP address of the sending MTA to see if it was authorised by the sender, and, if so, what the 'strength' of the sender's policy is on this particular MTA. If her policy says 'pass' ('+'). then she is saying 'If this MTA offers you a message purporting to be from my domain, I trust it, and so should you'. The receiver has to trust: 1) The DNS service to deliver the correct SPF policy for the domain 2) The IP transport system to report accurately the IP address of the sending MTA. There his need to trust anything associated with the shared MTA ends. The message has been identified as coming from the sender's domain, and the sender has accepted responsibility for the behaviour of the MTA. > > The "trust" you mention above includes two separate trust > relationships, only one of which can be verified by the recipient. To > me, this means we should talk about the trust relationships in > isolation, and not together. I invite you to be specific about this second trust relationship you talk of. Just what is it that the reciever has to trust the sending MTA to do or not do, and which is not covered by the sender's trust in that MTA? A specific example would help me understand your concern. > > It also means that a binary trust value for the shared MTA is > inadequate. A "trusted" value can be used for MTA's you control, an > "untrusted" value for MTA's you don't like, and a "maybe" value could > be used for shared MTA's. As noted earlier, this is being done today > with SPF. Agreed - I don't think I was advocating a 'binary' value in the trust itself, was I? > > > I can't understand the basis of your concern about a "weakness in any MAIL > > FROM..." . > > I'm looking at it from the view of the recipient, and from an > examination of what information is available, and what things are > being trusted. We can say that publishing a "MAIL FROM" > authentication record has the meaning you intend, but that meaning > contains pieces ("trusted" message origin) that contains claims by the > originator which cannot be verified by the recipient. In contrast, > the "trusted to use MAIL FROM with my name" claim CAN be verified by > the recipient: he has a connection where the shared MTA is using MAIL > FROM with that name. > > My method is a bit reductionist: divide everything into small > pieces, and examine how those pieces are used, and how they're put > togther. Only when we understand the pieces can we be confident that > a system built on those pieces does what we want. That's what I have started above. > > The alternative is to build a "house of sand". It's pretty, but > with no foundations. It will collapse as soon as one of the unspoken > assumptions is questioned, or proven wrong. If you intend this as a criticism of SPF then you have to expose these unspoken assumptions. Please be specific. Let me explain where I'm coming from: I'm not associated with any one scheme. I'm a 'sufferer' who needs a workable, engineeringly-viable solution. I see in SPF something that's pretty neat - I like its architecture, the one which keeps the sender in charge of the policy. But I can also see problems with it, e.g. with whether the _sender's_ trust in an MTA not under her administrative control can ever be well-founded. There appear to be several other schemes being proposed in this space. At the time of the chairs' choosing I'll be just as interested in them. I think those who have alternative schemes to offer are being put in a difficult position by the procedure that has been adopted in this WG. We are being invited to consider the candidates one by one. This goes agains all my engineering instincts, which are to: a) Agree the objectives and metrics of success, b) Identify all viable candidates, c) Assess them in parallel against the objectives, constructing interesting scenarios, test cases etc. - against which all candidates can be evaluated. Instead we have a procedure which feels as if it could end with a winner being declared as soon as the first 'just about acceptable' solution has been identified. Those proponents of candidate solutions which have not yet been considered probably feel the need to continually draw attention to the defects of those candidates which were lucky enough to be considered first. This is challenging because the points of difference are difficult to describe when you are not allowed to be specific about the 'better' approach which you cannot yet talk about. So I have a lot of sympathy for those proponents waiting to get their candidate exposed. But I, for one, feel that any criticism of a scheme which _is_ on the table has to be phrased in very concrete terms. There has to be a specific example of a weakness, of a security vulnerability etc. for the rest of us to be able to understand the concern. It may well be that you can see some specific weakness in the use of Mail-From that the rest of us cannot see and that you can do the WG a service by exposing that specific weakness. I've been trying to manoeuvre you into doing this with your 'trust' concern. I'm genuinely trying to understand the 'space' in which the receiver's trust or mistrust of the sending MTA matters to you. What is it that the sending MTA can do or not do which, whilst still honoring the trust that the sender has in that MTA, causes Mail-From to be flawed? > > Alan DeKok. > > > Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 13:51: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 NAA05919 for ; Sat, 18 Sep 2004 13:51: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 i8IHN7UO095019; Sat, 18 Sep 2004 10:23: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 i8IHN7Ln095018; Sat, 18 Sep 2004 10:23:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IHN274094995 for ; Sat, 18 Sep 2004 10:23:03 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C8ivL-0007Va-00 for ; Sat, 18 Sep 2004 19:22:59 +0200 Received: from du-042-113.access.de.clara.net ([213.221.65.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Sep 2004 19:22:59 +0200 Received: from nobody by du-042-113.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Sep 2004 19:22:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: draft-ietf-marid-mailfrom-00 (was: New Drafts) Date: Sat, 18 Sep 2004 19:22:07 +0200 Organization: Lines: 37 Message-ID: <414C6EBF.674F@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-113.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > draft-ietf-marid-mailfrom-00 Thanks, it's almost ready, and it covers the mandatory case (empty Return-Path) of HELO checks in SPF1. I like it very much. Six typos and other observations: Line 363 (typo) << to determine the list hosts that they allow to use their domain name >> to determine the list of hosts that they allow to use their domain Line 415 (policy violation) << Tests against some other identity may also be used to override the << test against the "Mail From" identity. >> Line 455 (designated open relays can be used with spf2.0/mfrom) << However, the use of open MTA relays on the Internet has long been << noted as a security problem. Most sites do not run open relays and << many refuse e-mail from known open relays. >> Line 465 (typo) << published SPF records must authorized any MTAs >> published SPF records must authorize any MTAs Line 472 (typo) << Internal MTAs then do not perform the authorization test To >> Internal MTAs then do not perform the authorization test. To Line 507 ff. (deficits of "exp" are a matter of protocol) << The explanation may contain URLs that may be malicious, and/or << offensive or misleading text. >> Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 14:33:36 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 OAA08051 for ; Sat, 18 Sep 2004 14:33: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 i8II6UYF098357; Sat, 18 Sep 2004 11:06: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 i8II6Uv4098356; Sat, 18 Sep 2004 11:06:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8II6RmY098343 for ; Sat, 18 Sep 2004 11:06:29 -0700 (PDT) (envelope-from SRS0+19bad5fc43a4758fd958+391+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8jbE-0004xU-7w; Sat, 18 Sep 2004 14:06:17 -0400 Subject: Re: Why we should authenticate multiple identities From: David Woodhouse To: Meng Weng Wong Cc: Roy Badami , John Levine , ietf-mxcomp@imc.org In-Reply-To: <20040918154928.GN23667@dumbo.pobox.com> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> <20040918154928.GN23667@dumbo.pobox.com> Content-Type: text/plain; charset=UTF-8 Date: Sat, 18 Sep 2004 19:01:14 +0100 Message-Id: <1095530475.5065.152.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 2004-09-18 at 11:49 -0400, Meng Weng Wong wrote: > The SPF story goes like this: > > "If I don't publish SPF records, what have I got to lose?" > > "Spammers might spoof with your domain name in the > return-path or the headers." > > "Will people reject my mail simply because I have no SPF > record?" > > "Considering that lots of domains have no SPF record, > that day is pretty far off. Though you never know how > aggressive some people might get." > > "Then why should I bother?" > > "Because when people forge your domain name in the > return-path or the headers, you get the bounces, and > your users get phished. Is that a problem for you?" > > "Oh, then yes, that is a problem." Actually the DK/IIM/etc. story about true end-to-end authentication goes like that too. It's at _this_ point that they diverge, and you left out the end of the story. The SPF story continues like this: "This phishing is mostly academic, but would be nice to stop. But more importantly, I did this SPF record and now there are people out there who are rejecting my _real_ email. That's more important to me. They tell me I should stop publishing a record like you say. What is the truth?" "Er, um, er. They should upgrade because the way the whole world works is different now." "I asked around and they say that this hasn't changed for years and you are being naïve. Did you trick me? Do we need to wait for everyone out there to change the way that Internet email works first? I removed my SPF records." Now when we come to them with the same conversation about DK/IIM/whatever, they're going to tell us to get stuffed. This is going to be _entirely_ counterproductive in the long run. If you want true authentication, implement a true end-to-end scheme rather than a hop-by-hop scheme which cannot ever solve the problem. MARID has its place but this is _not_ it. We need to stop disingenuously selling SPF/SenderID as a real authentication scheme. Those who sell it like this are doing us _all_ a disservice because they're going to severely hurt adoption of whatever true authentication scheme is settled upon by those groups who are working on it as we speak. As for selling SPF as a method to stop bounces -- that's just bizarre. BATV/SES are a totally effective way of doing that, without requiring _anything_ of third parties for the 'publisher' to get the benefit. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 14:37: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 OAA08249 for ; Sat, 18 Sep 2004 14:37:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IICGv7099057; Sat, 18 Sep 2004 11:12: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 i8IICGAj099056; Sat, 18 Sep 2004 11:12:16 -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 i8IICFvf099050 for ; Sat, 18 Sep 2004 11:12:15 -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 i8IIORN2004856; Sat, 18 Sep 2004 11:24:27 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8IIORBV004851; Sat, 18 Sep 2004 11:24:27 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 18 Sep 2004 11:24:27 -0700 (PDT) From: "william(at)elan.net" To: Meng Weng Wong cc: Roy Badami , John Levine , Subject: Re: Why we should authenticate multiple identities In-Reply-To: <20040918154928.GN23667@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 Sat, 18 Sep 2004, Meng Weng Wong wrote: > A patent application is not a patent; I understand that > nowadays applications are filed containing many claims that > the filer doesn't actually expect to be approved, but if > they are approved, bonus! At the same time we also heard that only the most obvious claims are rejected and that most are not and patent office is expecting that if patent does not have a leg to stand on then it'll not be possible to defend in court. > So let's look at which claims we > can realistically expect to survive into patent form, and do > our best to educate the patent office about the rest. It appears patent office will ignore any attempts to contact them regarding patent applications other then your own (i.e. you can contact them in regards to somebody else patent application only as long as it has anything to do with your own patent application and they conflict). > The ones that do make it into the patent may not turn out to be > an encumbrance after all, or if they are an encumbrance at > least we have a solid idea of how to route around them. Hard to say... > On Sat, Sep 18, 2004 at 12:34:13PM +0100, Roy Badami wrote: > | > | I don't think that's true. The domain/IP verification schemes > | directly address forgery, in a way that CSV doesn't. Think about > | Sender ID as a tool for senders who (for whatever reason) want to be > | able to prevent others from sending forged mail claiming to be from > | them. > > I agree that the anti-fraud aspects of SPF/Sender ID are > stronger than CSV, and should not be abandoned just yet. Lets separate SPF from SenderID - they are in no way equivalent terms. I see these terms as follows: "SPF" is protocol in a way that it defines record format for representation of policy record in dns that can whitelist or blacklist certain ip addresses "SPF Classic" (now SPF Mail From) is using SPF protocol to protect RFC2821 Mail From (aka ReturhPath) identity of email system SenderID is using SPF protocol to protect a validate new PRA identity based on combination of RFC2822 headers From, Sender, Resent-From, Resent-Sender > CSV alone is not sufficient because it has a weaker > deployment driver than SPF / Sender ID. To wit: Agreed. And CSV Authors themselve have proposed extensions to protect RFC2821 Mail-From. > So it seems to me that the average domain owner has a more > compelling case to do SPF than CSV. I'm not saying nobody > will do CSV: I fully expect ESPs and ISPs to do CSV on their > MTAs, but you're not going to see uninterested parties > putting negative CSV assertions on all the other hostnames > that could be HELO'ed by MTAs. By contrast, I expect many > more people to put SPF records on their domains because the > benefits are more immediate and more apparent. I do not think that we should do CSV + SPF (but its not a strong believe as long as both are clearly standartized, its ok - I just think its easier for implementation if ways to protect different identities is done in simular way). I think that it would be better for overall standartization process if we go with either CSV+MPR or Unified SPF (From + EHLO + PTR + etc) with standard defined list of protected identities base on each method. > | As a tool for recipients, Sender ID and CSV both provide a hook on > | which to hang reputation and accreditation systems, and I'm agnostic > | as to which will work better in the real world, though my feeling is > | that they may in fact turn out to be complementary. > > I agree that they will be complementary. In the same way > that restaurants offer a variety of eating options to > satisfy different needs, we should aim to offer a variety of > authentication options to accommodate the market better. Lets not compare Apples to Oranges .... There is a need to diverse options in the business market place, but there is also reason why we have unified list of standard internet protocols and why we have IETF for that matter. As an example we have SMTP protocol that is defined and we dont have multiple email systems (I note that in the IM world that is the case and its sad ...) but we do have quite a number of diverse mail clients that users can use and its very good that is so as it offers several interfaces to the system so that people can choose one that best suites their enviroment and his/her behavior in it. But in the end all this systems talk to each other no matter how diverse. > I have been observing a pattern of fallacious debate which can perhaps > be called "winner takes all". I do not believe that is the case. What is happening is that we're trying to decide on best technical solution that can become standard and by standard I mean something that everybody can implement. It is not unusual for IETF to consider multiple technical approaches on how to implement something, just recently on CRISP WG we had two ways for new whois database system - FIRS based on LDAP and IRIS based on XML over BEEP and both fully accomplished the requirements. In the LEMONADE WG we had two proposals on how to implement remote email submission that can include parts of existing email messages without downloading them to MUA. DNS extensions WG considered two ways to implement IPv6 dns records (A6 and AAAA), MULTI6 is considering several approaches on how to implement multihoming with IPV6, etc. There are lots and lots of workgroups that had before them several proposals and approachesto solutiona and they had to choose one - that is part of standartization process. It is in fact those situations where standartization failed and where opposting standards exist that created problems for deployement such is the case of S/MIME and PGP and neither one has achieved wide deployment as the programs supporting one often can not deal with the other type of signature. I do not wish to be in the same situation with solutions created by this WG and if we create something it must be something that everone can deply and implement and that verification systems are compatible with each other. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 14:37: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 OAA08266 for ; Sat, 18 Sep 2004 14:37:45 -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 i8IIGPEo099281; Sat, 18 Sep 2004 11:16: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 i8IIGPmS099280; Sat, 18 Sep 2004 11:16:25 -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 i8IIGP98099274 for ; Sat, 18 Sep 2004 11:16:25 -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 i8IIGDqC009966 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 18 Sep 2004 11:16:13 -0700 Subject: Re: Why we should authenticate multiple identities From: Douglas Otis To: Meng Weng Wong Cc: Roy Badami , John Levine , ietf-mxcomp@imc.org In-Reply-To: <20040918154928.GN23667@dumbo.pobox.com> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> <20040918154928.GN23667@dumbo.pobox.com> Content-Type: text/plain Message-Id: <1095531183.6480.76.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 18 Sep 2004 11:13:04 -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 Sat, 2004-09-18 at 08:49, Meng Weng Wong wrote: > A patent application is not a patent; I understand that > nowadays applications are filed containing many claims that > the filer doesn't actually expect to be approved, but if > they are approved, bonus! So let's look at which claims we > can realistically expect to survive into patent form, and do > our best to educate the patent office about the rest. The > ones that do make it into the patent may not turn out to be > an encumbrance after all, or if they are an encumbrance at > least we have a solid idea of how to route around them. > > On Sat, Sep 18, 2004 at 12:34:13PM +0100, Roy Badami wrote: > | > | I don't think that's true. The domain/IP verification schemes > | directly address forgery, in a way that CSV doesn't. Think about > | Sender ID as a tool for senders who (for whatever reason) want to be > | able to prevent others from sending forged mail claiming to be from > | them. > > I agree that the anti-fraud aspects of SPF/Sender ID are > stronger than CSV, and should not be abandoned just yet. Just as Sender-ID required making the PRA visible, making the validated MTA EHLO name visible would play the same role in preventing spoofing. To also aid those where the EHLO domain is different from that of the RFC2822 From, a simple name list provides a means of association which can be obtained within a single DNS lookup. This makes SPF/Sender-ID seem extremely clumsy for this purpose. > CSV alone is not sufficient because it has a weaker > deployment driver than SPF / Sender ID. To wit: > > Suppose we have lazy.example.com. We want to encourage > lazy.example.com to deploy whatever we come up with. But > they're lazy, so they naturally want to know the > consequences of noncompliance. > > "If I don't publish CSV records, what have I got to lose?" CSV would allow a low cost means of white-listing. Rather than obtaining hundreds of addresses that will need constant maintenance, the root MTA name plays that role. As I also illustrated with marid-mpr draft, this also greatly reduces overhead needed to associate ANY mailbox domain with the MTA. CSV lays a solid foundation for more advanced schemes like MPR later. > "Spammers might spoof with your HELO domain name." Actually, I find BATV more compelling in preventing the MAIL FROM spoofing than SPF. That would remove some SPF motivations. BATV provides this protection unilaterally. > "Will people reject my mail simply because I have no CSV > record?" I would expect any reputation scheme to evolve into known good, or known affiliations (verified by way of the CSV name), and have the unknown receive slow path treatment and perhaps extensive filtering. The motivation would be to restore an ability to send higher volumes of mail. A reputation scheme can not be based upon the identities obtained from either SPF or Sender-ID as these identities are far too weak. > "Considering that lots of MTAs don't even HELO with a > resolvable hostname, and we seem resigned to that, frankly > I'd have to say they're not going to reject your mail." Until there is also a CSV-CSA record discovered, then the advantages of being recognized will not exist. CSV will allow the validation of the MTA by name. CSV is resolved to change the depreciation of the EHLO name. > "Then why should I bother?" > > "Because it makes life easier for other people who'd be > victimized by spoofing --- we aim to get CSV records on > every legitimate HELO hostname in the world so we can > close that loophole." Currently there is a tremendous expense consumed by those that send mail using false identities. This may mean a phase-in aimed at slowing this flood of abusive mail. To consume less time looking through filtered mail, and to conserve the remaining network for productive uses, a combination of white-listing and slow path approaches should provide plenty of motivation. The white-list may even allow an ability to override an IP address black-list. > The SPF story goes like this: > > "If I don't publish SPF records, what have I got to lose?" > > "Spammers might spoof with your domain name in the > return-path or the headers." But if the domain leaves the SPF/Sender-ID list open to allow the acceptance of forwarded mail, then this will actually invite spoofing as a means of usurping the domain's reputation. : ( > "Will people reject my mail simply because I have no SPF > record?" > > "Considering that lots of domains have no SPF record, > that day is pretty far off. Though you never know how > aggressive some people might get." > > "Then why should I bother?" > > "Because when people forge your domain name in the > return-path or the headers, you get the bounces, and > your users get phished. Is that a problem for you?" BATV solves the bounce mail problem. SPF NEVER stops the phishing problem. Even Sender-ID would be a valuable tool for a confidence artist, as it allows easy means to either spoof of deceive the recipient. Displaying a validated EHLO name would be a much more difficult name to spoof and where financial institutions should make an effort to be consistent in their use of these EHLO names. Making the EHLO name visible when it is validate would also be motivation for the deployment of CSV records. Making this name visible would also provide valuable consumer protections that are not possible with SPF or Sender-ID. In addition, the use of these names does not tie consumers to a particular provider, nor will this name risk the reputation of a domain that uses the services of providers. CSV leaves the accountability with the providers. > "Oh, then yes, that is a problem." > > So it seems to me that the average domain owner has a more > compelling case to do SPF than CSV. I'm not saying nobody > will do CSV: I fully expect ESPs and ISPs to do CSV on their > MTAs, but you're not going to see uninterested parties > putting negative CSV assertions on all the other hostnames > that could be HELO'ed by MTAs. By contrast, I expect many > more people to put SPF records on their domains because the > benefits are more immediate and more apparent. The risks publishing SPF records will become more apparent when SPF based reputation becomes employed. Expect a flood of unhappy individuals and litigation. Should the validated EHLO domain become visible to the recipient, then this acts to protect their name. This can be confirmed by way of a simple list if needed. Why expend all the effort listing addresses over and over? > | As a tool for recipients, Sender ID and CSV both provide a hook on > | which to hang reputation and accreditation systems, and I'm agnostic > | as to which will work better in the real world, though my feeling is > | that they may in fact turn out to be complementary. > > I agree that they will be complementary. In the same way > that restaurants offer a variety of eating options to > satisfy different needs, we should aim to offer a variety of > authentication options to accommodate the market better. Although I would agree that SPF plays a more significant function than Sender-ID in combating spam, I suspect BATV remains a better solution in that respect. SPF or Sender-ID can not live up to the promise of providing trustworthy validations of the sending domain. > I have been observing a pattern of fallacious debate which > can perhaps be called "winner takes all". In this pattern, > when you are given a choice of N options, you are allowed to > pick only one: so proponents fight tooth and nail for their > favourite choice. This happens a lot because winning feels > good; many of us are trained to try very hard to win; and > besides, people who do not subscribe to this pattern of > living tend to be interest themselves in things other than > IETF working groups. There is a large infrastructure built upon an incredibly ubiquitous application. Retaining the scalability of this application also means considering the implications any scheme has upon routing and overhead. In my view, SPF and Sender-ID fail in those considerations. Making a cornucopia of options for what should be a universal method to send a message is also counter to such a goal. > Very often, though, in the real world, we end up with a > blend of multiple inputs, or we end up going with a > plurality of the choices that lie before us. Yesterday at > lunch we ordered the chocolate catheke *and* the key lime pie. > There's nothing inherently wrong with getting two desserts > instead of one. There are some operational considerations, > of course: it costs more, and we certainly didn't want to > order every single dessert on the menu just to have a taste. > In the same way, we probably don't want to tell the Internet > to have to do 512 different things; if we can limit our > recommendations to a small set of four or five they'll > probably find that livable. Any reasonable person who hears > "this is the one and only thing you have to do" will probably > think was a bit of a hard sell. > > The silly sort of "winner takes all" debate ends up looking > like: > > "Children, what is your favourite colour?" > - "I like yellow!" > - "I like blue!" > - "No you don't!" > - "Yes I do!" > > I am implementing a next-generation system based on the > Aspen model of authentication, reputation, accreditation. > In that system, I'll check authentication on SPFv1, SPFv2, > CSV, and Domain Keys. I'll check Spamhaus and Cloudmark > Rating and the VDL. Two heads are better than one, and > yellow and blue go very nicely together. Will you be providing the reputation services for SPF? -Doug From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 14:51:24 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 OAA08812 for ; Sat, 18 Sep 2004 14:51: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 i8IIOQKi099720; Sat, 18 Sep 2004 11:24:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IIOQLk099719; Sat, 18 Sep 2004 11:24:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IIOPa5099713 for ; Sat, 18 Sep 2004 11:24:25 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id C4293132D6A; Sat, 18 Sep 2004 14:24:22 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 550765D3; Sat, 18 Sep 2004 14:24:28 -0400 (EDT) Date: Sat, 18 Sep 2004 14:24:28 -0400 From: Meng Weng Wong To: David Woodhouse Cc: Meng Weng Wong , ietf-mxcomp@imc.org Subject: Re: Why we should authenticate multiple identities Message-ID: <20040918182428.GQ334@dumbo.pobox.com> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> <20040918154928.GN23667@dumbo.pobox.com> <1095530475.5065.152.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095530475.5065.152.camel@localhost.localdomain> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 18, 2004 at 07:01:14PM +0100, David Woodhouse wrote: | | This is going to be _entirely_ counterproductive in the long run. If you | want true authentication, implement a true end-to-end scheme rather than | a hop-by-hop scheme which cannot ever solve the problem. MARID has its | place but this is _not_ it. | I plan to implement DomainKeys as soon as a plugin is available for my MTA. Have you implemented it yet? | We need to stop disingenuously selling SPF/SenderID as a real | authentication scheme. Those who sell it like this are doing us _all_ a | disservice because they're going to severely hurt adoption of whatever | true authentication scheme is settled upon by those groups who are | working on it as we speak. | | As for selling SPF as a method to stop bounces -- that's just bizarre. | BATV/SES are a totally effective way of doing that, without requiring | _anything_ of third parties for the 'publisher' to get the benefit. I will try to clarify an important misunderstanding. SPF Classic targets the practice of return-path spoofing. The immediate benefit to publishers is that they will begin to get fewer bounces. But that is not the only benefit. The total benefit is that return-path spoofing will be reduced. Part of the harm of return-path spoofing is that undeliverable addresses generate cause bogus bounces. But another part of the harm of return-path spoofing is that deliverable addresses receive forgeries. A bounce may not get generated, but harm is still done. I agree that BATV/SES are the best solution to the stop-bogus-bounces problem, better than SPF Classic because they can be implemented unilaterally. The cost is only slightly higher than SPF Classic: both require domains to corral all their users into using the domain's approved servers. In addition, BATV/SES sign outbound return-paths. However, BATV/SES only limit the harm from the fraction of the mail that does bounce. It does not address the fraction of the mail that is delivered. SPF Classic and Sender ID do. Therefore, the benefit of SPF Classic goes beyond reducing bounces. Likewise, the purported benefit of Sender ID addresses phishing, which for whatever reason is not being addressed by true end-to-end methods today. When banks start DomainKeys or S/MIME signing all outbound mail, I promise to give up SPF and Sender ID. If you want me to stop campaigning for SPF and Sender ID, I suggest you focus your energies on the dependency. To reiterate my position: if you believe you have the One True Solution, please go and help make it happen. If you believe that someone else's One True Solution is wrong, it is more productive in the long run to work on your solution than attack somebody else's. Mathemeticians stand on each other's shoulders. Computer scientists stand on each other's feet. -- originally Richard Hamming, I think. From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 15:17: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 PAA10760 for ; Sat, 18 Sep 2004 15:17:04 -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 i8IIsCwZ001430; Sat, 18 Sep 2004 11:54: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 i8IIsC6X001429; Sat, 18 Sep 2004 11:54:12 -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 i8IIsB4L001423 for ; Sat, 18 Sep 2004 11:54:11 -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 i8IJ6afK005846; Sat, 18 Sep 2004 12:06:36 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8IJ6awl005842; Sat, 18 Sep 2004 12:06:36 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 18 Sep 2004 12:06:36 -0700 (PDT) From: "william(at)elan.net" To: Meng Weng Wong cc: David Woodhouse , Subject: Re: Why we should authenticate multiple identities In-Reply-To: <20040918182428.GQ334@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 Sat, 18 Sep 2004, Meng Weng Wong wrote: > On Sat, Sep 18, 2004 at 07:01:14PM +0100, David Woodhouse wrote: > | > | This is going to be _entirely_ counterproductive in the long run. If you > | want true authentication, implement a true end-to-end scheme rather than > | a hop-by-hop scheme which cannot ever solve the problem. MARID has its > | place but this is _not_ it. > > I plan to implement DomainKeys as soon as a plugin is > available for my MTA. Have you implemented it yet? No and I don't believe anybody else should either. That is unless you're prepared to loose legitimate email when it comes through email list. DK is badly engineered mail signature system that will cause many false positives - it falls particularly badly with maillists and with majority of other cases of email being reintroduced by gateways or intermediate email processors, in fact anything that changes headers in any way! If you want something that is ok consider MTA Signatures or possibly Cisco identified email proposal. Neither one is perfect, but at least there is not as much space for failures. > | We need to stop disingenuously selling SPF/SenderID as a real > | authentication scheme. Nobody does. But at the same time SPF offers ability to protect communication parameters of the transmission (envelope) and its a lightweight approach that can be more easily implemented and can allow to reject mesage before transmission even began. All encryption methods while offering a lot stronger protection, they also carry heavier penalties for those doing signatures and verification and they require a lot more changes to all MTAs to support it. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 17:18:48 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 RAA16575 for ; Sat, 18 Sep 2004 17:18:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IKoDZr009145; Sat, 18 Sep 2004 13:50:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IKoD8Y009144; Sat, 18 Sep 2004 13:50:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IKoCNi009135 for ; Sat, 18 Sep 2004 13:50:13 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C8m9w-0002IR-00 for ; Sat, 18 Sep 2004 22:50:16 +0200 Received: from pd9e91fb5.dip.t-dialin.net ([217.233.31.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Sep 2004 22:50:16 +0200 Received: from claus by pd9e91fb5.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Sep 2004 22:50:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) Subject: Re: Why we should authenticate multiple identities Date: 18 Sep 2004 22:26:00 +0200 Lines: 20 Message-ID: <9H4wMdJ3cDD@gmane.3247.org> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> <20040918154928.GN23667@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9e91fb5.dip.t-dialin.net User-Agent: OpenXP/3.9.8-cvs (Win32; Delphi) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong schrieb/wrote: > The SPF story goes like this: ... > "Oh, then yes, that is a problem." Some time later: "I'm getting more rouge bounces." "That's because some servers bounce messages when the SPF check failed." "I thought they should not do that." "Well, some do anyway." Claus -- http://www.faerber.muc.de From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 19:58: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 TAA24383 for ; Sat, 18 Sep 2004 19:58: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 i8INUdmw017882; Sat, 18 Sep 2004 16:30: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 i8INUdMC017881; Sat, 18 Sep 2004 16:30:39 -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 i8INUcO5017867 for ; Sat, 18 Sep 2004 16:30:38 -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 i8INUcKx022820 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 18 Sep 2004 16:30:39 -0700 Subject: Re: Why we should authenticate multiple identities From: Douglas Otis To: Meng Weng Wong Cc: David Woodhouse , ietf-mxcomp@imc.org In-Reply-To: <20040918182428.GQ334@dumbo.pobox.com> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> <20040918154928.GN23667@dumbo.pobox.com> <1095530475.5065.152.camel@localhost.localdomain> <20040918182428.GQ334@dumbo.pobox.com> Content-Type: text/plain Message-Id: <1095550049.6480.161.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 18 Sep 2004 16:27:29 -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 Sat, 2004-09-18 at 11:24, Meng Weng Wong wrote: > On Sat, Sep 18, 2004 at 07:01:14PM +0100, David Woodhouse wrote: > | > | This is going to be _entirely_ counterproductive in the long run. If you > | want true authentication, implement a true end-to-end scheme rather than > | a hop-by-hop scheme which cannot ever solve the problem. MARID has its > | place but this is _not_ it. > | > > I plan to implement DomainKeys as soon as a plugin is > available for my MTA. Have you implemented it yet? I suspect the ultimate solution for digital signatures will be a merger of IIM and DomainKeys. I'll wait to see how these solutions are resolved once MASS gets going. > | We need to stop disingenuously selling SPF/SenderID as a real > | authentication scheme. Those who sell it like this are doing us _all_ a > | disservice because they're going to severely hurt adoption of whatever > | true authentication scheme is settled upon by those groups who are > | working on it as we speak. > | > | As for selling SPF as a method to stop bounces -- that's just bizarre. > | BATV/SES are a totally effective way of doing that, without requiring > | _anything_ of third parties for the 'publisher' to get the benefit. > > I will try to clarify an important misunderstanding. > > SPF Classic targets the practice of return-path spoofing. > > The immediate benefit to publishers is that they will begin > to get fewer bounces. > > But that is not the only benefit. > > The total benefit is that return-path spoofing will be > reduced. > > Part of the harm of return-path spoofing is that > undeliverable addresses generate cause bogus bounces. The reason for the spoofed MAIL FROM strategy is to circumvent blacklists which prevent the message from being sent directly. BATV blocks this back-door technique entirely. A public version of BATV should also allow the return path to be discarded before an attempt to send the bounce is made. The message will be stopped before it is sent in most case however, even with the private mode. > But another part of the harm of return-path spoofing is that > deliverable addresses receive forgeries. A bounce may not > get generated, but harm is still done. By preventing the success of this strategy with BATV, there should be fewer such attempts over time. > I agree that BATV/SES are the best solution to the > stop-bogus-bounces problem, better than SPF Classic because > they can be implemented unilaterally. The cost is only > slightly higher than SPF Classic: both require domains to > corral all their users into using the domain's approved > servers. In addition, BATV/SES sign outbound return-paths. > > However, BATV/SES only limit the harm from the fraction of > the mail that does bounce. It does not address the fraction > of the mail that is delivered. SPF Classic and Sender ID do. BATV can be done by the MUA as well as the MTA. There is not a requirement to constrain where the message originates for the BATV scheme to still function. The granularity of the BATV can be over both users and time. Once implemented system wide, there will be a high percentage of bounces eliminated. SPF or Sender-ID schemes do not address the sources of abuse. Abusers can publish these records as well as legitimate domains. As both the SPF and Sender-ID identities are easily spoofed, these names are worthless for asserting a reputation without the risk of harming innocent domains. Their weak identities likely make these schemes more of a risk than an asset. > Therefore, the benefit of SPF Classic goes beyond reducing > bounces. Likewise, the purported benefit of Sender ID > addresses phishing, which for whatever reason is not being > addressed by true end-to-end methods today. Sender-ID does not address phishing! If anything a confidence artist will likely use the "validations" of Sender-ID as a means to establish credibility which can be done a number ways. If financial institutions adopt consistent EHLO names and have these validated names made visible, this would make phishing significantly more difficult. As it would be difficult to spoof the EHLO name, it is not likely to serve to falsely increase the credibility of a message. Unlike Sender-ID, a consistent field would be made visible which prevents the sneak path made possible by differences in the PRA selection algorithm. Until the MUA is upgraded to display this validated EHLO name information, nothing changes with respect to the level of reliance consumers are asked to give the mailbox addresses they see. In the case of Sender-ID, the PRA may be fully validated by the MTA, but the From can remain Big-Bank.com. Suggesting consumers can trust the mailbox domain once Sender-ID is in place would be extremely hazardous. > When banks start DomainKeys or S/MIME signing all outbound > mail, I promise to give up SPF and Sender ID. If you want > me to stop campaigning for SPF and Sender ID, I suggest you > focus your energies on the dependency. Just like Sender-ID and SPF, these signatures will not reduce the spam problem. With the higher overhead needed to process these signatures, it becomes even more urgent to address the spam issue for these technologies to be viable. > To reiterate my position: if you believe you have the One > True Solution, please go and help make it happen. If you > believe that someone else's One True Solution is wrong, it > is more productive in the long run to work on your solution > than attack somebody else's. Focus on goals more than a specific solution. It seems serious issues are not addressed out of a sheer desire to promote "the" solution irrespective of potential downsides. As was illustrated by the marid-mpr draft, taking two steps in the process actually takes less time, incurs less cost in terms of maintenance, and protects the customers of providers by not forcing a mailbox domain or allowing a provider's neglect to unfairly tarnish their domain's reputation. By the same token, responsible providers must be allowed to defend their address space from abusive customers. This is often done through transparent interception or port blocking. Devising a scheme that works for an end-to-end exchange is not appropriate for mail that must consider the use of a shared MTA. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 20:07:44 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 UAA24726 for ; Sat, 18 Sep 2004 20:07:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8INjAek018588; Sat, 18 Sep 2004 16:45:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8INjAoA018587; Sat, 18 Sep 2004 16:45:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend1.messagingengine.com (frontend1.messagingengine.com [66.111.4.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8INj9LE018580 for ; Sat, 18 Sep 2004 16:45:09 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: KiW9LAZj3y/f9FfgX6X5og 1095551111 Received: from [192.168.0.4] (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by www.fastmail.fm (Postfix) with ESMTP id 95E66C1564F; Sat, 18 Sep 2004 19:45:09 -0400 (EDT) Message-ID: <414CC8B1.6060902@elvey.com> Date: Sat, 18 Sep 2004 16:45:53 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Meng Weng Wong Cc: Roy Badami , John Levine , ietf-mxcomp@imc.org Subject: Re: Why we should (not) authenticate multiple identities References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> <20040918154928.GN23667@dumbo.pobox.com> In-Reply-To: <20040918154928.GN23667@dumbo.pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Meng Weng Wong wrote: >A patent application is not a patent; I understand that >nowadays applications are filed containing many claims that >the filer doesn't actually expect to be approved, but if >they are approved, bonus! So let's look at which claims we >can realistically expect to survive into patent form, and do >our best to educate the patent office about the rest. The >ones that do make it into the patent may not turn out to be >an encumbrance after all, or if they are an encumbrance at >least we have a solid idea of how to route around them. > That's important. Also, isn't anything that's provably prior art that makes it into the patent not an encumberance either? In other words, what will make it into the patent and can be successfully defended is the relevant question, yes? > >CSV alone is not sufficient because it has a weaker >deployment driver than SPF / Sender ID. To wit: > > I don't disagree with your arguments in support of this claim, but I disagree with the conclusion because of strong counterarguments. Here are some arguments that the opposite is true (an edited version of Meng's post): SPF / Sender ID alone is not sufficient because it has a weaker deployment driver than CSV / SPF3. To wit: Suppose we have lazy.example.com. We want to encourage lazy.example.com to deploy whatever we come up with. But they're lazy, so they naturally want to know the consequences of noncompliance. "If I don't publish CSV records, what have I got to lose?" "Spammers might spoof with your HELO domain name. Besides, it's quicker to do it than to spend a few minutes discussing 'why bother?'. Heck, if you don't run your own mail servers, you can just publish an empty record, which will ensure you have a good reputation when you decide you want to have your own mail servers. It's much, much easier than creating a good SPF1 record." "Will people reject my server's mail simply because I have no CSV record?" "If spammers spoof with your HELO domain name, it'll get blacklisted. They're going to reject your server's mail once that happens." "Oh, then yes, that is a problem. I'd better make a CSV record. There'll be CSV records on every legitimate HELO hostname in the world soon, so as to close that loophole, huh?" The SPF story goes like this: "If I don't publish SPF records, what have I got to lose?" "Spammers might spoof with your domain name in the return-path or the headers." "How do I create an SPF record to prevent this? My users send mail through servers like smtp.comcast.com. According to AOL's Hutzler, 'AOL already gets >85% of our spam from other ISPs main outbound MTAs.' "You can't. (Unless you force your users to use servers you control.)" "Will people reject my mail simply because I have no SPF record?" "No..." So it seems to me that the average domain owner has a more compelling case to do *CSV than SPF*. I'm not saying nobody will do SPF... >I have been observing a pattern of fallacious debate which >can perhaps be called "winner takes all". In this pattern, >when you are given a choice of N options, you are allowed to >pick only one: so proponents fight tooth and nail for their >favourite choice. This happens a lot because winning feels >good; many of us are trained to try very hard to win; and >besides, people who do not subscribe to this pattern of >living tend to be interest themselves in things other than >IETF working groups. > > Yes, the wannabe-standards can be seen as complementary. The IETF can endorse (so to speak) several of them. However, there's a cost to implementation of each one (and they vary!). To the extent that we can standardize on the minimum number that is sufficient to accomplish the goals best (in terms of, e.g. the amount of effort needed to implement them) we reduce the total cost of implementation. Given that all the proposals require A&R (Accredidation and Reputation Services) to be effective*, the amount of work needed for A&R should be considered important as well. (*notwithstanding Doug argument that that SPF-style A&R is nigh impossible.) Hence it's appropriate for you and I to argue, as we are doing, which is better. Remember all the effort that sysadmins went through to close open relays? It was thought that this would go a long way toward solving the spam problem. It failed to stem the tide. We need to have some confidence that when we go to sysadmins and ask 'em to do something else to solve the problem that it WILL stem the tide. Hence the urgent need for a *closely scrutinized / debugged* BCP on how M.A.R.I.D.s should be used. (Yes, I'm agreeing with William - we should choose one MARID scheme. >I am implementing a next-generation system based on the >Aspen model of authentication, reputation, accreditation. >In that system, I'll check authentication on SPFv1, SPFv2, >CSV, and Domain Keys. I'll check Spamhaus and Cloudmark >Rating and the VDL. Two heads are better than one, and >yellow and blue go very nicely together. > > Cool. I expect SpamAssassin will be doing much of this as well (not the SenderID bit!). OT: How does one access the VDL? David Woodhouse said: >We need to stop disingenuously selling SPF/SenderID > Yup. Claus Färber wrote: >... >Some time later: > > "I'm getting more rouge bounces." > > It's 'rogue'; folks keep misspelling it or I wouldn't mention it. > "That's because some servers bounce messages when the SPF check > failed." > > "I thought they should not do that." > > That's true but the spec itself doesn't say whether they should or not. Anyone want to work on the BCP? I'm thinking of putting it up on a wiki (the ASRG wiki, so that contributions are covered by needed policy) for collaborative improvement. From owner-ietf-mxcomp@mail.imc.org Sat Sep 18 22:21:23 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 WAA00073 for ; Sat, 18 Sep 2004 22:21:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J1tFcu025842; Sat, 18 Sep 2004 18:55:15 -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 i8J1tFM7025841; Sat, 18 Sep 2004 18:55:15 -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 i8J1t70A025825 for ; Sat, 18 Sep 2004 18:55:08 -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 38C4E16CC4 for ; Sat, 18 Sep 2004 22:04:33 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Trust, and who knows what (was Re: SPF abused by spammers ) In-Reply-To: Your message of "Sat, 18 Sep 2004 18:05:30 BST." <046101c49da1$b5296160$0200000a@ringo> Date: Sat, 18 Sep 2004 22:04:33 -0400 Message-Id: <20040919020433.38C4E16CC4@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Chris Haynes" wrote: > The recipient is invited to accept that the message _is_ from the > purported domain because the Sender's Policy says he should - she > has declared that shared MTA trustworthy. It's her message, her > policy, her choice of shared MTA. I can publish a record saying my MTA is the best in the world. That's my perogative as admin, but it doesn't mean that statement is an accurate refelection of reality. It's a statement of faith, and nothing more. > The receiver has to trust: > > 1) The DNS service to deliver the correct SPF policy for the domain > > 2) The IP transport system to report accurately the IP address of the sending > MTA. The recipient already trusts DNS & IP transport, independent of any additional records in DNS. Adding SPF or other records in DNS changes nothing about that trust. > The message has been identified as coming from the sender's domain, and the > sender has accepted responsibility for the behaviour of the MTA. Which is not the same as claiming the message actually originating from the sender. So why make that claim? Instead, claim that "MAIL FROM" checks means that the domain admits that the shared MTA can use it's name in MAIL FROM, and that the domain will accept the bounces from messages sent by that MTA, for messages which use it's name in MAIL FROM. > I invite you to be specific about this second trust relationship you talk of. I'm not sure what part of my message was unclear. a) An "originating" domain allows the shared MTA to send messages using it's name in "MAIL FROM". The recipient can verify that the name is being used, and that the "originating" domain has publicly stated that such use of it's name is permitted. b) An "originating" domain claims that when a shared MTA uses it's name in "MAIL FROM", that those messages are not being spoofed by another party sharing that MTA. The recipient has no way of proving to his own satisfaction that such a statement is true. Therefore, that statement has little or no meaning the recipient. It is useful solely as a statement about the "originating" domain's beliefs, and not as a statement reflecting any kind of objective reality. > Agreed - I don't think I was advocating a 'binary' value in the trust itself, > was I? No. > If you intend this as a criticism of SPF then you have to expose > these unspoken assumptions. It's not a criticism of SPF. > I'm not associated with any one scheme. I'm a 'sufferer' who needs > a workable, engineeringly-viable solution. That's pretty much my stance. I haven't seen anything dramatically useful, just a collection of tools which can help. > We are being > invited to consider the candidates one by one. This goes agains all my > engineering instincts, which are to: > > a) Agree the objectives and metrics of success, The charter already talks about MTA authorization records in DNS. To a certain extent, any discussion of the objectives is too late. > b) Identify all viable candidates, > > c) Assess them in parallel against the objectives, constructing interesting > scenarios, test cases etc. - against which all candidates can be evaluated. Yes, well, that would be nice. Instead, we have umpteen patent discussions, and few ways to determine which proposal is "better", or even if a proposal is "good enough". > It may well be that you can see some specific weakness in the use of > Mail-From that the rest of us cannot see and that you can do the WG > a service by exposing that specific weakness. I'm not sure it's a weakness, so much as a lack of information. The MAIL FROM isn't about the originator, it's about the bounce path. So all you know about any value used in MAIL FROM is: a) the SMTP client sent you that value b) that value might be an actual bounce path for the message Any "trust" in the MAIL FROM cannot be based on information which MAIL FROM does not contain: the identity of the originator. Any "trust" in MAIL FROM can only be based on the information which MAIL FROM does contain: the bounce path. > I've been trying to manoeuvre you into doing this with your 'trust' > concern. I'm genuinely trying to understand the 'space' in which > the receiver's trust or mistrust of the sending MTA matters to you. I understand, and I've tried to explain as best I can. > What is it that the sending MTA can do or not do which, whilst still > honoring the trust that the sender has in that MTA, causes Mail-From > to be flawed? It's not the MAIL FROM which is flawed, it's the ability of the recipient to believe the senders trust in the shared MTA, as anything other than a statement of faith made by the vender. Faith is nice for the believer, but it means nothing to someone else. Experiments, and directions for reproducing those experiments, are useful to both the experimentor and to anyone he's trying to convince. For MARID, unverifiable statements about a senders beliefs are faith, nothing more. Or, as Emily Dickinson said: Faith is a fine invention When gentlemen can see, But microscopes are prudent In an emergency. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 03:28:11 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 DAA29384 for ; Sun, 19 Sep 2004 03: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 i8J71GG0085815; Sun, 19 Sep 2004 00:01: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 i8J71GtH085814; Sun, 19 Sep 2004 00:01:16 -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 i8J71FUm085806 for ; Sun, 19 Sep 2004 00:01:16 -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 i8J710N7029269 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 19 Sep 2004 00:01:00 -0700 Subject: Re: IPR: analysis of Microsoft patent applications From: Douglas Otis To: Roy Badami Cc: David Woodhouse , John Levine , ietf-mxcomp@imc.org In-Reply-To: <16716.7477.80423.26426@giles.gnomon.org.uk> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> Content-Type: text/plain Message-Id: <1095577070.2686.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 18 Sep 2004 23:57:51 -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 Sat, 2004-09-18 at 04:34, Roy Badami wrote: > >>>>> "David" == David Woodhouse writes: > > David> When considered holistically, the domain/IP verification > David> schemes don't actually manage to achieve anything more than > David> CSV does -- they only give a way to determine how much to > David> trust the individual mail server which is offering the > David> mail. > > I don't think that's true. The domain/IP verification schemes > directly address forgery, in a way that CSV doesn't. Think about > Sender ID as a tool for senders who (for whatever reason) want to be > able to prevent others from sending forged mail claiming to be from > them. When financial institutions use consistent EHLO names for their MTAs and validated EHLO names are presented to users, then this too serves to foil forgeries. This depends upon users being able to recognize these names through their normal correspondence. The marid-mpr draft was to illustrate a simple name list could be used to confirm the message is within the nominal mail channel. The advantages using CSV/MPR over Sender-ID are as follows: a) The RFC2822 From will be marked out of the nominal mail channel irrespective of any other headers. b) A single DNS lookup is required to obtain the mailbox domain/MTA association. c) Phase-in is safer with reliance upon the EHLO name and not the mailbox domain. Until seen, there is no increased expectations. d) The EHLO is stronger, and more difficult to spoof than Sender-ID and allows for reputations to be safely asserted. e) Reputation assertions upon the EHLO name- 1) Isolate problems where this is not true for Sender-ID. 2) Does not constrain the use of the mailbox domain allowing provider choice. 3) Protects consumers from lax providers tarnishing their reputation. 4) Allows mailbox domain associations to safely be open without inviting spoofing exploits. > As a tool for recipients, Sender ID and CSV both provide a hook on > which to hang reputation and accreditation systems, and I'm agnostic > as to which will work better in the real world, though my feeling is > that they may in fact turn out to be complementary. Sender-ID does not provide a safe hook for reputation assertions nor does it provide good forgery protection as it can be easily spoofed. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 06:26: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 GAA07155 for ; Sun, 19 Sep 2004 06:26:32 -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 i8JA5IOU046859; Sun, 19 Sep 2004 03:05: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 i8JA5IjH046858; Sun, 19 Sep 2004 03:05:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JA5DJ6046798 for ; Sun, 19 Sep 2004 03:05:18 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1C8yZB-000FgX-00 for ietf-mxcomp@imc.org; Sun, 19 Sep 2004 11:05:10 +0100 Message-ID: <055a01c49e2f$a98454d0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: Proposal for VERIFIED keyword Date: Sun, 19 Sep 2004 11:01:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Problem statement ------------------ A shared MTA has to be trusted to have ensured that the sender is authorised to use the Mail-From address. There is no indication in the SMTP protocol, or in the message headers, that this verification is actually taking place on a message-by-message basis. Mis-configurations, operational errors, changes in policy, etc., could mean that the tests at the shared MTA have temporarilly ceased, yet the node is still being trusted. Senders who have declared their trust in the MTA by listing it with a '+' may have their trust betrayed; under these abnormal conditions the MTA may permit other users of the shared MTA to forge the mail-from address. This should be of particular concern to those senders who use a shared outbound MTA not under their administrative control (e.g. customers of most ISPs). New keyword -------------- We define an SMTP service extension which uses the keyword "VERIFIED" When an MTA is offering a verified message to a receiver which supports VERFIED, it MUST include the parameterless keyword VERIFIED in the MAIL FROM command. Example: MAIL FROM: fred@example.com VERIFIED Actions by sending MTA ------------------------ To verify the mail-from address the sending MTA MUST perform at least one of the following two tests: 1) It MAY verify the mail-from address using its own Sender-ID.mail-from test, and the test result MUST NOT be a 'fail' or, 2) It MAY receive the message through some other mechanism by which it has ensured that the entity which supplied it with the message was authorised to use that mail-from address. (Example : it could have perfomed SMTP AUTH and then checked in its own database that this authenticated entity is authorised to use that specific mail-from address). Messages which are not verified by at least one of the above two tests SHOULD NOT be offered for onwards transmission. If, they fail the verification but are nevertheless offered for onwards transmission, the "VERIFIED" keyword MUST NOT be used in the MAIL-FROM command. Actions by receiving MTA -------------------------- When the message is offered the receiving MTA SHOULD undertake the Sender-ID.mail-from tests in the usual way. If the VERIFIED keyword is not present, and the Sender-ID.mail-from test result was 'pass', the receiving MTA MUST downgrade the mail-from test result to 'neutral' ('?') before any further use is made of that test result. ================= This proposal covers the need to protect the sender's interests against operational errors, equipment failures, mis-configuration of MTA, policy changes etc. etc. at the site of the shared MTA. It does not protect against sites which are prepared to lie - but this should have been taken into account when the sender decided how much trust to have in that MTA when she formulated her SPF policy. It would also IMHO be a useful addition even when the outbound MTA is not shared and is within the sender's organisation. My advice to senders would be to only list as '+' those trusted MTAs which have committed to the use of VERIFIED. Indeed, the effect of my proposal is that messages sent through MTAs which do not yet support VERIFIED can NEVER be given a '+' test result - there MUST be a VERIFIED keyword present to achieve a '+' mail-from test result. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 07:12: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 GAA07156 for ; Sun, 19 Sep 2004 06:26:32 -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 i8JA0rr4044254; Sun, 19 Sep 2004 03:00: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 i8JA0r48044253; Sun, 19 Sep 2004 03:00:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost4.mail.uk.easynet.net (smarthost4.mail.uk.easynet.net [212.135.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JA0qJc044241 for ; Sun, 19 Sep 2004 03:00:53 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost4.mail.uk.easynet.net with smtp (Exim 4.10) id 1C8yV3-000A41-00 for ietf-mxcomp@imc.org; Sun, 19 Sep 2004 11:00:53 +0100 Message-ID: <055901c49e2f$103fe190$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <20040919020433.38C4E16CC4@mail.nitros9.org> Subject: Re: Trust, and who knows what (was Re: SPF abused by spammers ) Date: Sun, 19 Sep 2004 10:57:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "Alan DeKok" replied: > > It's not the MAIL FROM which is flawed, it's the ability of the > recipient to believe the senders trust in the shared MTA, as anything > other than a statement of faith made by the vender. > Ah! Now here we can agree. We may differ as to _whose_ trust is broken, but the crucial point is that a shared MTA is being trusted to have ensured that the sender is authorised to use the Mail-From. There is no indication in the SMTP protocol, or in the message headers, that this authorisation is actually taking place. I raised this problem as a criticism of PRA - where the MUA had no indication that the MTA had actually verified the PRA. Exactly the same criticism can now be directed at the current set of drafts. All sorts of operational errors, changes in policy, etc., could mean that the tests at the shared MTA have temporarilly ceased, yet the node is still being trusted. This should be of particular concern to those senders who use a shared outbound MTA not under their administrative control (e.g. customers of most ISPs). I've just posted a new thread "Proposal for VERIFIED keyword". Would something like this help your trust concerns? It would mine. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 08:26:09 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 IAA13063 for ; Sun, 19 Sep 2004 08:26: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 i8JBxjtk070298; Sun, 19 Sep 2004 04:59: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 i8JBxj1Q070297; Sun, 19 Sep 2004 04:59: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 i8JBxiDX070288 for ; Sun, 19 Sep 2004 04:59: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 i8JCCIna009387 for ; Sun, 19 Sep 2004 05:12:18 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8JCCHGb009384 for ; Sun, 19 Sep 2004 05:12:18 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 19 Sep 2004 05:12:17 -0700 (PDT) From: "william(at)elan.net" To: MARID Subject: SenderID name in use by somebody else 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: I have found that apparently both senderid.net and senderid.org domains are registered (to unknown party as whois info lists domainsbyproxy, but registration is dated Oct 2003 and thus is prior to MARID): http://www.completewhois.com/cgi-bin/whois.cgi?query=91739046&options=retrieve Looking at the website at http://www.senderid.org it appears they are adding "tm" to every use of SenderID on their website which makes me think they may have applied for a trademark. The website appears to indicate that these domains are related and setup by makers of software called MailKey. I'm not reallyfamiliar with that company but I seem to remember them being somewhatof an annoynance at ASRG last year with their stupid C/R implementation, some people even decided to filter them out: http://www1.ietf.org/mail-archive/web/asrg/current/msg02479.html Here is how SenderID is described on their website: What is SenderID(tm)? SenderID(tm) permits the identification of inbound emails which have "spoofed" (faked) "From" addresses. SenderID(tm) enabled servers also help people to authenticate the origin of emails sent from them; so SenderID(tm) messages can be trusted more than other messages. Using SenderID(tm) on outbound messages helps to reduce the risk of Identity Theft. The above description comes very close to wha MARID is doing (and appears to cover it), futher on webpage it says: What about legitimate exceptional IP addresses from which mail is sent? SenderID(tm) v1.1 will be compatible with the SPF authentication system developed by Meng Weng Wong. SPF allows the reverse look up, on the DNS system, of the exceptional IP addresses from which legitimate mail can be sent. Domains registered with SenderID(tm) can also list their exceptional IP addresses from which legitimate mail is sent at SenderID.org. SenderID(tm) software checks for the presence of any of these exceptional IP addresses on its central registry There is also a link to spf.pobox.com on their links page. So while I'm not entirely certain if they are trying to capilalize on our work or not, clearly their use of this name is in direct conflict to what MARID is doing It does also that they have a seniority on use of this name as for example is referenced in the following article back from Feb 2004: http://www.findarticles.com/p/articles/mi_pwwi/is_200402/ai_mark1121481067 As such I believe their use of SenderID predated this WG and its our use that is in conflict with their software and not the other way around. This gives them very good standing in court and otherwise and it may become a serious problem for us in the future, as such I STRONGLY advise this WG to reconsider futher use of the SenderID name in light of this conflict. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 09:00: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 JAA14509 for ; Sun, 19 Sep 2004 09:00: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 i8JCcxnU072198; Sun, 19 Sep 2004 05:38: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 i8JCcxbN072197; Sun, 19 Sep 2004 05:38:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JCcwbH072188 for ; Sun, 19 Sep 2004 05:38:58 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39679) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1C90xz-00076O-HH (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Sun, 19 Sep 2004 13:38:55 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C90xz-0007ZX-8O; Sun, 19 Sep 2004 13:38:55 +0100 Date: Sun, 19 Sep 2004 13:38:55 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Meng Weng Wong cc: ietf-mxcomp@imc.org Subject: Re: Why we should authenticate multiple identities In-Reply-To: <20040918182428.GQ334@dumbo.pobox.com> Message-ID: References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> <20040918154928.GN23667@dumbo.pobox.com> <1095530475.5065.152.camel@localhost.localdomain> <20040918182428.GQ334@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 18 Sep 2004, Meng Weng Wong wrote: > > I agree that BATV/SES are the best solution to the > stop-bogus-bounces problem, better than SPF Classic because > they can be implemented unilaterally. The cost is only > slightly higher than SPF Classic: both require domains to > corral all their users into using the domain's approved > servers. Incorrect: you can implement BATV on a per-user basis. Users can continue to work as they currently do, but if backscatter is a problem for them they can reconfigure as necessary (so that they always use authenticated message submission via the domain's home systems) and turn on BATV, without affecting other users of that domain. Tony. -- f.a.n.finch http://dotat.at/ HEBRIDES BAILEY: WEST BACKING SOUTHWEST 6 TO GALE 8, BECOMING CYCLONIC LATER IN BAILEY. SHOWERS THEN RAIN. GOOD BECOMING MODERATE OR POOR. From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 13:05: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 NAA29901 for ; Sun, 19 Sep 2004 13:05: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 i8JGYs7x087999; Sun, 19 Sep 2004 09:34:54 -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 i8JGYsid087998; Sun, 19 Sep 2004 09:34:54 -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 i8JGYrPs087992 for ; Sun, 19 Sep 2004 09:34:53 -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; Sun, 19 Sep 2004 12:34:55 -0400 id 000DBE03.414DB52F.000057D6 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: MARID From: Andrew Newton Subject: Re: SenderID name in use by somebody else Date: Sun, 19 Sep 2004 12:34:51 -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: Content-Transfer-Encoding: 7bit On Sep 19, 2004, at 8:12 AM, william(at)elan.net wrote: > As such I believe their use of SenderID predated this WG and its our > use > that is in conflict with their software and not the other way around. > This > gives them very good standing in court and otherwise and it may become > a > serious problem for us in the future, as such I STRONGLY advise this WG > to reconsider futher use of the SenderID name in light of this > conflict. After rereading Section 7.4 of RFC 3667, it would appear that it is not our place to judge the validity of this trademark registration. Either the IETF has been granted the right to the trademark in its reproduction of documents or it has not... and in this case I believe the latter is true. And unlike the issue of the patent application and patent license, this directly affects the liability of ISOC/IETF. I will consult with the PTB to verify this. -andy From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 13:59: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 NAA03802 for ; Sun, 19 Sep 2004 13:59: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 i8JHXP45092421; Sun, 19 Sep 2004 10:33: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 i8JHXPJO092420; Sun, 19 Sep 2004 10:33:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JHXNat092412 for ; Sun, 19 Sep 2004 10:33:24 -0700 (PDT) (envelope-from SRS0+cc5810394dac36bdc22f+392+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C95Yx-0006Nd-MI; Sun, 19 Sep 2004 13:33:24 -0400 Subject: Re: Why we should authenticate multiple identities From: David Woodhouse To: Meng Weng Wong Cc: ietf-mxcomp@imc.org In-Reply-To: <20040918182428.GQ334@dumbo.pobox.com> References: <20040917235142.24405.qmail@xuxa.iecc.com> <1095502538.5065.81.camel@localhost.localdomain> <16716.7477.80423.26426@giles.gnomon.org.uk> <20040918154928.GN23667@dumbo.pobox.com> <1095530475.5065.152.camel@localhost.localdomain> <20040918182428.GQ334@dumbo.pobox.com> Content-Type: text/plain Date: Sun, 19 Sep 2004 18:28:10 +0100 Message-Id: <1095614891.5065.252.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2004-09-18 at 14:24 -0400, Meng Weng Wong wrote: > I plan to implement DomainKeys as soon as a plugin is > available for my MTA. Have you implemented it yet? > When banks start DomainKeys or S/MIME signing all outbound > mail, I promise to give up SPF and Sender ID. The problem with DomainKeys is that it's not _ready_ yet. If my understanding is correct, it still actually breaks in the real world -- mail sent via mailing lists which add a few lines to the mail will appear to have a _broken_ signature. We need to make sure that is fixed first. As I said, it's massively counterproductive to sell something before it's ready, especially if it's going to reject valid mail. All you'll do is put people off and then they won't play when it really _does_ work. But it's being worked on. Be patient :) > I agree that BATV/SES are the best solution to the > stop-bogus-bounces problem, better than SPF Classic because > they can be implemented unilaterally. Right. > The cost is only slightly higher than SPF Classic: both require > domains to corral all their users into using the domain's > approved servers. As Tony pointed out, that's not strictly necessary. I currently implement SES on an opt-in basis. You can instantly stop getting any bounces to mail you didn't send -- but you have to start using SMTP AUTH. It's a per-user choice (actually per-address). > However, BATV/SES only limit the harm from the fraction of > the mail that does bounce. It does not address the fraction > of the mail that is delivered. SPF Classic and Sender ID do. Actually SES _can_ address the fraction of the mail that is delivered. Try delivering MAIL FROM: to any machine which does SMTP sender verification callouts, for example. I appreciate that callouts are unpopular in some quarters -- the use of a stunt DNS server and something like the SPF 'exists' mechanism has also been suggested, as a way to assist recipients in identifying fake messages. > To reiterate my position: if you believe you have the One > True Solution, please go and help make it happen. If you > believe that someone else's One True Solution is wrong, it > is more productive in the long run to work on your solution > than attack somebody else's. To a certain extent I agree with that sentiment, but not entirely. For a start I don't like your choice of pronouns. We're all in this together; there should be no 'us and them'. If we sell them snake oil now, they're less likely to trust us later when we _do_ get the formula right. If I didn't think that SPF was actively harmful in the long run, I wouldn't argue against it. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 14:25: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 OAA04900 for ; Sun, 19 Sep 2004 14:25: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 i8JHvp4w093581; Sun, 19 Sep 2004 10:57: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 i8JHvpkZ093580; Sun, 19 Sep 2004 10:57:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JHvpI1093573 for ; Sun, 19 Sep 2004 10:57:51 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i8JHvo3V013758 for ; Sun, 19 Sep 2004 10:57:50 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 4C3B584F865; Sun, 19 Sep 2004 10:57:50 -0700 (PDT) Date: Sun, 19 Sep 2004 10:57:50 -0700 From: "Mark C. Langston" To: IETF MARID WG Subject: Re: Trust, and who knows what (was Re: SPF abused by spammers ) Message-ID: <20040919175750.GG1070@bitshift.org> References: <20040919020433.38C4E16CC4@mail.nitros9.org> <055901c49e2f$103fe190$0200000a@ringo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <055901c49e2f$103fe190$0200000a@ringo> User-Agent: Mutt/1.4.1i X-Uptime: 10:54AM up 17 days, 16:50, 14 users, load averages: 0.00, 0.04, 0.02 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Sep 19, 2004 at 10:57:22AM +0100, Chris Haynes wrote: > > "Alan DeKok" replied: > > > > It's not the MAIL FROM which is flawed, it's the ability of the > > recipient to believe the senders trust in the shared MTA, as anything > > other than a statement of faith made by the vender. > > > > Ah! Now here we can agree. We may differ as to _whose_ trust is broken, but the > crucial point is that a shared MTA is being trusted to have ensured that the > sender is authorised to use the Mail-From. There is no indication in the SMTP > protocol, or in the message headers, that this authorisation is actually taking > place. > But with SPF, the trust you're being asked to place is not whether the sender is authorized to use that MAIL FROM:; it's whether the entity connecting to your MTA (the destination MTA, presumably) is one associated with the MAIL FROM: RHS. It's a somewhat subtle, but important, distinction. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 15:15: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 PAA08701 for ; Sun, 19 Sep 2004 15:15: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 i8JIoYtk095996; Sun, 19 Sep 2004 11:50:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8JIoYb1095995; Sun, 19 Sep 2004 11:50:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JIoXXI095987 for ; Sun, 19 Sep 2004 11:50:33 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8JIoZg12623; Sun, 19 Sep 2004 11:50:35 -0700 From: Dave Crocker To: Meng Weng Wong CC: X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Reply-To: Dave Crocker Date: Sun, 19 Sep 2004 11:31:11 -0700 Message-ID: <2004919113111.422144@bbprime> In-Reply-To: <1095550049.6480.161.camel@localhost.localdomain> Delivery-Date: Sun, 19 Sep 2004 11:31:11 -0000 Subject: Re: Why we should authenticate multiple identities 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 Meng, On Sat, 2004-09-18 at 11:24, Meng Weng Wong wrote: > A patent application is not a patent; I understand that > nowadays applications are filed containing many claims that > the filer doesn't actually expect to be approved, but if > they are approved, bonus! So let's look at which claims we > can realistically expect to survive into patent form, and do You are suggesting depending upon a particular Patent Office outcome. Patent processes are not nearly that predictable. Feel free to present some evidence to the contrary. In general Internet-scale adoption and use of technology is significantly constrained by the number of strategic dependencies to that adoption and use. Fewer is always markedly better. Each critical dependency can have unwanted outcomes, thereby jeopardizing the effort that depends on it. > I agree that the anti-fraud aspects of SPF/Sender ID are > stronger than CSV, and should not be abandoned just yet. First of all, let's be clear about focus, function and dependencies: SPF is mostly about validating a particular message's original sender. It does this indirectly, by authenticating the RFC2821.MailFrom. It relies on the authorization of the MTAs along the delivery path to each recipient. It requires on-going coordination between the originating sender, the administrator of the RFC2821.MailFrom's domain name and administrators of each MTA along the path the each recipient. SPF has no accreditation mechanisms. Sender-ID is mostly about validating a particular message's author. It does authentication of the RFC2822.From and authorization of the the MTAs along the delivery path to each recipient . It requires on-going coordination between the author, the administrator of the RFC2822.From's domain name and administrators of each MTA along the path the each recipient. These are often independent administrative authorities. Sender-ID as no mechanisms relating to accreditation. CSV is about validating the operator of a peer (client) MTA. It does authentication and authorization of the RFC2821.Helo/Ehlo domain name, used by that MTA. It requires on-going coordination between the operator of that domain name and the administrator the domain name used by the MTA in the RFC2821.Helo/Ehlo; this is typically the same administrative entity. CSV also does accreditation of that domain name. So the scope and focus of each of these is notably different. One therefore ought to be rather careful in comparing them. > CSV alone is not sufficient because it has a weaker > deployment driver than SPF / Sender ID. To wit: Assessing adoption and use incentives requires a tad more effort. What are the administrative requirements? Who must perform them? How often? What parts of the infrastructure must change? What problems does it solve? How do cost vs. benefit compare? And so on. SPF and Sender-ID require that someone responsible for generating or posting content must know ahead of time what MTAs their message will go through. That means that virtually every domain name must pre-register path records and must maintain them when new or different paths will be used. So, for example, the administrator of the originator's domain must know when the ISP who is running the MTAs changes IP Addresses for their MTAs. And SPF and Sender-ID break existing third-party origination and relaying scenarios. Hence, SPF and Sender-ID work comfortably only for some very simple scenarios. The fact that those scenarios are popular is seductive enough to make it easy to miss the challenges posed for other, entirely legitimate scenarios. Attempting to apply SPF or Sender-ID to those other scenarios requires changing the nature of email admin, ops and use. CSV requires that the operator of a client MTA use some domain name that supports CSV conventions. Any domain name will do. Hence the number of domain names to support is some orders of magnitude smaller than for SPF or Sender-ID. And CSV does not try to correlate message content with message path. So there is no requirement for ongoing "cross-talk" between administrative realms. Further, CSV cannot evaluate an individual message. Rather it permits assessing an operator's aggregate performance. SPF and Sender-ID cannot do this. CSV does not involve any changes to Internet-scale scenarios, such as forwarding. For all that, CSV and SPF/Sender-ID try to solve very different problems. SPF/Sender-ID try to ask whether a particular message is likely to be safe. CSV tries to ask whether a particular MTA operator is likely to be safe. > "Will people reject my mail simply because I have no CSV > record?" .... > "Will people reject my mail simply because I have no SPF > record?" These exemplars purport to go to the heart of what one can and cannot do with the different mechanisms. What the exemplars miss is that no one attempting to use them can reasonably assert a negative, in the absence of support by the client. Hence, these schemes are primarily useful only for making a positive assessment. That is the logic difference between confirming a sender that is on a whitelist, versus rejecting a sender that is not. It is essential to assume that no scheme will have very large-scale adoption anytime soon. Internet experience in changing existing services is quite consistent on this point. That ought to make us all pretty modest about our expectations. It also means we should validate that a scheme is useful when there is small-scale adoption; that is, when the typical case is that it is not supported. > "Considering that lots of domains have no SPF record, > that day is pretty far off. Though you never know how > aggressive some people might get." > "Then why should I bother?" > "Because when people forge your domain name in the > return-path or the headers, you get the bounces, and > your users get phished. Is that a problem for you?" This says that the SPF is useful for protecting against forged bounce addresses. For this we modify the email architecture and we incur on-going path registration costs. > So it seems to me that the average domain owner has a more > compelling case to do SPF than CSV. CSV is not for the 'average' domain owner. It is strictly for MTA operators. SPF and Sender-ID require on-going coordination between those average domain owners and MTA operators. CSV requires no such coordination between independent administrative entities. Care to re-consider your assessment about adoption and use incentives? > but you're not going to see uninterested parties > putting negative CSV assertions on all the other hostnames > that could be HELO'ed by MTAs. I re-read this statement a number of times and I still can't figure out what you are saying. > I have been observing a pattern of fallacious debate which > can perhaps be called "winner takes all". I've been observing a pattern of responding to all new issues with "we can fold that into [the undocumented] Unified SPF". And, yes, that sounds a lot like a winner take all model. What is troubling is that it misses the long and well-established lesson that schemes that try to be all inclusive usually fall down of their design, implementation, administration and operations complexity. d/ -- Brandenburg InternetWorking dcrocker@brandenburg.com +1.408.246.8253 From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 15:33: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 PAA09801 for ; Sun, 19 Sep 2004 15:33: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 i8JJ98f9096967; Sun, 19 Sep 2004 12:09: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 i8JJ98AB096966; Sun, 19 Sep 2004 12:09:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost4.mail.uk.easynet.net (smarthost4.mail.uk.easynet.net [212.135.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JJ97f6096960 for ; Sun, 19 Sep 2004 12:09:07 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost4.mail.uk.easynet.net with smtp (Exim 4.10) id 1C973f-000AKD-00 for ietf-mxcomp@imc.org; Sun, 19 Sep 2004 20:09:11 +0100 Message-ID: <069d01c49e7b$aa3c6fb0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <20040919020433.38C4E16CC4@mail.nitros9.org> <055901c49e2f$103fe190$0200000a@ringo> <20040919175750.GG1070@bitshift.org> Subject: Re: Trust, and who knows what (was Re: SPF abused by spammers ) Date: Sun, 19 Sep 2004 20:05:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "Mark C. Langston" opined: > > On Sun, Sep 19, 2004 at 10:57:22AM +0100, Chris Haynes wrote: > > > > "Alan DeKok" replied: > > > > > > It's not the MAIL FROM which is flawed, it's the ability of the > > > recipient to believe the senders trust in the shared MTA, as anything > > > other than a statement of faith made by the vender. > > > > > > > Ah! Now here we can agree. We may differ as to _whose_ trust is broken, but the > > crucial point is that a shared MTA is being trusted to have ensured that the > > sender is authorised to use the Mail-From. There is no indication in the SMTP > > protocol, or in the message headers, that this authorisation is actually taking > > place. > > > > > But with SPF, the trust you're being asked to place is not whether the > sender is authorized to use that MAIL FROM:; it's whether the entity > connecting to your MTA (the destination MTA, presumably) is one > associated with the MAIL FROM: RHS. It's a somewhat subtle, but > important, distinction. > I beg to differ. SPF can check the whole of the MAIL-FROM address, not just the RHS. You can construct policies which use the macro function to insert the LHS into a further look-up - thus giving a policy which is user-specific, not just domain-specific. A 'trusted' shared MTA must prevent cross-customer forgery to at least the level of granualarity of the corresponding SPF policy. So, to be _sure_ of providing the level of trust required in offering the message it must, I think, ensure that the whole Mail-From address LHS@RHS may be used by whatever entity is asking it to send the message. My language "sender is authorised to use..." relates to the tests which a trusted MTA server needs to undertake internally to discharge the trust that is placed in it, not to the semantics of the SPF test itself. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 15:52:22 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 PAA10936 for ; Sun, 19 Sep 2004 15:52:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JJTjTW098124; Sun, 19 Sep 2004 12:29: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 i8JJTjMQ098123; Sun, 19 Sep 2004 12:29:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JJTimo098117 for ; Sun, 19 Sep 2004 12:29:44 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8JJTig15194; Sun, 19 Sep 2004 12:29:44 -0700 From: Dave Crocker To: "Mark C. Langston" CC: IETF MARID WG X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Reply-To: Dave Crocker Date: Sun, 19 Sep 2004 12:29:42 -0700 Message-ID: <2004919122942.258756@bbprime> In-Reply-To: <20040919175750.GG1070@bitshift.org> Subject: Re: Trust, and who knows what (was Re: SPF abused by spammers ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark, On Sun, 19 Sep 2004 10:57:50 -0700, Mark C. Langston wrote: > But with SPF, the trust you're being asked to place is not whether the > sender is authorized to use that MAIL FROM:; it's whether the entity > connecting to your MTA (the destination MTA, presumably) is one > associated with the MAIL FROM: RHS. It's a somewhat subtle, but > important, distinction. I think that summarizing SPF as asking "whether the sender is authorized to use that MAIL FROM:" Rather than simply giving a different summary that is valid, could you please explain what is wrong with the semantics of this one? d/ -- Brandenburg InternetWorking dcrocker@brandenburg.com +1.408.246.8253 From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 16:07:09 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 QAA11759 for ; Sun, 19 Sep 2004 16:07: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 i8JJdXhn098549; Sun, 19 Sep 2004 12:39:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8JJdXl8098548; Sun, 19 Sep 2004 12:39:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JJdXjt098541 for ; Sun, 19 Sep 2004 12:39:33 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i8JJdZ3V016335 for ; Sun, 19 Sep 2004 12:39:35 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id CA04584F867; Sun, 19 Sep 2004 12:39:35 -0700 (PDT) Date: Sun, 19 Sep 2004 12:39:35 -0700 From: "Mark C. Langston" To: IETF MARID WG Subject: Re: Trust, and who knows what (was Re: SPF abused by spammers ) Message-ID: <20040919193935.GI1070@bitshift.org> References: <20040919175750.GG1070@bitshift.org> <2004919122942.258756@bbprime> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2004919122942.258756@bbprime> User-Agent: Mutt/1.4.1i X-Uptime: 12:33PM up 17 days, 18:30, 9 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Sep 19, 2004 at 12:29:42PM -0700, Dave Crocker wrote: > > Mark, > > > On Sun, 19 Sep 2004 10:57:50 -0700, Mark C. Langston wrote: > > But with SPF, the trust you're being asked to place is not whether the > > sender is authorized to use that MAIL FROM:; it's whether the entity > > connecting to your MTA (the destination MTA, presumably) is one > > associated with the MAIL FROM: RHS. It's a somewhat subtle, but > > important, distinction. > > I think that summarizing SPF as asking "whether the sender is authorized to use > that MAIL FROM:" > > Rather than simply giving a different summary that is valid, could you please > explain what is wrong with the semantics of this one? > Yes. Sorry for not being clear the first time. It's a problem for the reason pointed out by the poster to whom I was responding: it says nothing about the policies of the entity connecting to the MTA doing the SPF check. There's no way to know whether the original sender was, in fact, a legitimate claimant to that MAIL FROM:. The connecting MTA could be an open relay, allowing anyone to claim that MAIL FROM: and pass it through that MTA to the destination. If the SPF record checks out, the best you can say is that the connecting MTA is legitimately associated with that domain name. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 16:57: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 QAA14113 for ; Sun, 19 Sep 2004 16:57: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 i8JKV3Hf000382; Sun, 19 Sep 2004 13:31:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8JKV3f7000381; Sun, 19 Sep 2004 13:31:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JKV25A000375 for ; Sun, 19 Sep 2004 13:31:02 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8JKUug18860; Sun, 19 Sep 2004 13:31:03 -0700 From: Dave Crocker To: "Mark C. Langston" CC: IETF MARID WG X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Reply-To: Dave Crocker Date: Sun, 19 Sep 2004 13:30:52 -0700 Message-ID: <2004919133052.723648@bbprime> In-Reply-To: <20040919193935.GI1070@bitshift.org> Subject: Re: Trust, and who knows what (was Re: SPF abused by spammers ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 19 Sep 2004 12:39:35 -0700, Mark C. Langston wrote: > it says > nothing about the policies of the entity connecting to the MTA doing the > SPF check. Let's see: - The MailFrom contains a domain name. - Under that domain name, the client MTA is registered. - The client MTA does not have to give the domain name administrator "permission" - The client MTA *does* decide to carry the message containing that MailFrom So there really *is* a policy relationship between the creator of the MailFrom and the operator of the MTA. (An open relay is merely an MTA with a promiscuous policy.) > There's no way to know whether the original sender was, in > fact, a legitimate claimant to that MAIL FROM:. The connecting MTA > could be an open relay, allowing anyone to claim that MAIL FROM: and > pass it through that MTA to the destination. > If the SPF record checks > out, the best you can say is that the connecting MTA is legitimately > associated with that domain name. Oh. You are saying that there is a formal relationship between the MailFrom domain and the client MTA, but no enforcement of any relationship between the Mailfrom and the RFC2822.From or RFC2821.Sender? And, in fact, From or Sender can specify any MailFrom they want? Good point. However, the MailFrom domain presumably register client MTA addresses that it trusts. If the MailFrom domain administrator is registered addresses for open relays, that's their problem. In other words, the presumption is that the MailFrom domain very much is making an explicit decision about the acceptability of that client MTA. So, when the original sender chooses to go through a particular MTA, using a particular MailFrom, the presumption is that the administrator of that MailFrom trusts the posting policies of the client MTA. Presumably this means that the client MTA has appropriate controls on who can post. This would mean that the kind of possible MailFrom abuse you are suggesting would not be permitted by that Client MTA. So, this still sounds to me like " the sender is authorized to use that MAIL FROM:", albeit through a pretty obscure set of relationships. d/ -- Brandenburg InternetWorking dcrocker@brandenburg.com +1.408.246.8253 From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 18:47: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 SAA20119 for ; Sun, 19 Sep 2004 18:47: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 i8JMHcbf007015; Sun, 19 Sep 2004 15:17: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 i8JMHc7u007014; Sun, 19 Sep 2004 15:17:38 -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 i8JMHbFu007008 for ; Sun, 19 Sep 2004 15:17:37 -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 i8JMHdp3004447 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 19 Sep 2004 15:17:41 -0700 Subject: Re: Trust, and who knows what (was Re: SPF abused by spammers ) From: Douglas Otis To: Chris Haynes Cc: IETF MARID WG In-Reply-To: <069d01c49e7b$aa3c6fb0$0200000a@ringo> References: <20040919020433.38C4E16CC4@mail.nitros9.org> <055901c49e2f$103fe190$0200000a@ringo> <20040919175750.GG1070@bitshift.org> <069d01c49e7b$aa3c6fb0$0200000a@ringo> Content-Type: text/plain Message-Id: <1095632070.2686.123.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 19 Sep 2004 15:14:30 -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-09-19 at 12:05, Chris Haynes wrote: > "Mark C. Langston" opined: > > On Sun, Sep 19, 2004 at 10:57:22AM +0100, Chris Haynes wrote: > > > "Alan DeKok" replied: > > > > > > > > It's not the MAIL FROM which is flawed, it's the ability of > > > > the recipient to believe the senders trust in the shared MTA, as > > > > anything other than a statement of faith made by the vendor. > > > > > > Ah! Now here we can agree. We may differ as to _whose_ trust is > > > broken, but the crucial point is that a shared MTA is being > > > trusted to have ensured that the sender is authorized to use the > > > Mail-From. There is no indication in the SMTP protocol, or in the > > > message headers, that this authorization is actually taking place. > > > > But with SPF, the trust you're being asked to place is not whether the > > sender is authorized to use that MAIL FROM:; it's whether the entity > > connecting to your MTA (the destination MTA, presumably) is one > > associated with the MAIL FROM: RHS. It's a somewhat subtle, but > > important, distinction. > > I beg to differ. > > SPF can check the whole of the MAIL-FROM address, not just the RHS. > You can construct policies which use the macro function to insert the > LHS into a further look-up - thus giving a policy which is > user-specific, not just domain-specific. > > A 'trusted' shared MTA must prevent cross-customer forgery to at least > the level of granularity of the corresponding SPF policy. So, to be > _sure_ of providing the level of trust required in offering the > message it must, I think, ensure that the whole Mail-From address > LHS@RHS may be used by whatever entity is asking it to send the > message. > > My language "sender is authorized to use..." relates to the tests > which a trusted MTA server needs to undertake internally to discharge > the trust that is placed in it, not to the semantics of the SPF test > itself. There are a few security concerns using a script that can reference labels for a third parties (victims) to resolve in sequence. The ability to direct lookups to one DNS server and then another will identify the source port for some implementations. This then makes a birthday attack relatively simple. Using this label construction macro's ability to resolve valid users is also fraught with additional security problems. In addition with a need to create a replicate user list for each IP address used by the outbound MTA, the NXT function will allow this list to be discovered. As was illustrated by the marid-mpr draft, multiple MTA domains can be associated with a mailbox domain without requiring these dangerous subsequent DNS lookup on different servers. The TXT script approach may already overwhelm the DNS resolver. To include a function normally performed by the source domain only seems to be in denial of the problem. The dangerous macro language allows TXT, A, AAAA, MX, and PTR records to be queried using arbitrary labels. This seems like a really bad idea and one nearly impossible to defend, especially when the use is to grant authorizations. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Sep 19 19:32:57 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 SAA20136 for ; Sun, 19 Sep 2004 18:47: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 i8JMOMXM007550; Sun, 19 Sep 2004 15:24:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8JMOMFo007549; Sun, 19 Sep 2004 15:24:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JMOI2E007538 for ; Sun, 19 Sep 2004 15:24:19 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C9A6S-00058B-00 for ; Mon, 20 Sep 2004 00:24:16 +0200 Received: from du-042-195.access.de.clara.net ([213.221.65.195]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Sep 2004 00:24:16 +0200 Received: from nobody by du-042-195.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Sep 2004 00:24:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: draft-ietf-marid-protocol-03 (was: New Drafts) Date: Mon, 20 Sep 2004 00:12:37 +0200 Organization: Lines: 247 Message-ID: <414E0455.52EE@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-042-195.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > draft-ietf-marid-protocol-03 My observations in protocol-03 (minus typos and stuff already reported by Nate Lion): Line 7 ("Sender-ID" (tm)) << The SPF Record Format and Sender-ID Protocol >> The Sender Policy Framework (SPF) Record Format and Protocol Short title for all page headers: << The SPF Record Format and Sender-ID Protocol >> The SPF Record Format and Protocol Then replace the eight remaining strings "Sender-ID" by "SPF". --------------------------------------------------------------- Line 186 (delete) << A compliant domain SHOULD publish authorizations for every << defined scope. >> Big ISPs may not want to regulate how and where their users use "their" 2822-From. That's a matter of the policy of the domain owner, and it's the reason why we have more than one SPF scope. --------------------------------------------------------------- Lines 206 - 212 (3 typos and a dubious MUST) << When a mail receiver decides to perform a Sender-ID check, it << MUST implement and evaluate the check_host() function (see << below) correctly and follow the requirements of the particular << scope under test. >> When a mail receiver decides to perform a SPF check, it >> determines the result of the check_host() function (see >> below) following the requirements of the particular scope >> under test. SPF checks are defined in terms of the check_host() function, and definitions IMHO don't qualify for an additional MUST. << While the tests as a whole or optional, once it has been << decided to perform a test it must as performed specified << so that the correct semantics are preserved between << publisher and receiver. >> While the tests as a whole are optional, once it has been >> decided to perform a test it MUST be performed as >> specified so that the correct semantics are preserved >> between publisher and receiver. --------------------------------------------------------------- Line 244 (see also Nate's report) << This ensure that domains with published records and mail << receiver agree on the semantics of the scope. >> This ensures that domains with published records and mail >> receivers agree on the semantics of the scope. Or say "the mail receiver" instead of "mail receivers". --------------------------------------------------------------- Line 327 (delete) << A domain name MUST have a record of at least one type. >> Domains without sender policy are perfectly okay. --------------------------------------------------------------- Line 339 << A Sender-ID compliant check SHOULD lookup both types. If << both types of records are returned for a domain, the SPF << type MUST be used. >> A SPF compliant check SHOULD lookup both types if necessary. This SHOULD is about "do try both ways if the first way didn't work". It's not about receivers checking that both records are identical, that's entirely the problem of the publisher. The receiver is free to use whatever it gets first as is. --------------------------------------------------------------- Line 455 ff. (see also Nate's report) << 2.1.8 Minor Version Pleae move this stuff to section 2.1.2 (Version). --------------------------------------------------------------- Line 520 (typo) << The function check_host() take four arguments: >> The function check_host() takes four arguments: Line 590 (typo) << If the records are in a cache, and has not expired, then >> If the records are in a cache, and have not expired, then Line 660 (nitpick) << A given mechanism type may always appear multiple times >> A given mechanism type may appear multiple times --------------------------------------------------------------- Line 681 (not more than one CIDR) << mechanism = name [ ":" domain-spec ] *( "/" *DIGIT ) >> mechanism = name [ ":" domain-spec ] [ "/" *DIGIT ] --------------------------------------------------------------- Line 739 (KISS) << Global modifiers MAY appear anywhere in the record, but << SHOULD appear at the end >> Global modifiers SHOULD appear at the end As long as you don't say MUST the "MAY" is implied by a SHOULD. --------------------------------------------------------------- Line 758 (delete) << A modifier is not allowed to be defined as both global and << positional. >> That's IMHO obvious, same idea as for SINGULAR vs. MULTIPLE. --------------------------------------------------------------- Line 767 (typo ?) << An intended side effect of these rules is modifiers cannot << be defined that modify other modifiers. >> An intended side effect of these rules is that modifiers >> cannot be defined to modify other modifiers. --------------------------------------------------------------- Line 880 (typo) << When any mechanisms fetches host addresses to compare with >> When any mechanism fetches host addresses to compare with Line 887 (typo ?) << Should the server return domain does not exist (RCODE 3) >> Should the server return "domain does not exist" (RCODE 3) --------------------------------------------------------------- Line 909 (maybe) << Mechanisms after "all" will never be tested. >> Mechanisms after "all" will never be tested. Any "redirect" >> (5.1) has no effect in the presence of an "all" directive. Line 918 (maybe) << The , and arguments remain the same << as current evaluation of check_host(). >> The , and arguments remain always the >> same. --------------------------------------------------------------- Line 1012 (the MX priorities are here IMHO irrelevant) << Then perform an address lookup on each MX name returned, in << order of MX priority. >> Then it performs an address lookup on each MX name returned. --------------------------------------------------------------- Line 1189 (typo) << provide an way to extend the record format in the future >> provide a way to extend the record format in the future Line 1195 - 1198 (delete) << This document reserves two modifiers for future definition: << "accredit" and "match_subdomains". Until these are defined, << implementations SHOULD ignore them. There is also one deprecated << modifier: "default". Implementations MUST ignore it. >> This document is quite clear about unknown and future modifiers without this paragraph. Obviously implementations MUST ignore undefined modifiers. What else "SHOULD" they do, if returning random results is not an option ? --------------------------------------------------------------- Line 1211 (see also line 918) << The , and arguments remain the same as << current evaluation of check_host(). >> The , and arguments remain always the >> same. Line 1215 (typo ?) << the result of current evaluation. >> the result of the current evaluation. Line 1309 (typo) << a URL with the parameters check_host() >> a URL with the parameters of check_host() Line 1312 (upper case both Redirect ?) << during execution of a Redirect modifier, the explanation << string from the target of the redirect is used. >> during execution of a Redirect modifier, the explanation >> string from the target of the Redirect is used. Line 1394 (typo ?) << evaluation limit of an implementation is reached >> the evaluation limit of an implementation is reached --------------------------------------------------------------- Line 1466 (KISS) << macro-string = *( macro-char / v-char-ms ) >> macro-string = *( macro-char / v-char-dm / "/" ) Line 1473 (delete) << v-char-ms = %x21-24 / %x26-7E << ; visible characters except "%" >> Dito in lines 2076 and 2091 + 2092, get rid of v-char-ms, it's the same as v-char-dm or slash. --------------------------------------------------------------- Line 1467 and 2077 (ALPHA) << macro-char = ( "%{" ALPHA transformer *delimiter "}" ) Why not use the proper subset sSlLoOdDiIpPvVcCrRtT here ? --------------------------------------------------------------- Line 1485 (as reported by Nate) << o = domain of << d = >> o = original domain of >> d = of evaluated SPF record --------------------------------------------------------------- Line 1489 (typo ?) << v = the string "in-addr" for if is ipv4, or "ip6" if >> v = the string "in-addr" if is ipv4, else the string "ip6" What's the idea here, why not "ip4" resp. "in-addr.arpa" ? --------------------------------------------------------------- Line 1497 (undefined term) << t = current timestamp in UTC epoch seconds notation Please add a reference. Assume that I have an ISO timestamp for the year 2170 and need a %{t} formula, or vice versa. Line 1499 (dito) << uppercase versions of all these macros are URL-encoded. >> uppercase versions of all these macros are percent-encoded. IIRC that's now the preferred term (compare 2396bis) I'll try to read the remaining 800 lines in protocol-03 later, but as far as I'm concerned the stuff is as good as ready for standards track. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 10:09:44 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 KAA05102 for ; Mon, 20 Sep 2004 10:09: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 i8KDcR2Z088473; Mon, 20 Sep 2004 06:38:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8KDcRPf088472; Mon, 20 Sep 2004 06:38:27 -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 i8KDcEAo088454 for ; Mon, 20 Sep 2004 06:38:26 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 3F89126C0BD; Mon, 20 Sep 2004 15:38:07 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 3EE5026C0DC; Mon, 20 Sep 2004 15:38:06 +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 i8KDc58q695164; Mon, 20 Sep 2004 15:38:06 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 9F7E3FB6E; Mon, 20 Sep 2004 15:38:05 +0200 (CEST) Date: Mon, 20 Sep 2004 15:38:05 +0200 From: Stephane Bortzmeyer To: Mark Lentczner Cc: IETF MARID WG Subject: Re: New drafts Message-ID: <20040920133805.GA12084@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 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 Thu, Sep 16, 2004 at 12:41:46AM -0700, Mark Lentczner wrote a message of 36 lines which said: > I've submitted two drafts: > draft-ietf-marid-protocol-03 > draft-ietf-marid-mailfrom-00 I do not find a new version of draft-ietf-marid-core. Is anyone working on it? The version draft-ietf-marid-core-03 has at least two big problems: * depends on PRA so is not compatible with the new plan announced on Sept. 11th "co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004". * in its 7.2, contains wrong uses of Resent-* headers From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 10:21: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 KAA06624 for ; Mon, 20 Sep 2004 10:21: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 i8KDp8vh089232; Mon, 20 Sep 2004 06:51: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 i8KDp8co089231; Mon, 20 Sep 2004 06:51:08 -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 i8KDp7uc089225 for ; Mon, 20 Sep 2004 06:51:08 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 97E4E26C0E0; Mon, 20 Sep 2004 15:51:09 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 86BA126C0DB; Mon, 20 Sep 2004 15:51:08 +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 i8KDp88q690275; Mon, 20 Sep 2004 15:51:08 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 16AE1FB6E; Mon, 20 Sep 2004 15:51:08 +0200 (CEST) Date: Mon, 20 Sep 2004 15:51:08 +0200 From: Stephane Bortzmeyer To: Markus Stumpf Cc: David Woodhouse , MARID Subject: Language too strict in draft-ietf-marid-mailfrom-00 (Was: DEPLOY: Permitting '-all' to be used immediately represents a flag day. Message-ID: <20040920135108.GA12993@nic.fr> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915183930.GF37562@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, Sep 15, 2004 at 08:39:30PM +0200, Markus Stumpf wrote a message of 27 lines which said: > Why all the hassle. Let the people/market decide. > > - if someone publishes -all and gets important mail bounced s/he can > still decide to remove/change -all I agree. This is a local policy issue. The second paragraph in the section 2.2 of draft-ietf-marid-mailfrom-00.txt ("SHOULD publish SPF records that end in "-all") should be deleted or moved to "Security considerations" with a less demanding wording. From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 11:37:49 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 LAA13445 for ; Mon, 20 Sep 2004 11:37:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8KF9LCl098193; Mon, 20 Sep 2004 08:09:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8KF9LeG098192; Mon, 20 Sep 2004 08:09:21 -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 i8KF9KTJ098185 for ; Mon, 20 Sep 2004 08:09:20 -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 i8KF9DdZ029357; Mon, 20 Sep 2004 08:09:13 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Sep 2004 08:09:13 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Andrew Newton'" , "william(at)elan.net" Cc: MARID Subject: RE: SenderID name in use by somebody else Date: Mon, 20 Sep 2004 08:09:10 -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: The issue is not necessarily one of Registered Trademark protection. A registered trademark provides an advantage in establishing priority and in claiming damages BUT it is also possible to infringe a mark even if it is not registered. There is a common-law tort in the UK called 'Passing-Off'. It would be one thing if the other 'sender-id' mark was being used by a dohnut shop, but in this case the product is in the same field. I certainly do not want to end up with a lawsuit over a name. I like the idea of having a simple self-explanatory name. One thing that we might do is to use a name that has already been checked for trademark etc. We did this earlier with some names we were going to use for our email signing authentication scheme that we developed two years ago. I won't mention the name on the list though till I have checked on the IP. Phill > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Sunday, September 19, 2004 12:35 PM > To: william(at)elan.net > Cc: MARID > Subject: Re: SenderID name in use by somebody else > > > > > On Sep 19, 2004, at 8:12 AM, william(at)elan.net wrote: > > > As such I believe their use of SenderID predated this WG > and its our > > use > > that is in conflict with their software and not the other > way around. > > This > > gives them very good standing in court and otherwise and it > may become > > a > > serious problem for us in the future, as such I STRONGLY > advise this WG > > to reconsider futher use of the SenderID name in light of this > > conflict. > > After rereading Section 7.4 of RFC 3667, it would appear that > it is not > our place to judge the validity of this trademark > registration. Either > the IETF has been granted the right to the trademark in its > reproduction of documents or it has not... and in this case I believe > the latter is true. > > And unlike the issue of the patent application and patent > license, this > directly affects the liability of ISOC/IETF. > > I will consult with the PTB to verify this. > > -andy > From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 12:11:04 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 MAA16169 for ; Mon, 20 Sep 2004 12:11:04 -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 i8KFfvT2000761; Mon, 20 Sep 2004 08:41: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 i8KFfv55000760; Mon, 20 Sep 2004 08:41:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.geekstuff.tv (www.blogorama.co.uk [212.13.197.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8KFfuwr000753 for ; Mon, 20 Sep 2004 08:41:57 -0700 (PDT) (envelope-from pol@geekstuff.tv) Received: from chunky.intra.geekstuff.me.uk (spc2-ayle1-3-0-cust117.asfd.broadband.ntl.com [80.0.200.117]) by mail.geekstuff.tv (Postfix) with ESMTP id 4F7995B174; Mon, 20 Sep 2004 15:37:57 +0000 (GMT) From: "Paul S. Brown" To: "Hallam-Baker, Phillip" Subject: Re: SenderID name in use by somebody else Date: Mon, 20 Sep 2004 16:41:45 +0100 User-Agent: KMail/1.7 Cc: "'Andrew Newton'" , "william(at)elan.net" , MARID References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2848736.K73xm8aOFR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409201641.57492.pol@geekstuff.tv> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart2848736.K73xm8aOFR Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Monday 20 Sep 2004 16:09, Hallam-Baker, Phillip wrote: > The issue is not necessarily one of Registered Trademark protection. > > A registered trademark provides an advantage in establishing priority > and in claiming damages BUT it is also possible to infringe a > mark even if it is not registered. There is a common-law tort > in the UK called 'Passing-Off'. > > It would be one thing if the other 'sender-id' mark was being used > by a dohnut shop, but in this case the product is in the same field. > > > I certainly do not want to end up with a lawsuit over a name. I like > the idea of having a simple self-explanatory name. One thing that we > might do is to use a name that has already been checked for trademark > etc. We did this earlier with some names we were going to use for > our email signing authentication scheme that we developed two years > ago. I won't mention the name on the list though till I have checked > on the IP. > > > Phill > To stave off any potential comeback, assuming it's not already taken would = it=20 not be prudent to recommend changing the disputed mark to "Sender=20 Identification" - it's at least as meaningful and doesn't (as far as I know= )=20 conflict with any other registered trademarks. According to TESS the "sender-id" trademark lapsed in 2000.=20 Thoughts? =2D-=20 If Mind over Matter is a Matter of Course, Does it Matter if Nobody Minds? --nextPart2848736.K73xm8aOFR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBTvpF0Ak6hY/IMeIRAiPvAJ9/GHMeFgMEvNhlBVX8XxYBveJAqgCfbkn8 8HewD9hDwSrXxbHBGdBCkBk= =otvn -----END PGP SIGNATURE----- --nextPart2848736.K73xm8aOFR-- From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 14:58: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 OAA00594 for ; Mon, 20 Sep 2004 14:58: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 i8KI4lta014476; Mon, 20 Sep 2004 11:04:47 -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 i8KI4lR1014475; Mon, 20 Sep 2004 11:04:47 -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 i8KI4kRt014463 for ; Mon, 20 Sep 2004 11:04:46 -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 i8KIHYbX024350 for ; Mon, 20 Sep 2004 11:17:35 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8KIHYED024347 for ; Mon, 20 Sep 2004 11:17:34 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 20 Sep 2004 11:17:34 -0700 (PDT) From: "william(at)elan.net" To: MARID Subject: RE: SenderID name in use by somebody else 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: [I'm forwarding something that I originally answered in private, but I believe the answers (both to me & Andrew, and my reply) are of interest to MARID WG and IETF in general] > Andrew, > > Microsoft completed a trademark search and found that no issues. I > should note since we have gone public with using the name on June 1, > others have attempted to submit trademark applications, which will be > rejected due to prior usage. If the question is can it be "trademarked" > the answer is no. > > If the question if the name can be used without infringing on another > trademark, the answer is yes. > > PS - The proper use of the name is with a space between Sender & ID, not > as a single word. > > Hope this helps. Ok. That helps and explains why problem was not found, but I'll note that both on this list and in press and in many other places the name used was simply "SenderID", in other places such as latest version of protocol document it is "Sender-ID". There is clearly some confusion in the name even among the people who are developing the technology and I believe confusion will continue and as such the presense of "SenderID(tm)" from senderid.org with technology description so similar to ordinary person to Sender ID of MARID may lead people to wrong place which means problem adaption. Additionally I'll note that Microsoft in the past has filed legal actions against people and organizations that have used names that sound similar to its patented marks, for example just recently there was well publicised case of Microsoft vs Mike Rowe in regards to mikerowesoft.com Without taking a position on if Microsoft actions against Mike Row were appropriate or well supported by current laws, I'll note that presense of such disputes means that there are those that believe that trademark is more then just spelling, and as such if we continue with using "Sender ID", this might put IETF and ISOC in the position of being responsible for trademark infringement and might cause legal actions, which, no matter if IETF wins or not, is not a pleasent situation and something that we should try to avoid by minimizing possibility of name and trademark disputes in regards to terms used by IETF. I believe it would be appropriate for WG chairs to take this matter further with IESG or IAB (I think this is already being done) to decide the course of actions further in regards to IETF continuning use of the "Sender ID" name in its documents. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 15:56:09 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 PAA06386 for ; Mon, 20 Sep 2004 15:56: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 i8KJPSHQ022612; Mon, 20 Sep 2004 12:25: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 i8KJPS9C022611; Mon, 20 Sep 2004 12:25:28 -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 i8KJPRPF022603 for ; Mon, 20 Sep 2004 12:25:27 -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 D09E5414C4; Mon, 20 Sep 2004 12:25:24 -0700 (PDT) Subject: Re: Language too strict in draft-ietf-marid-mailfrom-00 (Was: DEPLOY: Permitting '-all' to be used immediately represents a flag day. From: Douglas Otis To: Stephane Bortzmeyer Cc: Markus Stumpf , David Woodhouse , MARID In-Reply-To: <20040920135108.GA12993@nic.fr> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> <20040920135108.GA12993@nic.fr> Content-Type: text/plain Message-Id: <1095708324.10961.84.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 20 Sep 2004 12:25:24 -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 Mon, 2004-09-20 at 06:51, Stephane Bortzmeyer wrote: > On Wed, Sep 15, 2004 at 08:39:30PM +0200, > Markus Stumpf wrote > a message of 27 lines which said: > > > Why all the hassle. Let the people/market decide. > > > > - if someone publishes -all and gets important mail bounced s/he can > > still decide to remove/change -all > > I agree. This is a local policy issue. The second paragraph in the > section 2.2 of draft-ietf-marid-mailfrom-00.txt ("SHOULD publish SPF > records that end in "-all") should be deleted or moved to "Security > considerations" with a less demanding wording. Publishing "open" records using "?all" or "+all" is not without risk and is the reason for indicating a SHOULD USE "-all". Unless there is a restructuring of the methods to authorize the MTA separately from the association of the MTA to mailbox domains, an "open" list will invite spoofing in a quest to falsely claim to be "authorized" by this mailbox domain. While such an "open" list is vital to ensuring mail is not lost, it also invites the problem SPF attempted to address in the first place. It is not reasonable to expect a near-term solution for this problem. This creates a quandary. The list can not be closed without causing mail to be lost, yet leaving the list open invites the problem that was supposedly being solved. It is also hazardous to allow unknown entities to dictate various DNS records of differing domains be looked up sequentially within a process that grants authorization. The many varied record types that SPF allows to be arbitrarily referenced dramatically increases the risk. This also opens up other security concerns as the message may reference a website using poisoned records. The means of delegation to other domains could be done by name and not by address to avoid this problem. By using a two step approach, the mailbox domain and MTA relationships can be name based. A list of names can be obtained in a single DNS query and does not require a script. This allows dropping use of TXT records as no amount of script changes or warnings offers a solution for the many fundamental design flaws: a) Prone to DNS record poisoning b) High overhead prone to DoS attack c) UDP exponential back-off ignored d) Allows phishing and spoofing e) Invites spoofing MAIL FROM! f) Identity easily spoofed to receive "Pass" or "Neutral" g) Identity does not locate source of abuse h) Identity does not accurately authorize the MTA i) Weak identity unsuitable for reputation assessment j) Script macros make SPF records unsuitable for white-listing k) Script macros allows spammers to hide their full address list l) Closed list will break mail m) Closed list may force use of provider's mailbox domain n) Process does not indicate records as "open" or "closed" o) MTAs not indicated as "shared" p) Can be used to falsely gain credibility by passing checks If this was a medicine, it would only make the patient sicker. Clearly the risks do not out weight the benefits. There is a viable solution however. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 16:29:36 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 QAA11924 for ; Mon, 20 Sep 2004 16:29:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8KK2VGa025846; Mon, 20 Sep 2004 13:02:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8KK2VRO025844; Mon, 20 Sep 2004 13:02:31 -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 i8KK2Vl4025837 for ; Mon, 20 Sep 2004 13:02:31 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 20 Sep 2004 16:02:33 -0400 id 001B7A99.414F3759.00006D9B Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <01D64F09-0B40-11D9-BE1D-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: MARID List From: Andrew Newton Subject: MARID Monday Date: Mon, 20 Sep 2004 16:02:32 -0400 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 Just a reminder... Jabber room: marid@ietf.xmpp.org Date: Every other Monday starting April 19 Time: 20:00 UTC Your Time: http://www.timeanddate.com/worldclock/fixedtime.html? day=19&month=4&year=2004&hour=20&min=0&sec=0&p1=0 -andy From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 16:51:36 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 QAA17227 for ; Mon, 20 Sep 2004 16:51:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8KKKTZ6027000; Mon, 20 Sep 2004 13:20:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8KKKTPj026999; Mon, 20 Sep 2004 13:20:29 -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 i8KKKTq8026985 for ; Mon, 20 Sep 2004 13:20:29 -0700 (PDT) (envelope-from jcouzens@6o4.ca) Received: (qmail 3388 invoked by uid 1006); 20 Sep 2004 20:20:31 -0000 Received: from unknown (HELO mailadmin.dev.6o4.ca) (24.85.96.241) by data.6o4.ca with SMTP; 20 Sep 2004 20:20:31 -0000 Received-SPF: neutral (data.6o4.ca: domain of jcouzens@6o4.ca is neutral about designating 24.85.96.241 as permitted sender) Subject: Re: Existing implementation of SPF1 for Exchange 2000? From: James Couzens Reply-To: jcouzens@6o4.ca To: ietf-mxcomp@imc.org In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7KORcTc3J5bBw+1iYnAs" Organization: 6o4.ca Message-Id: <1095711631.27945.140.camel@code3> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 20 Sep 2004 13:20:31 -0700 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-7KORcTc3J5bBw+1iYnAs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-09-17 at 09:01, Gordon Fecyk wrote: > I know Meng and crew went nuts developing a stack of libraries to support= SPF > v1 (yes v1, the same thing that AOL's using to check incoming mail). I'd > like to know if someone's developed an event sink for Exchange 2000 or 20= 03 > yet among that stack. As Meng has apparently already pointed out there is one available. It would be prudent to review the downloads page @ http://spf.pobox.com/downloads.html. > A really clever add-on could even automatically insert records into the D= NS > through dynamic update when the Exchange server starts. I almost give up. I've rewritten this response several times attempting to show my displeasure at finding (what I perceive to be) such an exceptionally bad idea being expressed on this list (yes I know by now I should be used to it (*COUGH* XML IN DNS *COUGH*)). But I'll give it a whirl anyways. Are you referring to dynamically updating an authoritative name server or a private internal one merely using the DNS server as a database? 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 --=-7KORcTc3J5bBw+1iYnAs 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) iD8DBQBBTzuPMagRinp8fc8RApL6AKDfO51KcvfqRjNzgfcG9KtjuiMd0QCeKsDA 93DsOKEvYX2DP4hEiIIKBcQ= =Mfl1 -----END PGP SIGNATURE----- --=-7KORcTc3J5bBw+1iYnAs-- From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 17:00: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 RAA19382 for ; Mon, 20 Sep 2004 17:00:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8KKUlSm027812; Mon, 20 Sep 2004 13:30:47 -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 i8KKUlKP027811; Mon, 20 Sep 2004 13:30:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8KKUj6K027805 for ; Mon, 20 Sep 2004 13:30:45 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C9Uo7-0002Mb-00 for ; Mon, 20 Sep 2004 22:30:43 +0200 Received: from 212.82.251.248 ([212.82.251.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Sep 2004 22:30:43 +0200 Received: from nobody by 212.82.251.248 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Sep 2004 22:30:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Language too strict in draft-ietf-marid-mailfrom-00 Date: Mon, 20 Sep 2004 22:27:47 +0200 Organization: Lines: 29 Message-ID: <414F3D43.2E20@xyzzy.claranet.de> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> <20040920135108.GA12993@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.248 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: >> if someone publishes -all and gets important mail bounced >> s/he can still decide to remove/change -all > I agree. This is a local policy issue. Yes and no. Yes, s/he can still decide to do something. But I'd never remove or change a -all, there are better options. Like using an alias of my address not covered by the sender policy. But so far I never had this problem. But I got about 180,000 bounces and other side effects of forged MAIL FROMs in six months (03-08). I'd never remove the -all voluntarily. And apparently no other user of claranet.de vanity hosts had any problem (the wildcard was added in May IIRC). > "SHOULD publish SPF records that end in "-all" > should be deleted or moved to "Security considerations" with > a less demanding wording. It's perfectly okay. SPF without -all is about as efficient as the new FUSSP RfC 3865 [some remarks about RfC 3865 censored, because this would cost me the write access to MARID]. So add whatever CAVEATs and warnings you want, but don't touch this SHOULD. SPF without -all is a complete waste of bandwidth and time. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 20:02: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 UAA08963 for ; Mon, 20 Sep 2004 20:02: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 i8KNVcjT041527; Mon, 20 Sep 2004 16:31: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 i8KNVc95041526; Mon, 20 Sep 2004 16:31:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8KNVb9B041518 for ; Mon, 20 Sep 2004 16:31:38 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: xEVl3nU2CVIrM1Y5aAljYQ 1095723096 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 895BC56D32F; Mon, 20 Sep 2004 19:31:36 -0400 (EDT) Message-ID: <414F68D1.2070003@elvey.com> Date: Mon, 20 Sep 2004 16:33:37 -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: Make CSV backwards compatible with SPF? 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 Here's the idea in a nutshell: CSV makes use of extant SPF records which already list tens of thousands of domains that are authorized for use in HELO. Who supports/opposes this change? Details: Perhaps a CSV that was backwards compatible with a simple subset of SPF1 records would be useful. SPF records that expect to result in an 'SPF pass' already must list the names used in HELO, so why not make use of that fact? There was a survey (I tried to find it, but failed) mentioned on list showing that ~95% of all SPF records were one of a dozen strings (-all, ~all, +a +mx -all, ...) that were resolvable with one DNS query (a link would be appreciated). Who thinks compatibility with a subset of SPF records would be an improvement to CSV? Domains could continue to publish one of these records, and would need do nothing else to be compatible with this revised CSV, or if they preferred more flexibility and/or wanted to be good neighbors, could publish normal CSV records. The subset could be defined as a)those that resolve to one of the n (e.g. n=12) most popular records, or b)records that use only, e.g. a, ptr, mx, ip4, or ip6 and fit in UDP. In either case, parsing issues, and the issues of TCP failover, TXT crowding and DNS providers that don't support CSV nearly disappear. The algorithm would be that a check is done for a CSV record first (and if found, only it is used); if none is found, a check is made for a conforming SPF record. Who would support this change? Would you prefer a CSV compatible with a larger set of SPF records? (Keep in mind that domains that aren't used in HELO don't need to have these records at all, as far as CSV is concerned. If you have a complex SPF record, that's OK - keep it. Just add a simple SPF record for the hostname you announce in HELO, or add a CSV record.) From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 20:09: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 UAA09373 for ; Mon, 20 Sep 2004 20:09: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 i8KNe1M9042054; Mon, 20 Sep 2004 16:40: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 i8KNe1NE042053; Mon, 20 Sep 2004 16:40:01 -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 i8KNdwaI042043 for ; Mon, 20 Sep 2004 16:39:58 -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 38BD8414C4; Mon, 20 Sep 2004 16:40:04 -0700 (PDT) Subject: Re: Language too strict in draft-ietf-marid-mailfrom-00 From: Douglas Otis To: Frank Ellermann Cc: MARID In-Reply-To: <414F3D43.2E20@xyzzy.claranet.de> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> <20040920135108.GA12993@nic.fr> <414F3D43.2E20@xyzzy.claranet.de> Content-Type: text/plain Message-Id: <1095723604.11083.264.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 20 Sep 2004 16:40:04 -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 Mon, 2004-09-20 at 13:27, Frank Ellermann wrote: > Stephane Bortzmeyer wrote: > > >> if someone publishes -all and gets important mail bounced > >> s/he can still decide to remove/change -all > > > I agree. This is a local policy issue. > > Yes and no. Yes, s/he can still decide to do something. But > I'd never remove or change a -all, there are better options. > Like using an alias of my address not covered by the sender > policy. You would not know which alias to use to overcome a problem that can not be known in advance. : ( > But so far I never had this problem. But I got about > 180,000 bounces and other side effects of forged MAIL FROMs in > six months (03-08). I would expect BATV will be a good solution for this problem. > I'd never remove the -all voluntarily. And apparently no other > user of claranet.de vanity hosts had any problem (the wildcard > was added in May IIRC). It is often difficult to know when a message simply goes missing. There would be no way of knowing which recipients are forwarding their messages. You are suggesting when a message does go missing, (perhaps without notice) that there be an alternative address to recover from the problem. It could be this assumption of acceptable losses holds because far fewer use SPF to reject mail than publish records. > > "SHOULD publish SPF records that end in "-all" > > should be deleted or moved to "Security considerations" with > > a less demanding wording. > > It's perfectly okay. SPF without -all is about as efficient as > the new FUSSP RfC 3865 [some remarks about RfC 3865 censored, > because this would cost me the write access to MARID]. So add > whatever CAVEATs and warnings you want, but don't touch this > SHOULD. SPF without -all is a complete waste of bandwidth and > time. Bye, Frank Although changing the structure of Sender-ID slightly does allow goals of the MARID charter to be safely achieved, I recognize this has not been the shared concept that brought the group together. I hope a few see such efforts as an earnest endeavor to achieve the goals of the MARID charter and not as an effort to thwart progress. By using a two step process, the recipients can be notified when a message is outside the nominal mail channel, and a name based list can be used to safely establish the MTA/Mailbox-domain relationship. An open SPF/Sender-ID list would be worse than a waste of bandwidth, but closing the list would make mail delivery unreliable. By having the MTA authorization separate from the mailbox domain association, there would much less motivation for spammers to utilize these open records. In the jabber session, there was a discussion looking for an a header to be inserted into the message associated with the sending MTA. I suggested the EHLO/Received: header, if validated using CSV, establishes an equally strong relationship as would adding a new header or redefining other existing headers. The advantage would be that these headers already exists and, once validated, would be suitable to associate the message with the sending MTA. Fix what we know to be broken first. Not authenticating the EHLO name is broken. Once the EHLO name is reliable, then this becomes an inflection point. With this long broken aspect of SMTP repaired, then the information needed to associate mailbox domains becomes dead simple and very safe. Such a solution allows the needed identity strength for asserting a reputation where much of the abuse will be abated. A validated EHLO alone would be extremely helpful in preventing spoofing and phishing. Sender-ID could simply build upon a foundation of "strengthened" existing structures. Sender-ID then becomes a simple name list to associate the mailbox-domain to MTAs. The goal of the MARID charter does not require that a script be used nor does the goal require an address list be used to define the Mailbox-domain/MTA relationship. As can be discerned by the potential downsides using addresses instead of names, the slight change being suggested is to use names rather than addresses. Fix what we know to be broken, and then add Sender-ID using names. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 20:49:24 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 UAA11397 for ; Mon, 20 Sep 2004 20:49: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 i8L0Lh82045898; Mon, 20 Sep 2004 17:21: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 i8L0LhLH045897; Mon, 20 Sep 2004 17:21: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 i8L0Lhkg045890 for ; Mon, 20 Sep 2004 17:21: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 C9628414C4; Mon, 20 Sep 2004 17:21:48 -0700 (PDT) Subject: Re: Make CSV backwards compatible with SPF? From: Douglas Otis To: Matthew Elvey Cc: MXCOMP In-Reply-To: <414F68D1.2070003@elvey.com> References: <414F68D1.2070003@elvey.com> Content-Type: text/plain Message-Id: <1095726108.11083.323.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 20 Sep 2004 17:21:48 -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 Mon, 2004-09-20 at 16:33, Matthew Elvey wrote: > Here's the idea in a nutshell: CSV makes use of extant SPF records which > already list tens of thousands of domains that are authorized for use in > HELO. > > Who supports/opposes this change? Ney. This is a repeat of an older debate. This would not be an improvement over the current CSV draft. SPF often requires a series of lookups to resolve an address list. This list is often not fully defined as it is commonly intended to associate mailbox domains with a much larger set of MTA addresses. It also may allow the EHLO domain to use SPF/Sender-ID records as a means to spoof, as these records are often open-ended. The host name used within the EHLO domain will require a separate record anyway, so why not use a record that achieves an answer within a single lookup? Why not use a different record which can not exploit a record intended to associate mailbox domains with MTAs? Making SPF/Sender-ID records an optional fall-back will only cause problems. SPF/Sender-ID does not need to be an "all for one, and one for all" record. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 22:18:55 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 WAA16815 for ; Mon, 20 Sep 2004 22:18:54 -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 i8L1muIv054862; Mon, 20 Sep 2004 18:48: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 i8L1muC7054861; Mon, 20 Sep 2004 18:48:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L1mrPs054846 for ; Mon, 20 Sep 2004 18:48:55 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: rDQjvaJEQcodK6cD2lsXVA 1095731333 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id D49D156D31E; Mon, 20 Sep 2004 21:48:52 -0400 (EDT) Message-ID: <414F88FE.6010109@elvey.com> Date: Mon, 20 Sep 2004 18:50:54 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis , MXCOMP Subject: Re: Make CSV backwards compatible with SPF? References: <414F68D1.2070003@elvey.com> <1095726108.11083.323.camel@ddev.mail-abuse.org> In-Reply-To: <1095726108.11083.323.camel@ddev.mail-abuse.org> 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 On 9/20/2004 5:21 PM, Douglas Otis sent forth electrons to convey: >On Mon, 2004-09-20 at 16:33, Matthew Elvey wrote: > > >>Here's the idea in a nutshell: CSV makes use of extant SPF records which >>already list tens of thousands of domains that are authorized for use in >>HELO. >> >>Who supports/opposes this change? >> >> > >Ney. > >This is a repeat of an older debate. > No, I'm making a different suggestion. Please read the whole post! I'm eliminating some or all of the records that you mention having a problem with below. I should have stated one thing clearly: only +type components of records would be relevant; ~type and ?type would be ignored. I registered your Nay on Jabber... >SPF often requires a series of lookups to >resolve an address list. This list is often not fully defined as it is >commonly intended to associate mailbox domains with a much larger set of >MTA addresses. It also may allow the EHLO domain to use SPF/Sender-ID >records as a means to spoof, as these records are often open-ended. > No open-ended records would be allowed. I don't think the fact that, e.g. +0/0 is allowed is of much concern, as spammers have demonstrated they can create MARID records for their own domains quite well; A&R are required. > The >host name used within the EHLO domain will require a separate record >anyway, so why not use a record that achieves an answer within a single >lookup? > We should, as my post makes clear. But there are reported to be what, ~300,000 SPF records? Why not use them to the extent that I suggest? From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 22:42: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 WAA18331 for ; Mon, 20 Sep 2004 22:42:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L282dM056732; Mon, 20 Sep 2004 19:08: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 i8L282xk056731; Mon, 20 Sep 2004 19:08:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L282Kr056721 for ; Mon, 20 Sep 2004 19:08:02 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id B18D3E0695; Mon, 20 Sep 2004 22:08:06 -0400 (EDT) Date: Mon, 20 Sep 2004 22:08:06 -0400 From: John Leslie To: Matthew Elvey Cc: MXCOMP Subject: Re: Make CSV backwards compatible with SPF? Message-ID: <20040921020806.GA8468@verdi> References: <414F68D1.2070003@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414F68D1.2070003@elvey.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Matthew Elvey wrote: > > Perhaps a CSV that was backwards compatible with a simple subset of > SPF1 records would be useful. I don't wish to support or oppose this; but some discussion might be helpful. Hopefully we can agree (for purposes of this discussion anyway) that the subset should be small. At first blush, there are exactly two useful cases: - "+a -all" - "-all" The first says that the exact list of address records (ipv4 or ipv6) are all authorized to act as MTAs using this domain string as the EHLO parameter; the second says that no host is authorized to use this domain string as the EHLO parameter. In the first case, another DNS query for the address records would be needed, which immediately raises two questions: - is the response going to fit in a UDP reply? If not, we add a lot of complexity, and problems with (poorly configured) firewalls could be an issue. - is the response going to return a complete list of address records, or are we facing a specialized DNS server which returns partial lists? If so, the situation is hopeless: we'd need to forbid this. IMHO, the "+a -all" case is a bad deal for CSV unless we define that the response MUST be the complete set and MUST fit in a standard-size UDP reply. The second case looks more useful: people _could_ publish wildcard TXT records to forbid a wide variety of subdomains as EHLO parameters. My personal thinking is that what we actually want is better accomplished by wildcard suggested-service PTR records; but I don't want to rule out other options. It's worth noting that CSV doesn't _need_ a way to publish prohibitions in order to accomplish its purpose. There _will_ be many domains without CSV policy published: if these domains only use IP address ranges with no history of email abuse, there's no reason they _need_ CSV authentication, authorization, and accreditation. CSV's great benefit is its ability to quickly disseminate accreditation information which is both positive and dependable. I agree there will be domains that want to make the prohibition of use of any subdomains as EHLO strings; and it _might_ be conceptually easier for managers of those domains to understand the use of SPF1 -all records for that purpose. (My thinking for such domains has been to _not_ publish a CSV SRV record, but publish a wildcard CSV PTR record with a target which will recommend _against_ trusting MTAs using that EHLO string.) -- John Leslie From owner-ietf-mxcomp@mail.imc.org Mon Sep 20 23:46:50 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 XAA21940 for ; Mon, 20 Sep 2004 23:46:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L31W1B060596; Mon, 20 Sep 2004 20:01:32 -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 i8L31Wqa060595; Mon, 20 Sep 2004 20:01:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L31T1r060584 for ; Mon, 20 Sep 2004 20:01:30 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C9auL-0000fA-00 for ; Tue, 21 Sep 2004 05:01:33 +0200 Received: from 212.82.251.248 ([212.82.251.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Sep 2004 05:01:33 +0200 Received: from nobody by 212.82.251.248 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Sep 2004 05:01:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Language too strict in draft-ietf-marid-mailfrom-00 Date: Tue, 21 Sep 2004 04:53:11 +0200 Organization: Lines: 73 Message-ID: <414F9797.36AB@xyzzy.claranet.de> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> <20040920135108.GA12993@nic.fr> <414F3D43.2E20@xyzzy.claranet.de> <1095723604.11083.264.camel@ddev.mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.248 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > You would not know which alias to use to overcome a problem > that can not be known in advance. : ( Not sure what you're talking about. Let's say that I send a mail to somebody AT infradead mentioned here in other threads. The receiver forwards this to a 3rd party without changing my MAIL FROM. The 3rd party says "you are not allowed to forge xyzzy addreses" and refuses to accept the mail. Infradead's MTA returns the mail to me. That's IMHO working as designed. I could fix this problem by using a MAIL FROM de.clara.net or another mailer (today with all these BLs around we all have at least one backup MSA, or at least I found that this is a MUST HAVE). But I wouldn't authorize the ill-behaved MTA to use my address, neither directly by adding this MTA to "my" sender policy, nor indirectly by modifying "-all" to something else. That's not how I understand SMTP, for me the MX is meant as the gateway to the receiver. It can forward, and relay, and do whatever it wishes, but it _must not_ say MAIL FROM xyzzy while talking with the MX of a 3rd party. If I'd wanted to send my mail to this 3rd MX, then I'd do it directly. Okay, it may change common practice for some systems, and it's obviously different from what Dave said, but OTOH we're here in MARID because there _is_ a problem with SMTP. Or rather more than one problem, spf2.0/mfrom fixes only one of the problems. > I would expect BATV will be a good solution for this problem. In theory it could be, but spf2.0/mfrom is something working today with my MUA and my ISP. They didn't have to do anything, only publish a sender policy with "-all". No new MTA. Spf2.0/mfrom also offers something for the receiver, the MX can reject all FAILs. That's also the reason why there SHOULD be a "-all" in sender policies: Without "-all" or similar without any FAIL mechanism at all, why should the receiver bother to evaluate the sender policy ? SPF is a voluntary cooperation between the (author of the) sender (policy) and the receiver, and without a chance to get a FAIL the receiver has no reason to cooperate. Maybe I'd even implement it this way, if a sender policy has no word starting with a "-" or a "redirect" stop the evaluation as waste of time (yes, that violates several MUST in protocol-03, but I could do it before calling check_host()). > It could be this assumption of acceptable losses holds > because far fewer use SPF to reject mail than publish > records. That's of course possible, but in my infradead scenario there are no losses. Hadmut published RMX in December 2002, RMX and SPF were discussed over and over again, SPF started in January 2004, and so far the number of unexpected side-effects appears to be minimal. Forwarders and mail forgers have to adjust, yes. But that's a feature and not a bug. I like it. Now please let's be done with it, get the two RfCs out a.s.a.p., and then start to work on other ideas like CSV, MTAMARK, or more SPF scopes. As long as SPF isn't ready I don't trust other ideas, because I'm not sure if that's only meant to derail SPF or create FUD. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 04:17: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 EAA22348 for ; Tue, 21 Sep 2004 04:17: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 i8L7c9LV038351; Tue, 21 Sep 2004 00:38: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 i8L7c9xu038350; Tue, 21 Sep 2004 00:38:09 -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 i8L7c9CI038340 for ; Tue, 21 Sep 2004 00:38:09 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 043BA26C0BC; Tue, 21 Sep 2004 09:38:09 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id DE08626C06D; Tue, 21 Sep 2004 09:38:07 +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 i8L7c78q885361; Tue, 21 Sep 2004 09:38:07 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 7E343FACE; Tue, 21 Sep 2004 09:38:07 +0200 (CEST) Date: Tue, 21 Sep 2004 09:38:07 +0200 From: Stephane Bortzmeyer To: Douglas Otis Cc: Frank Ellermann , MARID Subject: Re: Language too strict in draft-ietf-marid-mailfrom-00 Message-ID: <20040921073807.GA16199@nic.fr> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> <20040920135108.GA12993@nic.fr> <414F3D43.2E20@xyzzy.claranet.de> <1095723604.11083.264.camel@ddev.mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095723604.11083.264.camel@ddev.mail-abuse.org> 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 Mon, Sep 20, 2004 at 04:40:04PM -0700, Douglas Otis wrote a message of 90 lines which said: > I would expect BATV will be a good solution for this problem. Speaking of BATV, any implementation on the radar screen? Or a concrete syntax? At the present time, I only see draft-levine-mass-batv-00.txt. From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 04:17: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 EAA22372 for ; Tue, 21 Sep 2004 04:17: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 i8L7mvJn042008; Tue, 21 Sep 2004 00:48: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 i8L7mvuh042007; Tue, 21 Sep 2004 00:48:57 -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 i8L7muwN041996 for ; Tue, 21 Sep 2004 00:48:57 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 8792526C0C0; Tue, 21 Sep 2004 09:48:56 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 747A726C06D; Tue, 21 Sep 2004 09:48:55 +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 i8L7mt8q887542; Tue, 21 Sep 2004 09:48:55 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 43FBDFACE; Tue, 21 Sep 2004 09:48:55 +0200 (CEST) Date: Tue, 21 Sep 2004 09:48:55 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Cc: ietf-mxcomp@imc.org Subject: Re: Language too strict in draft-ietf-marid-mailfrom-00 Message-ID: <20040921074855.GA16530@nic.fr> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> <20040920135108.GA12993@nic.fr> <414F3D43.2E20@xyzzy.claranet.de> <1095723604.11083.264.camel@ddev.mail-abuse.org> <414F9797.36AB@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414F9797.36AB@xyzzy.claranet.de> 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 Tue, Sep 21, 2004 at 04:53:11AM +0200, Frank Ellermann wrote a message of 73 lines which said: > Maybe I'd even implement it this way, if a sender policy has no word > starting with a "-" or a "redirect" stop the evaluation as waste of > time (yes, that violates several MUST in protocol-03, but I could do > it before calling check_host()). Anyone can implement stupid policies on his own site. One can add an implicit -all at the end, he can assume a "a/24 mx/24 -all" if there is no SPF record, he can reject SPF records that are too lax (ip4:0.0.0.0/0), he can use a badly-managed blacklist, he can have frivolous requirments (like asking for a PTR record), etc. That's the freedom you have on the Internet. You are never forced to accept mail, you can require any criteria you want. But it is one thing to have this freedom and it is another thing to ask for a sanctification of these stupid policies in a RFC on the standards track. > SPF started in January 2004, and so far the number of unexpected > side-effects appears to be minimal. Because very few domains publish SPF and even less test it (and it is often for information only, without rejections). And the current users are quite knowledgeable about email. When SPF will become widely deployed, you will see the "unexpected side-effects". From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 04:18: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 EAA22494 for ; Tue, 21 Sep 2004 04:18:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L7Yjw6037137; Tue, 21 Sep 2004 00:34: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 i8L7Yj3t037135; Tue, 21 Sep 2004 00:34:45 -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 i8L7YaNT037085 for ; Tue, 21 Sep 2004 00:34:45 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 4679E26C087; Tue, 21 Sep 2004 09:34:36 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 2DAE826C06D; Tue, 21 Sep 2004 09:34: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 i8L7YZ8q883777; Tue, 21 Sep 2004 09:34:35 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 07C38FACE; Tue, 21 Sep 2004 09:34:35 +0200 (CEST) Date: Tue, 21 Sep 2004 09:34:35 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Cc: ietf-mxcomp@imc.org Subject: Re: Language too strict in draft-ietf-marid-mailfrom-00 Message-ID: <20040921073435.GA15799@nic.fr> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> <20040920135108.GA12993@nic.fr> <414F3D43.2E20@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414F3D43.2E20@xyzzy.claranet.de> 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 Mon, Sep 20, 2004 at 10:27:47PM +0200, Frank Ellermann wrote a message of 29 lines which said: > But I'd never remove or change a -all, there are better options. Do what you want. My idea was not to constrain you but to free the others :-) > SPF without -all is a complete waste of bandwidth and time. With ?all, you never have FAIL but you still have the PASS, which are important for my whitelists. If -all becomes mandatory, I will certainly *not* deploy SPF. I do not want my "~/.forward" to break suddenly (and if you say that I should switch from forwarding to remailing right now, I would reply they have different semantics, specially when the mail cannot be delivered. Without any real deployment of SRS or BATV - which are only proofs of concept at this time - I will *not* use -all.) The rest is a bit off-topic: > [some remarks about RfC 3865 censored, because this would cost me > the write access to MARID]. I cannot speak for the MARID Police but, since RFC 3865 "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension" talks about a related issue, informed opinions on RFC 3685 may be useful to MARID, specially if you talk about how it combines with MARID. From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 04:48: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 EAA24011 for ; Tue, 21 Sep 2004 04:48: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 i8L814M5046855; Tue, 21 Sep 2004 01:01: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 i8L814DD046854; Tue, 21 Sep 2004 01:01:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8L812L3046799 for ; Tue, 21 Sep 2004 01:01:03 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-16.tower-48.messagelabs.com!1095753657!5106897 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 5031 invoked from network); 21 Sep 2004 08:00:57 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-16.tower-48.messagelabs.com with SMTP; 21 Sep 2004 08:00:57 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Sep 2004 09:00:56 +0100 Received: (qmail 8746 invoked from network); 20 Sep 2004 07:56:59 -0000 Received: from unknown (HELO ?10.191.100.31?) (10.191.100.31) by matt?dev.int.star.co.uk with SMTP; 20 Sep 2004 07:56:59 -0000 Date: Tue, 21 Sep 2004 09:00:56 +0100 (BST) From: Matt Sergeant X-X-Sender: matt@localhost.localdomain To: Douglas Otis cc: Matthew Elvey , MXCOMP Subject: Re: Make CSV backwards compatible with SPF? In-Reply-To: <1095726108.11083.323.camel@ddev.mail-abuse.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 21 Sep 2004 08:00:56.0884 (UTC) FILETIME=[200B0F40:01C49FB1] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Sep 2004, Douglas Otis wrote: > This is a repeat of an older debate. This would not be an improvement > over the current CSV draft. SPF often requires a series of lookups to > resolve an address list. This list is often not fully defined as it is > commonly intended to associate mailbox domains with a much larger set of > MTA addresses. It also may allow the EHLO domain to use SPF/Sender-ID > records as a means to spoof, as these records are often open-ended. The > host name used within the EHLO domain will require a separate record > anyway, so why not use a record that achieves an answer within a single > lookup? My argument for this idea is simply that we settled on the SPF format simply because single lookups (an "exists" lookup) were not flexible enough for people's full needs. I doubt CSV's single lookup will be either. Of course there is nowhere near as much adoption of CSV as there is of SPF so we can't possibly be certain of this yet. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 06:16: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 GAA00309 for ; Tue, 21 Sep 2004 06:16: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 i8L9doLl082562; Tue, 21 Sep 2004 02:39:50 -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 i8L9doXc082561; Tue, 21 Sep 2004 02:39:50 -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 i8L9dnZa082553 for ; Tue, 21 Sep 2004 02:39:49 -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 i8L9dnkc012168 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Sep 2004 02:39:50 -0700 Subject: Re: Language too strict in draft-ietf-marid-mailfrom-00 From: Douglas Otis To: Frank Ellermann Cc: ietf-mxcomp@imc.org In-Reply-To: <414F9797.36AB@xyzzy.claranet.de> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> <20040920135108.GA12993@nic.fr> <414F3D43.2E20@xyzzy.claranet.de> <1095723604.11083.264.camel@ddev.mail-abuse.org> <414F9797.36AB@xyzzy.claranet.de> Content-Type: text/plain Message-Id: <1095759400.3265.139.camel@adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 21 Sep 2004 02:36:40 -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 Mon, 2004-09-20 at 19:53, Frank Ellermann wrote: > Douglas Otis wrote: > > > You would not know which alias to use to overcome a problem > > that can not be known in advance. : ( > > Not sure what you're talking about. Let's say that I send a > mail to somebody AT infradead mentioned here in other threads. > > The receiver forwards this to a 3rd party without changing my > MAIL FROM. The 3rd party says "you are not allowed to forge > xyzzy addreses" and refuses to accept the mail. Infradead's > MTA returns the mail to me. That's IMHO working as designed. The MTA may check the MAIL FROM prior to use and not always as a condition of receipt. There could easily be MTAs within the path that do not implement this scheme. An MTA administrator wishing to reduce bounce traffic could drop messages that appear spoofed, and get it right fairly often at the cost of reliability. The alternative alias solution you suggest was to leave the record open for reliable delivery, but this record will attract those wishing to spoof in this brave new world. When there is also a reputation service using this identity, then even the "reliable" method may not work. : ( To overcome this problem, make the MTA authorization a separate operation from the mailbox domain/mail channel association. Then the use an open association record would not invite spoofing and retain the reputation of such an open record. This record can remain reliable in all cases. The recipient could be notified when the message was outside the mail channel without needing to reject the message. The recipient would also know where the message originated by way of a validated MTA name. These identity relationships should not take an intelligent filter long to recognize (or a human for that matter). > I could fix this problem by using a MAIL FROM de.clara.net or > another mailer (today with all these BLs around we all have > at least one backup MSA, or at least I found that this is a > MUST HAVE). But with SPF, there are now two new reasons for needing a backup email address. Neither of these reasons are necessary to achieve the goal of indicating which messages are within the nominal mail channel. I would expect only financial institutions would close their records and cause some mail to either be rejected or go missing in an effort to fight phishing. I would also expect this painful mode would be a temporary fix pending a widely deployed signature solution. > But I wouldn't authorize the ill-behaved MTA to use my address, > neither directly by adding this MTA to "my" sender policy, nor > indirectly by modifying "-all" to something else. If your network provider protected their address space and transparently intercepted port 25 traffic, then you may not have a choice which MTA is used. Depending upon your location, there may not be many alternatives. The problem SPF creates by using addresses is your reputation is on the line, and not the provider's. If your domain gets blocked as a result, even going to a new provider will not overcome the problem. If you were using two providers, as you say you do, then knowing which of these providers caused your dilemma may not be obvious to you. > That's not how I understand SMTP, for me the MX is meant as the > gateway to the receiver. It can forward, and relay, and do > whatever it wishes, but it _must not_ say MAIL FROM xyzzy while > talking with the MX of a 3rd party. If I'd wanted to send my > mail to this 3rd MX, then I'd do it directly. Again, you may not be allowed that option for good reasons. > Okay, it may change common practice for some systems, and it's > obviously different from what Dave said, but OTOH we're here in > MARID because there _is_ a problem with SMTP. Or rather more > than one problem, spf2.0/mfrom fixes only one of the problems. "The primary current use case for this facility is to allow recipient MTAs to confirm that peer MTAs' actions are authorized by specific domains or networks." As not everything will change overnight, closed records are not practical for describing the mail channel relationship with a mailbox domain. Providers will not want to retrain customers, they will not want to deal with rejected messages or a slew of lost messages. The mail channel association with mailbox domain should be seen as informational for a long time to come. A closed record is practical immediately for describing the addresses used by a specific MTA referenced by the MTA name. To then describe either a restrictive or informational mailbox domain to mail channel relationship only requires a safe and simple name list. The scope of this list can easily include both the From and MAIL FROM (even the PRA if the application tanks). > > I would expect BATV will be a good solution for this problem. > > In theory it could be, but spf2.0/mfrom is something working > today with my MUA and my ISP. They didn't have to do anything, > only publish a sender policy with "-all". No new MTA. Does that not run the risk of adding credibility to those that manage to spoof this check? Not checking within the channel makes spoofing relatively simple in many cases. > Spf2.0/mfrom also offers something for the receiver, the MX can > reject all FAILs. That's also the reason why there SHOULD be a > "-all" in sender policies: Without "-all" or similar without > any FAIL mechanism at all, why should the receiver bother to > evaluate the sender policy ? SPF is a voluntary cooperation > between the (author of the) sender (policy) and the receiver, > and without a chance to get a FAIL the receiver has no reason > to cooperate. But the use of "-all" is not without a cost. When the goal defined by the charter is taken seriously, then using a closed record is vital. The question is which record can be safely closed, and which record should be expected to remain open. The mail channel can not be closed by many providers for practical reasons. These are systems that make it simple for the average user to send messages and where the provider can detect and block a spammer but does not offer mailboxes. The return path can not be expected to hold a relationship with with the sending MTA in every case without making wrenching changes to the way mail is used. > Maybe I'd even implement it this way, if a sender policy has no > word starting with a "-" or a "redirect" stop the evaluation as > waste of time (yes, that violates several MUST in protocol-03, > but I could do it before calling check_host()). > > > It could be this assumption of acceptable losses holds > > because far fewer use SPF to reject mail than publish > > records. > > That's of course possible, but in my infradead scenario there > are no losses. Hadmut published RMX in December 2002, RMX and > SPF were discussed over and over again, SPF started in January > 2004, and so far the number of unexpected side-effects appears > to be minimal. > > Forwarders and mail forgers have to adjust, yes. But that's a > feature and not a bug. I like it. Now please let's be done > with it, get the two RfCs out a.s.a.p., and then start to work > on other ideas like CSV, MTAMARK, or more SPF scopes. > > As long as SPF isn't ready I don't trust other ideas, because > I'm not sure if that's only meant to derail SPF or create FUD. I have listed the security and reputation problems that will exist with the SPF approach. This is not to dismiss the goals of MARID with FUD. The goals of MARID can be achieved. The mailbox domain/mail channel relationship can not be described using addresses safely. It can be done using MTA names however. Let's achieve the goal with the safest and simplest solutions. Above all, let's achieve the goal safely. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 07:33:48 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 HAA05781 for ; Tue, 21 Sep 2004 07:33:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LAxcaH013492; Tue, 21 Sep 2004 03:59: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 i8LAxc6D013491; Tue, 21 Sep 2004 03:59:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LAxPqZ013472 for ; Tue, 21 Sep 2004 03:59:38 -0700 (PDT) (envelope-from SRS0+7c9233cc1524d04bd36c+394+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C9iMZ-0002Dh-Tn; Tue, 21 Sep 2004 11:59:11 +0100 Subject: Re: Language too strict in draft-ietf-marid-mailfrom-00 From: David Woodhouse To: Stephane Bortzmeyer Cc: Douglas Otis , Frank Ellermann , MARID In-Reply-To: <20040921073807.GA16199@nic.fr> References: <1095240230.9144.1128.camel@imladris.demon.co.uk> <20040915183930.GF37562@Space.Net> <20040920135108.GA12993@nic.fr> <414F3D43.2E20@xyzzy.claranet.de> <1095723604.11083.264.camel@ddev.mail-abuse.org> <20040921073807.GA16199@nic.fr> Content-Type: text/plain Message-Id: <1095764350.31730.4333.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Tue, 21 Sep 2004 11:59:10 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-09-21 at 09:38 +0200, Stephane Bortzmeyer wrote: > On Mon, Sep 20, 2004 at 04:40:04PM -0700, > Douglas Otis wrote > a message of 90 lines which said: > > > I would expect BATV will be a good solution for this problem. > > Speaking of BATV, any implementation on the radar screen? Or a > concrete syntax? At the present time, I only see > draft-levine-mass-batv-00.txt. Largely the point is it's unilateral so you don't _have_ to have an agreed syntax. I've had an implementation purely in Exim configuration since February -- http://david.woodhou.se/eximconf/include/routers-ses Currently that stops the backscatter, and it stops fakes being delivered to anyone who actually does SMTP sender verification callouts. It's been suggested that we could implement a stunt DNS server and publish an SPF record using 'exists' to get potential recipients to verify the localpart that way, but I haven't bothered yet. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 09:28: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 JAA13240 for ; Tue, 21 Sep 2004 09:28:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LCuX4b023802; Tue, 21 Sep 2004 05:56:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LCuXKo023801; Tue, 21 Sep 2004 05:56:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LCuVBH023785 for ; Tue, 21 Sep 2004 05:56:32 -0700 (PDT) (envelope-from roy+dated+1098363383.7aea4c@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i8LCvXDD095221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Sep 2004 12:57:38 GMT (envelope-from roy+dated+1098363383.7aea4c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i8LCuNB0086792 for ; Tue, 21 Sep 2004 13:56:23 +0100 (BST) (envelope-from roy+dated+1098363383.7aea4c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i8LCuNm4086791 for ietf-mxcomp@imc.org; Tue, 21 Sep 2004 13:56:23 +0100 (BST) (envelope-from roy+dated+1098363383.7aea4c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 21 Sep 2004 13:56:18 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16720.9458.21094.738005@giles.gnomon.org.uk> Date: Tue, 21 Sep 2004 13:56:18 +0100 To: quinlan@pathname.com Cc: ietf-mxcomp@imc.org Subject: IANAL and neither are you In-Reply-To: <16713.64521.588061.380843@proton.pathname.com> References: <16713.64521.588061.380843@proton.pathname.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Daniel" == Daniel Quinlan writes: Daniel> I have yet to meet a lawyer *anywhere* who would disagree Daniel> with the sentiment expressed in that post. If you're refering to the sentiment that reading the patent may increase your liability, then there appears to be one lawyer on this list who disagrees. In http://www.imc.org/ietf-mxcomp/mail-archive/msg04982.html Anne argues that _failing_ to read the patent may increase your liability. -roy From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 13:02: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 NAA02074 for ; Tue, 21 Sep 2004 13:02: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 i8LFQGij041392; Tue, 21 Sep 2004 08:26: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 i8LFQGKA041391; Tue, 21 Sep 2004 08:26:16 -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 i8LFQFSY041384 for ; Tue, 21 Sep 2004 08:26:15 -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 i8LFQ7Xr018065; Tue, 21 Sep 2004 08:26:07 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Sep 2004 08:26:07 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Roy Badami'" , quinlan@pathname.com Cc: ietf-mxcomp@imc.org Subject: RE: IANAL and neither are you Date: Tue, 21 Sep 2004 08:26:05 -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: I agree with Ann on this one, I think that it is difficult to claim that a policy of not reading patents that you have good reason to beleive may be infringed represents due dilligence. But the position is far from unusual in US corporations. I know of several global 500 brands where the policy is engineers do not read patents. Which kind of reduces the point of the exercise if patents are meant to be a way of encouraging sharing of ideas. There needs to be a root an branch reform of the patent system. Unfortunately this is not currently within the scope of this group's charter. > >>>>> "Daniel" == Daniel Quinlan writes: > > Daniel> I have yet to meet a lawyer *anywhere* who would disagree > Daniel> with the sentiment expressed in that post. > > If you're refering to the sentiment that reading the patent may > increase your liability, then there appears to be one lawyer on this > list who disagrees. > > In http://www.imc.org/ietf-mxcomp/mail-archive/msg04982.html Anne > argues that _failing_ to read the patent may increase your liability. > > -roy > From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 13:53:54 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 NAA05720 for ; Tue, 21 Sep 2004 13:53: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 i8LHG01s053693; Tue, 21 Sep 2004 10:16:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LHG01D053692; Tue, 21 Sep 2004 10:16:00 -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 i8LHFxpe053683 for ; Tue, 21 Sep 2004 10:15:59 -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; Tue, 21 Sep 2004 13:16:00 -0400 id 001B7A97.415061D0.00007026 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: MARID List From: Andrew Newton Subject: regarding the trademark for "Sender ID" Date: Tue, 21 Sep 2004 13:15:58 -0400 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 With regards to the registration of the mark of "Sender ID", the following are the relevant facts we have found: - there is a UK trademark application for "Sender ID" and "SenderID" by the same registrant. - this registrant has been using "SenderID" since at least February 2004. - to our knowledge, the IETF has not been given permission to use either "SenderID" or "Sender ID" marks It is our opinion that all MARID documents should no longer reference the output of the MARID working group as "Sender ID" or any other similar mark. We believe the risk to the ISOC and the IETF standards publishing process to be too great. If there is a need to refer to a simple name covering this work in IETF documents, we recommend "MARID". Of course, individuals and organizations are free to refer to their specific MARID implementations by whatever marks they find acceptable. -andy From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 15:12: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 PAA11745 for ; Tue, 21 Sep 2004 15:12:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LIeN2c060470; Tue, 21 Sep 2004 11:40:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LIeNVl060469; Tue, 21 Sep 2004 11:40:23 -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 i8LIeMLL060463 for ; Tue, 21 Sep 2004 11:40:22 -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 1C9pYo-0004Gy-M6 for ietf-mxcomp@imc.org; Tue, 21 Sep 2004 13:40:25 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Tue, 21 Sep 2004 13:40:18 -0500 In-Reply-To: (Andrew Newton's message of "Tue, 21 Sep 2004 13:15:58 -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: regarding the trademark for "Sender ID" 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.6 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 Andrew Newton writes: > If there is a need to refer to a simple name covering this work in > IETF documents, we recommend "MARID". For what it is worth, everytime the subject of "MARID" comes up on slashdot, someone points out that it means "sick" in some language they use. Maybe we should just use "SPF"? -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 15:20: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 PAA12789 for ; Tue, 21 Sep 2004 15:20:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LIWBMZ059992; Tue, 21 Sep 2004 11:32: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 i8LIWB6K059991; Tue, 21 Sep 2004 11:32:11 -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 i8LIWAPN059985 for ; Tue, 21 Sep 2004 11:32:10 -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 1C9pQs-0006Wa-0J for ietf-mxcomp@imc.org; Tue, 21 Sep 2004 13:32:13 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Tue, 21 Sep 2004 13:32:02 -0500 In-Reply-To: (Andrew Newton's message of "Tue, 21 Sep 2004 13:15:58 -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: regarding the trademark for "Sender ID" 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.6 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 Andrew Newton writes: > It is our opinion that all MARID documents should no longer reference > the output of the MARID working group as "Sender ID" or any other > similar mark. We believe the risk to the ISOC and the IETF standards > publishing process to be too great. Huh. I thought this trademark issue was resolved at IETF-60. According to Harry, the Microsoft lawyers investigated it and, unlike terms like "windows", "word", and "access", they determined that "SenderID" was generic and could not be trademarked. See ca 17:25 in: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html More detailed explanations can be heard if you download the audio, but I deleted my copy so I can't check. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 15:29:17 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 PAA13501 for ; Tue, 21 Sep 2004 15:29:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LIvELU061644; Tue, 21 Sep 2004 11:57: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 i8LIvEDj061643; Tue, 21 Sep 2004 11:57:14 -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 i8LIvDrj061637 for ; Tue, 21 Sep 2004 11:57:13 -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 CCF73414C6; Tue, 21 Sep 2004 11:57:17 -0700 (PDT) Subject: Re: Make CSV backwards compatible with SPF? From: Douglas Otis To: Matt Sergeant Cc: Matthew Elvey , MXCOMP In-Reply-To: References: Content-Type: text/plain Message-Id: <1095793037.11712.86.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 21 Sep 2004 11:57:17 -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 Tue, 2004-09-21 at 01:00, Matt Sergeant wrote: > On Mon, 20 Sep 2004, Douglas Otis wrote: > > > This is a repeat of an older debate. This would not be an improvement > > over the current CSV draft. SPF often requires a series of lookups to > > resolve an address list. This list is often not fully defined as it is > > commonly intended to associate mailbox domains with a much larger set of > > MTA addresses. It also may allow the EHLO domain to use SPF/Sender-ID > > records as a means to spoof, as these records are often open-ended. The > > host name used within the EHLO domain will require a separate record > > anyway, so why not use a record that achieves an answer within a single > > lookup? > > My argument for this idea is simply that we settled on the SPF format > simply because single lookups (an "exists" lookup) were not flexible > enough for people's full needs. I doubt CSV's single lookup will be > either. Of course there is nowhere near as much adoption of CSV as there > is of SPF so we can't possibly be certain of this yet. You are right. Much like a post-mark, the CSV records simply fix SMTP EHLO authentication to lay a solid foundation upon which other relationships can be asserted using additional records. Importantly, an authenticated MTA name is strong enough to provide reputation assertions. Building upon a validated list of MTA names allows a relationship with some mailbox-domain and some vast mail channel to be asserted using a simple name list. There would be little motivation to spoof the mailbox-domain/mail-channel (open) relationships, as this identity would typically be unable to serve a gate-keeping function. In the few cases where it is used in this manner, the outbound mail-channel must not be shared, and recipients must be alerted to not offer a forwarded mail address. By allowing the MTA to be validated, this identifies where the mail originated, much like a post-mark. Should you receive a letter from Uncle Jon, but from a different city, you can write back and asked about his trip. If he says "What trip?" then the post-mark served a valuable service. If there was a crime, this electronic post-mark indicates where to obtain logs to discover the true source of the message. The post-mark itself may be all that is needed should this be used by a single organization. At some point in the future, it is possible mail providers may request customers to create CSV-CSA records to enable the use of customer's domain within the EHLO name for messages being sent on their behalf. This assumes the CSV name reputation trumps any IP address black-list, as it should. This additional record could be: _marid.my-mailbox-domain.tld. PTR my-isp.com. _marid.my-mailbox-domain.tld. PTR my-support.com. _marid.my-mailbox-domain.tld. PTR my-remote-office.com. ... The scope of the assertions implied by this _marid record should be for a single field, the RFC2822 From and nothing else in my view. As I said in another post, it could be for the REF2821 MAIL FROM or the PRA selected field for that matter. The point is simple. By using a name list rather than an address list, there is no need for highly risky and time consuming subsequent lookups to just discover addresses. A name is a much more concise means of expressing this relationship which does not involve the same level of maintenance and trouble. The great thing about rehabilitating the EHLO name, is that this name is provided early in every SMTP session. The EHLO name is captured within the message headers to allow tracing. There is no need for submitter or to invent new mail headers to discern where the message is originating with the use of CSV applying the post-mark so to speak. On Mon, 2004-09-20 at 18:50, Matthew Elvey wrote: > On 9/20/2004 5:21 PM, Douglas Otis sent forth electrons to convey: > >On Mon, 2004-09-20 at 16:33, Matthew Elvey wrote: > > > >> Here's the idea in a nutshell: CSV makes use of extant SPF records > >> which already list tens of thousands of domains that are authorized > >> for use in HELO. > >> > >> Who supports/opposes this change? > > > > Ney. > > > > This is a repeat of an older debate. > > No, I'm making a different suggestion. Please read the whole post! > I'm eliminating some or all of the records that you mention having a > problem with below. > > I should have stated one thing clearly: only +type components of > records would be relevant; ~type and ?type would be ignored. As I said, this will allow the use of other record types to spoof the EHLO name. The SPF type of record will normally be across an entire array of providers and not for a single host. One compromised system within this vast region can then utilize one of these records to spoof the EHLO name then. If reputations are based upon the MTA name and not the mailbox domain, then protecting the MTA name would be much more important. It MUST not be possible to mix these records out of this concern. > I registered your Nay on Jabber... Thanks. > > SPF often requires a series of lookups to resolve an address list. > > This list is often not fully defined as it is commonly intended to > > associate mailbox domains with a much larger set of MTA addresses. > > It also may allow the EHLO domain to use SPF/Sender-ID records as a > > means to spoof, as these records are often open-ended. > > No open-ended records would be allowed. I don't think the fact that, > e.g. +0/0 is allowed is of much concern, as spammers have demonstrated > they can create MARID records for their own domains quite well; A&R are > required. > > > The host name used within the EHLO domain will require a separate > > record anyway, so why not use a record that achieves an answer > > within a single lookup? > > We should, as my post makes clear. But there are reported to be what, > ~300,000 SPF records? Why not use them to the extent that I suggest? These records are for a different purpose, and expose a different set of machines. The EHLO record set must be kept narrow in order to serve the purpose of establishing accountability. The broad and weak nature of the identities obtained using SPF/Sender-ID are not useful for this purpose. SPF/Sender-ID should be viewed as informative for but a few exceptions. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 16:07:49 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 QAA17798 for ; Tue, 21 Sep 2004 16:07:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LJakGx064482; Tue, 21 Sep 2004 12:36: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 i8LJakxu064481; Tue, 21 Sep 2004 12:36:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LJajJd064470 for ; Tue, 21 Sep 2004 12:36:46 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: regarding the trademark for "Sender ID" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A012.556B2248" Date: Tue, 21 Sep 2004 14:36:47 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DACD1@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: regarding the trademark for "Sender ID" Thread-Index: AcSgEMULfXXzk4QkStG+vBnZR/mfHQAAH1hY From: "Gordon Fecyk" To: "IETF MARID WG" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4A012.556B2248 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGb3Igd2hhdCBpdCBpcyB3b3J0aCwgZXZlcnl0aW1lIHRoZSBzdWJqZWN0IG9mICJNQVJJRCIg Y29tZXMgdXAgb24NCj4gc2xhc2hkb3QsIHNvbWVvbmUgcG9pbnRzIG91dCB0aGF0IGl0IG1lYW5z ICJzaWNrIiBpbiBzb21lIGxhbmd1YWdlDQo+IHRoZXkgdXNlLg0KDQpUaGF0J3MganVzdCB0aGUg a2FybWEgd2hvcmVzIHRyeWluZyB0byByYWNrIHVwICs1IEZ1bm55IHNjb3JlcyBmcm9tDQptb2Rl cmF0b3JzLiBObyBkaWZmZXJlbnQgdGhhbiB0aGUgYmVoYXZpb3VyIG9mIG90aGVyIGthcm1hIHdo b3JlcyB3aG8gYmxhbWUNCk1pY3Jvc29mdCBldmVyeSB0aW1lIGEgV2luZG93cyB2dWxuZXJhYmls aXR5IGdldHMgcmVwb3J0ZWQgdGhlcmUuIENvbnNpZGVyDQp0aGUgc291cmNlLg0KIA0KQW5kIHJp Z2h0IGFsb25nc2lkZSB0aGUgYmFubmVyIGFkcyBwYWlkIGZvciBieSBNaWNyb3NvZnQgdGhlbXNl bHZlcy4gTm93DQp0aGF0J3MgKzUgRnVubnkuDQogDQo= ------_=_NextPart_001_01C4A012.556B2248 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY0ODcuMSI+CjxUSVRMRT5SZTogcmVnYXJkaW5nIHRo ZSB0cmFkZW1hcmsgZm9yICZxdW90O1NlbmRlciBJRCZxdW90OzwvVElUTEU+CjwvSEVBRD4KPEJP RFkgZGlyPWx0cj4KPERJVj48Rk9OVCBzaXplPTI+Jmd0OyBGb3Igd2hhdCBpdCBpcyB3b3J0aCwg ZXZlcnl0aW1lIHRoZSBzdWJqZWN0IG9mICJNQVJJRCIgCmNvbWVzIHVwIG9uPEJSPiZndDsgc2xh c2hkb3QsIHNvbWVvbmUgcG9pbnRzIG91dCB0aGF0IGl0IG1lYW5zICJzaWNrIiBpbiBzb21lIAps YW5ndWFnZTxCUj4mZ3Q7IHRoZXkgdXNlLjxCUj48QlI+PC9GT05UPjxGT05UIHNpemU9Mj5UaGF0 J3MganVzdCB0aGUga2FybWEgCndob3JlcyB0cnlpbmcgdG8gcmFjayB1cCArNSBGdW5ueSBzY29y ZXMgZnJvbSBtb2RlcmF0b3JzLiZuYnNwO05vIGRpZmZlcmVudCB0aGFuIAp0aGUgYmVoYXZpb3Vy IG9mIG90aGVyIGthcm1hIHdob3JlcyB3aG8gYmxhbWUgTWljcm9zb2Z0IGV2ZXJ5IHRpbWUgYSBX aW5kb3dzIAp2dWxuZXJhYmlsaXR5IGdldHMgcmVwb3J0ZWQgdGhlcmUuJm5ic3A7Q29uc2lkZXIg dGhlIHNvdXJjZS48L0ZPTlQ+PC9ESVY+CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8 L0RJVj4KPERJVj48Rk9OVCBzaXplPTI+QW5kIHJpZ2h0IGFsb25nc2lkZSB0aGUgYmFubmVyIGFk cyBwYWlkIGZvciBieSBNaWNyb3NvZnQgCnRoZW1zZWx2ZXMuIDwvRk9OVD48Rk9OVCBzaXplPTI+ Tm93IHRoYXQncyArNSBGdW5ueS48L0ZPTlQ+PC9ESVY+CjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNw OzwvRElWPjwvRk9OVD4KCjwvQk9EWT4KPC9IVE1MPg== ------_=_NextPart_001_01C4A012.556B2248-- From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 21:31:34 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 VAA19058 for ; Tue, 21 Sep 2004 21:31:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8M0q6Qx090356; Tue, 21 Sep 2004 17:52: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 i8M0q6Dw090355; Tue, 21 Sep 2004 17:52:06 -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 i8M0q5oA090338 for ; Tue, 21 Sep 2004 17:52:06 -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 1C9vMX-0001Fa-JQ for ietf-mxcomp@imc.org; Tue, 21 Sep 2004 19:52:08 -0500 To: "IETF MARID WG" References: <01D64F09-0B40-11D9-BE1D-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 21 Sep 2004 19:52:01 -0500 In-Reply-To: <01D64F09-0B40-11D9-BE1D-000A95B3BA44@hxr.us> (Andrew Newton's message of "Mon, 20 Sep 2004 16:02:32 -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: MARID Monday 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.6 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 <01D64F09-0B40-11D9-BE1D-000A95B3BA44@hxr.us> Andrew Newton writes: > Jabber room: marid@ietf.xmpp.org > Date: Every other Monday starting April 19 > Time: 20:00 UTC Sorry I came late to this one. I did make it to the one two weeks ago, but since it was labor day, no one else showed up. Andy: During the last Jabber session you made mention that only a very small number of the mailing lists that you are on rewrite the 2821.MAILFROM. I express surprise at this observation, since it does not match my personal experience, nor the survey done on gmane.org. I also haven't seen any comments about this at all on the SPF-discuss list. If you could, I would greatly appreciate any info about these mailing lists. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 23:09:50 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 XAA24629 for ; Tue, 21 Sep 2004 23:09:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8M2jZhM097298; Tue, 21 Sep 2004 19:45: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 i8M2jYrn097297; Tue, 21 Sep 2004 19:45:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8M2jXGx097278 for ; Tue, 21 Sep 2004 19:45:34 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: 54jQCwBPYAuq8wc3JARzUw 1095821135 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 9693E56D2DC; Tue, 21 Sep 2004 22:45:34 -0400 (EDT) Message-ID: <4150E74F.6030804@elvey.com> Date: Tue, 21 Sep 2004 19:45:35 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis Cc: Matt Sergeant , MXCOMP , John Leslie Subject: Re: Make CSV backwards compatible with SPF? (new revisions) References: <1095793037.11712.86.camel@ddev.mail-abuse.org> In-Reply-To: <1095793037.11712.86.camel@ddev.mail-abuse.org> 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 Doug, still hoping to hear back from you - on 9/14, I asked: > Doug, did you get my email - of a possible broad, strong example > showing [SenderID] falling down. and > If foo.dom's SPF/SenderID record lists just MX, and doesn't send spam, > how/why would a reputation service blacklist foo.dom? > e.g . > foo.dom. IN TXT "v=spf1 mx -all" On 9/21/2004 11:57 AM, Douglas Otis sent forth electrons to convey: > >The great thing about rehabilitating the EHLO name, is that this name is >provided early in every SMTP session. The EHLO name is captured within >the message headers to allow tracing. There is no need for submitter or >to invent new mail headers to discern where the message is originating >with the use of CSV applying the post-mark so to speak. > > Well put. > >On Mon, 2004-09-20 at 18:50, Matthew Elvey wrote: > > >>On 9/20/2004 5:21 PM, Douglas Otis sent forth electrons to convey: >> >> >>>On Mon, 2004-09-20 at 16:33, Matthew Elvey wrote: >>> >>> >>> >>>>Here's the idea in a nutshell: CSV makes use of extant SPF records >>>>which already list tens of thousands of domains that are authorized >>>>for use in HELO. >>>> >>>>Who supports/opposes this change? >>>> >>>> >>>Ney. >>> >>>This is a repeat of an older debate. >>> >>> >>No, I'm making a different suggestion. Please read the whole post! >>I'm eliminating some or all of the records that you mention having a >>problem with below. >> >>I should have stated one thing clearly: only +type components of >>records would be relevant; ~type and ?type would be ignored. >> >> > >As I said, this will allow the use of other record types to spoof the >EHLO name. > I claim this is impossible. Please provide an example of this (using a record of the kind that my proposal proposes using). >The SPF type of record will normally be across an entire >array of providers and not for a single host. > I don't see how this is possible using a record of the kind that my proposal proposes using. +include:comcast.net is not allowed, for example! +ptr isn't allowed either (we don't want to allow the likes of dialup-pool.234.234.comcast.net...) >One compromised system >within this vast region can then utilize one of these records to spoof >the EHLO name then. If reputations are based upon the MTA name and not >the mailbox domain, then protecting the MTA name would be much more >important. It MUST not be possible to mix these records out of this >concern. > > I don't believe my proposal does this. >> >> >>>The host name used within the EHLO domain will require a separate >>>record anyway, so why not use a record that achieves an answer >>>within a single lookup? >>> >>> >>We should, as my post makes clear. But there are reported to be what, >>~300,000 SPF records? Why not use them to the extent that I suggest? >> >> > >These records are for a different purpose, and expose a different set of >machines. The EHLO record set must be kept narrow in order to serve the >purpose of establishing accountability. The broad and weak nature of >the identities obtained using SPF/Sender-ID are not useful for this >purpose. SPF/Sender-ID should be viewed as informative for but a few >exceptions. > Let's nail down what exceptions are appropriate then! (Again, I'm NOT suggesting using the identities obtained using SPF/SenderID!) Some refinements to my proposal based on stuff hashed out in private email: 99% of the time, an MX query will return the A records for all the servers listed in the MX record as add'l records, all in one UDP packet. Let's say that's a requirement for our purposes, where there's a +MX in the SPF record. "+a +mx -all" would need 2 more DNS queries to resolve (unless a ALL query was done, which is likely a bad idea). I think it's reasonable to accomodate a bit more than 1 add'l DNS query. Let's not worry about the <<1% of records where the DNS servers are known to return incomplete lists of Address records Let's say that's a requirement for our purposes that this not happen. The fix in these cases would be make a 'proper' CSV record. Also, a pass relying on such records would carry slightly less weight than a pass based on a 'proper' CSV record. But let's keep the definition tight enough that the weight be only slightly less. Again, the reason for my proposal is not to change or obsolete CSV records, but to make CSV work in some reasonable cases where it can work without them without being significantly detrimental. From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 23:33: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 XAA26404 for ; Tue, 21 Sep 2004 23:33: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 i8M39L8n099400; Tue, 21 Sep 2004 20:09:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8M39KgB099398; Tue, 21 Sep 2004 20:09:20 -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 i8M39JG0099386 for ; Tue, 21 Sep 2004 20:09:19 -0700 (PDT) (envelope-from sb0-068340c8b3-johnl@iecc.com) Received: (qmail 27296 invoked by uid 100); 22 Sep 2004 03:09:25 -0000 Date: 22 Sep 2004 03:09:25 -0000 Message-ID: <20040922030925.27295.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: regarding the trademark for "Sender ID" In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >I thought this trademark issue was resolved at IETF-60. According to >Harry, the Microsoft lawyers investigated it and, unlike terms like >"windows", "word", and "access", they determined that "SenderID" was >generic and could not be trademarked. Since the USPTO shows two live registrations (from the same company) for the term SENDERID, I can't say that I'm too reassured by that legal analysis. I can tell you from experience that if the USPTO thinks a term is too generic, they won't accept a registration for it. In the unlikely event that MARID recommends Microsoft's Sender-ID for standardization in spite of its technical and patent problems, I agree that it's no big deal at this stage to pick a different name. From owner-ietf-mxcomp@mail.imc.org Tue Sep 21 23:36: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 XAA26628 for ; Tue, 21 Sep 2004 23:36:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8M39Led099401; Tue, 21 Sep 2004 20:09:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8M39KQw099399; Tue, 21 Sep 2004 20:09:20 -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 i8M39Jh4099385 for ; Tue, 21 Sep 2004 20:09:19 -0700 (PDT) (envelope-from sb0-068340c8b3-johnl@iecc.com) Received: (qmail 27296 invoked by uid 100); 22 Sep 2004 03:09:25 -0000 Date: 22 Sep 2004 03:09:25 -0000 Message-ID: <20040922030925.27295.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: regarding the trademark for "Sender ID" In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >I thought this trademark issue was resolved at IETF-60. According to >Harry, the Microsoft lawyers investigated it and, unlike terms like >"windows", "word", and "access", they determined that "SenderID" was >generic and could not be trademarked. Since the USPTO shows two live registrations (from the same company) for the term SENDERID, I can't say that I'm too reassured by that legal analysis. I can tell you from experience that if the USPTO thinks a term is too generic, they won't accept a registration for it. In the unlikely event that MARID recommends Microsoft's Sender-ID for standardization in spite of its technical and patent problems, I agree that it's no big deal at this stage to pick a different name. From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 01:55: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 BAA04465 for ; Wed, 22 Sep 2004 01:55:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8M5TKgq016561; Tue, 21 Sep 2004 22:29:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8M5TKWa016559; Tue, 21 Sep 2004 22:29:20 -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 i8M5TJjK016548 for ; Tue, 21 Sep 2004 22:29:19 -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 1C9zgr-00072g-99 for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 00:29:25 -0500 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 22 Sep 2004 00:29:17 -0500 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> (Gordon Fecyk's message of "Fri, 17 Sep 2004 11:01:36 -0500") 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: Existing implementation of SPF1 for Exchange 2000? 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.6 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 <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> "Gordon Fecyk" writes: > I know Meng and crew went nuts developing a stack of libraries to support SPF > v1 (yes v1, the same thing that AOL's using to check incoming mail). I'd > like to know if someone's developed an event sink for Exchange 2000 or 2003 > yet among that stack. See: http://www.michaelbrumm.com/smtpspffilter.html Also: http://www.pamho.net/source/ -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 02:05: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 CAA10097 for ; Wed, 22 Sep 2004 02:05: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 i8M5QsnT015697; Tue, 21 Sep 2004 22:26:54 -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 i8M5QsrQ015696; Tue, 21 Sep 2004 22:26:54 -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 i8M5QrjI015684 for ; Tue, 21 Sep 2004 22:26:53 -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 1C9zeY-00050a-Fi for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 00:27:00 -0500 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 22 Sep 2004 00:26:54 -0500 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> (Gordon Fecyk's message of "Fri, 17 Sep 2004 11:01:36 -0500") 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: Existing implementation of SPF1 for Exchange 2000? 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.6 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 <700EEF5641B7E247AC1C9B82C05D125D05540C@srv1.pan-am.ca> "Gordon Fecyk" writes: > I know Meng and crew went nuts developing a stack of libraries to support SPF > v1 (yes v1, the same thing that AOL's using to check incoming mail). I'd > like to know if someone's developed an event sink for Exchange 2000 or 2003 > yet among that stack. See: http://www.pamho.net/source/ -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 04:31:49 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 EAA13389 for ; Wed, 22 Sep 2004 04:31:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8M84Sq7075502; Wed, 22 Sep 2004 01:04: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 i8M84Skm075501; Wed, 22 Sep 2004 01:04:28 -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 i8M84PhU075479 for ; Wed, 22 Sep 2004 01:04:25 -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 i8M84Lb6015740 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Sep 2004 01:04:21 -0700 Subject: Re: Make CSV backwards compatible with SPF? (new revisions) From: Douglas Otis To: Matthew Elvey Cc: Matt Sergeant , MXCOMP , John Leslie In-Reply-To: <4150E74F.6030804@elvey.com> References: <1095793037.11712.86.camel@ddev.mail-abuse.org> <4150E74F.6030804@elvey.com> Content-Type: text/plain Message-Id: <1095840071.2951.84.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 22 Sep 2004 01:01:11 -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 Tue, 2004-09-21 at 19:45, Matthew Elvey wrote: > Doug, still hoping to hear back from you - on 9/14, I asked: > > > Doug, did you get my email - of a possible broad, strong example > > showing [SenderID] falling down. In general, shared MTA environments and open lists are the basic ingredients for having a reputation damaged by SPF/PRA schemes which only bolster the mailbox domain which would be the likely selected identity for reputation assessment. This would be a bad situation. > and > > > If foo.dom's SPF/SenderID record lists just MX, and doesn't send spam, > > how/why would a reputation service blacklist foo.dom? > > e.g . > > foo.dom. IN TXT "v=spf1 mx -all" In a simple environment exchanging messages end-to-end, the risks would be low. There are risks accepting these types of records when a process walks through redirects, includes and arbitrary labels for several record types. This invites a birthday attack where foo.dom can be planted as a poison record in the cache. The many possible records that may be involved in the potential SPF matrix offers a risk where the minimum accepted is 10 scripts and the record count could be in the hundreds. > On 9/21/2004 11:57 AM, Douglas Otis sent forth electrons to convey: > > > The great thing about rehabilitating the EHLO name, is that this name is > > provided early in every SMTP session. The EHLO name is captured within > > the message headers to allow tracing. There is no need for submitter or > > to invent new mail headers to discern where the message is originating > > with the use of CSV applying the post-mark so to speak. > > Well put. > > > On Mon, 2004-09-20 at 18:50, Matthew Elvey wrote: > >> On 9/20/2004 5:21 PM, Douglas Otis sent forth electrons to convey: > >>> On Mon, 2004-09-20 at 16:33, Matthew Elvey wrote: > >>> > >>>> Here's the idea in a nutshell: CSV makes use of extant SPF records > >>>> which already list tens of thousands of domains that are authorized > >>>> for use in HELO. > >>>> > >>>> Who supports/opposes this change? > >>>> > >>> Ney. > >>> > >>> This is a repeat of an older debate. > >> > >> No, I'm making a different suggestion. Please read the whole post! > >> I'm eliminating some or all of the records that you mention having a > >> problem with below. > >> > >> I should have stated one thing clearly: only +type components of > >> records would be relevant; ~type and ?type would be ignored. > > > > As I said, this will allow the use of other record types to spoof the > > EHLO name. > > I claim this is impossible. Please provide an example of this (using a > record of the kind that my proposal proposes using). The label used to select the SPF record is normally based upon the mailbox domain to select a full set of outbound MTAs. The EHLO name can be made to match any such mailbox domain provided one of the machines is permitted in this SPF record set. This would be bad. Again, the intent of the SPF record is to grant a broad set of MTAs, within many different domains, authority to send messages on behalf of the mailbox domain. The CSV record is limited to the single administrative domain. Only the domain that is actually administering the domain should be included, actually just the machine hosting the MTA. > > The SPF type of record will normally be across an entire > > array of providers and not for a single host. > > I don't see how this is possible using a record of the kind that my > proposal proposes using. > +include:comcast.net is not allowed, for example! > +ptr isn't allowed either (we don't want to allow the likes of > dialup-pool.234.234.comcast.net...) One, you want to use existing SPF records that were not intended to provide the narrow selection of machines administered by the MTA operators. Two, there is no means to restrict this list after the fact. > > One compromised system within this vast region can then utilize one > > of these records to spoof the EHLO name then. If reputations are > > based upon the MTA name and not the mailbox domain, then protecting > > the MTA name would be much more important. It MUST not be possible > > to mix these records out of this concern. > > I don't believe my proposal does this. > Your approach was to prune the record set used just for the EHLO domain. That pruning can not differentiate between machines within a delegated domain or machines within the administered domain. This would be bad. > >>> The host name used within the EHLO domain will require a separate > >>> record anyway, so why not use a record that achieves an answer > >>> within a single lookup? > >> > >> We should, as my post makes clear. But there are reported to be what, > >> ~300,000 SPF records? Why not use them to the extent that I suggest? > > > > These records are for a different purpose, and expose a different set of > > machines. The EHLO record set must be kept narrow in order to serve the > > purpose of establishing accountability. The broad and weak nature of > > the identities obtained using SPF/Sender-ID are not useful for this > > purpose. SPF/Sender-ID should be viewed as informative for but a few > > exceptions. > > Let's nail down what exceptions are appropriate then! > (Again, I'm NOT suggesting using the identities obtained using > SPF/SenderID!) The exceptions would be with respect to those domains that feel it is okay to close their lists. Small organizations, able to manage the support issues and don't care when some mail goes missing or gets rejected, may opt to endure these problems. There may be a trade-off dealing with aggressive phishing attacks causing worse problems. If you look at the marid-mpr draft, you will see I have a setting to assert that the name list is the exclusive source of mail for the mailbox domain. I described this mode being suitable for exigent situations, but would not expect this to be the typically use. > Some refinements to my proposal based on stuff hashed out in private email: > > 99% of the time, an MX query will return the A records for all the > servers listed in the MX record as add'l records, all in one UDP packet. > Let's say that's a requirement for our purposes, where there's a +MX in > the SPF record. > > "+a +mx -all" would > need 2 more DNS queries to resolve (unless a ALL query was done, which > is likely a bad idea). I think it's reasonable to accomodate a bit more > than 1 add'l DNS query. For both network and security concerns, running a parser that walks through these records is not reasonable. The CSV record can be obtained in a single binary query, and the MPR list also can be obtain within a single query. Neither of these operations require a parser to perform this operation. My concern would be dedicating a thread to run the parser will likely constrain the port used to do the queries. Having this parser forced to lookup one arbitrary record after the next on any number of DNS servers enables a fairly lazy attack to be successful. I suppose this would be a way to get people to speed up deployment of DNSSEC, but I would rather stay on the safe side of the use of DNS for now. I see little about these TXT script records in DNS as being safe. > Let's not worry about the <<1% of records where the DNS servers are > known to return incomplete lists of Address records. Let's say that's > a requirement for our purposes that this not happen. Once the IETF has expended their considerable efforts to endorse a method that is well considered and robust, I doubt there will be any trouble with the adoption of the standard. The problem of spam is that great. Domains like AOL, as example, return incomplete lists. I doubt you could say their lists are actually incomplete, they are simply open to indicate mail from their customers my emerge from machines outside their networks. > The fix in these cases would be make a 'proper' CSV record. As I indicated, there are serious problem using scripts to spew a huge list of addresses. This should change to being just a list of names used to define the potential sources of mail. Leave the address list to be within the natural scale of DNS records, the single host as provided by the SRV record for example. > Also, a pass relying on such records would carry slightly less weight > than a pass based on a 'proper' CSV record. But let's keep the > definition tight enough that the weight be only slightly less. I still insist the SPF record should never be allowed to validate the EHLO domain. It is a different data set for a different purpose. > Again, the reason for my proposal is not to change or obsolete > CSV records, but to make CSV work in some reasonable cases where it > can work without them without being significantly detrimental. Sorry, but I fail to see the point in using a TXT record and a parser to obtain a list of addresses through a dangerous and expensive set of lookups, when it can be done in one lookup safely. Also where it will not accidentally allow other domains to spoof the EHLO identity. This exclusion is needed to establish accountability. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 07:40: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 HAA27200 for ; Wed, 22 Sep 2004 07:40:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MBBisK038588; Wed, 22 Sep 2004 04:11: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 i8MBBiww038586; Wed, 22 Sep 2004 04:11:44 -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.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8MBBhta038569 for ; Wed, 22 Sep 2004 04:11:43 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 07:16:47 -0400 Received: from ([65.10.117.66]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 2022206078; Wed, 22 Sep 2004 07:16:47 -0400 Message-ID: <002c01c4a094$733343c0$6401a8c0@hdev1> From: "Hector Santos" To: "John Levine" , Cc: References: <20040922030925.27295.qmail@xuxa.iecc.com> Subject: Re: regarding the trademark for "Sender ID" Date: Wed, 22 Sep 2004 07:08:08 -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 ----- Original Message ----- From: "John Levine" To: Cc: Sent: Tuesday, September 21, 2004 11:09 PM Subject: Re: regarding the trademark for "Sender ID" > > >I thought this trademark issue was resolved at IETF-60. According to > >Harry, the Microsoft lawyers investigated it and, unlike terms like > >"windows", "word", and "access", they determined that "SenderID" was > >generic and could not be trademarked. > > Since the USPTO shows two live registrations (from the same company) > for the term SENDERID, I can't say that I'm too reassured by that > legal analysis. I can tell you from experience that if the USPTO > thinks a term is too generic, they won't accept a registration for it. The UK company has encapulated the IP protection by registering the terms: SenderID Trusted SenderID Message both as a Server Mark and Trademark. The distinction is important. If there is any weight in the strength, it would be the "Trusted Sender Message" Service Mark and Trademark. As a trademark would be a like a product name or brand As a service mark, it is part of a 'system', like a protocol or API. With "SenderID" itself, they will have trouble enforcing. The most obvious would be as a trademark - too generic. As a service mark, they could claim market confusion and if they can show lost of exclusive income, they might be able to get a case heard, but it would be difficult to prove with this just this specific word usage. The prior art exist. SenderID has been part of our API and channel communications framework in our Wildcat! telecommunications and data communications/hosting product since 1987. Here is our C structure for it: typedef struct tagTWildcatChannelMessage { DWORD Channel; DWORD SenderId; WORD UserData; WORD DataSize; BYTE Data[MAX_CHANNEL_MESSAGE_SIZE]; } TWildcatChannelMessage; No doubt we have a proven case of long term prior usage for many years and thus they would have difficult enforcing this service or trademark. They can't stop us from continuing the usage of this single term for our telecommunication/data products. Plain and simple. Now as a Trademark, if we did something like "Wildcat! SenderID Protocol" there could be a risk here for market confusion against the "Trusted SenderID Message" Trademark, but not as a SenderID service mark. For Marid, using it in the overall MARID protocol could be open to a challenge if MARID uses SenderID by itself in documentation/communications. I doubt the owner could claim a lost, but down the road (years) once it has been branded, they can claim market confusion and lost of potential exclusive income. Again, they have to be able to prove market confusion and lost of exclusive income. Here is a very possible situation in these days of age with the growth of web mail ads and the new borderline unethnical email scanning systems such as gmail.com: The UK company has a potential customer who is inquirying about their "Trusted SenderID Message" product offerings. The user has a gmail.com account and gmail.com scans the mail for keywords and frames the company's sales response message back to the user with direct marketing advertisements pointing to the various and/or fee-paying exclusive competing methods such a "Microsoft SenderID Protocol" whoi now has embedded the technology in Microsoft's new Exchange Mail Server. The user sees this new competing information with interest and eventually foregoes the UK solution for Microsoft solution. Back hair will raise when the company does a sales followup and founds out the user saw an ad about Microsoft's system and opted to go that way. The UK company will have a big argument for tortious interference against gmail and trademark infringement against Microsoft claiming market confusion and lost of sales. Probably lost the trademark suit, but will win the tort claim. It has already happen with success and good reason. > In the unlikely event that MARID recommends Microsoft's Sender-ID for > standardization in spite of its technical and patent problems, I agree > that it's no big deal at this stage to pick a different name. This is what I did with Microsoft CallerID for our documentation and implementation. For our product, we don't call it CallerID. It conflicts with existing CallerID terminology in our product line. So its called MCEP - Microsoft Caller ID Protocol. For MARID, if it wants to keep using SenderID, it needs more words attaches to it, like "Microsoft SenderID Protocol" or "MARID Sender Identification Protocol" with a possible acronym MSP or MSIP. Look people, the only way I will use MARID if at all, is with its CORE only. In my strong opinion (I already stated this before), the MARID core should be generic as possible which can service an security augmentaion to the SMTP protocol. This will give it the maximum consideration by everyone who might have interest in one or more protocols, but more importation it allows MARID CORE to be an "basic specification" for future possible security protocols. As it is right now, its locked in to a few selected solution and these solutiion have problems in various forms. If they didn't, they would of been adopted and implemented by now. In case, the MARID-CORE can have generic terms such as: SMTP MAIL SENDER IDENTIFICATION PROTOCOLS and then have its index or addendix reference the various methods currently in place. Again, this allows for future possible ideas to fit in the MARID solution, thus be a "plug and play" concept for mail server vendors to implement and offer to this customers. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 07:40: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 HAA27202 for ; Wed, 22 Sep 2004 07:40:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MBBi9M038589; Wed, 22 Sep 2004 04:11: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 i8MBBib7038587; Wed, 22 Sep 2004 04:11:44 -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.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8MBBhKE038567 for ; Wed, 22 Sep 2004 04:11:43 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 07:16:47 -0400 Received: from ([65.10.117.66]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 2022206078; Wed, 22 Sep 2004 07:16:47 -0400 Message-ID: <002c01c4a094$733343c0$6401a8c0@hdev1> From: "Hector Santos" To: "John Levine" , Cc: References: <20040922030925.27295.qmail@xuxa.iecc.com> Subject: Re: regarding the trademark for "Sender ID" Date: Wed, 22 Sep 2004 07:08:08 -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 ----- Original Message ----- From: "John Levine" To: Cc: Sent: Tuesday, September 21, 2004 11:09 PM Subject: Re: regarding the trademark for "Sender ID" > > >I thought this trademark issue was resolved at IETF-60. According to > >Harry, the Microsoft lawyers investigated it and, unlike terms like > >"windows", "word", and "access", they determined that "SenderID" was > >generic and could not be trademarked. > > Since the USPTO shows two live registrations (from the same company) > for the term SENDERID, I can't say that I'm too reassured by that > legal analysis. I can tell you from experience that if the USPTO > thinks a term is too generic, they won't accept a registration for it. The UK company has encapulated the IP protection by registering the terms: SenderID Trusted SenderID Message both as a Server Mark and Trademark. The distinction is important. If there is any weight in the strength, it would be the "Trusted Sender Message" Service Mark and Trademark. As a trademark would be a like a product name or brand As a service mark, it is part of a 'system', like a protocol or API. With "SenderID" itself, they will have trouble enforcing. The most obvious would be as a trademark - too generic. As a service mark, they could claim market confusion and if they can show lost of exclusive income, they might be able to get a case heard, but it would be difficult to prove with this just this specific word usage. The prior art exist. SenderID has been part of our API and channel communications framework in our Wildcat! telecommunications and data communications/hosting product since 1987. Here is our C structure for it: typedef struct tagTWildcatChannelMessage { DWORD Channel; DWORD SenderId; WORD UserData; WORD DataSize; BYTE Data[MAX_CHANNEL_MESSAGE_SIZE]; } TWildcatChannelMessage; No doubt we have a proven case of long term prior usage for many years and thus they would have difficult enforcing this service or trademark. They can't stop us from continuing the usage of this single term for our telecommunication/data products. Plain and simple. Now as a Trademark, if we did something like "Wildcat! SenderID Protocol" there could be a risk here for market confusion against the "Trusted SenderID Message" Trademark, but not as a SenderID service mark. For Marid, using it in the overall MARID protocol could be open to a challenge if MARID uses SenderID by itself in documentation/communications. I doubt the owner could claim a lost, but down the road (years) once it has been branded, they can claim market confusion and lost of potential exclusive income. Again, they have to be able to prove market confusion and lost of exclusive income. Here is a very possible situation in these days of age with the growth of web mail ads and the new borderline unethnical email scanning systems such as gmail.com: The UK company has a potential customer who is inquirying about their "Trusted SenderID Message" product offerings. The user has a gmail.com account and gmail.com scans the mail for keywords and frames the company's sales response message back to the user with direct marketing advertisements pointing to the various and/or fee-paying exclusive competing methods such a "Microsoft SenderID Protocol" whoi now has embedded the technology in Microsoft's new Exchange Mail Server. The user sees this new competing information with interest and eventually foregoes the UK solution for Microsoft solution. Back hair will raise when the company does a sales followup and founds out the user saw an ad about Microsoft's system and opted to go that way. The UK company will have a big argument for tortious interference against gmail and trademark infringement against Microsoft claiming market confusion and lost of sales. Probably lost the trademark suit, but will win the tort claim. It has already happen with success and good reason. > In the unlikely event that MARID recommends Microsoft's Sender-ID for > standardization in spite of its technical and patent problems, I agree > that it's no big deal at this stage to pick a different name. This is what I did with Microsoft CallerID for our documentation and implementation. For our product, we don't call it CallerID. It conflicts with existing CallerID terminology in our product line. So its called MCEP - Microsoft Caller ID Protocol. For MARID, if it wants to keep using SenderID, it needs more words attaches to it, like "Microsoft SenderID Protocol" or "MARID Sender Identification Protocol" with a possible acronym MSP or MSIP. Look people, the only way I will use MARID if at all, is with its CORE only. In my strong opinion (I already stated this before), the MARID core should be generic as possible which can service an security augmentaion to the SMTP protocol. This will give it the maximum consideration by everyone who might have interest in one or more protocols, but more importation it allows MARID CORE to be an "basic specification" for future possible security protocols. As it is right now, its locked in to a few selected solution and these solutiion have problems in various forms. If they didn't, they would of been adopted and implemented by now. In case, the MARID-CORE can have generic terms such as: SMTP MAIL SENDER IDENTIFICATION PROTOCOLS and then have its index or addendix reference the various methods currently in place. Again, this allows for future possible ideas to fit in the MARID solution, thus be a "plug and play" concept for mail server vendors to implement and offer to this customers. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 13:09: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 NAA24181 for ; Wed, 22 Sep 2004 13:09: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 i8MGVeen067361; Wed, 22 Sep 2004 09:31:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MGVeEr067360; Wed, 22 Sep 2004 09:31:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MGVeQW067350 for ; Wed, 22 Sep 2004 09:31:40 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8MGVW1i002604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Sep 2004 09:31:33 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8MGVRDY017455; Wed, 22 Sep 2004 09:31:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Wed, 22 Sep 2004 09:31:26 -0700 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: MARID to close Cc: andy@hxr.us, mrose@dbc.mtview.ca.us, Scott Hollenbeck Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: After an assessment of the current state of the MARID working group, its charter, and its milestones, the working group chairs and Area Advisor have concluded that the MARID working group should be terminated. The group was originally chartered with a very tight time frame, with the expectation that a focused group of engineers would be able to produce in relatively short order a standard in the area of DNS-stored policies related to and accessible by MTAs. The group has had no lack of energy. From the outset, however, the working group participants have had fundamental disagreements on the nature of the record to be provided and the mechanism by which it would be checked. Technical discussion of the merits of these mechanisms has not swayed their proponents, and what data is available on existing deployments has not made one choice obviously superior. Each represents trade-offs, and the working group has not succeeded in establishing which trade-offs are the most appropriate for this purpose. These assessments have been difficult in part because they have been moved out of the realm of pure engineering by the need to evaluate IPR and licensing related to at least one proposal in the light of a variety of licenses associated with the deployed base of MTAs. Efforts to reach consensus by compromise and by inclusion have been attempted on multiple occasions. Despite early hopes of success after each such attempt, post-facto recycling of technical issues which these efforts should have closed has shown that the group remains divided on very basic issues. The working group chairs and Area Advisor are agreed that the working group has no immediate prospect of achieving its primary milestone: Aug 04 Submit working group document on MTA Authorization Record in DNS to PS Rather than spin in place, the working group chairs and Area Advisor believe that the best way forward is experimentation with multiple proposals and a subsequent review of deployment experience. The working group chairs and Area Advisor intend to ask that the editors of existing working group drafts put forward their documents as non-working group submissions for Experimental RFC status. Given the importance of the world-wide email and DNS systems, it is critical that IETF-sponsored experimental proposals likely to see broad deployment contain no mechanisms that would have deleterious effects on the overall system. The Area Directors intend, therefore, to request that the experimental proposals be reviewed by a focused technology directorate. This review group has not yet been formed but, as with all directorates, its membership will be publicly listed at http://www.ietf.org/u/ietfchair/directorates.html once it has been constituted. Concluding a group without it having achieved its goals is never a pleasant prospect, and it is always tempting to believe that just a small amount of additional time and energy will cause consensus to emerge. After careful consideration, however, the working group chairs and area advisor have concluded that such energy would be better spent on gathering deployment experience. regards, Ted Hardie co-Area Director, Applications From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 14:43: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 OAA00690 for ; Wed, 22 Sep 2004 14:43:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MIAYUH074535; Wed, 22 Sep 2004 11:10:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MIAYu0074534; Wed, 22 Sep 2004 11:10:34 -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 i8MIAXbL074528 for ; Wed, 22 Sep 2004 11:10:33 -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 1CABZR-00028O-HG for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 13:10:35 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Wed, 22 Sep 2004 13:10:25 -0500 In-Reply-To: (Ted Hardie's message of "Wed, 22 Sep 2004 09:31:26 -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: MARID to close 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.6 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 Ted Hardie writes: > After an assessment of the current state of the MARID working group, > its charter, and its milestones, the working group chairs and Area > Advisor have concluded that the MARID working group should be > terminated. *heavy sigh* I think this is a mistake. I agree that this is currently no consensus, but I do not think that a rough consensus is out of reach. I think there are several things that could be done to bring consensus. First off, IPR issues can not be ignored. This was a recognized problem since before the interim meeting and was discussed at that meeting. The failure of the AD and co-chairs to make sure that these problems were resolved many months ago is an astounding failure. I personally feel that Ted Hardie (AD) is very much responsible for this failure as Ted actively tried to sweep this problem under the rug instead of solve it. Secondly, the co-chairs/AD allowed this working group to try and create a standard, instead of standardizing existing practices. It is far easier to reach a rough consensus on what people *ARE* doing that what people *SHOULD BE* doing. Even if you don't like what people are doing, it is very useful to give clear descriptions of what is being done. Thirdly, the co-chairs/AD only allowed one proposal to advance. They put all the eggs in one basket and now that basket is smashed. This has caused people to fight against each other in order to get that one spot for advancement. For the 2822.From: identity, only the patent encumbered PRA was considered, greatly increasing the problems of licensing. For the 2821.HELO identity, it was CSV only, instead of both CSV and SPF-classic's HELO checking. For the 2821.MAILFROM identity, *nothing* was advanced, even though it is what a majority of the input documents dealt with and what a vast majority of the deployed code uses. > The working group chairs and Area > Advisor are agreed that the working group has no immediate prospect of > achieving its primary milestone: > > Aug 04 Submit working group document on MTA Authorization Record in DNS to PS Actually, the marid-protocol I-D seems to have a rough consensus to me. This *is* an MTA Authorization Record in DNS. > Rather than spin in place, the working group chairs and Area Advisor > believe that the best way forward is experimentation with multiple > proposals and a subsequent review of deployment experience. This is what should have been done all along. > Concluding a group without it having achieved its goals is never a > pleasant prospect, and it is always tempting to believe that just a > small amount of additional time and energy will cause consensus to > emerge. After careful consideration, however, the working group > chairs and area advisor have concluded that such energy would be > better spent on gathering deployment experience. I do not believe that just a small amount of additional time and energy will lead to consensus. I do believe that a change of tactics by the co-chars and AD would. I believe that this has been obvious since the first month or two of this working group. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 14:47: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 OAA00831 for ; Wed, 22 Sep 2004 14:47: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 i8MHwLr4073268; Wed, 22 Sep 2004 10:58:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MHwL7D073267; Wed, 22 Sep 2004 10:58:21 -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 i8MHwKAk073242; Wed, 22 Sep 2004 10:58:20 -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 i8MIBSpB019285; Wed, 22 Sep 2004 11:11:28 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8MIBSXH019282; Wed, 22 Sep 2004 11:11:28 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 22 Sep 2004 11:11:28 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org cc: phoffman@imc.org Subject: Re: MARID to close 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: I'd like to request that this mail list not be closed together with WG so that we could continue to discuss dns / email authorization technologies here and get input into possible experimental drafts that some may want to publish that address the area that this WG was supposed to work on. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 14:59: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 OAA01220 for ; Wed, 22 Sep 2004 14:59:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MIPDM0075614; Wed, 22 Sep 2004 11:25:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MIPDba075613; Wed, 22 Sep 2004 11:25:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MIPC2u075598 for ; Wed, 22 Sep 2004 11:25:13 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i8MIP7kT004269 for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 20:25:07 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i8MIOJnS030597 for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 20:24:19 +0200 From: Hadmut Danisch Date: Wed, 22 Sep 2004 20:24:19 +0200 To: ietf-mxcomp@imc.org Subject: Re: MARID to close Message-ID: <20040922182419.GA30381@danisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 22, 2004 at 11:11:28AM -0700, william(at)elan.net wrote: > > > I'd like to request that this mail list not be closed together with WG so > that we could continue to discuss dns / email authorization technologies > here and get input into possible experimental drafts that some may want > to publish that address the area that this WG was supposed to work > on. I second this proposal and like to request to keep the archives open as well. I'd also like to discuss the non-technical part (e.g. patent issues, laws, the OECD recommendations, etc., everything which is related to email authorization). If this list won't stay open or is the wrong place to go on with that kind of discussion, I can offer to open an mailing list for that. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 15:12: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 PAA02543 for ; Wed, 22 Sep 2004 15:12: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 i8MIj5uM077272; Wed, 22 Sep 2004 11:45: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 i8MIj5CH077271; Wed, 22 Sep 2004 11:45:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MIj46a077264 for ; Wed, 22 Sep 2004 11:45:04 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i8MIj84k004773 for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 20:45:08 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i8MIitTd031408 for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 20:44:55 +0200 From: Hadmut Danisch Date: Wed, 22 Sep 2004 20:44:55 +0200 To: IETF MARID WG Subject: Re: MARID to close Message-ID: <20040922184455.GA31257@danisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 22, 2004 at 01:10:25PM -0500, wayne wrote: > > The failure of the AD and co-chairs to make sure that these > problems were resolved many months ago is an astounding failure. I agree. They did their very best to ignore the major problems and to aggressively make everyone quiet who tried to mention the problems. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 15:28: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 PAA03995 for ; Wed, 22 Sep 2004 15:28: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 i8MJ0f2u078247; Wed, 22 Sep 2004 12:00:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MJ0fGM078246; Wed, 22 Sep 2004 12:00:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MJ0e1f078235; Wed, 22 Sep 2004 12:00:40 -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, 22 Sep 2004 15:00:41 -0400 id 001B7256.4151CBDA.00000EE2 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org, phoffman@imc.org From: Andrew Newton Subject: Re: MARID to close Date: Wed, 22 Sep 2004 15:00:38 -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: Content-Transfer-Encoding: 7bit On Sep 22, 2004, at 2:11 PM, william(at)elan.net wrote: > I'd like to request that this mail list not be closed together with WG > so > that we could continue to discuss dns / email authorization > technologies > here and get input into possible experimental drafts that some may want > to publish that address the area that this WG was supposed to work on. I think this is an excellent idea. -andy From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 16:19: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 QAA12107 for ; Wed, 22 Sep 2004 16:19: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 i8MJtWug082161; Wed, 22 Sep 2004 12:55:32 -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 i8MJtWhV082160; Wed, 22 Sep 2004 12:55:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MJtVhD082153 for ; Wed, 22 Sep 2004 12:55:31 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-091-641.area3.spcsdns.net ([68.245.100.150]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1CADD9-0006Xh-JN for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 15:55:33 -0400 Message-ID: <4151D8AA.3010608@solidmatrix.com> Date: Wed, 22 Sep 2004 15:55:22 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: A Note of Appreciation X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I just wanted to thank Andy Newton, Marshall Rose and Ted Hardie for doing a lot of hard work and for putting up with all of us. While it is unfortunate that we could not produce something tangible, it has been a fun ride. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 16:22: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 QAA12333 for ; Wed, 22 Sep 2004 16:22: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 i8MJqt3o082010; Wed, 22 Sep 2004 12:52:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MJqt0N082009; Wed, 22 Sep 2004 12:52:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MJqrNM082002 for ; Wed, 22 Sep 2004 12:52:54 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06804; Wed, 22 Sep 2004 15:52:55 -0400 (EDT) Message-Id: <200409221952.PAA06804@ietf.org> From: The IESG To: IETF-Announce@ietf.org Cc: ietf-mxcomp@imc.org, "Marshall T. Rose" , Andrew Newton Subject: WG Action: Conclusion of MTA Authorization Records in DNS (marid) Date: Wed, 22 Sep 2004 15:52:55 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The MTA Authorization Records in DNS (MARID) working group in the Applications Area has concluded. The IESG contact persons are Ted Hardie and Scott Hollenbeck. The mailing list will remain active. After an assessment of the current state of the MARID working group, its charter, and its milestones, the working group chairs and Area Advisor concluded that the MARID working group should be terminated. The group was originally chartered with a very tight time frame, with the expectation that a focused group of engineers would be able to produce in relatively short order a standard in the area of DNS-stored policies related to and accessible by MTAs. The group has had no lack of energy. From the outset, however, the working group participants have had fundamental disagreements on the nature of the record to be provided and the mechanism by which it would be checked. Technical discussion of the merits of these mechanisms has not swayed their proponents, and what data is available on existing deployments has not made one choice obviously superior. Each represents trade-offs, and the working group has not succeeded in establishing which trade-offs are the most appropriate for this purpose. These assessments have been difficult in part because they have been moved out of the realm of pure engineering by the need to evaluate IPR and licensing related to at least one proposal in the light of a variety of licenses associated with the deployed base of MTAs. Efforts to reach consensus by compromise and by inclusion have been attempted on multiple occasions. Despite early hopes of success after each such attempt, post-facto recycling of technical issues which these efforts should have closed has shown that the group remains divided on very basic issues. The working group chairs and Area Advisor are agreed that the working group has no immediate prospect of achieving its primary milestone: Aug 04 Submit working group document on MTA Authorization Record in DNS to PS Rather than spin in place, the working group chairs and Area Advisor believe that the best way forward is experimentation with multiple proposals and a subsequent review of deployment experience. The working group chairs and Area Advisor intend to ask that the editors of existing working group drafts put forward their documents as non-working group submissions for Experimental RFC status. Given the importance of the world-wide email and DNS systems, it is critical that IETF-sponsored experimental proposals likely to see broad deployment contain no mechanisms that would have deleterious effects on the overall system. The Area Directors intend, therefore, to request that the experimental proposals be reviewed by a focused technology directorate. This review group has not yet been formed but, as with all directorates, its membership will be publicly listed at http://www.ietf.org/u/ietfchair/directorates.html once it has been constituted. Concluding a group without it having achieved its goals is never a pleasant prospect, and it is always tempting to believe that just a small amount of additional time and energy will cause consensus to emerge. After careful consideration, however, the working group chairs and area advisor have concluded that such energy would be better spent on gathering deployment experience. From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 16:55: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 QAA15290 for ; Wed, 22 Sep 2004 16:55: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 i8MKT6aG084445; Wed, 22 Sep 2004 13:29: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 i8MKT6Cs084444; Wed, 22 Sep 2004 13:29:06 -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 i8MKT6W1084438 for ; Wed, 22 Sep 2004 13:29:06 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: by neko-base.nekodojo.org (Postfix, from userid 500) id 261B21D65B; Wed, 22 Sep 2004 13:29:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 253661D657 for ; Wed, 22 Sep 2004 13:29:10 -0700 (PDT) Date: Wed, 22 Sep 2004 13:29:10 -0700 (PDT) From: Greg Connor To: ietf-mxcomp@imc.org Subject: Disappointed 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: I was ready to send this last night, but I sat on it to give myself time to review and see if it's really what I want to say. Now, following the announcement that the WG is to be closed, it's perhaps even more appropriate. I certainly don't want to start a flame war over who is at fault... I realize that the WG had lots more problems than just the IPR issue. But the IPR issue is an important one and I want to go on record with my thoughts, in case it benefits future working groups faced with "encumbered" options. I previously wrote to the group saying something like "I would rather have MS on board than not. While I don't like the "contribution" being encumbered, I also see some advantage to having MS as a partner." I would like to revise my statement. After reviewing the MS patent applications, I found to my disappointment that it covers a lot more stuff, even stuff that MS clearly did not "invent". If this patent pending becomes a real patent, I would need a license from MS to implement Sender ID, SPF, DMP, RMX, and probably even DomainKeys. To MS I say: shame on you, for trying to take credit for other people's ideas. Shame on you for taking a "microinvention" such as PRA and trying to use that to take over all email sender verification world-wide. Shame on you for misrepresenting the license as compatible with open source until the very last minute. Shame on you, Harry and Jim, for your name is on that patent application which claims credit for the inventions of others. If you are really serious about getting people to use PRA or any other part of Caller ID, place it completely in the public domain, or at least go out of your way to make sure the license is acceptable to all, especially open source developers and distributors. If you are really serious about wanting to participate in a working group, go back to your corporate masters and explain to them that everyone else in the group will be contributing unencumbered ideas for everyone's mutual benefit, and MS will be the only one at the table looking to increase its own portfolio. To the rest of the WG I say: we have been fooled once by the likes of MS; let's not let it happen again. We should be *very* wary of any "idea" that comes to us encumbered. If someone really wants to contribute their ideas, let them contribute them completely to the public domain, or let the burden of proof of acceptable license be upon them before their "invention" is given any discussion time, let alone selected for inclusion in a proposed standard. We should be wary of any license that is not exposed and reviewed, and we should be wary of any IPR claims that refer to unpublished patent applications or other secret documents. We should go out of our way to favor free solutions, and only consider encumbered solutions when there is an obvious benefit not available in the free version. And we should alert other working groups to the dangers of encumbered property. Some of us may find our way into other working groups and I hope we will keep IPR in mind if we do. For myself, I will continue to work on this problem and be a part of this group. My focus will be on making sure that an unencumbered solution is available, such as SPF with varying scope and other alternatives. I have always been a strong supporter of SPF and I will continue to work on trying to make it (or something like it) available as an RFC (or at least as an experimental RR if we can't get anything to the RFC stage). Also, if I have any influence in the matter, I will try to make sure PRA or anything poisoned by MS *doesn't* make it to PS stage, though this is a lower priority; I'm sure the public is capable of voting with their feet if an unencumbered track is available. And who knows? Maybe our wishes will come true, their patent app will be denied, and nothing will really be encumbered anyway. In that case MS will be thwarted in the larger crime of stealing everyone else's work, and will only be guilty of the lesser misdemeanor of wasting huge amounts of our time with legal discussions when we could have been talking about technical, tactical, and strategic issues. I would also like to thank everyone who contributed time and energy, ideas and inspiration, collaboration and compromise, and other manner of blood, sweat and tears, and did so without any thought to protecting their "rights" to certain dubious "property". I guess it's true that you never really find out the value of something until you find it conspicuously missing. We have a good group of people and I hope this list is allowed to stay open -- if not (or if you choose not to stay on the list for your own reasons) please consider spf-discuss as an alternative forum. -- Greg Connor gconnor@nekodojo.org Everyone says that having power is a great responsibility. This is a lot of bunk. Responsibility is when someone can blame you if something goes wrong. When you have power you are surrounded by people whose job it is to take the blame for your mistakes. If they're smart, that is. -- Cerebus, "On Governing" From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 16:56: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 QAA15345 for ; Wed, 22 Sep 2004 16:56: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 i8MKPTkO084203; Wed, 22 Sep 2004 13:25:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MKPTXS084202; Wed, 22 Sep 2004 13:25:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MKPRfr084192 for ; Wed, 22 Sep 2004 13:25:28 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CADg7-0003fc-00 for ; Wed, 22 Sep 2004 22:25:27 +0200 Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Sep 2004 22:25:22 +0200 Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Sep 2004 22:25:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: MARID to close Date: Wed, 22 Sep 2004 22:25:09 +0200 Organization: Lines: 11 Message-ID: <4151DFA5.231F@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > I believe that this has been obvious since the first > month or two of this working group. I agree with everything you say. What was the idea here, waiting until somebody patented ideas stolen from the IETF, and then close the corresponding WG ? Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 16:57:17 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 QAA15398 for ; Wed, 22 Sep 2004 16:57:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MKNgeN084122; Wed, 22 Sep 2004 13:23:42 -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 i8MKNgsr084121; Wed, 22 Sep 2004 13:23:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MKNfiV084112 for ; Wed, 22 Sep 2004 13:23:41 -0700 (PDT) (envelope-from mbaugher@cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 22 Sep 2004 13:23:48 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn4-594.cisco.com [10.21.82.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8MKNc3c024994; Wed, 22 Sep 2004 13:23:39 -0700 (PDT) In-Reply-To: <20040922184455.GA31257@danisch.de> References: <20040922184455.GA31257@danisch.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <42A0193E-0CD5-11D9-BB05-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Mark Baugher Subject: Re: MARID to close Date: Wed, 22 Sep 2004 13:23:26 -0700 To: Hadmut Danisch 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 I am sorry to read stuff like this and feel that the chairs did a pretty good job and so did the IETF despite this particular disappointment. Mark On Sep 22, 2004, at 11:44 AM, Hadmut Danisch wrote: > > On Wed, Sep 22, 2004 at 01:10:25PM -0500, wayne wrote: >> >> The failure of the AD and co-chairs to make sure that these >> problems were resolved many months ago is an astounding failure. > > > I agree. They did their very best to ignore the major > problems and to aggressively make everyone quiet who tried > to mention the problems. > > > regards > Hadmut > > From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 17:16: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 RAA16493 for ; Wed, 22 Sep 2004 17:16:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MKihQP085437; Wed, 22 Sep 2004 13:44: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 i8MKihNv085436; Wed, 22 Sep 2004 13:44:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MKifEB085427 for ; Wed, 22 Sep 2004 13:44:42 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i8MKq4Z0014340; Wed, 22 Sep 2004 16:52:04 -0400 From: To: "'Mark Baugher'" , "'Hadmut Danisch'" Cc: "'IETF MARID WG'" Subject: RE: MARID to close Date: Wed, 22 Sep 2004 16:39:31 -0400 Message-ID: <003601c4a0e4$44085180$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <42A0193E-0CD5-11D9-BB05-000A95DC10F2@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit If certain people had been a little more "PRO GROUP" and a little less "PRO WHATEVER MS WANTS TO PUSH" then I would agree with you. But the facts are the facts: -the suppression of anyone talking about the IP concerns -the suppression of the original mail-from SPF functionality -accepting the repeated disclosure delays from Microsoft -giving the OK to the MS license which is clearly incompatible with a significant portion of MTA's -the suppression of alternative parallel scopes (until forced at the very end) Therefore I cannot agree with you. It stank from day 1, and this effort of MS to steal the IP of SPF and related methods illustrates an ulterior motive from the start. The good news is I don't think it will work, providing the patent claims are fought off with prior art disclosure, and the fact that MS does NOT represent the majority of MTA's anyway. Lets proceed with SPF Classic and/or Unified SPF. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Mark Baugher > Sent: Wednesday, September 22, 2004 4:23 PM > To: Hadmut Danisch > Cc: IETF MARID WG > Subject: Re: MARID to close > > > > I am sorry to read stuff like this and feel that the chairs did a > pretty good job and so did the IETF despite this particular > disappointment. > > Mark > On Sep 22, 2004, at 11:44 AM, Hadmut Danisch wrote: > > > > > On Wed, Sep 22, 2004 at 01:10:25PM -0500, wayne wrote: > >> > >> The failure of the AD and co-chairs to make sure that these > >> problems were resolved many months ago is an astounding failure. > > > > > > I agree. They did their very best to ignore the major > > problems and to aggressively make everyone quiet who tried > > to mention the problems. > > > > > > regards > > Hadmut > > > > > From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 17:27:41 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 RAA17329 for ; Wed, 22 Sep 2004 17:27:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MKvYCf086378; Wed, 22 Sep 2004 13:57:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MKvXFx086377; Wed, 22 Sep 2004 13:57:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailshell.com (www13.mailshell.com [209.157.66.247]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8MKvXcp086367 for ; Wed, 22 Sep 2004 13:57:33 -0700 (PDT) (envelope-from mxcomp@brycer.com) Received: (qmail 11851 invoked by uid 99); 22 Sep 2004 20:57:31 -0000 Message-ID: <20040922205731.19765.qmail@mailshell.com> Date: Wed, 22 Sep 2004 13:57:30 -0700 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: MARID to close References: <20040922182419.GA30381@danisch.de> In-Reply-To: <20040922182419.GA30381@danisch.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: mxcomp@brycer.com To: ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hadmut Danisch wrote: > On Wed, Sep 22, 2004 at 11:11:28AM -0700, william(at)elan.net wrote: >> >>I'd like to request that this mail list not be closed together with WG so >>that we could continue to discuss dns / email authorization technologies >>here and get input into possible experimental drafts that some may want >>to publish that address the area that this WG was supposed to work >>on. > > I second this proposal and like to request to keep the archives > open as well. > I would like to see the archives remain available for educational and reference purposes. I would consel the chairs to close the email list. It has served its purpose. The WG is disbanded. I see no value in continuing the list. Given the tone the list has assumed, I had and have no further interest in reading posts. Bryce Ryan From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 17:42: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 RAA18509 for ; Wed, 22 Sep 2004 17:42: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 i8MLGEm4087845; Wed, 22 Sep 2004 14:16: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 i8MLGEa7087844; Wed, 22 Sep 2004 14:16:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from txdmzmailmx02.bankofamerica.com (txmx02.bankofamerica.com [171.161.160.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MLGDu7087837 for ; Wed, 22 Sep 2004 14:16:14 -0700 (PDT) (envelope-from Mike.Markley@bankofamerica.com) Received: from txdmzmailmx01.bankofamerica.com ([171.182.168.78]) by txdmzmailmx02.bankofamerica.com (8.12.11/8.12.11) with ESMTP id i8MLGCcq030565; Wed, 22 Sep 2004 21:16:12 GMT Received: from memscmpl1. (txdalcu01s1340.bankamerica.com [171.178.0.202]) by txdmzmailmx01.bankofamerica.com (8.12.11/8.12.11) with SMTP id i8MLG2J9025899; Wed, 22 Sep 2004 21:16:12 GMT Received: from memmta0201 (171.186.107.201) by memscmpl1. (Sigaba Gateway v3.6.1) with ESMTP id 76853418; Wed, 22 Sep 2004 16:16:12 -0500 Date: Wed, 22 Sep 2004 14:21:50 -0700 From: "Markley, Mike" Subject: RE: MARID to close To: Ted Hardie , ietf-mxcomp@imc.org Cc: andy@hxr.us, mrose@dbc.mtview.ca.us, Scott Hollenbeck Message-id: <252481A792E5C84C8D108F791D8F5E4E037C0C59@ex2k.bankofamerica.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-class: urn:content-classes:message Thread-topic: MARID to close Thread-index: AcSgw2OBT+ibTN96RXyDE04PCZKEYwAJVaPg X-OriginalArrivalTime: 22 Sep 2004 21:16:11.0695 (UTC) FILETIME=[62B32BF0:01C4A0E9] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Ted Hardie > Sent: Wednesday, September 22, 2004 9:31 AM > To: ietf-mxcomp@imc.org > Cc: andy@hxr.us; mrose@dbc.mtview.ca.us; Scott Hollenbeck > Subject: MARID to close > > Rather than spin in place, the working group chairs and Area Advisor > believe that the > best way forward is experimentation with multiple proposals and a > subsequent review of deployment experience. The working group chairs > and Area Advisor intend to ask that the editors of existing working > group drafts put forward their documents as non-working group > submissions for Experimental RFC status. Given the importance of the > world-wide email and DNS systems, it is critical that IETF-sponsored > experimental proposals likely to see broad deployment contain no > mechanisms that would have deleterious effects on the overall system. > The Area Directors intend, therefore, to request that the > experimental proposals be reviewed by a focused technology > directorate. This review group has not yet been formed but, as with > all directorates, its membership will be publicly listed at > http://www.ietf.org/u/ietfchair/directorates.html once it has been > constituted. Should this be construed to mean that there's still the hope and intention to someday producing a standards-track RFC for IP-based sender authentication? Despite the misgivings of those who think that IP-based schemes are pointless in the face of other efforts at cryptographic solutions, there are obviously many who think they're useful enough, and a "real" standard would be a great thing. -- Mike Markley UNIX Email Admin, Electronic Communications From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 17:46: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 RAA18804 for ; Wed, 22 Sep 2004 17:46: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 i8MLN0iP088318; Wed, 22 Sep 2004 14:23:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MLN0u7088317; Wed, 22 Sep 2004 14:23:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MLN0Ae088308 for ; Wed, 22 Sep 2004 14:23:00 -0700 (PDT) (envelope-from dotzero@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so2330147rnb for ; Wed, 22 Sep 2004 14:22:57 -0700 (PDT) Received: by 10.38.8.54 with SMTP id 54mr189379rnh; Wed, 22 Sep 2004 14:22:57 -0700 (PDT) Received: by 10.38.8.22 with HTTP; Wed, 22 Sep 2004 14:22:57 -0700 (PDT) Message-ID: <7ae58c2204092214225bc3d3ac@mail.gmail.com> Date: Wed, 22 Sep 2004 17:22:57 -0400 From: Michael Hammer Reply-To: Michael Hammer To: ietf-mxcomp@imc.org Subject: Re: MARID to close In-Reply-To: <4151DFA5.231F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4151DFA5.231F@xyzzy.claranet.de> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit First off I'd like to thank the co-chairs and AA for taking on a difficult task under difficult circumstances. Regardless of how things have played out it bothers me that some would accuse them of ill-intent or not doing a good job. While I don't agree with all the calls they made I'm not going to second guess those calls. I am disappointed that everyone is being turned loose to go their own way and experiment. This sort of approach is likely to increase email deliverability problems without addressing the issues that resulted in the formation of the working group. This is too important to let folks "duke it out" and whatever is left is the standard. Given the current circumstances I would be interested in how participants of the list would answer the 30 questions listed in the FTC/NIST Email Authentication Summit announcement. I'm still digesting the questions but do plan on writing down answers (not necessarily for submission to the FTC) and may post them to the list. If anyone else from the list is planning on attending the Summit (Nov 9/10 in Washington, D.C.) I wouldn't mind trying to get together a group of MARID list folks for dinner/discussion the evening of November 9th. Nothing formal and not sure what would come out of it. Mike From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 18:05: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 SAA20277 for ; Wed, 22 Sep 2004 18:05: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 i8MLbm4q089042; Wed, 22 Sep 2004 14:37: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 i8MLbmQI089041; Wed, 22 Sep 2004 14:37:48 -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 i8MLbl7v089031 for ; Wed, 22 Sep 2004 14:37:48 -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 i8MLbkZI022346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Sep 2004 17:37:50 -0400 Subject: Re: Disappointed From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1095889038.17005.21.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.plus.03.pri) Date: Wed, 22 Sep 2004 17:37:18 -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-09-22 at 16:29, Greg Connor wrote: Overall, very well stated. [snip] However: > To the rest of the WG I say: we have been fooled once by the likes of MS; > let's not let it happen again. This makes it sound like that it took this event to teach people. I pretty much refrained from any so-called Microsoft-bashing on this list. But over and over and over again, I find that people who claim that we should give the company the benefit of the doubt, forget one very important point: there is no doubt. Microsoft's goals in regards to patents, the GPL, and FOSS in general are a matter of public record. The company was only living up to what their executives have said in the press. This WG chose to ignore that, instead prohibiting any discussion of so-called "hidden" agenda. It wasn't hidden at all. I am also disappointed at the putting off of the extremely important non-technical IPR issue until it was too late. The members of IETF, wanting to be faithful to the 'E' in the name, naturally want to concentrate on engineering issues at least primarily, but even ONLY engineering, if that's possible. I would like to suggest that if that is the desire, it is an impossibility. You cannot compartmentalize your work that way. Especially in today's world. I would like to admonish everyone here that if we are going to involve Microsoft AT ALL in any future MTA authorization efforts to remain extremely wary. The company has shown its colors. Richard Stallman was right and frankly, at least in this particular instance, should not have been silenced. EXPECT it to happen again and do not accept anything less that full disclosure of ALL IPR. And show an unwaivering preference for unencumbered technologies. Don't wait until all technical matters are worked out. I'm not saying 'to hell with procedure'. I'm just cautioning against letting anyone waste a colossal amount of our time again. -- -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 Wed Sep 22 18:14: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 SAA21401 for ; Wed, 22 Sep 2004 18:14:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MLmW1G089794; Wed, 22 Sep 2004 14:48:32 -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 i8MLmWcd089793; Wed, 22 Sep 2004 14:48:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MLmV4L089787 for ; Wed, 22 Sep 2004 14:48:31 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-091-641.area3.spcsdns.net ([68.245.100.150]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1CAEyY-0005aZ-G0; Wed, 22 Sep 2004 17:48:36 -0400 Message-ID: <4151F323.4030008@solidmatrix.com> Date: Wed, 22 Sep 2004 17:48:19 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, ru, he MIME-Version: 1.0 To: mxcomp@brycer.com CC: ietf-mxcomp@imc.org Subject: Re: MARID to close References: <20040922182419.GA30381@danisch.de> <20040922205731.19765.qmail@mailshell.com> In-Reply-To: <20040922205731.19765.qmail@mailshell.com> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit mxcomp@brycer.com wrote: > > Hadmut Danisch wrote: > >> On Wed, Sep 22, 2004 at 11:11:28AM -0700, william(at)elan.net wrote: >> >>> >>> I'd like to request that this mail list not be closed together with >>> WG so >>> that we could continue to discuss dns / email authorization >>> technologies here and get input into possible experimental drafts >>> that some may want to publish that address the area that this WG was >>> supposed to work >>> on. >> >> >> I second this proposal and like to request to keep the archives >> open as well. >> > > I would like to see the archives remain available for educational and > reference purposes. I would consel the chairs to close the email list. > It has served its purpose. The WG is disbanded. I see no value in > continuing the list. Given the tone the list has assumed, I had and > have no further interest in reading posts. > There are multiple mailing lists operated on IMC.ORG that are related to the IETF and Internet email, while not being "official" lists of the IETF but serving as WG lists at some points. This may continue as one of them. Archives are of course always available at the IETF and Gmane.org. Yakov From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 18:48: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 SAA23891 for ; Wed, 22 Sep 2004 18:48: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 i8MMRRFC093901; Wed, 22 Sep 2004 15:27:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MMRRDS093900; Wed, 22 Sep 2004 15:27:27 -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 i8MMRQu8093879 for ; Wed, 22 Sep 2004 15:27:26 -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 i8MMeV1C028287; Wed, 22 Sep 2004 15:40:31 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8MMeVWP028284; Wed, 22 Sep 2004 15:40:31 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 22 Sep 2004 15:40:31 -0700 (PDT) From: "william(at)elan.net" To: "Markley, Mike" cc: ietf-mxcomp@imc.org Subject: RE: MARID to close In-Reply-To: <252481A792E5C84C8D108F791D8F5E4E037C0C59@ex2k.bankofamerica.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 Wed, 22 Sep 2004, Markley, Mike wrote: > Should this be construed to mean that there's still the hope and > intention to someday producing a standards-track RFC for IP-based sender > authentication? Despite the misgivings of those who think that IP-based > schemes are pointless in the face of other efforts at cryptographic > solutions, there are obviously many who think they're useful enough, and > a "real" standard would be a great thing. I think the answer given by IETF is that there can not be found at this time one solution that would reach consensus of all participants and that they will accept several solutions for EXPERIMENTAL track RFCs and after certain time and would like to see these solutions being deployed and compare the results. I would expect after one or two years one or more of these solutions that shows good results in its deployment maybe reconsidered for STANDARD track. IETF also specifically said that only solutions that are compatible with technical specs of existing RFCs would be considered even for experimental RFCs (directorate to be formed to decide if proposal moves forward or not). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 19:01:48 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 TAA24646 for ; Wed, 22 Sep 2004 19:01:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MMYd4a094508; Wed, 22 Sep 2004 15:34: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 i8MMYd6i094507; Wed, 22 Sep 2004 15:34:39 -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 i8MMYccI094500 for ; Wed, 22 Sep 2004 15:34:38 -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 1CAFh8-0008R3-MY for ietf-mxcomp@imc.org; Wed, 22 Sep 2004 17:34:43 -0500 To: "IETF MARID WG" References: <4151D8AA.3010608@solidmatrix.com> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 22 Sep 2004 17:34:38 -0500 In-Reply-To: <4151D8AA.3010608@solidmatrix.com> (Yakov Shafranovich's message of "Wed, 22 Sep 2004 15:55:22 -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: A Note of Appreciation 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.6 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 <4151D8AA.3010608@solidmatrix.com> Yakov Shafranovich writes: > I just wanted to thank [...] I decided not to send my first reply to the "MARID to close" thread, it was far too caustic. It did, however, contain the following thanks: I would like to thank Andy Newton for his work as co-chair. He has worked very hard to try to keep things on target. Andy did actual research into the effectiveness of the PRA and SPF, something that a chair is not required to do. I would also like the many participants here who dug up actual data and facts, the basis of which all engineering is done. Yakov Shafranovich and Margret Olson immediately jump to mind, but I know I'm missing some people. I would like to thank Meng, Mark and Eric for their work on the drafts. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 19:06:55 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 TAA24889 for ; Wed, 22 Sep 2004 19:06: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 i8MMhOLo095025; Wed, 22 Sep 2004 15:43: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 i8MMhOYt095024; Wed, 22 Sep 2004 15:43:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gizmo03ps.bigpond.com (gizmo03ps.bigpond.com [144.140.71.13]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8MMhLIG095012 for ; Wed, 22 Sep 2004 15:43:22 -0700 (PDT) (envelope-from ian.peter@ianpeter.com) Received: (qmail 5435 invoked from network); 22 Sep 2004 22:43:12 -0000 Received: from unknown (HELO psmam10.bigpond.com) (144.135.25.97) by gizmo03ps.bigpond.com with SMTP; 22 Sep 2004 22:43:12 -0000 Received: from cpe-144-136-148-138.qld.bigpond.net.au ([144.136.148.138]) by psmam10.bigpond.com(MAM REL_3_4_2a 216/44851380) with SMTP id 44851380; Thu, 23 Sep 2004 08:43:13 +1000 From: "Ian Peter" To: "'Paul Iadonisi'" , Subject: RE: Disappointed Date: Thu, 23 Sep 2004 08:43:12 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <1095889038.17005.21.camel@va.local.linuxlobbyist.org> Thread-Index: AcSg5b9CLxYvgXyVReCg4Ud+STVYSAADMJGA Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yep, I'm disappointed too. > I am also disappointed at the putting off of the extremely > important non-technical IPR issue until it was too late. The > members of IETF, wanting to be faithful to the 'E' in the > name, naturally want to concentrate on engineering issues at > least primarily, but even ONLY engineering, if that's > possible. I would like to suggest that if that is the > desire, it is an impossibility. You cannot compartmentalize > your work that way. Especially in today's world. That I think is the primary lesson. IETF is not structured to deal with non-engineering issues. But it had no choice. I hope these sort of issues are being looked at in the IETF review. I also have some suggestions with overall technical approach, but as they are out of scope for MARID, and for fear of having my ideas patented by others to the exclusion of open solutions, I'll look for another forum to raise those. Ian Peter Senior Partner Ian Peter and Associates Pty Ltd P.O. Box 10670 Adelaide St Brisbane 4000 Australia Tel (617) 3870 1181 Mobile (614) 1966 7772 www.ianpeter.com www.nethistory.info www.internetmark2.org (Internet Analysis Report - 2004 now available) www.theinternettapes.com (check out the new Internet history Audio CD and Ebook at this site) > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Paul Iadonisi > Sent: Thursday, 23 September 2004 7:37 AM > To: ietf-mxcomp@imc.org > Subject: Re: Disappointed > > > On Wed, 2004-09-22 at 16:29, Greg Connor wrote: > > Overall, very well stated. > > [snip] > > However: > > > To the rest of the WG I say: we have been fooled once by > the likes of > > MS; let's not let it happen again. > > This makes it sound like that it took this event to teach > people. I pretty much refrained from any so-called > Microsoft-bashing on this list. But over and over and over > again, I find that people who claim that we should give the > company the benefit of the doubt, forget one very important > point: there is no doubt. Microsoft's goals in regards to > patents, the GPL, and FOSS in general are a matter of public record. > The company was only living up to what their executives have > said in the press. This WG chose to ignore that, instead > prohibiting any discussion of so-called "hidden" agenda. It > wasn't hidden at all. > I am also disappointed at the putting off of the extremely > important non-technical IPR issue until it was too late. The > members of IETF, wanting to be faithful to the 'E' in the > name, naturally want to concentrate on engineering issues at > least primarily, but even ONLY engineering, if that's > possible. I would like to suggest that if that is the > desire, it is an impossibility. You cannot compartmentalize > your work that way. Especially in today's world. > I would like to admonish everyone here that if we are going > to involve Microsoft AT ALL in any future MTA authorization > efforts to remain extremely wary. The company has shown its > colors. Richard Stallman was right and frankly, at least in > this particular instance, should not have been silenced. > EXPECT it to happen again and do not accept anything less > that full disclosure of ALL IPR. And show an unwaivering > preference for unencumbered technologies. Don't wait until > all technical matters are worked out. I'm not saying 'to > hell with procedure'. I'm just cautioning against letting > anyone waste a colossal amount of our time again. > > -- > -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 Wed Sep 22 19:13:49 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 TAA25276 for ; Wed, 22 Sep 2004 19:13:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MMmj9v095347; Wed, 22 Sep 2004 15:48: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 i8MMmjoF095346; Wed, 22 Sep 2004 15:48:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MMmglS095330 for ; Wed, 22 Sep 2004 15:48:45 -0700 (PDT) (envelope-from SRS0=PBrbjpCb=ML=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i8MMmcMY087886 for ; Thu, 23 Sep 2004 00:48:38 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200409222248.I8MMMCRW087876@asarian-host.net> Date: Wed, 22 Sep 2004 22:48:38 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: MARID to close X-Trace: JyVh0AgIs/Myvnf0pUpBX3aVJKJYDc7Nh7xYPJojmbhPpIamqwqC7ZoUdLsGmTJqrp+SwbQQMADZ1PShSXPg/A== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Auth: Asarian-host PGP signature iQEVAwUAQVIBRjFqW1BleBN9AQGQwgf/VJjXa7rOxTcFx3l5hdgbg+JXJTAQpg4R hjcfsEzmrVuj49pPPGmHIQ/68UbuVo46KOccTik4mlc8xEPrASmdq6X4JmnEgcQ3 QWlgKLskmzpJ2CuVwAwyoBOdF8ONCK9wqY6fyjmkHqvgPunL3pubRDoyNs6A+WDg rwqMGbn2NucIrGZkzBLBTkftD50k7cNVABkTaiIuOTjK/jxxymp9ZhdvSvHWuxzk yVmLj9DsBIoGsNnYMr+7ABcF6+jRFwy/dnGSFxgyYMywDTOermi6LzhYHyXnvA0b ZC0MLLPhp8kwVclBDzEsTp82ZQ5JDiiOqQtV56H41J5hhk+Z67be6g== =PFUw Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ted Hardie wrote: > After an assessment of the current state of the MARID working group, > its charter, and its milestones, the working group chairs and Area > Advisor have concluded that the MARID working group should be > terminated. I respect the decision of the chairs, and their reasons for reaching it. Having said so, I am still saddened by that decision, though. No issue, like IPR, has ever gone away by ignoring it; nor has any problem ever been solved by simply closing the case. I believe the "raison d'etre" for MARID remains unchanged: we still need MTA Authorization Records in DNS. What will happen now, is that we will have to regroup, and come together somewhere else, and still be faced with the exact same questions. In that light, closing MARID feels like an unwelcome detour. I also wish to express my deep concern over core Internet technology being patented and elevated to standard. I believe the IETF should never even consider standardizing such patented technology. As a body of great authority, I feel the IETF has a responsibility to the Internet community at large. And I assert here my strong belief that standardizing, or seeking to get standardized, patent-encumbered, core Internet technology, runs counter to facilitating "the evolution of the Internet architecture and the smooth operation of the Internet". Especially the latter: "encumbered" and "smooth" simply do not go together. Nonetheless, I wish to thank the chairs for sticking with, what must undoubtedly have been, a frustrating process. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 19:15: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 TAA25459 for ; Wed, 22 Sep 2004 19:15:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MMoTeS095443; Wed, 22 Sep 2004 15:50:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MMoTTn095442; Wed, 22 Sep 2004 15:50:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MMoS4m095435 for ; Wed, 22 Sep 2004 15:50:28 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i8MMo8hN010756; Thu, 23 Sep 2004 00:50:08 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i8MMkZAd011330; Thu, 23 Sep 2004 00:46:35 +0200 From: Hadmut Danisch Date: Thu, 23 Sep 2004 00:46:35 +0200 To: Paul Iadonisi Cc: ietf-mxcomp@imc.org Subject: Re: Disappointed Message-ID: <20040922224635.GA10162@danisch.de> References: <1095889038.17005.21.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095889038.17005.21.camel@va.local.linuxlobbyist.org> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 22, 2004 at 05:37:18PM -0400, Paul Iadonisi wrote: > > This WG chose to ignore that, instead prohibiting any discussion > of so-called "hidden" agenda. It wasn't hidden at all. It was quite interesting to see that on one hand the chairs were strictly claiming that this WG was free of any commercial interests and that everyone would be speaking privately on his own only, and threatening everyone to be kicked out who dared to question this, while this WG was slowly slaughtered by exactly those commercial interests they disclaimed all the time. The WG was not really going anywhere forward in a technical sense. Instead it - and especially it's chairs - were completely busy with not seeing how this working group was failing and destructed. I really do not understand what intention someone can have to chair a group this way. This is the more questionable after the problems with the first ASRG chair. Everybody stresses that e-mail and spam protection is so important. But then it is just left to be triturated between commercial interests. I've been working on that subject in IRTF/IETF since the very first day of ASRG. Since then I've seen virtually everything but research and engineering (or only very little of it). I am under the impression that the anti-spam related working groups were driven by marketing, public relations, patent claims, business, people putting themselves in the newspapers and in front of microphones and cameras, politics and propaganda. If the IETF will not be able to prevent this in future, it should consider renaming itself into ICTF (C=commercialization). regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 19:20:44 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 TAA25789 for ; Wed, 22 Sep 2004 19:20: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 i8MN01Nw096185; Wed, 22 Sep 2004 16:00: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 i8MN01I4096184; Wed, 22 Sep 2004 16:00:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MN00jE096175 for ; Wed, 22 Sep 2004 16:00:01 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i8MN05NM010938 for ietf-mxcomp@imc.org; Thu, 23 Sep 2004 01:00:05 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i8MMw4xl011762 for ietf-mxcomp@imc.org; Thu, 23 Sep 2004 00:58:04 +0200 From: Hadmut Danisch Date: Thu, 23 Sep 2004 00:58:04 +0200 To: IETF MARID WG Subject: Re: A Note of Appreciation Message-ID: <20040922225804.GB10162@danisch.de> References: <4151D8AA.3010608@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ...and I'd like to thank Yakov Shafranovich who indeed did good, fair and honest work. I do appreciate that way of work. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 19:21: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 TAA25841 for ; Wed, 22 Sep 2004 19:21: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 i8MMvXIE096024; Wed, 22 Sep 2004 15:57:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MMvXLY096023; Wed, 22 Sep 2004 15:57:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MMvWIL096013 for ; Wed, 22 Sep 2004 15:57:32 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([64.229.25.235]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040922225734.SNLM15743.tomts22-srv.bellnexxia.net@ibmrkydk2ufvdd>; Wed, 22 Sep 2004 18:57:34 -0400 From: "John Glube" To: "'Yakov Shafranovich'" , "'IETF MARID WG'" Subject: RE: A Note of Appreciation Date: Wed, 22 Sep 2004 18:57:26 -0400 Message-ID: <000e01c4a0f7$8797df20$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <4151D8AA.3010608@solidmatrix.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8MMvWIL096017 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I simply wish to add a bit to Yakov's comments. Andy, Marshall and Ted did a lot of hard work and I am personally grateful for their effort, wisdom and patience. Although this group did not achieve its final objective, a lot of effort was put in by all and at least on my part, valuable lessons have been learned. I add that we do have two sets of experimental specifications to work on. These experimental standards can now be field tested and further refined, ultimately allowing a formal standard to emerge. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004 From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 19:23:48 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 TAA25933 for ; Wed, 22 Sep 2004 19:23:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MN0oSk096234; Wed, 22 Sep 2004 16:00:50 -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 i8MN0o75096233; Wed, 22 Sep 2004 16:00:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server1.moongroup.com (server1.moongroup.com [204.157.7.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MN0ork096226 for ; Wed, 22 Sep 2004 16:00:50 -0700 (PDT) (envelope-from csm@moongroup.com) Received: by server1.moongroup.com (Postfix, from userid 99) id 375611182408D; Wed, 22 Sep 2004 19:00:53 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1.moongroup.com (Postfix) with ESMTP id 4C2A81182408C for ; Wed, 22 Sep 2004 19:00:52 -0400 (EDT) Date: Wed, 22 Sep 2004 19:00:49 -0400 (EDT) From: csm@moongroup.com Reply-To: csm@moongroup.com To: ietf-mxcomp@imc.org Subject: Re: MARID to close In-Reply-To: Message-ID: References: X-Warning-1: Spammers extracting addresses from this message will definitely want to include the following addresses: X-Warning-2: uce@ftc.gov - report@fraud.org - spamrecycle@ChooseYourMail.com X-Warning-3: rbl@mail-abuse.org - rss@mail-abuse.org - dul@mail-abuse.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Bogosity: No, tests=bogofilter, spamicity=0.000142, version=0.92.6 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 22 Sep 2004, Ted Hardie spewed into the bitstream: TH> TH>After an assessment of the current state of the MARID working group, TH>its charter, and its milestones, the working group chairs and Area TH>Advisor have concluded that the MARID working group should be TH>terminated. An excellent choice. The whole of this has been an exercise in futility from day one. The knowledge of hidden limits made clear last week when the patent applications were published was clearly available to one of our members when we started and they chose to jerk several hundred people around for months in a clearly concerted effort to increase their already overwhelming market dominance. I will not personally involve myself again as a willing contributor in any process that presumes decency, honesty, or simple forthright behavior from that member. good luck. - -- csm@moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBUgQkv6Gjsf2pQ0oRAnbIAJsFKsFR7+IVInQ51Cm0iCCix4917wCfW1zE XBxwfLoHl2YWF4AKjDgm6ic= =zr6o -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 19:33:41 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 SAA23892 for ; Wed, 22 Sep 2004 18:48: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 i8MMNGZR093126; Wed, 22 Sep 2004 15:23: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 i8MMNGLn093125; Wed, 22 Sep 2004 15:23:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MMNE0I093119 for ; Wed, 22 Sep 2004 15:23:14 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CAFMC-0007w6-00 for ; Thu, 23 Sep 2004 00:13:00 +0200 Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Sep 2004 00:13:00 +0200 Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Sep 2004 00:13:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: regarding the trademark for "Sender ID" Date: Wed, 22 Sep 2004 23:46:05 +0200 Organization: Lines: 24 Message-ID: <4151F29D.6ED2@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote in mxcomp: > to our knowledge, the IETF has not been given permission to > use either "SenderID" or "Sender ID" marks > It is our opinion that all MARID documents should no longer > reference the output of the MARID working group as "Sender > ID" or any other similar mark. We believe the risk to the > ISOC and the IETF standards publishing process to be too > great. Good idea, let's use SPF, it's widely accepted, and it has a certain fun factor. > If there is a need to refer to a simple name covering this > work in IETF documents, we recommend "MARID". You wrote this Tue, 21 Sep 2004 13:15:58 -0400. Apparently the area directors failed to inform the co-chairs about their plans to close MARID. They also failed to discuss this idea with the WG as outlined in BCP 25 chapter 4. What else went wrong ? Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 19:49: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 TAA27486 for ; Wed, 22 Sep 2004 19:49: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 i8MNDajD097172; Wed, 22 Sep 2004 16:13:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MNDaIb097171; Wed, 22 Sep 2004 16:13:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imladris.surriel.com (imladris.surriel.com [66.92.77.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MNDYjn097165 for ; Wed, 22 Sep 2004 16:13:35 -0700 (PDT) (envelope-from riel@surriel.com) Received: from [127.0.0.1] (helo=localhost) by imladris.surriel.com with esmtp (Exim 4.22) id 1CAGIj-000646-Dt; Wed, 22 Sep 2004 19:13:29 -0400 Date: Wed, 22 Sep 2004 19:13:29 -0400 (EDT) From: Rik van Riel To: terry@ashtonwoodshomes.com cc: "'Mark Baugher'" , "'Hadmut Danisch'" , "'IETF MARID WG'" Subject: RE: MARID to close In-Reply-To: <003601c4a0e4$44085180$2766f30a@development.greatgulfhomes.com> Message-ID: References: <003601c4a0e4$44085180$2766f30a@development.greatgulfhomes.com> X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org 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, 22 Sep 2004 terry@ashtonwoodshomes.com wrote: > Lets proceed with SPF Classic and/or Unified SPF. I hope we'll be able to proceed with SES. It seems much nicer in that it provides end-to-end authentication. Rik -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 20:01: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 UAA28150 for ; Wed, 22 Sep 2004 20:01: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 i8MNXfR2098603; Wed, 22 Sep 2004 16:33: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 i8MNXfSY098602; Wed, 22 Sep 2004 16:33:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts22-srv.bellnexxia.net (tomts22-srv.bellnexxia.net [209.226.175.184]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MNXe6t098595 for ; Wed, 22 Sep 2004 16:33:40 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([64.229.25.235]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040922233345.TOAV15743.tomts22-srv.bellnexxia.net@ibmrkydk2ufvdd>; Wed, 22 Sep 2004 19:33:45 -0400 From: "John Glube" To: "'Yakov Shafranovich'" , "'IETF MARID WG'" Subject: RE: A Note of Appreciation Date: Wed, 22 Sep 2004 19:33:37 -0400 Message-ID: <000f01c4a0fc$957fa5f0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8MNXe6t098597 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit One follow up point. As pointed out in the note from Ted: >The working group chairs and Area Advisor intend to ask >that the editors of existing working group drafts put >forward their documents as non-working group submissions >for Experimental RFC status. Given the importance of the >world-wide email and DNS systems, it is critical that >IETF-sponsored experimental proposals likely to see broad >deployment contain no mechanisms that would have >deleterious effects on the overall system. The Area >Directors intend, therefore, to request that the >experimental proposals be reviewed by a focused technology >directorate. I believe this is a very prudent decision. I support it fully and look forward to receiving notice of the posting of the IETF-sponsored experimental proposals, so that the community at large can move forward with field testing. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004 From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 20:30: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 UAA29510 for ; Wed, 22 Sep 2004 20:30:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N05v5d001757; Wed, 22 Sep 2004 17:05: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 i8N05vDc001756; Wed, 22 Sep 2004 17:05:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vodka.at-once.com (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N05uSf001745 for ; Wed, 22 Sep 2004 17:05:56 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vodka.at-once.com (8.12.11/8.12.11) with ESMTP id i8N05jtj018234; Wed, 22 Sep 2004 17:05:45 -0700 Subject: Re: MARID to close From: Ryan Ordway To: Ted Hardie Cc: ietf-mxcomp@imc.org, andy@hxr.us, mrose@dbc.mtview.ca.us, Scott Hollenbeck In-Reply-To: References: Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1095897945.12817.59.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 22 Sep 2004 17:05:45 -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 Wed, 2004-09-22 at 09:31, Ted Hardie wrote: > After an assessment of the current state of the MARID working group, > its charter, and its milestones, the working group chairs and Area > Advisor have concluded that the MARID working group should be > terminated. A sad but IMO forseeable event. > Concluding a group without it having achieved its goals is never a > pleasant prospect, and it is always tempting to believe that just a > small amount of additional time and energy will cause consensus to > emerge. After careful consideration, however, the working group > chairs and area advisor have concluded that such energy would be > better spent on gathering deployment experience. I truly hope that the work that has been done here can eventually translate into a working standard. If not MARID, then something. I'm sure even those vehemently against what has gone on here can agree that SOMETHING needs to be done, and the piecemeal solutions to-date are obviously note enough. We need a solution. Many thanks to the co chairs, Mr. Hardie and everyone else. Ryan -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 20:38:51 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 UAA29913 for ; Wed, 22 Sep 2004 20:38: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 i8N0EK6x002225; Wed, 22 Sep 2004 17:14:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8N0EKvi002224; Wed, 22 Sep 2004 17:14:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N0EJDb002217 for ; Wed, 22 Sep 2004 17:14:19 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: The Crystal Ball Says... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 22 Sep 2004 19:14:22 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D055421@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: MARID to close Thread-Index: AcSgx71PER1tyip6THCLYdOGPUEJQAAMp0OA From: "Gordon Fecyk" To: "IETF MXCOMP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8N0EKDb002219 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dismiss me as a comic (and a bad one at that) if you wish, but my little crystal ball reveals to me... 1) Microsoft will finish their product, continue to call it Sender ID, sue the daylights out of whoever that UK firm is for using "their" trademark, bundle it with Exchange Server 2008 or whatever they will call it, and overprice the license for its use on any non-Exchange product. They will declare The End Of Spam Is Nigh! and on schedule with their two year plan, even though it would be four years later. 2) Yahoo and Verisign (if Microsoft doesn't beat Yahoo to it) will establish a DomainKeys registry, charge obscene amounts of money for yearly subscriptions to certificate services, charge more money for an Exchange event sink for it. Or if Microsoft gets in on it, enter into yet another collusion with Verisign over PKI, like they have with signing applications Designed for Windows XP[1], and provide a competing service - Verisign wins twice. 3) Open source advocates and programmers will fully develop SPF as a competing technology, license it under the GPL and give it away. The moment a real working [3] Exchange event sink appears for it, Microsoft will sue for patent infringement. SPF development will move to Norway with its older brother PGPi, to continue distribution "illegally," and suffer the same fate as PGP. It will be called "SPFi" or some variant on that theme, and many comparisons to it and PGPi will grace technical news sites and Slashdot, where karma whores will continue to get +5 Funny scores by comparing it to sunscreen.[4] 4) In the meantime, poor sysadmins and consultants like myself will have to explain to their clients or employers why they should 1) spend exorbant amounts of money to pay for a Microsoft / Verisign solution to prevent their domain from being forged, even though half the Internet doesn't recognize it. Or 2) explain why they should engage in civil disobedience in the name of Open Source, and install something potentially illegal (depending on their country) which could expose the client or employer to action, yet is The Right Thing To Do For The Good Of The Internet, even though, *sigh*, the other half the Internet doesn't recognize it. 5) Or, some sysadmins like myself will tell everyone trying to sell / preach e-mail verification systems to go hang themselves with a CAT5 cable, and instead recommend subscribing to Messagelabs, Brightmail, Black Spider, and other managed e-mail providers, giving rise potentially to another 800 pound gorilla Who Controls Your E-mail. 6) Oh yes, let's not forget that there will be a fellow who will say that He Started It All and He Should Be Rich and He Will Sue Microsoft And SPFi for Stealing His Ideas and that The IETF Is Corrupt.[2] For all I preach about not blaming Microsoft, here's an instance where I'll gladly say it. The words: "BLAME MICROSOFT," creep across my crystal ball. Oops, my crystal ball just told me KERNEL_DATA_INPAGE_ERROR - I guess I shook it too hard. Time to replace one of the crystals, reformat and reinstall. [1] Don't even get me started here - Microsoft's Designed for Windows XP Software page and linked documentation make no reference that there would possibly be other PKI vendors who would provide code signing certificates that would let Microsoft bless their application with XP Holy Water. It's hard enough trying to make developers design for security when there are (perceived) cost barriers like this. [2] As much as I respect you Hadmut, for your gall and knowledge and sheer guts, blasting the IETF and raving like The Village Idiot throughout this process earned you that paragraph. *I'M* supposed to be The Village Idiot! [3] I tried two which promptly crashed IIS5 trying to send mail to dumbo.pobox.com. Someone forgot to test sending as well as receiving mail, apparently. [4] Or if you're a pure mathematician, "SPFi" would have a SPF value of the square root of minus one, and applying it would make you more susceptible to sunburn than your own skin would. As in Count Dracula sunburn. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 20:44: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 UAA00291 for ; Wed, 22 Sep 2004 20:44:32 -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 i8N0GvOT002690; Wed, 22 Sep 2004 17:16: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 i8N0GvJl002689; Wed, 22 Sep 2004 17:16:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N0Gus0002680 for ; Wed, 22 Sep 2004 17:16:56 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: CRMCeW8J5P8+xMtt2Vulwg 1095898617 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 335FE56D323; Wed, 22 Sep 2004 20:16:54 -0400 (EDT) Message-ID: <415215F7.7090105@elvey.com> Date: Wed, 22 Sep 2004 17:16:55 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP , Douglas Otis Cc: John Leslie Subject: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) 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 On 9/22/2004 12:52 PM, The IESG sent forth electrons to convey: >The MTA Authorization Records in DNS (MARID) working group in the >Applications Area has concluded. > > > : ( (more fully expressed by Greg Connor, with whom I fully concur, at http://article.gmane.org/gmane.ietf.mxcomp/5240 .) Thanks to all those working to produce a good MARID standard. >The mailing list will remain active. > > : ) (Bryce: unsubcrlbe!) BTW, how many subscribers do we have (peak?) >The Area Directors intend, therefore, to request that the >experimental proposals be reviewed by a focused technology >directorate. This review group has not yet been formed but, as with >all directorates, its membership will be publicly listed at >http://www.ietf.org/u/ietfchair/directorates.html once it has been >constituted. > I believe that a directorate being so tasked would be contrary to the goals of the IETF. It puts undue power in the hands of the directorate and its appointers. Spamfighting inherently presents a great challenge to achieving rough consensus. But the IETF consensus-building process is going to do a far better job achieving it than a directorate appointed by the area directors. This is evidenced by the ill-advised (and/or poorly made) decision push SenderID to last call. This decision was made by folks who were appointed by the the same folks who will appoint the directorate, yes? What a recipe for disaster! I'm opposed. Avoidance of deleterious effects is not something that creation of such a directorate would make any easier. (It also is the case that a good MARID will by design, have deleterious effects on certain traffic, e.g. email from most members of the DMA.) It seems to me that CSV and SPF were (are) both more ready for last call than SenderID ever was. =-=-=-=-=-= On 9/22/2004 1:01 AM, Douglas Otis sent forth electrons to convey: >On Tue, 2004-09-21 at 19:45, Matthew Elvey wrote: > > >>Doug, still hoping to hear back from you - on 9/14, I asked: >> >> >> >>>Doug, did you get my email - of a possible broad, strong example >>>showing [SenderID] falling down. >>> >>> > >In general.... > I was hoping for validation of the example, not generalities. But thanks for the reply. > > > >>and >> >> >> >>>If foo.dom's SPF/SenderID record lists just MX, and doesn't send spam, >>>how/why would a reputation service blacklist foo.dom? >>>e.g . >>>foo.dom. IN TXT "v=spf1 mx -all" >>> >>> > >In a simple environment exchanging messages end-to-end, the risks would >be low. There are risks accepting these types of records when a process >walks through redirects, includes and arbitrary labels for several >record types. > Huh? The question is about the record given, which has none of these problems. I conclude from your statement that given the proposed record, foo.com would be pretty safe from being blacklisted by an SPF reputation service. I don't see a specific example of what would lead a reputation service to blacklist foo.dom that could not befall a CSV system. Do you claim a server running CSV (and not using DNSSEC, of course) is not vulnerable to a poisoned cache? As I said in private email, I'm trying to nail down as mainstream an example as possible. I can't think of one, given this record. Given a record *without* -all, or with entries like ?comcast.net, I can see how a domain could well get blacklisted. Doug: >Elvey: > > >>On 9/21/2004 11:57 AM, Douglas Otis sent forth electrons to convey: >> >> >>>On Mon, 2004-09-20 at 18:50, Matthew Elvey wrote: >>> >>> >>>>On 9/20/2004 5:21 PM, Douglas Otis sent forth electrons to convey: >>>> >>>> >>>>>On Mon, 2004-09-20 at 16:33, Matthew Elvey wrote: >>>>> >>>>> >>>>> >>>>>>Here's the idea in a nutshell: CSV makes use of extant SPF records >>>>>>which already list tens of thousands of domains that are authorized >>>>>>for use in HELO. >>>>>> >>>>>>Who supports/opposes this change? >>>>>> >>>>>> >>>>>> >>>>>Ney. >>>>> >>>>>This is a repeat of an older debate. >>>>> >>>>> >>>>No, I'm making a different suggestion. Please read the whole post! >>>>I'm eliminating some or all of the records that you mention having a >>>>problem with below. >>>> >>>>I should have stated one thing clearly: only +type components of >>>>records would be relevant; ~type and ?type would be ignored. >>>> >>>> >>>As I said, this will allow the use of other record types to spoof the >>>EHLO name. >>> >>> >>I claim this is impossible. Please provide an example of this (using a >>record of the kind that my proposal proposes using). >> >> > >The label used to select the SPF record is normally based upon the >mailbox domain to select a full set of outbound MTAs. The EHLO name can >be made to match any such mailbox domain provided one of the machines is >permitted in this SPF record set. This would be bad. > > I asked for an example. I see no example here. I can't extrapolate from what you have said to come up with an example, either. Perhaps you're avoiding providing one. > > >>>The SPF type of record will normally be across an entire >>>array of providers and not for a single host. >>> >>> >>I don't see how this is possible using a record of the kind that my >>proposal proposes using. >>+include:comcast.net is not allowed, for example! >>+ptr isn't allowed either (we don't want to allow the likes of >>dialup-pool.234.234.comcast.net...) >> >> > >One, you want to use existing SPF records that were not intended to >provide the narrow selection of machines administered by the MTA >operators. Two, there is no means to restrict this list after the fact. > > 1)Sort of. 2)Nonsense. We ignore records or record components that don't meet our rules. Would you argue that there is no means to restrict a CSV "Client SMTP Authorization SRV Record" from having illegal values (e.g. a Weight of 8)? > > >>>One compromised system within this vast region can then utilize one >>>of these records to spoof the EHLO name then. If reputations are >>>based upon the MTA name and not the mailbox domain, then protecting >>>the MTA name would be much more important. It MUST not be possible >>>to mix these records out of this concern. >>> >>> >>I don't believe my proposal does this. >> >> >> > >Your approach was to prune the record set used just for the EHLO >domain. > I don't think so. It's not clear what you mean by that, so I'm not sure, but your sentence doesn't make sense to me; I don't know what you're trying to say. >That pruning can not differentiate between machines within a >delegated domain or machines within the administered domain. This would >be bad. > > I don't see where I'm saying something from which one could conclude that a record for aol.com would be non-differentiable from one for dhcp234.234.dialup.aol.com. > > >>>>>The host name used within the EHLO domain will require a separate >>>>>record anyway, so why not use a record that achieves an answer >>>>>within a single lookup? >>>>> >>>>> >>>>We should, as my post makes clear. But there are reported to be what, >>>>~300,000 SPF records? Why not use them to the extent that I suggest? >>>> >>>> >>>These records are for a different purpose, and expose a different set of >>>machines. The EHLO record set must be kept narrow in order to serve the >>>purpose of establishing accountability. The broad and weak nature of >>>the identities obtained using SPF/Sender-ID are not useful for this >>>purpose. SPF/Sender-ID should be viewed as informative for but a few >>>exceptions. >>> >>> >>Let's nail down what exceptions are appropriate then! >>(Again, I'm NOT suggesting using the identities obtained using >>SPF/SenderID!) >> >> > >The exceptions would be with respect to those domains that feel it is >okay to close their lists. > That conclusion isn't warranted. It's incorrect. In fact, I said: > [O]nly +type components of records would be relevant; ~type and ?type would be ignored. I didn't say that the entire record containing in, e.g. ~all would be ignored, just that the ~all would be ignored. So your follow-on conclusions are also unwarranted. > > > >>Some refinements to my proposal based on stuff hashed out in private email: >> >>99% of the time, an MX query will return the A records for all the >>servers listed in the MX record as add'l records, all in one UDP packet. >>Let's say that's a requirement for our purposes, where there's a +MX in >>the SPF record. >> >>"+a +mx -all" would >>need 2 more DNS queries to resolve (unless a ALL query was done, which >>is likely a bad idea). I think it's reasonable to accomodate a bit more >>than 1 add'l DNS query. >> >> >>Let's not worry about the <<1% of records where the DNS servers are >>known to return incomplete lists of Address records. Let's say that's >>a requirement for our purposes that this not happen. >> >> > >Once the IETF has expended their considerable efforts to endorse a >method that is well considered and robust, I doubt there will be any >trouble with the adoption of the standard. The problem of spam is that >great. > Certainly, if those things are all true, then the following is true as well. Todays events suggest otherwise. > >I still insist the SPF record should never be allowed to validate the >EHLO domain. It is a different data set for a different purpose. > > > >>Again, the reason for my proposal is not to change or obsolete >>CSV records, but to make CSV work in some reasonable cases where it >>can work without them without being significantly detrimental. >> >> > >Sorry, but I fail to see the point in using a TXT record and a parser to >obtain a list of addresses through a dangerous and expensive set of >lookups, when it can be done in one lookup safely. Also where it will >not accidentally allow other domains to spoof the EHLO identity. This >exclusion is needed to establish accountability. > > WTF??? I have not suggested a dangerous or expensive set of lookups. I have not not suggested a scheme that would readily allow other domains to spoof the EHLO identity. I even asked you to provide an example disproving this and you were unable to. From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 22:04: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 WAA04965 for ; Wed, 22 Sep 2004 22:04: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 i8N1ar64008891; Wed, 22 Sep 2004 18:36: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 i8N1arEO008890; Wed, 22 Sep 2004 18:36:53 -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 i8N1arMr008882 for ; Wed, 22 Sep 2004 18:36:53 -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 i8N1axiB008852 for ; Wed, 22 Sep 2004 18:36:59 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Sep 2004 18:36:59 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: ietf-mxcomp@imc.org Subject: RE: Disappointed Date: Wed, 22 Sep 2004 18:36:51 -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: > I am also disappointed at the putting off of the extremely important > non-technical IPR issue until it was too late. The members of IETF, > wanting to be faithful to the 'E' in the name, naturally want to > concentrate on engineering issues at least primarily, but even ONLY > engineering, if that's possible. I would like to suggest that if that > is the desire, it is an impossibility. You cannot > compartmentalize your work that way. The engineering issues are trivial and more or less irrelevant. The problem has always been how to get ubiquitous deployment. The spammers have won this round. That has consequences. Those arguing that the ITU take over responsibility for Internet standards will probably cite this result as evidence. From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 22:44: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 WAA18305 for ; Wed, 22 Sep 2004 22:44: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 i8N2IGMw011372; Wed, 22 Sep 2004 19:18: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 i8N2IG46011371; Wed, 22 Sep 2004 19:18:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N2IFPZ011363 for ; Wed, 22 Sep 2004 19:18:16 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: [OK, one more time...] RE: Disappointed MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 22 Sep 2004 21:18:21 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D055426@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Disappointed Thread-Index: AcShElaFdHvXy1t1Qe+al8uBCrxLgQAAEXHg From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8N2IGPZ011366 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > The spammers have won this round. That has consequences. And I thought we were over the whole "This will stop spam" thing. OK, one more time: This is your spam: - v14gr4@spammer.domain This is sender verification: - v14gr4@spammer.domain may send mail from here. This is your spam on sender verification: - 250 OK message received from spammer.domain Any questions? Anyone continuing to claim otherwise is deluded. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 23:25:23 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 XAA20166 for ; Wed, 22 Sep 2004 23:25:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N2kIFi013017; Wed, 22 Sep 2004 19:46: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 i8N2kI96013016; Wed, 22 Sep 2004 19:46:18 -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 i8N2kHdM013010 for ; Wed, 22 Sep 2004 19:46:17 -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 i8N2xbnP006039; Wed, 22 Sep 2004 19:59:37 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8N2xaCf006036; Wed, 22 Sep 2004 19:59:37 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 22 Sep 2004 19:59:36 -0700 (PDT) From: "william(at)elan.net" To: "Hallam-Baker, Phillip" cc: ietf-mxcomp@imc.org Subject: RE: Disappointed 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: I'll note a from the start that I'm dissapointed as well that IETF has decided to close MARID, I was not expecting this outcome. However I do not believe this is the end of standartization efforts of these technologies as far as IETF is concerned. > The engineering issues are trivial and more or less irrelevant. Engineering issues are never irrelevent and they are certainly not trivial. I'll note that current proposal based on CallerID algorithm basicly is flowed as far as IETF existing standards are concerned. And I'm not certain Microsoft would ever agree to modifying algorithm if this were to cause it to no longer be subject its CallerID patent application. > The problem has always been how to get ubiquitous deployment. True. And trying to push through proposal that can not be deployed by open-source community is not a way to go forward with the process. You seem to forget here that 75% of MTAs in the world are in fact using open-source email servers at their core... > The spammers have won this round. That has consequences. On this I do not agree for several reasons. First - neither SPF nor Sender ID are anti-spam technologies, they are designed to provide better email security and anti-forgery protection, but they are not the "silver bullet" to spam. Second - the technology is not dead, we'll continue with SPF. It'll be deployed (though admitedly it'd not be deployed quite as quickly and as widely as it would happened were it to become IETF standard rather then experimental RFC). > Those arguing that the ITU take over responsibility for Internet > standards will probably cite this result as evidence. I'm somewhat sceptical about UN bureaucrats in general... So I don't particularly see ITU as a solution in place of yet much smaller icann bureaucracy or non-bureaucratic ietf (which may well not be the "perfect" standards organization but certainly comes much closer to representing interests of individual internet users then ISO or OASIS which are designed to provide forum of standartization primarily only for large organizations) -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 23:44: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 XAA21242 for ; Wed, 22 Sep 2004 23:44:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N36XZG014135; Wed, 22 Sep 2004 20:06:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8N36XpL014134; Wed, 22 Sep 2004 20:06:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N36VTT014126 for ; Wed, 22 Sep 2004 20:06:32 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CAJwG-0007SP-00 for ; Thu, 23 Sep 2004 05:06:32 +0200 Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Sep 2004 05:06:32 +0200 Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Sep 2004 05:06:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: draft-ietf-marid-protocol-03 (was: New Drafts) Date: Thu, 23 Sep 2004 05:04:06 +0200 Organization: Lines: 32 Message-ID: <41523D26.3CFB@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote in mxcomp (list of the former MARID WG): > draft-ietf-marid-protocol-03 Now after the IETF has closed MARID, and the IESG has not yet accepted my appeal, I guess it's the best to continue all SPF discussions in spf-discuss for the moment. For SPF I'd like to see an update of draft-mengwong-spf-01.txt, reflecting all the work that has gone into protocol-03. The syntax in protocol-03 is much better than the original syntax. We probably can't use the stuff about different scopes for now, therefore I propose to remove this from the "protocol", and return to the original v=spf1 prefix instead of spf2.0/mfrom. Without the IETF we can also remove the parts about a new DNS RR SPF and return to the plain TXT approach. That's not very elegant, but the TXT "v=spf1" syntax _is_ common practice, and introducing any incompatability with this common practice makes no sense at this moment. AFAIK the Received-SPF: header in draft-mengwong-spf-01.txt is the only interesting part of "classic SPF" not yet covered by protocol-03 plus mailfrom-00. There are still a lot of minor issues with protocol-03 and mailfrom-00, but I'm most interested in salvaging as much as possible from this "fun ride" (quoting Yakov Shafranovich). Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Sep 22 23:55:04 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 XAA21750 for ; Wed, 22 Sep 2004 23:55: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 i8N3RUSu015657; Wed, 22 Sep 2004 20:27: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 i8N3RUEJ015656; Wed, 22 Sep 2004 20:27:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N3RTu2015646 for ; Wed, 22 Sep 2004 20:27:29 -0700 (PDT) (envelope-from shedevil@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so3208691rnk for ; Wed, 22 Sep 2004 20:27:31 -0700 (PDT) Received: by 10.38.2.75 with SMTP id 75mr3858976rnb; Wed, 22 Sep 2004 20:27:30 -0700 (PDT) Received: by 10.38.92.2 with HTTP; Wed, 22 Sep 2004 20:27:30 -0700 (PDT) Message-ID: Date: Wed, 22 Sep 2004 20:27:30 -0700 From: "Anne P. Mitchell, Esq. " Reply-To: amitchell@isipp.com To: ietf-mxcomp@imc.org Subject: Disappointed, yet..not surprised (was Re: Disappointed) Cc: spf-discuss@v2.listbox.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > To MS I say: shame on you, for trying to take credit for other people's ideas. > Shame on you for taking a "microinvention" such as PRA and trying to use that > to take over all email sender verification world-wide. Earlier this month, Matt Sergeant, of Messagegate, for whom I have a great deal of respect, wrote, of the licensing issues with Sender I.D.: "I pressed him: "Will you fix the license?". I never really got a confirmed yes or no, but my feeling was "no" when we ended the conversation. I suggested that they give their IP to the IETF (such as I believe there is precedence of - I know that IBM has committed patents to the public domain before in a similar act of openness), to which I was told that Craig believed this was a reasonable idea, but that Bill Gates himself had vetoed that idea because of the current focus on patent gathering and IPR issues at Microsoft." ..the more things change, the more they remain the same. I don't know how many of you knew Gary Kildall, or are familiar with his story, but you can read about him here - pay particular attention to the last paragraph. http://www.pbs.org/wgbh/theymadeamerica/whomade/kildall_hi.html Anne From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 00:09: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 AAA22849 for ; Thu, 23 Sep 2004 00:09: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 i8N3iLi7016893; Wed, 22 Sep 2004 20:44:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8N3iLv3016892; Wed, 22 Sep 2004 20:44:21 -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 i8N3iLIV016870 for ; Wed, 22 Sep 2004 20:44:21 -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 22E3E414C9; Wed, 22 Sep 2004 20:44:21 -0700 (PDT) Subject: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) From: Douglas Otis To: Matthew Elvey Cc: MXCOMP , John Leslie In-Reply-To: <415215F7.7090105@elvey.com> References: <415215F7.7090105@elvey.com> Content-Type: text/plain Message-Id: <1095911060.13180.168.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 22 Sep 2004 20:44:21 -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 Wed, 2004-09-22 at 17:16, Matthew Elvey wrote: The goals were obtainable, but obviously not in the time frame alloted. Perhaps diligently expressing concerns with various aspects of using script within DNS, I deserve a fair amount of the blame for this failure. Some still see this as a wonderful innovation however. When submitting CSV to the graybeards, DNS security was a primary concern and they requested ensuring a random port was an added security consideration. A technical review was not something SPF/Sender-ID advocates desired. Not wanting to point out problems without offering solutions was the motivation for creating the MPR draft. Recognizing where a suite of protocols are weak and working on these problems seems more fundamental than creating new features or complex impediments when knowing every chink will be exploited. These concerns seem to pale when compared to promises from a large company destine to change the landscape. It is also ironic, as this type of amorphous scripting in mail has largely caused the current situation. Although the goals were relatively well defined, there was still an ongoing debate whether this was actually to prevent spam, spoofing, phishing or whatever seemed to "fit" the solution touted. SMTP is a well crafted battle-scarred solution with a few odd bits broken. The EHLO name, acting as a type of post-mark is an obvious example of something broken ever since machines used more IP addresses than fit in a DNS query. I know by being outspoken, this has been a disappoint to Dave Crocker. Both Dave and John Levine deserve a great deal of credit for having a great deal of understanding in both the inter-operation of the protocols and the IETF. And now more of the same... > > In a simple environment exchanging messages end-to-end, the risks would > > be low. There are risks accepting these types of records when a process > > walks through redirects, includes and arbitrary labels for several > > record types. > Huh? The question is about the record given, which has none of these > problems. There is a good overview here. http://www.securityfocus.com/guest/17905 > I conclude from your statement that given the proposed record, foo.com > would be pretty safe from being blacklisted by an SPF reputation service. > I don't see a specific example of what would lead a reputation service > to blacklist foo.dom that could not befall a CSV system. > Do you claim a server running CSV (and not using DNSSEC, of course) is > not vulnerable to a poisoned cache? By limiting the mechanism to a single DNS lookup to a single DNS server, the exposure is much less. The goal and results are the same, the structure of the lookups are different. For what it is worth, SPF "requires" more than a single record be read perhaps from many different DNS servers. This opens a sizable can of worms. This creates a setup for an attack, especially when needing a parser to process the records. A "safe" record is thus not as safe owning to this. Yes, the simple record in your example itself would not have been useful for such an exploit. The danger lies in the general requirement to explore many different domains to resolve an address list being compiled. This problem vanishes had the list been of names rather than addresses. > As I said in private email, I'm trying to nail down as mainstream an > example as possible. I can't think of one, given this record. > > Given a record *without* -all, or with entries like ?comcast.net, I can > see how a domain could well get blacklisted. Few large organizations would wish to deal with the results of full fledged SPF and closed records. > > The label used to select the SPF record is normally based upon the > > mailbox domain to select a full set of outbound MTAs. The EHLO name can > > be made to match any such mailbox domain provided one of the machines is > > permitted in this SPF record set. This would be bad. > > I asked for an example. I see no example here. I can't extrapolate > from what you have said to come up with an example, either. > Perhaps you're avoiding providing one. Example: Mailbox.tld has SPF records that define the entire address space for three of their providers where they outsource some of their mail, and their own. I contend reputation should be based upon what you have control over. That would mean it would not be to your advantage to include the machines of these other providers in a reputation assessment. mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self. ehlo.dom spf cidr for self A compromised host in one of the ISPs or even perhaps some clever shell program issues EHLO with mailbox.dom rather than the intended ehlo.dom. The advantages of using this common DNS script structure vanish when you wish to limit your exposure for EHLO reputation assessments. > > > > One, you want to use existing SPF records that were not intended to > > provide the narrow selection of machines administered by the MTA > > operators. Two, there is no means to restrict this list after the fact. > > 1) Sort of. > 2) Nonsense. We ignore records or record components that don't meet our > rules. > Would you argue that there is no means to restrict a CSV "Client SMTP > Authorization SRV Record" from having illegal values (e.g. a Weight of 8)? The rules that accept only closed SPF components still do not achieve a goal of assessing only the administrator accountable. > > > Your approach was to prune the record set used just for the EHLO > > domain. > > I don't think so. It's not clear what you mean by that, so I'm not > sure, but your sentence doesn't make sense to me; I don't know what > you're trying to say. Just removing open elements will not achieve the desired goal as it does not provide the same set. > > That pruning can not differentiate between machines within a > > delegated domain or machines within the administered domain. This would > > be bad. > > I don't see where I'm saying something from which one could conclude > that a record for aol.com would be non-differentiable from one for > dhcp234.234.dialup.aol.com. SPF does not have the concept of administrative versus authorized. There is nothing in the syntax that would allow the differentiation. In addition, the EHLO name can express any label to select any record. > > Once the IETF has expended their considerable efforts to endorse a > > method that is well considered and robust, I doubt there will be any > > trouble with the adoption of the standard. The problem of spam is that > > great. > > Certainly, if those things are all true, then the following is true as > well. Todays events suggest otherwise. Today is not a stellar day. > > > > Sorry, but I fail to see the point in using a TXT record and a parser to > > obtain a list of addresses through a dangerous and expensive set of > > lookups, when it can be done in one lookup safely. Also where it will > > not accidentally allow other domains to spoof the EHLO identity. This > > exclusion is needed to establish accountability. > > I have not suggested a dangerous or expensive set of lookups. It is my opinion these DNS scripts are dangerous from the standpoint of both security and network integrity. > I have not not suggested a scheme that would readily allow other domains > to spoof the EHLO identity. By attempting to reuse the same SPF records for both EHLO validation and the mail channel authorization, this exposes the EHLO reputation to a larger set of MTA servers. Labels to these records is not a means to prevent their use for either purpose. > I even asked you to provide an example disproving this and you were > unable to. The line from Cool Hand Luke comes to mind. It is not because I have not tried. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 00:44: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 AAA25822 for ; Thu, 23 Sep 2004 00:44: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 i8N4CLXi019621; Wed, 22 Sep 2004 21:12:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8N4CLmh019620; Wed, 22 Sep 2004 21:12:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (news.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8N4CJ24019602 for ; Wed, 22 Sep 2004 21:12:20 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Thu, 23 Sep 2004 00:17:31 -0400 Received: from ([65.10.117.66]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 2083448828; Thu, 23 Sep 2004 00:17:29 -0400 Message-ID: <006a01c4a123$09430150$6401a8c0@hdev1> From: "Hector Santos" To: , "Ted Hardie" Cc: , , "Scott Hollenbeck" References: Subject: Re: MARID to close - Comments/Suggestions Date: Thu, 23 Sep 2004 00:08:48 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Ted, Andy: I think this a good direction. I believe the opportunity should remain available to explore the "right" solution. I also believe keeping this forum/mailing list in place will provide an avenue of public record and disclosure for all parties. So I welcome this direction and I personally would like to get more involved if its in the right direction with the proposed review group. We have commercial deployment experience with a suite of methods, including SPF, Microsoft Caller-ID, CBV (Call Back Verification), RBL and other concepts and methods centralized designed around strong product liability considerations. With that said, I would like to make specific comments and recommendations. Hopefully, some of the comments will provide helpful feedback to help mode the new direction. First I hate to deviate to this, but around here, it sounds like it needs to be stated. Although IANAL, I was trained to understand IP and analyze IP. My 25+ years of rich engineering expertise and understanding of high tech IP related issues in both the corporate and private market place is well established. This includes an understanding of the patent process both past and present, especially how the software patent process has changed over the years. . In short, there has nearly not been one day in my entire career where IP, especially product liability issues was not a major part and/or consideration for systems projects and/or product lines. With that said, I will note that in regards to the recent MS patents, we have no concerns with the claims cited in the patent applications. We have been in this market for a long time with a high-end, integrated product line and this certainly not the first time new software patents based on post 1996 relaxed guidelines were issued with claims touching based with old technology or methods re-invented as "internet solutions.". Push comes to shove, the prior art, obviousness, the relationship of natural elements in the Markush-type claims for these specific patent applications and the negligence of due diligence can be well established by the expert in the field and market of invention. So we are not worry about it. Like the others with frivolous prior-art claims, it would not be in Microsoft interest to enforce and pursue this in a court of law as it will open the door for counter-suits and patent review and establishing invalidity. I mentioned this because I believe the problem with MARID was its structure which allowed the MS patent to happen to the first place. Back in July, I offered a proposal to restructure the core to eliminate the IP issue. This proposed design structure is 100% based on providing fundamental protection against with Markus-type claims. I don't think it needs to be restate the proposal at this point, however, I do believe the following items are extremely important considerations in this new direction. 1) SMTP Protocol Summary We need to create a summary statement what are the critical issues with the SMTP. What are the loop hole? What are the ambiguities that need to be cleared up? What are the possible compatibility issues? What are the current authentication methods? This will be the basic problem statement that will help provide a total picture and "Check Off list" for the augmentation of new Extended SMTP security enhancements. 2) Extended SMTP Protocol Security Enhancements. Once have the SMTP Protocol Summary, we can begin to suggest the natural and obvious black box extensions that provide added security. In my view, this could of been the MARID CORE specification, however, as it was currently, it was locked into some current problematic and troublesome proposals. What need to do is "separate" the protocol from the actual implementations in the market place. This is very important and it will lay and establish the groundwork to pre-empt Utility Patents claims against the process. I should note this is already prior art and thus provides, if required, evidence for disputes against the Microsoft Patents. It is for this reason, Santronics is not concern about these recent email patents as this have been the framework for Santronics mail and file servers for many years. Nonetheless, MARID needs to take a position where a CORE specification provides an open-ended security enhancements to the SMTP protocol. Once this is done, the proposed "review group" can be used this new MARID CORE as a framework to evaluate new MARID compatible protocol proposals. What will the MARID-CORE include? The most important ones that stand out are: - a generic framework for ESMTP mail sender/client validation, i.e., like LMAP. - a new standard for client/server version recognition, - a proposal new set of new ESMTP commands, - a new standard set of ESMTP response codes, and - a guideline to backward SMTP compatibility (how to deal with legal operations.). 3) Optional: Rewrite SMTP 2821 One of the problems MARID had from the beginning was that lack of participation of the core IETF-SMTP participants, including the WG chair,. I was astonished by the response by the chair, the author of RFC 2821, as to why he opted out of the MARID process. It was not to hard to see that MARID was crippled when the suggestions in the proposals did not even go their the IETF-SMTP process. It was the somewhat the same issue with RFC 2822 but here there was some IETF-2822 participants due to the significances of the 822/2822 related issues. In any case, unless the MARID group gets the IETF-SMTP involved, it will be a tough climb to reach the common goals we are all looking for success across the board. We need to recognize that the old design philosophy in SMTP 2821, a "relaxed internet spirit required for wide deployment with less emphasis with security" no longer applies today. In summary: In step 1, we take a step back to the SMTP protocol to establish the groundwork for step 2. We get a good picture of what's wrong with the protocol. At a minimum, by providing a new SMTP specification in step 3 it establishes a unambiguous basis for current or new SMTP mail servers to use for required hosting requirements in the new era. Finally, in step 2, the new MARID-CORE is designed with a new level of SMTP operational expectations that it can use as a generic framework for mail security. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "Ted Hardie" To: Cc: ; ; "Scott Hollenbeck" Sent: Wednesday, September 22, 2004 12:31 PM Subject: MARID to close > Rather than spin in place, the working group chairs and Area Advisor > believe that the best way forward is experimentation with multiple proposals and a > subsequent review of deployment experience. The working group chairs > and Area Advisor intend to ask that the editors of existing working > group drafts put forward their documents as non-working group > submissions for Experimental RFC status. Given the importance of the > world-wide email and DNS systems, it is critical that IETF-sponsored > experimental proposals likely to see broad deployment contain no > mechanisms that would have deleterious effects on the overall system. > > The Area Directors intend, therefore, to request that the > experimental proposals be reviewed by a focused technology > directorate. This review group has not yet been formed but, as with > all directorates, its membership will be publicly listed at > http://www.ietf.org/u/ietfchair/directorates.html once it has been > constituted. > > Concluding a group without it having achieved its goals is never a > pleasant prospect, and it is always tempting to believe that just a > small amount of additional time and energy will cause consensus to > emerge. After careful consideration, however, the working group > chairs and area advisor have concluded that such energy would be > better spent on gathering deployment experience. > > regards, > Ted Hardie > co-Area Director, Applications > > From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 01:07: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 BAA27197 for ; Thu, 23 Sep 2004 01:07:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N4alAn021215; Wed, 22 Sep 2004 21:36:47 -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 i8N4al2B021214; Wed, 22 Sep 2004 21:36:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8N4akJm021208 for ; Wed, 22 Sep 2004 21:36:46 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Thu, 23 Sep 2004 00:41:57 -0400 Received: from ([65.10.117.66]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 2084915531; Thu, 23 Sep 2004 00:41:56 -0400 Message-ID: <007a01c4a126$73776450$6401a8c0@hdev1> From: "Hector Santos" To: "Hallam-Baker, Phillip" , References: Subject: Re: Disappointed Date: Thu, 23 Sep 2004 00:33:06 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 ----- Original Message ----- From: "Hallam-Baker, Phillip" To: Sent: Wednesday, September 22, 2004 9:36 PM Subject: RE: Disappointed > The engineering issues are trivial and more or less irrelevant. Phillip, I respectfully disagree. I believe this has been the fundamental reason why there was no censensus. These administrative based proposals were crippled from the onset due to the lack of understanding technical SMTP operations in the market place, which include concepts such as Dynamic vs POST SMTP mail analysis. A important distinction in how these proposals work or do not work, and more important how it related to product and operator liability issues. > The problem has always been how to get ubiquitous deployment. and this begins by with stepping back and understanding the barriers to deployment. What is needed is a clarification of the SMTP functional specification with the removal of all loop holes at the "specification" level. Once that is done, then the software vendors and administrators have a basis to get a clear picture for the operability and reliability of ESMTP based security proposals (MARID) and how the software is implemented by administrators. Basic example: Both CSV can work, it needs to lay the ground with a new 2821 specification that will enforce the CVS entities to exist. Current software developers can upgrade their software based on the new 2821 alone and new SMTP developers have new 2821 document to use a framework. This will great a market of growing compatible products. Once this is done, then CSV and SPF proposals will work better. Until that happens, what is left is a suite of solutions required by the vendors. Just consider a product like ours which provides a 98% reject rate based on 5-6 suite of methods in place. We must write and run our SMTP software such a way that is based on the idea that no one single method will cover it all. At the moment, we get one or two high reliable methods, people will adopt because the software vendors will adopt the technology. But that won't happen until we revisit SMTP and get that straight. Anyway, this is all deja-vu: "Administrative vs. Developer" philosophical conflicts has always hampered progress, especially in an area so important that requires a costly revamp of operations from end to end. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 01:52:48 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 BAA29505 for ; Thu, 23 Sep 2004 01:52:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N5Llht030779; Wed, 22 Sep 2004 22:21:47 -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 i8N5LlUH030778; Wed, 22 Sep 2004 22:21:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8N5Li4l030751 for ; Wed, 22 Sep 2004 22:21:44 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Thu, 23 Sep 2004 01:26:57 -0400 Received: from ([65.10.117.66]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 2087614828; Thu, 23 Sep 2004 01:26:55 -0400 Message-ID: <008c01c4a12c$bc4c3380$6401a8c0@hdev1> From: "Hector Santos" To: "Douglas Otis" , "Matthew Elvey" Cc: "MXCOMP" , "John Leslie" References: <415215F7.7090105@elvey.com> <1095911060.13180.168.camel@ddev.mail-abuse.org> Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) Date: Thu, 23 Sep 2004 01:18:10 -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 Douglas, I will be among the first to implement a solution that make sense. In regards to your CSV, I commend you for excellent written proposals, however, I offer the following reasons for why they have an element that prohibit consideration for implementation. CSV is a solution based on two methods: CSA vs. DNA. I understand all the arguments for your design, however, I don't think you (among others) have completely understood the deployment and real operations paradigm that makes CSV conflictive: First, this applies to all proposals. The EHLO/MAIL FROM validation is useless if RCPT TO is invalid. We already covered this in our emails a few months back. I believe I concluded that it should be mentioned in the specs. Second, it is possible to use CSA only for True Negatives. What are true negatives?. Here is my extended terminology for establishing the level of trust in the email arena: False Positives - a Pass that was deemed incorrect upon inspection True Positives - a Pass that was deemed correct upon inspection False Negative - a Reject that was deemed incorrect upon inspection True Negative - a Reject that was deemed correct upon inspection For example: A EHLO check that results in a REJECTION is a 100% Trusted result. This can be fundamentally proven with local domain EHLO checks, i.e., An anonymous IP trying to use your own domain(s) for the EHLO command is an easy spoof check. However, an EHLO check that results with a PASS is not a 100% trusted result and needs further scrutiny. This is where you use DNA as a well to check the trust of the result. What I am saying, you only need to do this for a PASS, not a rejection. What this means is that your lookup method needs to take into account this overhead reduction concept. Currently, the lookup says to do DNA first, then CSA. I say CSA first because ..... Third, DNA is too exclusive. CSV will not get adopted unless it has ready DNA sites. The problem I have is how to offer it to customers from a marketing standpoint. We can't make a claim for "new anti-spam technology using CSV" with a footnote that says "requires double A batteries (DNA) in order to work." If they are only 1 DNA site (MAPS for example), then this will critical some issues that need to get worked out. So at this point in time, CSV is put on the back burner. I think overall, it will continue to have this DNA stigma. But I think we can use CSA by itself. The same applies to SPF for EHLO "True Negatives" checks. But SPF suffers from its relaxed provisions. SPF HELO checks can only be TRUE or FALSE, not soft or neutral. It is not logical. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "Douglas Otis" To: "Matthew Elvey" Cc: "MXCOMP" ; "John Leslie" Sent: Wednesday, September 22, 2004 11:44 PM Subject: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) > > On Wed, 2004-09-22 at 17:16, Matthew Elvey wrote: > > The goals were obtainable, but obviously not in the time frame alloted. > Perhaps diligently expressing concerns with various aspects of using > script within DNS, I deserve a fair amount of the blame for this > failure. Some still see this as a wonderful innovation however. > > When submitting CSV to the graybeards, DNS security was a primary > concern and they requested ensuring a random port was an added security > consideration. A technical review was not something SPF/Sender-ID > advocates desired. Not wanting to point out problems without offering > solutions was the motivation for creating the MPR draft. > > Recognizing where a suite of protocols are weak and working on these > problems seems more fundamental than creating new features or complex > impediments when knowing every chink will be exploited. These concerns > seem to pale when compared to promises from a large company destine to > change the landscape. It is also ironic, as this type of amorphous > scripting in mail has largely caused the current situation. Although > the goals were relatively well defined, there was still an ongoing > debate whether this was actually to prevent spam, spoofing, phishing or > whatever seemed to "fit" the solution touted. > > SMTP is a well crafted battle-scarred solution with a few odd bits > broken. The EHLO name, acting as a type of post-mark is an obvious > example of something broken ever since machines used more IP addresses > than fit in a DNS query. I know by being outspoken, this has been a > disappoint to Dave Crocker. Both Dave and John Levine deserve a great > deal of credit for having a great deal of understanding in both the > inter-operation of the protocols and the IETF. > > And now more of the same... > > > In a simple environment exchanging messages end-to-end, the risks would > > > be low. There are risks accepting these types of records when a process > > > walks through redirects, includes and arbitrary labels for several > > > record types. > > > Huh? The question is about the record given, which has none of these > > problems. > > There is a good overview here. > http://www.securityfocus.com/guest/17905 > > > I conclude from your statement that given the proposed record, foo.com > > would be pretty safe from being blacklisted by an SPF reputation service. > > I don't see a specific example of what would lead a reputation service > > to blacklist foo.dom that could not befall a CSV system. > > Do you claim a server running CSV (and not using DNSSEC, of course) is > > not vulnerable to a poisoned cache? > > By limiting the mechanism to a single DNS lookup to a single DNS server, > the exposure is much less. The goal and results are the same, the > structure of the lookups are different. > > For what it is worth, SPF "requires" more than a single record be read > perhaps from many different DNS servers. This opens a sizable can of > worms. This creates a setup for an attack, especially when needing a > parser to process the records. A "safe" record is thus not as safe > owning to this. Yes, the simple record in your example itself would not > have been useful for such an exploit. The danger lies in the general > requirement to explore many different domains to resolve an address list > being compiled. This problem vanishes had the list been of names rather > than addresses. > > > As I said in private email, I'm trying to nail down as mainstream an > > example as possible. I can't think of one, given this record. > > > > Given a record *without* -all, or with entries like ?comcast.net, I can > > see how a domain could well get blacklisted. > > Few large organizations would wish to deal with the results of full > fledged SPF and closed records. > > > > > The label used to select the SPF record is normally based upon the > > > mailbox domain to select a full set of outbound MTAs. The EHLO name can > > > be made to match any such mailbox domain provided one of the machines is > > > permitted in this SPF record set. This would be bad. > > > > I asked for an example. I see no example here. I can't extrapolate > > from what you have said to come up with an example, either. > > Perhaps you're avoiding providing one. > > Example: Mailbox.tld has SPF records that define the entire address > space for three of their providers where they outsource some of their > mail, and their own. I contend reputation should be based upon what you > have control over. That would mean it would not be to your advantage to > include the machines of these other providers in a reputation > assessment. > > mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self. > > ehlo.dom spf cidr for self > > A compromised host in one of the ISPs or even perhaps some clever shell > program issues EHLO with mailbox.dom rather than the intended ehlo.dom. > > The advantages of using this common DNS script structure vanish when you > wish to limit your exposure for EHLO reputation assessments. > > > > > > > > One, you want to use existing SPF records that were not intended to > > > provide the narrow selection of machines administered by the MTA > > > operators. Two, there is no means to restrict this list after the fact. > > > > 1) Sort of. > > 2) Nonsense. We ignore records or record components that don't meet our > > rules. > > Would you argue that there is no means to restrict a CSV "Client SMTP > > Authorization SRV Record" from having illegal values (e.g. a Weight of 8)? > > The rules that accept only closed SPF components still do not achieve a > goal of assessing only the administrator accountable. > > > > > > > Your approach was to prune the record set used just for the EHLO > > > domain. > > > > I don't think so. It's not clear what you mean by that, so I'm not > > sure, but your sentence doesn't make sense to me; I don't know what > > you're trying to say. > > Just removing open elements will not achieve the desired goal as it does > not provide the same set. > > > > That pruning can not differentiate between machines within a > > > delegated domain or machines within the administered domain. This would > > > be bad. > > > > I don't see where I'm saying something from which one could conclude > > that a record for aol.com would be non-differentiable from one for > > dhcp234.234.dialup.aol.com. > > SPF does not have the concept of administrative versus authorized. > There is nothing in the syntax that would allow the differentiation. In > addition, the EHLO name can express any label to select any record. > > > > Once the IETF has expended their considerable efforts to endorse a > > > method that is well considered and robust, I doubt there will be any > > > trouble with the adoption of the standard. The problem of spam is that > > > great. > > > > Certainly, if those things are all true, then the following is true as > > well. Todays events suggest otherwise. > > Today is not a stellar day. > > > > > > > > Sorry, but I fail to see the point in using a TXT record and a parser to > > > obtain a list of addresses through a dangerous and expensive set of > > > lookups, when it can be done in one lookup safely. Also where it will > > > not accidentally allow other domains to spoof the EHLO identity. This > > > exclusion is needed to establish accountability. > > > > I have not suggested a dangerous or expensive set of lookups. > > It is my opinion these DNS scripts are dangerous from the standpoint of > both security and network integrity. > > > I have not not suggested a scheme that would readily allow other domains > > to spoof the EHLO identity. > > By attempting to reuse the same SPF records for both EHLO validation and > the mail channel authorization, this exposes the EHLO reputation to a > larger set of MTA servers. Labels to these records is not a means to > prevent their use for either purpose. > > > I even asked you to provide an example disproving this and you were > > unable to. > > The line from Cool Hand Luke comes to mind. It is not because I have > not tried. > > -Doug > > From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 03:47: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 DAA19648 for ; Thu, 23 Sep 2004 03:47: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 i8N7FNIW080090; Thu, 23 Sep 2004 00:15:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8N7FNna080088; Thu, 23 Sep 2004 00:15:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend2.messagingengine.com (frontend2.messagingengine.com [66.111.4.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N7FND9080067 for ; Thu, 23 Sep 2004 00:15:23 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: Jh4fGYtIpEbRAD7dYprhDw 1095923718 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id 8B6CB56D33A; Thu, 23 Sep 2004 03:15:15 -0400 (EDT) Message-ID: <41527800.4000405@elvey.com> Date: Thu, 23 Sep 2004 00:15:12 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis Cc: wayne , MXCOMP Subject: Re: Make CSV backwards compatible with legacy SPF records? References: <415215F7.7090105@elvey.com> <1095911060.13180.168.camel@ddev.mail-abuse.org> In-Reply-To: <1095911060.13180.168.camel@ddev.mail-abuse.org> 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 Aha! I found the post with the relevant stats. They're from March, though. Also, my recollection was off - domains using the ten most popular SPF records included only 1/2 of the total domains with records. http://www.imc.org/ietf-mxcomp/mail-archive/msg00644.html Something reasonably recent would be great. Anyway, let's consider the top ten (which I've reordered a bit) from wayne: 1 1097 v=spf1 mx -all 3 463 v=spf1 a mx ptr -all 4 429 v=spf1 a mx -all 9 131 v=spf1 a mx ?all 6 306 v=spf1 a -all The above would generally take 1-3 UDP DNS queries to resolve. 5 325 v=spf1 -all 7 171 v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.example.com -all 8 131 v=spf1 include:example.org ~all 10 130 v=spf1 ?all These are equivalent to the null set, for the purposes of my proposal. 2 804 v=spf1 ip4:a.b.c.d/32 ip4:a.b.c.d/32 a ptr mx -all This is probably no longer in the top ten. On 9/22/2004 8:44 PM, Douglas Otis sent forth electrons to convey: >On Wed, 2004-09-22 at 17:16, Matthew Elvey wrote: > > > >>Huh? The question is about the record given, which has none of these >>problems. ( foo.dom. IN TXT "v=spf1 mx -all" ) >> > >There is a good overview here. >http://www.securityfocus.com/guest/17905 > > Yes, a good refresher. Anyway it leads me to believe that the record only suffers from a problem that also afflicts CSV and that a good bind9 or djbdns config can handle. > > >>I conclude from your statement that given the proposed record, foo.com >>would be pretty safe from being blacklisted by an SPF reputation service. >>I don't see a specific example of what would lead a reputation service >>to blacklist foo.dom that could not befall a CSV system. >>Do you claim a server running CSV (and not using DNSSEC, of course) is >>not vulnerable to a poisoned cache? >> >> > >By limiting the mechanism to a single DNS lookup to a single DNS server, >the exposure is much less. > Ok, it is a little less. The risk is also low to start with. (Birthday attacks aren't common, AFAIK; I've never logged one.) It's even lower to nonexistent given recent/patched/secure DNS software and systems (e.g. a split-split configuration). >For what it is worth, SPF "requires" more than a single record be read >perhaps from many different DNS servers. This opens a sizable can of >worms. > Clearly, I need to better explain my scheme, as it still seems unclear to you that what SPF "requires" isn't relevant to my proposal! Please, can you give up using this as an opportunity to bash SPF? It's OT. (Note the changed Subject:). > > > >>As I said in private email, I'm trying to nail down as mainstream an >>example as possible. I can't think of one, given this record. >> >>Given a record *without* -all, or with entries like ?comcast.net, I can >>see how a domain could well get blacklisted. >> >> > >Few large organizations would wish to deal with the results of full >fledged SPF and closed records. > > Doesn't matter; assuming this is true, it doesn't hurt my proposal. > > > > >>>The label used to select the SPF record is normally based upon the >>>mailbox domain to select a full set of outbound MTAs. The EHLO name can >>>be made to match any such mailbox domain provided one of the machines is >>>permitted in this SPF record set. This would be bad. >>> >>> >>I asked for an example. I see no example here. I can't extrapolate >>from what you have said to come up with an example, either. >>Perhaps you're avoiding providing one. >> >> > >Example: Mailbox.tld has SPF records that define the entire address >space for three of their providers where they outsource some of their >mail, and their own. I contend reputation should be based upon what you >have control over. That would mean it would not be to your advantage to >include the machines of these other providers in a reputation >assessment. > > Ah, I did say ip4 (and therefore CIDR ranges) might be OK. (I did suggest subsequently in mail to John Leslie that perhaps just +ip4:a.b.c.d/32 might be OK, note the /32!) Perhaps even that isn't a good idea, as mailbox.dom spf ip4:[isp1's smtp]/32,ip4:[isp2's smtp]/32,ip4:[isp3's smtp] -all enables me to inappropriately stake my domain's reputation on the ability of ISPs 1-3 to keep their smtp servers from being used to spam. HOWEVER: It's already the case that such SPF records are inappropriate. If I don't have high confidence in the ISPs, then the appropriate record would be: mailbox.dom spf ?ip4:[isp1's smtp]/32, ?ip4:[isp2's smtp]/32, ?ip4:[isp3's smtp] -all and this record would be equivalent to the null set in my scheme: my proposal ignores ~anything and ?anything. Similarly, anyone creating a record like >mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self. > > will suffer the consequences of doing something so dumb, if one of the 3 ISPs seriously fails keep their smtp servers from being used to spam using mailbox.dom. The domain will get blacklisted (in other words, its reputation will fall), and the spoofing will stop. Of course, your other example: >ehlo.dom spf cidr for self > > may also lead to a poor reputation - someone in marketing might decide to send a bunch of spam, get zombie-infected, etc., etc. So CSV-tied reputations won't be perfect either; it isn't reasonable to expect them to be. They just need to be reasonably secure. >A compromised host in one of the ISPs or even perhaps some clever shell >program issues EHLO with mailbox.dom rather than the intended ehlo.dom. > Sorry, how is a clever shell program not in one of the ISPs going to get away with this? (No BGP hack/bogon/break into mailbox.dom's server scenarios, please!) > > > >>>One, you want to use existing SPF records that were not intended to >>>provide the narrow selection of machines administered by the MTA >>>operators. Two, there is no means to restrict this list after the fact. >>> >>> >> >>1) Sort of. >>2) Nonsense. We ignore records or record components that don't meet our >> rules. >>Would you argue that there is no means to restrict a CSV "Client SMTP >>Authorization SRV Record" from having illegal values (e.g. a Weight of 8)? >> >> > >The rules that accept only closed SPF components still do not achieve a >goal of assessing only the administrator accountable. > > The rules I am refining do achieve that goal. Arguably, they do so better than CSV, because they'll work for most domains that haven't bothered to set up a CSV record. Heck, using the SPF 'best guess' may be appropriate where there's no SPF or CSV record - the A&R system will reflect reality if this guess allows much spam through. > > > >>>Your approach was to prune the record set used just for the EHLO >>>domain. >>> >>> >>I don't think so. It's not clear what you mean by that, so I'm not >>sure, but your sentence doesn't make sense to me; I don't know what >>you're trying to say. >> >> > >Just removing open elements will not achieve the desired goal as it does >not provide the same set. > > That's not a logical argument. The ultimate desired goal is to address the spam problem. It may or may not be material to achievement of that goal to get "the same set". > > >>>That pruning can not differentiate between machines within a >>>delegated domain or machines within the administered domain. This would >>>be bad. >>> >>> >>I don't see where I'm saying something from which one could conclude >>that a record for aol.com would be non-differentiable from one for >>dhcp234.234.dialup.aol.com. >> >> > >SPF does not have the concept of administrative versus authorized. >There is nothing in the syntax that would allow the differentiation. In >addition, the EHLO name can express any label to select any record. > > a record for aol.com is still differentiable from one for dhcp234.234.dialup.aol.com! > > >>I have not not suggested a scheme that would readily allow other domains >>to spoof the EHLO identity. >> >>I even asked you to provide an example disproving this and you were >>unable to. >> >> > >The line from Cool Hand Luke comes to mind. It is not because I have >not tried. > > You hadn't provided an example. Now you have. Though I don't think it disproves this, as I argued above. The example has enabled us to better discuss specifics. From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 06:01: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 GAA27743 for ; Thu, 23 Sep 2004 06:01: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 i8N9URVb027290; Thu, 23 Sep 2004 02:30:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8N9URSR027289; Thu, 23 Sep 2004 02:30:27 -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 i8N9UQvK027279 for ; Thu, 23 Sep 2004 02:30:26 -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 i8N9UOcU016748 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Sep 2004 02:30:25 -0700 Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) From: Douglas Otis To: Hector Santos Cc: Matthew Elvey , MXCOMP , John Leslie In-Reply-To: <008c01c4a12c$bc4c3380$6401a8c0@hdev1> References: <415215F7.7090105@elvey.com> <1095911060.13180.168.camel@ddev.mail-abuse.org> <008c01c4a12c$bc4c3380$6401a8c0@hdev1> Content-Type: text/plain Message-Id: <1095931635.5443.66.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 23 Sep 2004 02:27:15 -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 Wed, 2004-09-22 at 22:18, Hector Santos wrote: > CSV is a solution based on two methods: CSA vs. DNA. CSV is a suite of specifications that also includes DNA. I would expect DNA to become useful after inroads have been made to help promote the use of CSV. I would imagine typical white-listing services together with rhsbl services would get the ball rolling. > I understand all the arguments for your design, however, I don't > think you (among others) have completely understood the deployment and > real operations paradigm that makes CSV conflictive: > > First, this applies to all proposals. The EHLO/MAIL FROM validation is > useless if RCPT TO is invalid. CSV allows the construction of name based relationships to relate mailbox domains with the mail channel, as example, without requiring subsequent lookups. This alone is a significant advantage from several perspectives. The identity obtained from CSV relates directly to those that administer the MTA and must be held accountable if to curtail abuse. > We already covered this in our emails a few months back. I believe > I concluded that it should be mentioned in the specs. > > Second, it is possible to use CSA only for True Negatives. I have shown in the marid-mpr draft, the results of these lookups provide the same results over a scope of MAIL FROM, From, or even PRA. The basic difference is a deterministic DNS overhead that needs but a few lookups. > What are true negatives?. > > Here is my extended terminology for establishing the level of trust in the > email arena: > > False Positives - a Pass that was deemed incorrect upon inspection > True Positives - a Pass that was deemed correct upon inspection > False Negative - a Reject that was deemed incorrect upon inspection > True Negative - a Reject that was deemed correct upon inspection I do not think you understand what it is that CSV provides by going into these details. You get the same results with three really major differences. 1) CSV provides the strongest possible identity that DNS allows which happens to relate to the MTA administration. 2) The mailbox-domain/mail-channel association can optionally act in the role of a gate-keeper without an open-ended association being exploited. 3) The overhead is always low and deterministic. > For example: > > A EHLO check that results in a REJECTION is a 100% Trusted result. This can > be fundamentally proven with local domain EHLO checks, i.e., An anonymous > IP trying to use your own domain(s) for the EHLO command is an easy spoof > check. > > However, an EHLO check that results with a PASS is not a 100% trusted result > and needs further scrutiny. CSV provides the means to apply this additional scrutiny at the smallest possible cost by using a simple name list. > This is where you use DNA as a well to check the trust of the result. What I > am saying, you only need to do this for a PASS, not a rejection. What this > means is that your lookup method needs to take into account this overhead > reduction concept. Currently, the lookup says to do DNA first, then CSA. > I say CSA first because ..... > > Third, DNA is too exclusive. DNA provides for a large market of white-listing services without requiring a polling process across many to be made. By no means does CSV limit what can be used. The drafts mention any rhsbl can be used. Of course rbls can be used as well, but it is my view a rhsbl would over-ride the rbl. > CSV will not get adopted unless it has ready DNA sites. The problem I have > is how to offer it to customers from a marketing standpoint. We can't make > a claim for "new anti-spam technology using CSV" with a footnote that says > "requires double A batteries (DNA) in order to work." Good point, but but you don't need DNA. With CSV in place, the ability to offer comprehensive name based information will change what can be obtained from these types of services and the relative overhead needed to maintain this information. A lower cost of business in this area is good all around. It also means having a name that you can confidently protect. With Sender-ID and SPF, you must cross your fingers the service provider you use gets it right, or you suffer. > If they are only 1 DNA site (MAPS for example), then this will > critical some issues that need to get worked out. So at this point in > time, CSV is put on the back burner. Although they are small at this point, there are other rhsbl. There are other service providers that, for the most part, specialize in white-listing. CSV is ideal for both dropping the hammer and white-listing the good guys. You could not ask for a better tool. > I think overall, it will continue to have this DNA stigma. But I think we > can use CSA by itself. The same applies to SPF for EHLO "True Negatives" > checks. But SPF suffers from its relaxed provisions. SPF HELO checks can > only be TRUE or FALSE, not soft or neutral. It is not logical. I see CSV and an MPR approach removing one of the major stubbing blocks found with SPF. Among several that are all related to the same issue, leaving the association "open" with SPF is an exploit waiting to happen. The CSV MPR method removes that invitation. I feel like the guy in the movie Graduate giving advice, but rather than saying "Plastics", I am saying "Names". "Names" is the future in DNS. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 07:17: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 HAA01825 for ; Thu, 23 Sep 2004 07:17:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NAgFbG053668; Thu, 23 Sep 2004 03:42:15 -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 i8NAgFGQ053667; Thu, 23 Sep 2004 03:42:15 -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 i8NAgFut053647 for ; Thu, 23 Sep 2004 03:42:15 -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 i8NAgCQD018269 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Sep 2004 03:42:13 -0700 Subject: Re: Make CSV backwards compatible with legacy SPF records? From: Douglas Otis To: Matthew Elvey Cc: wayne , MXCOMP In-Reply-To: <41527800.4000405@elvey.com> References: <415215F7.7090105@elvey.com> <1095911060.13180.168.camel@ddev.mail-abuse.org> <41527800.4000405@elvey.com> Content-Type: text/plain Message-Id: <1095935943.5443.139.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 23 Sep 2004 03:39:03 -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-09-23 at 00:15, Matthew Elvey wrote: > > > >> Huh? The question is about the record given, which has none of these > >> problems. ( foo.dom. IN TXT "v=spf1 mx -all" ) > > > > There is a good overview here. > > http://www.securityfocus.com/guest/17905 > > Yes, a good refresher. Anyway it leads me to believe that the record > only suffers from a problem that also afflicts CSV and that a good bind9 > or djbdns config can handle. I would agree that someone making an effort could protect their DNS servers, but the risks parsing script in DNS TXT records traipsing from DNS server to DNS server does not compare to a single lookup of a binary record. > > By limiting the mechanism to a single DNS lookup to a single DNS server, > > the exposure is much less. > > Ok, it is a little less. The risk is also low to start with. (Birthday > attacks aren't common, AFAIK; I've never logged one.) It's even lower > to nonexistent given recent/patched/secure DNS software and systems > (e.g. a split-split configuration). This is entering a new territory where DNS is used to authorize transactions with a cost incentive to defeat these protections. Yes, one could use carefully configured DNS servers to minimize this risk. This should not overlook the fact this risk was not necessary however. > > For what it is worth, SPF "requires" more than a single record be read > > perhaps from many different DNS servers. This opens a sizable can of > > worms. > > Clearly, I need to better explain my scheme, as it still seems unclear > to you that what SPF "requires" isn't relevant to my proposal! > Please, can you give up using this as an opportunity to bash SPF? It's > OT. (Note the changed Subject:). Using SPF records is not relevant to what is required of SPF? If SPF was limited to CIDR notation and the MX record, then the value of SPF would increase significantly as a white-listing tool. Much of the label construction macros and exists syntax reduce SPF's value and will likely serve to obfuscate a ploy that hides zombies. > > Example: Mailbox.tld has SPF records that define the entire address > > space for three of their providers where they outsource some of their > > mail, and their own. I contend reputation should be based upon what you > > have control over. That would mean it would not be to your advantage to > > include the machines of these other providers in a reputation > > assessment. > > Ah, I did say ip4 (and therefore CIDR ranges) might be OK. > (I did suggest subsequently in mail to John Leslie that perhaps just > +ip4:a.b.c.d/32 might be OK, note the /32!) > Perhaps even that isn't a good idea, as > > mailbox.dom spf ip4:[isp1's smtp]/32,ip4:[isp2's smtp]/32,ip4:[isp3's smtp] -all > > enables me to inappropriately stake my domain's reputation on the > ability of ISPs 1-3 to keep their smtp servers from being used to spam. > HOWEVER: It's already the case that such SPF records are > inappropriate. If I don't have high confidence in the ISPs, then the > appropriate record would be: > > mailbox.dom spf ?ip4:[isp1's smtp]/32, ?ip4:[isp2's smtp]/32, ?ip4:[isp3's smtp] -all > and this record would be equivalent to the null set in my scheme: my proposal ignores ~anything and ?anything. > Similarly, anyone creating a record like > > > mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self. What you seem to miss is that SPF does not differentiate between authorization and administration. There is no way to know the relationship of a record in another domain. The cost of doing business in this area is based in no small part on getting this right. I see no reason to blur the distinction nor do I think the motive for using SPF records for this purpose is well founded. If the MTA is not willing to provide a significantly strong identifier, it does not make sense to start guessing what is meant by the SPF records. The fall back would be using the address. There can be no implied contract where a domain becomes accountable for the actions of others trusted to send their mail. A provider lax in their security should not be allowed to hide behind their customer's domains. Should the provider wish to force the customer to accept this risk, they can ask to have the customer setup a CSV-CSA record that enables their servers. You do not want this accountability to be implied as you suggest. > [mailbox.dom] will suffer the consequences of doing something so dumb, > if one of the 3 ISPs seriously fails keep their smtp servers from > being used to spam using mailbox.dom. The domain will get blacklisted > (in other words, its reputation will fall), and the spoofing will > stop. SPF requires the addresses of the entire mail channel. It is odd that you would call that dumb. > Of course, your other example: > > >ehlo.dom spf cidr for self > > may also lead to a poor reputation - someone in marketing might decide > to send a bunch of spam, get zombie-infected, etc., etc. So CSV-tied > reputations won't be perfect either; it isn't reasonable to expect them > to be. They just need to be reasonably secure. You have missed the point of the example. Attempting to use SPF records for the dual purpose of creating an address list for the entire mail channel versus an address list for just the MTA are not protected by way of the label. > > A compromised host in one of the ISPs or even perhaps some clever shell > > program issues EHLO with mailbox.dom rather than the intended ehlo.dom. > > Sorry, how is a clever shell program not in one of the ISPs going to get > away with this? (No BGP hack/bogon/break into mailbox.dom's server > scenarios, please!) I said IN one of the ISPs. You are leaving your reputation exposed by allowing the EHLO domain to reference an SPF record. A CSV-CSA record has but one purpose and is of a much more limited scope. > > > The rules that accept only closed SPF components still do not achieve a > > goal of assessing only the administrator accountable. > > The rules I am refining do achieve that goal. Arguably, they do so > better than CSV, because they'll work for most domains that haven't > bothered to set up a CSV record. Heck, using the SPF 'best guess' may > be appropriate where there's no SPF or CSV record - the A&R system will > reflect reality if this guess allows much spam through. I would hope it never comes to groping through various TXT script records looking for a clue. I understand what you are attempting, but there are risks getting this wrong. It is not worth the risk. > > > Just removing open elements will not achieve the desired goal as it does > > not provide the same set. > > That's not a logical argument. The ultimate desired goal is to address > the spam problem. It may or may not be material to achievement of that > goal to get "the same set". There are significant liabilities getting this wrong. > > SPF does not have the concept of administrative versus authorized. > > There is nothing in the syntax that would allow the differentiation. In > > addition, the EHLO name can express any label to select any record. > > a record for aol.com is still differentiable from one for > dhcp234.234.dialup.aol.com! But either label may appear within the EHLO response. You want a label that can only be used for the single purpose of indicating the administration of the MTA. From this information, it is a small matter to establish the mailbox-domain/mail-channel association. The mailbox-domain is too weak of an identifier for assessing reputations however. > You hadn't provided an example. Now you have. Though I don't think > it disproves this, as I argued above. The example has enabled us to > better discuss specifics. Yes. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 07:31:54 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 HAA02471 for ; Thu, 23 Sep 2004 07:31:54 -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 i8NB0GjE059304; Thu, 23 Sep 2004 04: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 i8NB0G2h059303; Thu, 23 Sep 2004 04:00:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NB0EXs059293 for ; Thu, 23 Sep 2004 04:00:15 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i8NB072x024416; Thu, 23 Sep 2004 13:00:07 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i8NAadxs005318; Thu, 23 Sep 2004 12:36:39 +0200 From: Hadmut Danisch Date: Thu, 23 Sep 2004 12:36:39 +0200 To: Gordon Fecyk Cc: "IETF MXCOMP (E-mail)" Subject: The Village Idiot's point of view (Re: The Crystal Ball Says...) Message-ID: <20040923103639.GA2612@danisch.de> References: <700EEF5641B7E247AC1C9B82C05D125D055421@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D055421@srv1.pan-am.ca> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Gordon On Wed, Sep 22, 2004 at 07:14:22PM -0500, Gordon Fecyk wrote: > [...a lot of awkward but true and correct things] Thanks for your comments, you're absolutely correct here. > 6) Oh yes, let's not forget that there will be a fellow who will say that He > Started It All and He Should Be Rich and He Will Sue Microsoft And SPFi for > Stealing His Ideas and that The IETF Is Corrupt.[2] > ... > [2] As much as I respect you Hadmut, for your gall and knowledge and sheer > guts, blasting the IETF and raving like The Village Idiot throughout this > process earned you that paragraph. *I'M* supposed to be The Village > Idiot! Thanks for at least mentioning. Unfortunately, this point is correct as well. Except for the fact that I didn't say I should be rich. I agree with you that I look like an idiot, but I'd like to defend against that money argument. If I wanted to earn money I wouldn't have published it the way I did. This was supposed to be open and available for everyone as many of those IETF publications. You certainly don't know why I developed RMX. Let me elaborate the two reasons: The first and simple reason was, that at that time I was flooded with thousands of bounce messages because some spammer used my domain danisch.de to forge the sender address. Since I worked on organizational e-mail security since the mid-nineties, it was just the consequence to develeop RMX. The records that had formerly been held in a local database were moved to DNS, the same way /etc/hosts was made public years before. I wanted to get rid of bounce messages. But the more important reason was completely different. Germany is suffering from a dramatic rise of corruption since the early nineties. I was a scientist at the European Institute for System Security (E.I.S.S.) at the University of Karlsruhe and wrote a dissertation about communication security in 1997, finished in spring 1998. Unfortunately it became common at many germany universities that an examiner demands money or other worthy services for an examination or degree. This is completely unlawful and a crime under german law, but it became reality. When I left the university and took a job in industries, the examiner demanded that my employer lets me work for him for about a year - for free, on the employer's expense. When my employer and myself denied to pay that kind of protection money, the university denied the examination. I complained to the ministry and they were forced to examine. They then rejected my dissertation with giving wrong technical opinions. I have proven that the examiner's reports are technically wrong and that one examiner didn't even read the dissertation. I was successful and won a lawsuit. Unfortunately, the university told me that they will keep me in an endless loop: They'll give me one wrong opinion after another, and whenever I succeed with a lawsuit, they'll just give me the next one and let me start again. How to escape from that loop? The german constitutional court had stated in 1991, that you can't fail an examination (about your profession) if your examination performance is "usable". I have secured the network of a nuclear power plant based on my dissertation, but needed to have a more obvious proof that my dissertation is "usable". It describes how to design security mechanisms. When I was flooded with bounce messages and when my domain was heavily abused, I said that someone should do anything against. - Wait a moment: I'm a security engineer myself and I just wrote a dissertation about how to deal with security threads. If my dissertation works, then it should be able to give a simple solution for that problem. I dropped in the problem and it spitted out RMX. I thought "Hey, this might be something which could convince a court. Let's hope that the judges use e-mail and are themselves annoyed by spam, so they will understand the problem and the solution" That's why I wrote the first RMX draft. It was meant to be a proof of concept of my dissertation for the court and the university. This was not about money, this was just about the label "invented by Danisch" to have something as that proof of concept. And yes, I feel bitterness because of the way I was treated, the way RMX was plagiarized, and when I am blamed for plagiarizing SPF as RMX (or even beeing blamed for writing RMX at all, thus disturbing the development). Now turning this into "the idiot who wants to be rich" is quite nasty and evil. My intention has never been to get any rich with that (although I spent a lot of my private money even when I was unemployed and hoped to get at least some compensation of my own expenses by those who would save millions by getting rid of spam). But my intention has neither been to pay the development of my own expense that others earn money, make patents and marketing, save millions of dollar. And I admit that I am very disappointed, annoyed, and to some degree filled with bitterness. And it was a long process to get there, starting in spring 2003: - From the very beginning of ASRG I have been personally attacked just because of the idea to invent some kind of authentication/authorization into e-mail. - The ASRG group had been abused by its first chair to put himself in front of the camera, suppressing any progress in technical development, especially if it didn't meet his personal marketing plans. - I was chased away from ASRG, and then called back to help in development (to the ASRG-RMX-List) just to learn that I was supposed to do the work while others gave interviews to the press telling that they did all that stuff. - I was attacked from the so called "open source community" who blamed me for not doing proper marketing. It would be my own fault if that idea was relabled and reauthored. Sorry, but that doesn't meet my idea of open source protocol development. At least I learned that there are pickpockets both at the cathedral and the bazaar. - I then was attacked in the way that RMX was bullshit because it required a new DNS RR type and that for this reason SPF was superior. Lateron I saw that SPF was said to be even more superior because it now would get a new RR type. Ironically, neither RMX nor SPF do depend on having or not having a new RR type. That's just a minor implementation detail, but only few people had the engineering and security skills to know that. - I also was told that RMX is bad design because it verified the envelope sender (of course, it was designed to also stop those bounce messages). I was told that other methods are better because they do not verify the envelope sender (and thus do not stop those bounce messages). And when Microsoft came with their patent, it was proposed to verify the MAIL FROM. Hooray. Beyond the fact of authorship, invention, and naming, this all caused a delay of development of about a year. Without that SPF/MARID circus it would have become an RFC about a year ago. First make an RFC and then the marketing hype would have been the better approach. The time delay was what allowed Microsoft to get the patent foot in the door. From my (idiot's) point of view, it was exactly the way the ASRG and MARID groups were chaired and the way the marketing was done which caused the confusion and the delay which finally defeated it all. This could never work and it was obvious from the early days. If you leave me the choice between those two roles, between those who crashed that whole thing by incompetence, commercial attitude, and abusive propaganda, and that idiot who was raving and not agreeing with all that, well, I do not feel too uncomfortable with that idiot's role. I'm happy with the fact that I did not agree with that all. Maybe you know a little bit about european history. In the dark middle age, a long time before the USA existed, it was common at the king's courts to have a person known as the joker, fool, idiot. He was wearing funny clothes and not respected, everyone was laughing at hime. Actually, everyone had to dance around the golden calw, had to bow and to lie to please the king. This "Hoffnarr" (joker/fool/idiot) was the only one who told the truth and didn't have to bow or to lie. He was the only one who could sit or stand in presence of the king. While wrapped in funny clothes and playing the idiot, he actually was one of the most important and most sapient advisor of the king. And, btw, the word "idiot" comes from ancient greek and just means "a private person". I'd like to emphasize that in contrast to most of those who defeated MARID, I was indeed here as a private person, speaking for myself and not bound to commerical interests. So in that ancient greek sense of the word "idiot", I do attach importance to the fact that I am suche a private person. This ist much more honest. I hope that those who delayed and caused that all will get happy with the amounts of spam in their mailbox. regards Hadmut (the village idiot) PS: After the university I was working for Xlink, first german internet provider, which became KPNQwest, which was hosting Strato, a major domain provider. We were hosting millions of domains, their web servers and mail relays. Unfortunatley, KPNQwest went bankrupt in 2002. If KPNQwest would have survived, I would have had the perfect experimental platform and could have invented RMX with some millions of domains just by a finger snip. SPF, CallerID and SenderID would never have existed if KPNQwest hadn't gone bankrupt. From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 10:57:34 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 KAA19953 for ; Thu, 23 Sep 2004 10:57:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NEDwrH076892; Thu, 23 Sep 2004 07:13: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 i8NEDwjE076891; Thu, 23 Sep 2004 07:13:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8NEDvvJ076883 for ; Thu, 23 Sep 2004 07:13:57 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 7688 invoked from network); 23 Sep 2004 14:15:05 -0000 Received: from unknown (HELO ?192.168.254.158?) (208.198.98.24) by ns1.hoster907.com with SMTP; 23 Sep 2004 14:15:05 -0000 Message-ID: <4152DA23.9070904@margaretolson.com> Date: Thu, 23 Sep 2004 10:13:55 -0400 From: Margaret Olson User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: A Note of Appreciation References: <4151D8AA.3010608@solidmatrix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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 wayne wrote: >I would also like the many participants here who dug up actual data >and facts, the basis of which all engineering is done. Yakov >Shafranovich and Margret Olson immediately jump to mind, but I know >I'm missing some people. I would like to thank Meng, Mark and Eric >for their work on the drafts. > > You are welcome! And I appreciated your contribution as well - you are always focused on the problem at hand rather than the many peripheral issues. Margaret. From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 11:30: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 LAA23015 for ; Thu, 23 Sep 2004 11:30:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NEoxtU080851; Thu, 23 Sep 2004 07:50: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 i8NEox3e080850; Thu, 23 Sep 2004 07:50:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NEouCZ080842 for ; Thu, 23 Sep 2004 07:50:58 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8NEowq30259 for ; Thu, 23 Sep 2004 07:50:58 -0700 From: Dave Crocker To: MXCOMP X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Reply-To: Dave Crocker Date: Thu, 23 Sep 2004 07:50:43 -0700 Message-ID: <200492375043.155918@bbprime> In-Reply-To: <1095931635.5443.66.camel@localhost.localdomain> Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2728-9" Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > CSV is a solution based on two methods: CSA vs. DNA. > CSV is a suite of specifications that also includes DNA. The assertion that there is a "versus" between CSA and DNA is quite simply wrong. Anyone not clear about the roles and functions of components in the the CSA specification is strongly encouraged to asked detailed questions about them. That way, we will know what needs to be changed in the specifications, to improve their clarity. > > The EHLO/MAIL FROM validation is > > useless if RCPT TO is invalid. > > CSV allows the construction of name based relationships to relate > mailbox domains with the mail channel, as example, without requiring > subsequent lookups. Invalid Rcpt-to? I suspect that was meant to refer to RFC2821.mailfrom. In any event, the RFC2821.helo/ehlo parameter is is per-session and is used to validate the OPERATOR OF THE MTA. The other SMTP parameters are per-message. MailFrom validation mechanisms pertain to the SENDER OF THE MESSAGE. These are entirely different entities, and validating each of them has entirely different benefits. d/ -- Dave Crocker Brandenburg InternetWorking From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 12:27: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 MAA27705 for ; Thu, 23 Sep 2004 12:27: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 i8NFs52j088411; Thu, 23 Sep 2004 08:54: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 i8NFs5Ro088410; Thu, 23 Sep 2004 08:54:05 -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 i8NFrsD3088380 for ; Thu, 23 Sep 2004 08:53:56 -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 9925B16CC4 for ; Thu, 23 Sep 2004 12:03:17 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) In-Reply-To: Your message of "Wed, 22 Sep 2004 20:44:21 PDT." <1095911060.13180.168.camel@ddev.mail-abuse.org> Date: Thu, 23 Sep 2004 12:03:17 -0400 Message-Id: <20040923160317.9925B16CC4@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > A technical review was not something SPF/Sender-ID advocates > desired. In professional fora, it is entirely inappropriate to make assertions about other people's desires, capabilities, and the like. > SMTP is a well crafted battle-scarred solution with a few odd bits > broken. It does not warrant calling an infrastructure with a 30-year history 'broken'. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 13:13:44 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 NAA02093 for ; Thu, 23 Sep 2004 13:13:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NGixio092546; Thu, 23 Sep 2004 09:44: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 i8NGixjI092545; Thu, 23 Sep 2004 09:44:59 -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 i8NGix7j092537 for ; Thu, 23 Sep 2004 09:44:59 -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 A8BBC414C8; Thu, 23 Sep 2004 09:45:00 -0700 (PDT) Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) From: Douglas Otis To: Dave Crocker Cc: MXCOMP In-Reply-To: <200492375043.155918@bbprime> References: <200492375043.155918@bbprime> Content-Type: text/plain Message-Id: <1095957900.13956.26.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 23 Sep 2004 09:45:00 -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-09-23 at 07:50, Dave Crocker wrote: > > > CSV is a solution based on two methods: CSA vs. DNA. > > CSV is a suite of specifications that also includes DNA. > > The assertion that there is a "versus" between CSA and DNA is quite > simply wrong. > > Anyone not clear about the roles and functions of components in the the > CSA specification is strongly encouraged to asked detailed questions > about them. That way, we will know what needs to be changed in the > specifications, to improve their clarity. > > > > The EHLO/MAIL FROM validation is > > > useless if RCPT TO is invalid. > > > > CSV allows the construction of name based relationships to relate > > mailbox domains with the mail channel, as example, without requiring > > subsequent lookups. > > Invalid Rcpt-to? I suspect that was meant to refer to RFC2821.mailfrom. Hector was describing a decision tree where, of course, there would be no point checking beyond the obvious. The message will be rejected due to the bad recipient. > In any event, the RFC2821.helo/ehlo parameter is is per-session and is > used to validate the OPERATOR OF THE MTA. The other SMTP parameters are > per-message. MailFrom validation mechanisms pertain to the SENDER OF > THE MESSAGE. Sorry, this is my fault for not being explicit with these references. CSV only validates the operator of the MTA. With this operator name established, it allows a safe construction of a name based relationship of the mailbox-domain association with a mail channel. This can be something as simple as a name list. >From the standpoint of a reputation service, this information is of little use, but for those wishing to improve operations of a mail filter, as I think Hector was describing, such information is helpful. This type of enhancement is what SPF et al aspires to achieve. I was simply attempting to point out some of the additional advantages CSV offered to help achieve their goal safely. There should be a symbolic relationship achieving these two goals. CSV does not do MailFrom, From, or PRA validation. CSV simply makes MailFrom, From or PRA validation safer. > These are entirely different entities, and validating each of them has > entirely different benefits. I can not agree more. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 14:08: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 OAA05978 for ; Thu, 23 Sep 2004 14:08: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 i8NHb8gQ097254; Thu, 23 Sep 2004 10:37: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 i8NHb8Zc097253; Thu, 23 Sep 2004 10:37:08 -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 i8NHb8I2097246 for ; Thu, 23 Sep 2004 10:37:08 -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 A744B414C7; Thu, 23 Sep 2004 10:37:11 -0700 (PDT) Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040923160317.9925B16CC4@mail.nitros9.org> References: <20040923160317.9925B16CC4@mail.nitros9.org> Content-Type: text/plain Message-Id: <1095961031.13956.51.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 23 Sep 2004 10:37:11 -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-09-23 at 09:03, Alan DeKok wrote: > Douglas Otis wrote: > > A technical review was not something SPF/Sender-ID advocates > > desired. > > In professional fora, it is entirely inappropriate to make > assertions about other people's desires, capabilities, and the like. You are right. You were willing to engage in these discussions and I should not have made such a generalization. Sorry, my frustration was showing in this statement. > > SMTP is a well crafted battle-scarred solution with a few odd bits > > broken. > > It does not warrant calling an infrastructure with a 30-year history > 'broken'. I don't think this sentence was describing SMTP as broken in a broad sense, meaning it does not work. There are aspects within SMTP that are broken. It is safe to describe excusing an authentication failure of the EHLO name as broken. I view this piece of information is analogous to the post-mark on a letter, as it tells you where the message was sorted for delivery. Currently this information is often bogus owing to RFC2821 permissions. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 18:28:11 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 SAA00209 for ; Thu, 23 Sep 2004 18:28:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NLx7N3018842; Thu, 23 Sep 2004 14:59: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 i8NLx7bA018841; Thu, 23 Sep 2004 14:59:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (news.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8NLx6NO018832 for ; Thu, 23 Sep 2004 14:59:06 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Thu, 23 Sep 2004 18:03:55 -0400 Received: from ([65.10.117.66]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 2147433531; Thu, 23 Sep 2004 18:03:54 -0400 Message-ID: <018f01c4a1b8$01947f20$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "MXCOMP" References: <200492375043.155918@bbprime> Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) Date: Thu, 23 Sep 2004 17:53:46 -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 ----- Original Message ----- From: "Dave Crocker" To: "MXCOMP" Sent: Thursday, September 23, 2004 10:50 AM Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) > > > CSV is a solution based on two methods: CSA vs. DNA. > > CSV is a suite of specifications that also includes DNA. > > The assertion that there is a "versus" between CSA and DNA is quite > simply wrong. I assert the lookup method needs to be refined. Let me clarify. As it relates to CSV, there are two distinctly different concepts in the total paradigm of trust. Overhead, wasted DNAs for example when in fact the exposed client domain name was illegal. You only need to do a accreditation lookup if CSA result is positive (passes). However, your lookup method requires a DNA lookup first. > Anyone not clear about the roles and functions of components in the the > CSA specification is strongly encouraged to asked detailed questions > about them. That way, we will know what needs to be changed in the > specifications, to improve their clarity. The point is that the specification is well understood. You are trying to implement a total product, but the product parts doesn't fit well in practical opertions. The "parts" of the product have conflicts as it fits into the total model. If it did not, it would of been adopted long ago. > > > The EHLO/MAIL FROM validation is > > > useless if RCPT TO is invalid. > > > > CSV allows the construction of name based relationships to relate > > mailbox domains with the mail channel, as example, without requiring > > subsequent lookups. > > Invalid Rcpt-to? I suspect that was meant to refer to RFC2821.mailfrom. No Dave, I 100% meant the forwarding address RCPT-TO. If it is invalid, everything else doesn't matter. It is wasted overhead to perform expensive DNS based validation. This is 100% proven to the the case in the spam world with an average of 35% reduction in EHLO/MAILFROM validation requirements. > In any event, the RFC2821.helo/ehlo parameter is is per-session and is > used to validate the OPERATOR OF THE MTA. The other SMTP parameters are > per-message. MailFrom validation mechanisms pertain to the SENDER OF > THE MESSAGE. > These are entirely different entities, and validating each of them has > entirely different benefits. The entities 2821.EHLO/HELO, 2821.MAILFROM, including 2821.RCPTTO are SMTP transport parameters and are all involved in the total equation validation/trust paradigm at the transport level. Until you recognize this, your proposals impose wasted overhead in systems. Your proposal (as well as others) all are designed on the presumption that the 2821.RCPTO forwarding address is valid and that the payload will be acceptable. The presumption is weak in the today's real world of anti-spam operational requirements. See RFC 2821 Section 3.3: | 3.3 Mail Transactions | | ..... | | ............. Despite the apparent | scope of this requirement, there are circumstances in which the | acceptability of the reverse-path may not be determined until one or | more forward-paths (in RCPT commands) can be examined. In those | cases, the server MAY reasonably accept the reverse-path (with a 250 | reply) and then report problems after the forward-paths are received | and examined. Normally, failures produce 550 or 553 replies. This is probably the most powerful concepts in RFC 2821 for anti-spam operations. It opens the door for Mail From Validation and it offers performance enhancement and overhead reductionn. We are probably among the first, if the the only product in the market to have implemented this recommendation. There is no way on earth we will add anything else to break this excellent mode of anti-spam oepration. Learn from REAL Deployments in the market place. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 21:29: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 VAA10590 for ; Thu, 23 Sep 2004 21:29: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 i8O10VrV030801; Thu, 23 Sep 2004 18:00:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8O10V8L030800; Thu, 23 Sep 2004 18:00:31 -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 i8O10VAU030794 for ; Thu, 23 Sep 2004 18:00:31 -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 5C9EB414C5; Thu, 23 Sep 2004 18:00:37 -0700 (PDT) Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) From: Douglas Otis To: Hector Santos Cc: MXCOMP In-Reply-To: <018f01c4a1b8$01947f20$6401a8c0@hdev1> References: <200492375043.155918@bbprime> <018f01c4a1b8$01947f20$6401a8c0@hdev1> Content-Type: text/plain Message-Id: <1095987637.13956.254.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 23 Sep 2004 18:00:37 -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-09-23 at 14:53, Hector Santos wrote: > On Thu, 2004-09-23 at 10:50, "Dave Crocker" wrote: > > > > > CSV is a solution based on two methods: CSA vs. DNA. > > > > > > CSV is a suite of specifications that also includes DNA. > > > > The assertion that there is a "versus" between CSA and DNA is quite > > simply wrong. > > I assert the lookup method needs to be refined. > > Let me clarify. > > As it relates to CSV, there are two distinctly different concepts in the > total paradigm of trust. Overhead, wasted DNAs for example when in fact the > exposed client domain name was illegal. You only need to do a accreditation > lookup if CSA result is positive (passes). However, your lookup method > requires a DNA lookup first. To reduce time expended validating a session, simultaneous queries could be made for the CSV-CSA record and likely, (at least in the early stages of deployment) an rhsbl and rbl list server. With the exception of the CSV-CSA record, these queries would be to known servers. For large ISPs, a majority of these names will be already known and placed within a protected category as part of a business model. The remainder will not have established a local reputation and will require a check against the name or address for ongoing abuse. The use of a name helps track histories of the entity better than just an address and allows them a freedom to change addresses with less concern about having the IP address previously blacklisted, as the rhsbl should supersede the rbl. Use of DNA will likely come somewhat later as the adoption rate increases. The use of a reputation service is not needed for there to be a value in validating the EHLO domain. If this validated name is made visible to the user, then just this alone helps thwart spoofing and phishing. So without any reputation service, there remains features that you should find useful. 1) The ability to safely relate the mailbox-domain with the mail-channel. (No reputation service needed.) 2) The ability to discourage spoofing and phishing attacks. (No reputation service needed.) Should there be a crime, this identity indicates which logs need to be discovered. And of course, the use of CSV provides an identity strong enough to permit a name based reputation service that can both open or close the door. > > Anyone not clear about the roles and functions of components in the the > > CSA specification is strongly encouraged to asked detailed questions > > about them. That way, we will know what needs to be changed in the > > specifications, to improve their clarity. > > The point is that the specification is well understood. You are trying to > implement a total product, but the product parts doesn't fit well in > practical operations. The "parts" of the product have conflicts as it fits > into the total model. If it did not, it would of been adopted long ago. I wonder how many things would fall into that category. > > > > The EHLO/MAIL FROM validation is useless if RCPT TO is invalid. > > > > > > CSV allows the construction of name based relationships to relate > > > mailbox domains with the mail channel, as example, without requiring > > > subsequent lookups. > > > > Invalid Rcpt-to? I suspect that was meant to refer to RFC2821.mailfrom. > > No Dave, I 100% meant the forwarding address RCPT-TO. If it is invalid, > everything else doesn't matter. It is wasted overhead to perform expensive > DNS based validation. This is 100% proven to the the case in the spam world > with an average of 35% reduction in EHLO/MAILFROM validation requirements. I understand what you are saying, but I don't see how this relates to a comparison of differing techniques. > > In any event, the RFC2821.helo/ehlo parameter is is per-session and is > > used to validate the OPERATOR OF THE MTA. The other SMTP parameters are > > per-message. MailFrom validation mechanisms pertain to the SENDER OF > > THE MESSAGE. > > > These are entirely different entities, and validating each of them has > > entirely different benefits. > > The entities 2821.EHLO/HELO, 2821.MAILFROM, including 2821.RCPTTO are SMTP > transport parameters and are all involved in the total equation > validation/trust paradigm at the transport level. Until you recognize > this, your proposals impose wasted overhead in systems. Most will attempt to compress the time it takes to handle a message to permit resources to be freed to handle the next message. Comparing CSV (even together with a name list) against SPF et al lookups offers a dramatic improvement with respect to overhead. Should the EHLO fail validation and cause a rejection, then little has been wasted in terms of either time or bandwidth. That is not true with SPF et al as the number of record lookups may be very large, whereas the same information is now available within a single name list. > Your proposal (as well as others) all are designed on the presumption that > the 2821.RCPTO forwarding address is valid and that the payload will be > acceptable. The presumption is weak in the today's real world of anti-spam > operational requirements. If this is true, then holding off these checks still costs less than the alternatives. Wide spread adoption of CSV will not cause additional lookups over today's efforts to validate EHLO. > See RFC 2821 Section 3.3: > > | 3.3 Mail Transactions > | ............. Despite the apparent > | scope of this requirement, there are circumstances in which the > | acceptability of the reverse-path may not be determined until one or > | more forward-paths (in RCPT commands) can be examined. In those > | cases, the server MAY reasonably accept the reverse-path (with a 250 > | reply) and then report problems after the forward-paths are received > | and examined. Normally, failures produce 550 or 553 replies. > > This is probably the most powerful concepts in RFC 2821 for anti-spam > operations. It opens the door for Mail From Validation and it offers > performance enhancement and overhead reduction. We are probably among the > first, if the only product in the market to have implemented this > recommendation. > > There is no way on earth we will add anything else to break this excellent > mode of anti-spam operation. > > Learn from REAL Deployments in the market place. How these checks are staged seem immaterial to the value of these checks. If various extended services depend upon name validation prior to running other processes, then publishing these records becomes just an extremely minor cost of doing business. The cost of these records also requires far less maintenance as well, as they are name based and not address based. (The address generation is automated.) : ) -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 23 22:09: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 WAA13079 for ; Thu, 23 Sep 2004 22:09: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 i8O1kEWl033973; Thu, 23 Sep 2004 18:46: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 i8O1kECt033972; Thu, 23 Sep 2004 18:46:14 -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 i8O1kDmw033965 for ; Thu, 23 Sep 2004 18:46:13 -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 1CAfA3-0000Ed-IU for ietf-mxcomp@imc.org; Thu, 23 Sep 2004 20:46:16 -0500 To: "IETF MARID WG" References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 23 Sep 2004 20:46:11 -0500 In-Reply-To: <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> (Andrew Newton's message of "Tue, 14 Sep 2004 12:06:52 -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: by the numbers 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.6 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: > Attached you will find a survey that Marcos Sanz and I did of com, > net, and de. I've had a couple of requests for more raw data about what TXT records are out there and SPF records in particular. So, I've finished up a couple of surveys and lightly munged the data to keep spammers from collecting domain names. You can find the raw data at: http://www.midwestcs.com/spf/surveys/ The "spammerlist" files are the domains found in a spammers list of email addresses. There were about 1.3 million unqiue domain names used by the spammer. The list was old when I got it about a year and a half ago and the spammer never bothered to clean up obviously bogus domain names, so the actual number of valid domain names is much less than 1.3 million, maybe as few as 500k. I have not bothered to clean up the list because I use it for testing SPF stuff. Even if the email addresses have bogus domains, I expect spammers to send email claiming to be from them so I need to make sure that my SPF system can deal with them. Files ending in "spf" are the unique SPF records found. Files ending in "txt" are summaries of the TXT records found. Let me know if you have questions. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 08:35: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 IAA06429 for ; Fri, 24 Sep 2004 08:35:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OC71lX085117; Fri, 24 Sep 2004 05:07: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 i8OC71eY085116; Fri, 24 Sep 2004 05:07:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OC70RQ085110 for ; Fri, 24 Sep 2004 05:07:00 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38232) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1CAoqm-0003hu-6Z (return-path ) for ietf-mxcomp@imc.org; Fri, 24 Sep 2004 13:06:56 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1CAoql-0006go-KX; Fri, 24 Sep 2004 13:06:55 +0100 Date: Fri, 24 Sep 2004 13:06:55 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Hector Santos cc: MXCOMP Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) In-Reply-To: <018f01c4a1b8$01947f20$6401a8c0@hdev1> Message-ID: References: <200492375043.155918@bbprime> <018f01c4a1b8$01947f20$6401a8c0@hdev1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 23 Sep 2004, Hector Santos wrote: > > We are probably among the first, if the the only product in the market > to have implemented this recommendation. Exim has always worked in this way, i.e. accept the MAIL FROM command unconditionally and perform all the checks after RCPT TO. The order in which the checks are performed is immaterial except from the efficiency point of view. Tony. -- f.a.n.finch http://dotat.at/ LOUGH FOYLE TO CARLINGFORD LOUGH: NORTHWEST 4 BACKING WEST OR SOUTHWEST 4 OR 5 LATER IN DAY. FAIR DURING DAY, RAIN TONIGHT. GOOD BECOMING MODERATE. SLIGHT OR MODERATE. From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 08:49:54 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 IAA07589 for ; Fri, 24 Sep 2004 08:49: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 i8OCQXlr086142; Fri, 24 Sep 2004 05:26:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8OCQXra086141; Fri, 24 Sep 2004 05:26:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8OCQXwJ086134 for ; Fri, 24 Sep 2004 05:26:33 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Fri, 24 Sep 2004 08:31:45 -0400 Received: from ([65.10.117.66]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 2199503312; Fri, 24 Sep 2004 08:31:44 -0400 Message-ID: <000d01c4a231$3c5e3280$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MARID WG" References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> Subject: Re: by the numbers Date: Fri, 24 Sep 2004 08:21:12 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Based on these numbers, the item of interest was the growth rate: Between 4/20 and 9/12, you had a growth rate of 68 new SPF spammers per day. This is just with two states, so it would be interesting to see the acceleration with more collection points. I suggest a weekly or monthly collection to see this pattern. Nevertheless, overall, its not good to see this, especially, if that rate does not go down over time. However, fortunately, in my analysis, most systems experience a segment of the spammer base. In other words, I'm only the basically the same systems or same pattern of systems using spoofs. What I find extremely interesting is that these systems don't seem to be learning from a programmatic standpoint, only administratively by adding the domains. In other words, my rejects are pretty constant with the same information, over and over and over again. They might go away for a few days or week, but soon enough they are back with the same type of information that gets them rejected. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "wayne" To: "IETF MARID WG" Sent: Thursday, September 23, 2004 9:46 PM Subject: Re: by the numbers > > > Attached you will find a survey that Marcos Sanz and I did of com, > > net, and de. > > > I've had a couple of requests for more raw data about what TXT records > are out there and SPF records in particular. So, I've finished up a > couple of surveys and lightly munged the data to keep spammers from > collecting domain names. You can find the raw data at: > > http://www.midwestcs.com/spf/surveys/ > > The "spammerlist" files are the domains found in a spammers list of > email addresses. There were about 1.3 million unqiue domain names > used by the spammer. The list was old when I got it about a year and > a half ago and the spammer never bothered to clean up obviously bogus > domain names, so the actual number of valid domain names is much less > than 1.3 million, maybe as few as 500k. I have not bothered to clean > up the list because I use it for testing SPF stuff. Even if the email > addresses have bogus domains, I expect spammers to send email claiming > to be from them so I need to make sure that my SPF system can deal > with them. > > Files ending in "spf" are the unique SPF records found. Files ending > in "txt" are summaries of the TXT records found. > > > Let me know if you have questions. > > > -wayne > > From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 09:36: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 JAA10585 for ; Fri, 24 Sep 2004 09:36: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 i8OD5dO8088758; Fri, 24 Sep 2004 06:05: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 i8OD5d02088757; Fri, 24 Sep 2004 06:05:39 -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 i8OD5cMI088751 for ; Fri, 24 Sep 2004 06:05:39 -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 1CAplX-0004iu-2q for ietf-mxcomp@imc.org; Fri, 24 Sep 2004 08:05:40 -0500 To: "IETF MARID WG" References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> <000d01c4a231$3c5e3280$6401a8c0@hdev1> From: wayne Reply-To: "IETF MARID WG" Date: Fri, 24 Sep 2004 08:05:34 -0500 In-Reply-To: <000d01c4a231$3c5e3280$6401a8c0@hdev1> (Hector Santos's message of "Fri, 24 Sep 2004 08:21:12 -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: by the numbers 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.6 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: [top posting fixed] In <000d01c4a231$3c5e3280$6401a8c0@hdev1> "Hector Santos" writes: > "wayne" wrote: > >> The "spammerlist" files are the domains found in a spammers list of >> email addresses. There were about 1.3 million unqiue domain names >> used by the spammer. [...] > > Based on these numbers, the item of interest was the growth rate: > > Between 4/20 and 9/12, you had a growth rate of 68 new SPF spammers per day. The "spammerlist" is not a list of spammers, but a list of email addresses used by at least one spammer. Or, are saying that "SPF spammers" are people who publish open SPF records or something? -wayne From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 12:16: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 MAA21309 for ; Fri, 24 Sep 2004 12:16: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 i8OFaqA2098777; Fri, 24 Sep 2004 08:36: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 i8OFaq57098776; Fri, 24 Sep 2004 08:36:52 -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 i8OFaq98098761 for ; Fri, 24 Sep 2004 08:36:52 -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; Fri, 24 Sep 2004 11:36:52 -0400 id 001B7A93.41543F14.00001661 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <200409121750.i8CHocL28553@zeder.TechFak.Uni-Bielefeld.DE> <178EF9A8-0668-11D9-BCF4-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8C97EF0E-0E3F-11D9-BE1D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: by the numbers Date: Fri, 24 Sep 2004 11:36:48 -0400 To: "IETF MARID WG" 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 Sep 23, 2004, at 9:46 PM, wayne wrote: > Let me know if you have questions. No question, just a comment: absolutely great stuff! -andy From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 12:19:24 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 MAA21528 for ; Fri, 24 Sep 2004 12:19: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 i8OFuqOK099873; Fri, 24 Sep 2004 08:56: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 i8OFupHb099872; Fri, 24 Sep 2004 08:56:51 -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 i8OFupxO099866 for ; Fri, 24 Sep 2004 08:56:51 -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; Fri, 24 Sep 2004 11:56:53 -0400 id 001B7A97.415443C6.00001839 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58CD7B98-0E42-11D9-BE1D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: Andrew Newton Subject: Re: Disappointed Date: Fri, 24 Sep 2004 11:56:50 -0400 To: "Hallam-Baker, Phillip" 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 Sep 22, 2004, at 9:36 PM, Hallam-Baker, Phillip wrote: > Those arguing that the ITU take over responsibility for Internet > standards will probably cite this result as evidence. FUD! -andy From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 12:27:54 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 MAA22310 for ; Fri, 24 Sep 2004 12:27: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 i8OFtBcx099781; Fri, 24 Sep 2004 08:55: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 i8OFtBaH099780; Fri, 24 Sep 2004 08:55: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 i8OFtBkd099774 for ; Fri, 24 Sep 2004 08:55:11 -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; Fri, 24 Sep 2004 11:55:14 -0400 id 001B7A97.41544362.0000181F In-Reply-To: <252481A792E5C84C8D108F791D8F5E4E037C0C59@ex2k.bankofamerica.com> References: <252481A792E5C84C8D108F791D8F5E4E037C0C59@ex2k.bankofamerica.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1DE3E4E7-0E42-11D9-BE1D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: MARID to close Date: Fri, 24 Sep 2004 11:55:11 -0400 To: "Markley, Mike" 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 Sep 22, 2004, at 5:21 PM, Markley, Mike wrote: > Should this be construed to mean that there's still the hope and > intention to someday producing a standards-track RFC for IP-based > sender > authentication? Absolutely. -andy From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 12:50:26 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 MAA25211 for ; Fri, 24 Sep 2004 12:50:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OGQudP002247; Fri, 24 Sep 2004 09:26: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 i8OGQuS9002246; Fri, 24 Sep 2004 09:26:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OGQtvr002240 for ; Fri, 24 Sep 2004 09:26:55 -0700 (PDT) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id B3C08BC1F7; Fri, 24 Sep 2004 12:26:57 -0400 (EDT) Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) In-Reply-To: <018f01c4a1b8$01947f20$6401a8c0@hdev1> "from Hector Santos at Sep 23, 2004 05:53:46 pm" To: ietf-mxcomp@imc.org Date: Fri, 24 Sep 2004 12:26:57 -0400 (EDT) Reply-To: ietf-mxcomp@imc.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20040924162657.B3C08BC1F7@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hector Santos: > See RFC 2821 Section 3.3: > > | 3.3 Mail Transactions > | > | ..... > | > | ............. Despite the apparent > | scope of this requirement, there are circumstances in which the > | acceptability of the reverse-path may not be determined until one or > | more forward-paths (in RCPT commands) can be examined. In those > | cases, the server MAY reasonably accept the reverse-path (with a 250 > | reply) and then report problems after the forward-paths are received > | and examined. Normally, failures produce 550 or 553 replies. > > This is probably the most powerful concepts in RFC 2821 for anti-spam > operations. It opens the door for Mail From Validation and it offers > performance enhancement and overhead reductionn. We are probably among the > first, if the the only product in the market to have implemented this > recommendation. The Postfix MTA does this by default since 19990510 (May 10, 1999), according to the day-to-day log. Wietse From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 13:10: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 NAA27291 for ; Fri, 24 Sep 2004 13:10:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OGiqQ1003911; Fri, 24 Sep 2004 09:44: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 i8OGiqXK003910; Fri, 24 Sep 2004 09:44:52 -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 i8OGiqcG003900 for ; Fri, 24 Sep 2004 09:44:52 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i8OGiq0u010516; Fri, 24 Sep 2004 09:44:52 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Sep 2004 09:44:52 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Andrew Newton'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: RE: Disappointed Date: Fri, 24 Sep 2004 09:44:48 -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: Andrew Newton [mailto:andy@hxr.us] > On Sep 22, 2004, at 9:36 PM, Hallam-Baker, Phillip wrote: > > > Those arguing that the ITU take over responsibility for Internet > > standards will probably cite this result as evidence. > > FUD! But possibly effective FUD. As I said to Harald after the plenary where this was mentioned, what exactly do the ITU imagine that they would do if they managed to take over the IETF? Who do they think would listen? From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 14:07: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 OAA02802 for ; Fri, 24 Sep 2004 14:07:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OHfC0W009200; Fri, 24 Sep 2004 10:41: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 i8OHfCaL009199; Fri, 24 Sep 2004 10:41:12 -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 i8OHfBBh009193 for ; Fri, 24 Sep 2004 10:41:11 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Fri, 24 Sep 2004 13:46:29 -0400 Received: from ([65.10.117.66]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 2218386984; Fri, 24 Sep 2004 13:46:27 -0400 Message-ID: <000f01c4a25d$33776f20$6401a8c0@hdev1> From: "Hector Santos" To: References: <20040924162657.B3C08BC1F7@spike.porcupine.org> Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) Date: Fri, 24 Sep 2004 13:37:42 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Great. Thanks for the feedback. What sort of 2821.MailFrom validation was PostFIX doing back in 99? So we have: Exim SMTP server PostFix SMTP server WIldcat! SMTP server all doing MAIL FROM delayed validation. How about SendMail? Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "Wietse Venema" To: Sent: Friday, September 24, 2004 12:26 PM Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) > > Hector Santos: > > See RFC 2821 Section 3.3: > > > > | 3.3 Mail Transactions > > | > > | ..... > > | > > | ............. Despite the apparent > > | scope of this requirement, there are circumstances in which the > > | acceptability of the reverse-path may not be determined until one or > > | more forward-paths (in RCPT commands) can be examined. In those > > | cases, the server MAY reasonably accept the reverse-path (with a 250 > > | reply) and then report problems after the forward-paths are received > > | and examined. Normally, failures produce 550 or 553 replies. > > > > This is probably the most powerful concepts in RFC 2821 for anti-spam > > operations. It opens the door for Mail From Validation and it offers > > performance enhancement and overhead reductionn. We are probably among the > > first, if the the only product in the market to have implemented this > > recommendation. > > The Postfix MTA does this by default since 19990510 (May 10, 1999), > according to the day-to-day log. > > Wietse > > From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 14:36:04 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 OAA04515 for ; Fri, 24 Sep 2004 14:36: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 i8OIDQll011558; Fri, 24 Sep 2004 11:13:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8OIDQFf011557; Fri, 24 Sep 2004 11:13:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OIDPt6011548 for ; Fri, 24 Sep 2004 11:13:26 -0700 (PDT) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id F2C6DBC1E5; Fri, 24 Sep 2004 14:13:26 -0400 (EDT) Subject: Re: Disappointed In-Reply-To: "from Hallam-Baker, Phillip at Sep 24, 2004 09:44:48 am" To: ietf-mxcomp@imc.org Date: Fri, 24 Sep 2004 14:13:26 -0400 (EDT) Reply-To: ietf-mxcomp@imc.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20040924181326.F2C6DBC1E5@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip: > > > From: Andrew Newton [mailto:andy@hxr.us] > > On Sep 22, 2004, at 9:36 PM, Hallam-Baker, Phillip wrote: > > > > > Those arguing that the ITU take over responsibility for Internet > > > standards will probably cite this result as evidence. > > > > FUD! > > But possibly effective FUD. As I said to Harald after the plenary where > this was mentioned, what exactly do the ITU imagine that they would > do if they managed to take over the IETF? Who do they think would listen? Perhaps the non-trivial portion of Internet providers that are affiliated with or part of a telecom provider, other technology producing organizations that are represented in ITU, and the governments of the 189 ITU member states. Wietse From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 14:39: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 OAA04643 for ; Fri, 24 Sep 2004 14:38:58 -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 i8OIH2rr011739; Fri, 24 Sep 2004 11:17: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 i8OIH2Dd011738; Fri, 24 Sep 2004 11:17:02 -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 i8OIH1aV011731 for ; Fri, 24 Sep 2004 11:17:01 -0700 (PDT) (envelope-from sb0-06851f9f07-johnl@iecc.com) Received: (qmail 7361 invoked by uid 100); 24 Sep 2004 18:17:04 -0000 Date: 24 Sep 2004 18:17:04 -0000 Message-ID: <20040924181704.7360.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: ITU, was Disappointed In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: pbaker@verisign.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >But possibly effective FUD. As I said to Harald after the plenary >where this was mentioned, what exactly do the ITU imagine that they >would do if they managed to take over the IETF? Who do they think >would listen? Based on conversations with people at and since the ITU WSIS spam meeting in Geneva, the ITU has no interest whatsoever in taking over the IETF. They got burned on X.400 and they thoroughly understand both how hard it is to make data network standards and why it is not in their interest to do so for the TCP/IP world. They would like to stay in closer touch so that they can recommend to their government members that they implement relevant IETF standards and the like. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 14:44:57 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 OAA04888 for ; Fri, 24 Sep 2004 14:44: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 i8OIIhia011867; Fri, 24 Sep 2004 11:18: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 i8OIIhNa011866; Fri, 24 Sep 2004 11:18:43 -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 i8OIIhBY011858 for ; Fri, 24 Sep 2004 11:18:43 -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; Fri, 24 Sep 2004 14:18:44 -0400 id 001B7256.41546504.000024B1 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <01D64F09-0B40-11D9-BE1D-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <29EE87BE-0E56-11D9-BE1D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: MARID Monday Date: Fri, 24 Sep 2004 14:18:41 -0400 To: "IETF MARID WG" 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 Sep 21, 2004, at 8:52 PM, wayne wrote: > If you could, I would greatly appreciate any info about these mailing > lists. Just a correction. I was mistaken. All but one rewrite MAIL FROM. I think I was thinking of something else. -andy From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 15:06: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 PAA06436 for ; Fri, 24 Sep 2004 15:06: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 i8OIeg6f013489; Fri, 24 Sep 2004 11:40:42 -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 i8OIeg1B013488; Fri, 24 Sep 2004 11:40:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from dellboy.highspot.net (dellboy.highspot.net [82.152.13.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OIeefC013471 for ; Fri, 24 Sep 2004 11:40:41 -0700 (PDT) (envelope-from glmxcomp040831@highspot.net) Received: from [82.152.13.66] (jaffa.highspot.net [82.152.13.66]) by dellboy.highspot.net (8.12.11/8.12.11) with ESMTP id i8OIekOk021816 for ; Fri, 24 Sep 2004 19:40:46 +0100 Message-ID: <41546A7B.2030303@highspot.net> Date: Fri, 24 Sep 2004 19:42:03 +0100 From: Graeme Leith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) References: <20040924162657.B3C08BC1F7@spike.porcupine.org> <000f01c4a25d$33776f20$6401a8c0@hdev1> In-Reply-To: <000f01c4a25d$33776f20$6401a8c0@hdev1> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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 Hector Santos wrote: > Great. Thanks for the feedback. > > What sort of 2821.MailFrom validation was PostFIX doing back in 99? > > So we have: > > Exim SMTP server > PostFix SMTP server > WIldcat! SMTP server > > all doing MAIL FROM delayed validation. How about SendMail? Sendmail does it if the delay_checks feature is enabled. I don't think it's enabled by default. From owner-ietf-mxcomp@mail.imc.org Fri Sep 24 15:43: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 PAA09278 for ; Fri, 24 Sep 2004 15:43:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OJHYDY016416; Fri, 24 Sep 2004 12:17:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8OJHYit016415; Fri, 24 Sep 2004 12:17:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8OJHXuK016408 for ; Fri, 24 Sep 2004 12:17:33 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i8OJHXTF021198 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 24 Sep 2004 12:17:34 -0700 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i8OJHXTF021198 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=rmaHpQlQhL0nQ6/4uTW/sUHnZqhz3bwNteCyrF/oZWWCGgUoDq99DU3NCg8J1L52B X+drr8RnaAQuyMHCUzlehE7Wm46n/dVy6jFixJK+vpwaOqXNyC80+FHBzseHf/ax4DG g7C4rrFrx/xBZyM3++WEqajLzJDbuJEwMvs+qQY= Date: Fri, 24 Sep 2004 12:17:33 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Hector Santos cc: ietf-mxcomp@imc.org Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions) In-Reply-To: <000f01c4a25d$33776f20$6401a8c0@hdev1> Message-ID: References: <20040924162657.B3C08BC1F7@spike.porcupine.org> <000f01c4a25d$33776f20$6401a8c0@hdev1> 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: According to internal records here, it was in sendmail 8.10, released 3/1/00. -Rand On Fri, 24 Sep 2004, Hector Santos wrote: > Great. Thanks for the feedback. > > What sort of 2821.MailFrom validation was PostFIX doing back in 99? > > So we have: > > Exim SMTP server > PostFix SMTP server > WIldcat! SMTP server > > all doing MAIL FROM delayed validation. How about SendMail? > > Sincerely, > > Hector Santos, CTO > Santronics Software, Inc. > http://www.santronics.com > 305-431-2846 Cell > 305-248-3204 Office > > > > ----- Original Message ----- > From: "Wietse Venema" > To: > Sent: Friday, September 24, 2004 12:26 PM > Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new > revisions) > > > > > > Hector Santos: > > > See RFC 2821 Section 3.3: > > > > > > | 3.3 Mail Transactions > > > | > > > | ..... > > > | > > > | ............. Despite the apparent > > > | scope of this requirement, there are circumstances in which the > > > | acceptability of the reverse-path may not be determined until one or > > > | more forward-paths (in RCPT commands) can be examined. In those > > > | cases, the server MAY reasonably accept the reverse-path (with a 250 > > > | reply) and then report problems after the forward-paths are received > > > | and examined. Normally, failures produce 550 or 553 replies. > > > > > > This is probably the most powerful concepts in RFC 2821 for anti-spam > > > operations. It opens the door for Mail From Validation and it offers > > > performance enhancement and overhead reductionn. We are probably among > the > > > first, if the the only product in the market to have implemented this > > > recommendation. > > > > The Postfix MTA does this by default since 19990510 (May 10, 1999), > > according to the day-to-day log. > > > > Wietse > > > > > > > From owner-ietf-mxcomp@mail.imc.org Sat Sep 25 00:10:23 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 AAA16515 for ; Sat, 25 Sep 2004 00:10:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8P3g1ls049731; Fri, 24 Sep 2004 20:42: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 i8P3g17B049730; Fri, 24 Sep 2004 20:42:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8P3g0Vh049715 for ; Fri, 24 Sep 2004 20:42:00 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: [On Rewriting SMTP and DNS] RE: MARID to close - Comments/Suggestions MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 24 Sep 2004 22:42:02 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D055428@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: MARID to close - Comments/Suggestions Thread-Index: AcShKMU6KkdU3ROQRwe7XEEauk/KvABgX2cg From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8P3g1Vh049725 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > 3) Optional: Rewrite SMTP 2821 > > unless the MARID group gets the IETF-SMTP involved, it will be > a tough climb to reach the common goals we are all looking for > success across the board. We need to recognize that the old > design philosophy in SMTP 2821, a "relaxed internet spirit > required for wide deployment with less > emphasis with security" no longer applies today. I'm a newcomer to the IETF and I've observed this snobbish attitude right from the first day I stepped into the the Lotte Hotel in Seoul[1]. That of the SMTP working group, I mean, and while Hector didn't mention them, the DNS working group too. "This fundamentaly changes the semantics of X," was a favorite line throughout this process. There are a few in this group who represent this thought who I will refer to as The Old Guard. Mitch Kapor, of Lotus 1-2-3 fame and co-founder of the Electronic Frontier Foundation, made opinions of The Old Guard clear to the author of The Hacker Crackdown (1992 Bantam Books) during an interview: "You go tell a hardware hacker that everyone should have a node on the Internet, and the first thing they'll tell you is: 'IP doesn't scale.' The answer is: Evolve the protocol! Get smart people together and figure out what to do. Do we add [identification]? Do we add protocol? Don't just say 'we can't do it.'" The Old Guard tells us We Can't Do It and then goes to extreme lengths to prove why. I say: B***S***. I'll bet Tim Berners-Lee thought that, and the result is the World Wide Web. We have The Old Guard saying that we can't do X in DNS, we can't do Y in SMTP. Even though it was done. We have Bob Atkinson telling me his company's software can't do X in DNS even though folks here proved him wrong. And it didn't even require rewriting DNS. Earlier proposals worked entirely within existing DNS and SMTP framework, even if they did change some semantics in SMTP and made some DNS old farts turn up their noses. They still worked within the system to the system's specifications. Yet they were rejected based on semantics. Outdated semantics, I might add, based on an Internet where it was assumed all communication was wanted and requested. To Mitch Kapor, "...this is the snobbery of the people on the Mayflower looking down their noses at the people who came over [to the New World] on the _second boat!_" By what right do you, The Old Guard, have to look down your noses at folks like me? Like Meng? Like Hadmut? Like Raymond? Criticism ("Where's the debugger?") is one thing, but you went beyond mere criticism to outright denial. As for the patent issues, I believe "Chairman Bill" and his pack of cartooneys can stand a lesson on where they came from. That goes for you guys, Harry, Bob, and the others whose names grace certain patent applications. You all came on The Second Boat looking down at us coming on the third, pretending that the Mayflower didn't exist. Or that the first boat infringed on your patents. Or something stupid like that. [1] During the second English keynote speech which I'll call the "Don't Try This At Home" speech, the speaker took an unnecessary stab at Microsoft Word as being a security risk for allowing active content in a document. I didn't hear any chuckles from the audience and I'm not surprised - not only was the presentation B-O-R-I-N-G, it was demeaning, disrespectful to the audience and disrespectful to "the folks on the second boat" who produced MS Word they way they did Because Their Customers Asked For It.[2] I took a moment to try to bring this to light to the speaker afterward. I made my first enemy in the IETF and it was only my first day on site. [2] Users keep demanding functionality with little or no regard to security. That's not Microsoft's fault. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Sat Sep 25 04:23: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 EAA11773 for ; Sat, 25 Sep 2004 04:23: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 i8P7eIcB015327; Sat, 25 Sep 2004 00:40: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 i8P7eIDh015326; Sat, 25 Sep 2004 00:40:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8P7eHKN015305 for ; Sat, 25 Sep 2004 00:40:18 -0700 (PDT) (envelope-from shedevil@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so3177061rnl for ; Sat, 25 Sep 2004 00:40:07 -0700 (PDT) Received: by 10.38.102.45 with SMTP id z45mr49562rnb; Sat, 25 Sep 2004 00:40:07 -0700 (PDT) Received: by 10.38.92.2 with HTTP; Sat, 25 Sep 2004 00:40:07 -0700 (PDT) Message-ID: Date: Sat, 25 Sep 2004 00:40:07 -0700 From: "Anne P. Mitchell, Esq. " Reply-To: amitchell@isipp.com To: ietf-mxcomp@imc.org Subject: Microsoft Statement regarding Sender I.D. Update and Plans (forwarded by request) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The following was sent to a large list of various interested parties, and is forwarded here by request: Subject: Sender ID Update & Plans Dear John, Over the past few months there have been several developments with the IETF and the status of the Sender ID Framework. The following mail is intended to provide clarify to the status and Microsoft's implementation plans. After discussion with the IETF MARID chairs, we jointly agreed to move forward with a proposal that provides implementers the choice of utilizing PRA or MAIL FROM for the Sender ID check mechanism. While the working group has recently shut down, we continue to work with the chairs and key stakeholders to move forward. Based on these recent discussions we have agreed to insure backward compatibility to SPF1 records. We believe this will help accelerate adoption for the early adapters and insure the majority of e-mail senders do not have to make any record changes. We anticipate these revised Sender ID specs will be published within the next week and posted at www.microsoft.com/senderid. While we would have preferred a single technical mechanism as the standard, we believe the specification to allow multiple scopes in the protocol is a reasonable approach, providing choice and flexibility. For Microsoft's implementation, we continue to move forward to utilize the PRA check because it examines header information in email, which we believe, provides a more reliable method to detect forged mail and phishing attempts. We also believe it will be easier for forwarders and other email intermediaries to adapt their practices and software to Sender ID. Later this fall Microsoft plans to publish both records for our customers, but will only be utilizing the PRA check for our customers. I would also like to clarify several misstatements pertaining to our license and patents. From the onset, Microsoft has confirmed that any potential patent rights that Microsoft may eventually be granted will be provided to all users, implementers and distributors of the Sender ID specification under Microsoft's royalty free license. Microsoft will not revoke its offer to extend this license to anyone now and in perpetuity. The information disclosed by Microsoft regarding its patent applications and its license terms meet and exceed the IETF requirements for such disclosure. Moving forward, Microsoft will continue to invest in research to combat spam and phishing. Innovation and investments in these technologies are paramount to insure the reliability and deliverability of e-mail, confidence in online commence and to protect the brand and reputations of businesses throughout the world. In summary, I want to assure you that Microsoft remains committed to Sender ID. We look forward to continuing our collaboration with [ ] to help move this important authentication protocol forward. If you have any questions or concerns, please don't hesitate to call. Craig Spiezle Microsoft Corporation Director, Safety Technology and Strategy Group From owner-ietf-mxcomp@mail.imc.org Sat Sep 25 15:51:54 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 PAA14146 for ; Sat, 25 Sep 2004 15:51: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 i8PJL1jI014563; Sat, 25 Sep 2004 12:21: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 i8PJL1j7014562; Sat, 25 Sep 2004 12:21:01 -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 i8PJL0br014553 for ; Sat, 25 Sep 2004 12:21:00 -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 9AD861D657 for ; Sat, 25 Sep 2004 12:21:04 -0700 (PDT) Date: Sat, 25 Sep 2004 12:21:06 -0700 From: Greg Connor To: ietf-mxcomp@imc.org Subject: Re: Microsoft Statement regarding Sender I.D. Update and Plans (forwarded by request) Message-ID: <1280130.1096114866@[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 > I would also like to clarify several misstatements pertaining to our > license and patents. From the onset, Microsoft has confirmed that any > potential patent rights that Microsoft may eventually be granted will > be provided to all users, implementers and distributors of the Sender > ID specification under Microsoft's royalty free license. Microsoft > will not revoke its offer to extend this license to anyone now and in > perpetuity. ... > > In summary, I want to assure you that Microsoft remains committed to > Sender ID. ... > Craig Spiezle > Microsoft Corporation > Director, Safety Technology and Strategy Group Hmm, too bad they weren't committed enough to make the license sub-licenseable. That's a key component of open source. MS really needs to work harder to get their lawyers to do the right thing, or else clarify that "all users, implementers and distributors" isn't meant to include open source implementers and distributors. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sat Sep 25 16:06: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 QAA14937 for ; Sat, 25 Sep 2004 16:06: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 i8PJhB38015483; Sat, 25 Sep 2004 12:43: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 i8PJhBRc015482; Sat, 25 Sep 2004 12:43:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8PJhA5V015476 for ; Sat, 25 Sep 2004 12:43:10 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3EEE5E04B2; Sat, 25 Sep 2004 15:43:12 -0400 (EDT) Date: Sat, 25 Sep 2004 15:43:12 -0400 From: John Leslie To: Hector Santos Cc: Dave Crocker , MXCOMP Subject: "Wasted" CSV-DNA lookups Message-ID: <20040925194312.GF70390@verdi> References: <200492375043.155918@bbprime> <018f01c4a1b8$01947f20$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <018f01c4a1b8$01947f20$6401a8c0@hdev1> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector Santos wrote: > > I assert the lookup method needs to be refined. Hector seems to be reacting to the "Overview" section in http://www.jlc.net/MARID/CSV/draft-ietf-marid-csv-intro-01.html This overview is there because people complained they didn't understand how to use CSV. It is _an_ example. Please note there isn't a single "MUST" in the entire Overview. In fact, there are rather few "MUST"s in the entire CSV series: In csv-intro: - A sending SMTP client MUST supply a published domain name as the parameter to an SMTP HELO or EHLO. - If an EHLO is issued, the entire CSV process MUST be restarted without needing to make a new connection. - CSV participants MUST use the method defined in Client SMTP Authorization (CSA) [ID-CSVCSA]. - Accreditation services MUST publish DNA-conformant records. In csv-csa: - DNS administration, servers and clients MUST support SRV queries. - Client MTA's MUST put their registered domain name in EHLO announcements. - Server MTA's MUST implement the validation procedure described in this specification. In csv-dna: - A direct accreditation service MUST publish its listings using the following record and format... - The Accreditation Report string MUST contain a report for a particular service, encoded as... - Strings which do not match this format MAY have meaning outside the scope of this specification and MUST be ignored by DNA parsers unaware of such meaning. - For MARID-CSV, the "service accredited" MUST be "MARID" and the "level accredited" currently MUST be "1". - Any CSV queries MUST discard any PTR records returned which do not contain that prefix ["_VOUCH._SMTP."]. That's it, folks... In fact, there's no requirement that the receiving MTA do any DNA test whatsoever: merely, that if they do, they must ignore PTR replies which don't start with the magic string, and must ignore TXT records which don't match the DNA report format. (Doug has already explained why we thought the example given in the Overview was _a_ good way to do things.) > As it relates to CSV, there are two distinctly different concepts in the > total paradigm of trust. Overhead, wasted DNAs for example when in fact > the exposed client domain name was illegal. You only need to do a > accreditation lookup if CSA result is positive (passes). However, your > lookup method requires a DNA lookup first. Hint on reading Standards: if it's not a MUST, it's not "required". (I really don't want to belittle Hector, but Standards _must_ be written as standards, and must be read as standards.) In fact, Hector's preferred way of implementing CSV is 100% permitted. > From: "Dave Crocker" > >> Anyone not clear about the roles and functions of components in the the >> CSA specification is strongly encouraged to asked detailed questions >> about them. That way, we will know what needs to be changed in the >> specifications, to improve their clarity. > > The point is that the specification is well understood. You are trying > to implement a total product, but the product parts doesn't fit well in > practical opertions. The "parts" of the product have conflicts as it fits > into the total model. If it did not, it would of been adopted long ago. We are not trying to "implement a total product": we're trying to write a standard. >> In any event, the RFC2821.helo/ehlo parameter is is per-session and is >> used to validate the OPERATOR OF THE MTA. The other SMTP parameters are >> per-message. MailFrom validation mechanisms pertain to the SENDER OF >> THE MESSAGE. >> >> These are entirely different entities, and validating each of them has > > entirely different benefits. > > The entities 2821.EHLO/HELO, 2821.MAILFROM, including 2821.RCPTTO are > SMTP transport parameters and are all involved in the total equation > validation/trust paradigm at the transport level. Until you recognize > this, your proposals impose wasted overhead in systems. "Wasted" is in the eye of the beholder. We need to write a standard which is workable in today's environment and also workable in a future world where spammers don't bother to send as much junk as they do today. And, though I hate repeating myself, the CSV proposal doesn't "impose" any DNA overhead whatsoever. > Your proposal (as well as others) all are designed on the presumption > that the 2821.RCPTO forwarding address is valid and that the payload > will be acceptable. This is simply not true. SMTP was designed with the assumption that RCPT-TO would "usually" be useful. We have done nothing to strengthen _or_ weaken that assumption. > The presumption is weak in the today's real world of anti-spam > operational requirements. "Today's" world -- yes. Tomorrow's world -- who knows? The standard _cannot_ only be for today's world. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Sat Sep 25 16:21: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 QAA15471 for ; Sat, 25 Sep 2004 16:21: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 i8PJxski016104; Sat, 25 Sep 2004 12:59:54 -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 i8PJxse8016103; Sat, 25 Sep 2004 12:59:54 -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 i8PJxsJg016094 for ; Sat, 25 Sep 2004 12:59:54 -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 i8PJxuxM025166 for ; Sat, 25 Sep 2004 12:59:56 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 25 Sep 2004 12:59:56 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: ietf-mxcomp@imc.org Subject: RE: [On Rewriting SMTP and DNS] RE: MARID to close - Comments/Sug gestions Date: Sat, 25 Sep 2004 12:59:53 -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: In fairness to Bob. There is a big difference between saying "DNS cannot do that" and "The deployed Microsoft DNS server does not do that". There are many cultural tensions at work here. The practices of systems operation acceptable in the UNIX world are not acceptable to Windows sysops. Within the UNIX world there is a vast gulf between the management practices acceptable in a small operation and the processes used by infrastructure providers. It is however somewhat incongruous to hear a network standards organization that has signally failed to provide security in email, DNS and the IP protocol go lecturing word processing vendors for design decisions taken long before the Internet went mainstream. > -----Original Message----- > From: Gordon Fecyk [mailto:gordonf@pan-am.ca] > Sent: Friday, September 24, 2004 11:42 PM > To: ietf-mxcomp@imc.org > Subject: [On Rewriting SMTP and DNS] RE: MARID to close - > Comments/Suggestions > > > > > 3) Optional: Rewrite SMTP 2821 > > > > unless the MARID group gets the IETF-SMTP involved, it will be > > a tough climb to reach the common goals we are all looking for > > success across the board. We need to recognize that the old > > design philosophy in SMTP 2821, a "relaxed internet spirit > > required for wide deployment with less > > emphasis with security" no longer applies today. > > I'm a newcomer to the IETF and I've observed this snobbish > attitude right > from the first day I stepped into the the Lotte Hotel in > Seoul[1]. That of > the SMTP working group, I mean, and while Hector didn't > mention them, the DNS > working group too. > > "This fundamentaly changes the semantics of X," was a favorite line > throughout this process. There are a few in this group who > represent this > thought who I will refer to as The Old Guard. > > Mitch Kapor, of Lotus 1-2-3 fame and co-founder of the > Electronic Frontier > Foundation, made opinions of The Old Guard clear to the > author of The Hacker > Crackdown (1992 Bantam Books) during an interview: > > "You go tell a hardware hacker that everyone should have a node on the > Internet, and the first thing they'll tell you is: 'IP > doesn't scale.' The > answer is: Evolve the protocol! Get smart people together > and figure out > what to do. Do we add [identification]? Do we add protocol? > Don't just say > 'we can't do it.'" > > The Old Guard tells us We Can't Do It and then goes to > extreme lengths to > prove why. I say: B***S***. I'll bet Tim Berners-Lee > thought that, and the > result is the World Wide Web. We have The Old Guard saying > that we can't do > X in DNS, we can't do Y in SMTP. > > Even though it was done. > > We have Bob Atkinson telling me his company's software can't > do X in DNS even > though folks here proved him wrong. And it didn't even > require rewriting > DNS. > > Earlier proposals worked entirely within existing DNS and > SMTP framework, > even if they did change some semantics in SMTP and made some > DNS old farts > turn up their noses. They still worked within the system to > the system's > specifications. > > Yet they were rejected based on semantics. Outdated > semantics, I might add, > based on an Internet where it was assumed all communication > was wanted and > requested. > > To Mitch Kapor, "...this is the snobbery of the people on the > Mayflower > looking down their noses at the people who came over [to the > New World] on > the _second boat!_" > > By what right do you, The Old Guard, have to look down your > noses at folks > like me? Like Meng? Like Hadmut? Like Raymond? Criticism > ("Where's the > debugger?") is one thing, but you went beyond mere criticism > to outright > denial. > > As for the patent issues, I believe "Chairman Bill" and his pack of > cartooneys can stand a lesson on where they came from. That > goes for you > guys, Harry, Bob, and the others whose names grace certain patent > applications. You all came on The Second Boat looking down > at us coming on > the third, pretending that the Mayflower didn't exist. Or > that the first > boat infringed on your patents. Or something stupid like that. > > [1] During the second English keynote speech which I'll call > the "Don't Try > This At Home" speech, the speaker took an unnecessary stab at > Microsoft Word > as being a security risk for allowing active content in a > document. I didn't > hear any chuckles from the audience and I'm not surprised - > not only was the > presentation B-O-R-I-N-G, it was demeaning, disrespectful to > the audience and > disrespectful to "the folks on the second boat" who produced > MS Word they way > they did Because Their Customers Asked For It.[2] I took a > moment to try to > bring this to light to the speaker afterward. I made my > first enemy in the > IETF and it was only my first day on site. > > [2] Users keep demanding functionality with little or no > regard to security. > That's not Microsoft's fault. > > > -- > PGP key (0x0AFA039E): > Sometimes it's hard to tell where the game ends and where > reality bites, > er, begins. > From owner-ietf-mxcomp@mail.imc.org Sat Sep 25 21: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 VAA28266 for ; Sat, 25 Sep 2004 21:19:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8Q0rbiC032058; Sat, 25 Sep 2004 17:53:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8Q0rbfm032057; Sat, 25 Sep 2004 17:53:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8Q0raGm032047 for ; Sat, 25 Sep 2004 17:53:37 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: [On Rewriting SMTP and DNS] RE: MARID to close - Comments/Suggestions MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 25 Sep 2004 19:53:40 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D05542A@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [On Rewriting SMTP and DNS] RE: MARID to close - Comments/Suggestions Thread-Index: AcSjPbH59T9GFtawRdSc2txQUaVongAIuh5Q From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8Q0rbGm032052 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > In fairness to Bob. There is a big difference between saying > "DNS cannot do that" and "The deployed Microsoft DNS server > does not do that". That's just it: Microsoft's deployed DNS server (Windows 2000 SP4 at least) CAN. Folks here provided examples and demonstrations of how it can. Even if not, I dared suggest that an alternate DNS service could provide anything that Microsoft's deployed DNS server (hypothetically, if not realisticly) could not provide. I clearly remember Bob's reaction to that, how I would Dare Suggest That Windows Components Could Be Replaced. How blasphemous. I suppose other folks with the same mentality would faint at the sight of seeing LitePC picking apart their prized OS[1], that Internet Explorer could somehow be completely removed from Windows. Even though that was just as clearly demonstrated in a US court of law. But no one in Redmond talks much about that little embarrassment.[2] [1] Using APIs published by Microsoft, no less! [2] Even local consultants here balk at the concept. And some of these folks are otherwise very smart people. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Sat Sep 25 21:43: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 VAA29148 for ; Sat, 25 Sep 2004 21:43:45 -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 i8Q1LZMU034614; Sat, 25 Sep 2004 18:21: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 i8Q1LZFB034613; Sat, 25 Sep 2004 18:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8Q1LZfg034607 for ; Sat, 25 Sep 2004 18:21:35 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Microsoft Statement regarding Sender I.D. Update and Plans (forwarded by request) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 25 Sep 2004 20:21:41 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D05542B@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Microsoft Statement regarding Sender I.D. Update and Plans (forwarded by request) Thread-Index: AcSjObhCFUtpXFM0R46l8FaQprrXuwAKnliw From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8Q1LZfg034608 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Hmm, too bad they weren't committed enough to make the license > sub-licenseable. That's a key component of open source. Therein lies the problem. Microsoft's lawyers really have no obligation to do this or anything else for their competition. Open source is in effect their only real competition so what real incentive do they have to provide for open source in any way? They're in the business to make money, not to save the world from spam or falsified e-mail. They're only doing Sender ID because their paying customers are asking for it - or something - to stop falsified e-mail. Open source people need to Get On With It[1] and finish SPF, or something else, as a viable and free alternative. You need to do that to keep Microsoft honest. And if it means moving development to Norway or wherever software patent law doesn't exist, do it. I've already offered to buy and set up a test machine running Win2K Server accessible through some kind of remote desktop service to one developer. Any other takers? [1] Gee, where have I said that before? -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Sun Sep 26 16:54: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 QAA29873 for ; Sun, 26 Sep 2004 16:54: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 i8QKKjeP010859; Sun, 26 Sep 2004 13:20: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 i8QKKjMc010858; Sun, 26 Sep 2004 13:20:45 -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 i8QKKf72010848 for ; Sun, 26 Sep 2004 13:20:42 -0700 (PDT) (envelope-from sb0-0687974619-johnl@iecc.com) Received: (qmail 7005 invoked by uid 100); 26 Sep 2004 20:20:45 -0000 Date: 26 Sep 2004 20:20:45 -0000 Message-ID: <20040926202045.7004.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: [On Rewriting SMTP and DNS] RE: MARID to close - Comments/Suggestions In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D05542A@srv1.pan-am.ca> Organization: I.E.C.C., Trumansburg NY USA Cc: gordonf@pan-am.ca Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >That's just it: Microsoft's deployed DNS server (Windows 2000 SP4 at least) >CAN. Folks here provided examples and demonstrations of how it can. I agree that there are alternatives for DNS service, although most of the suggestions seemed much too hacky for anything other than hobbyist systems. The insoluble problem for Windows users is on the client side. Someone decided that there would never ever be an new DNS record type, so their API for DNS requests has a separate call for every record type. They'll have to release both new client libraries and firewall services before hosts behind a firewall can see a new record type. I agree this was a breathtakingly poor design decision, but there's too many Windows boxes in the field to ignore it. This same problem will affect any scheme that publishes info in the DNS. Even if it defines new record types for new data (which is clearly the right thing to do for DNS performance), it'll need some sort of long-term transition kludge using existing record types. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 03:22: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 DAA08491 for ; Mon, 27 Sep 2004 03:22: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 i8R6qQkQ087499; Sun, 26 Sep 2004 23:52:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8R6qQqf087498; Sun, 26 Sep 2004 23:52:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8R6qOCU087432 for ; Sun, 26 Sep 2004 23:52:25 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i8R6qESU032539 for ; Mon, 27 Sep 2004 07:52:14 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i8R6qDkf032538; Mon, 27 Sep 2004 07:52:13 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: [On Rewriting SMTP and DNS] RE: MARID to close - Comments/Suggestions References: <20040926202045.7004.qmail@xuxa.iecc.com> From: Graham Murray Date: Mon, 27 Sep 2004 07:52:13 +0100 In-Reply-To: <20040926202045.7004.qmail@xuxa.iecc.com> (John Levine's message of "26 Sep 2004 20:20:45 -0000") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Levine writes: > They'll have to release both new client libraries and firewall > services before hosts behind a firewall can see a new record type. I > agree this was a breathtakingly poor design decision, but there's too > many Windows boxes in the field to ignore it. Or it could be used as a mechanism to force people to upgrade to the 'latest and greatest' windows. From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 03:31: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 DAA09046 for ; Mon, 27 Sep 2004 03:31:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8R78pHG093058; Mon, 27 Sep 2004 00:08: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 i8R78piL093056; Mon, 27 Sep 2004 00:08:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8R78p23093040; Mon, 27 Sep 2004 00:08:51 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8R78o404035; Mon, 27 Sep 2004 00:08:50 -0700 From: Dave Crocker To: X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Reply-To: Dave Crocker Date: Mon, 27 Sep 2004 00:08:48 -0700 Message-ID: <20049270848.800979@bbprime> Subject: mailing list for CSV/BATV pre-standards discussions 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 Folks, I've set up a mailing list for pre-working group discussions of CSV/BATV standardization. Please take a look at: It points to mailing list subscription information. It also primes the discussion pump with a draft charter. d/ -- Dave Crocker Brandenburg InternetWorking From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 07:58: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 HAA22550 for ; Mon, 27 Sep 2004 07:58: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 i8RBUJC0077521; Mon, 27 Sep 2004 04:30:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RBUJ6L077520; Mon, 27 Sep 2004 04:30:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts36-srv.bellnexxia.net (tomts36.bellnexxia.net [209.226.175.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RBUGJ4077512 for ; Mon, 27 Sep 2004 04:30:18 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([64.229.25.235]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040927113009.CSAR25796.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 27 Sep 2004 07:30:09 -0400 From: "John Glube" To: , , Subject: RE: Microsoft Statement regarding Sender I.D. Update and Plans (forwarded by request) Date: Mon, 27 Sep 2004 07:29:41 -0400 Message-ID: <000001c4a485$48495e70$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8RBUIJ4077515 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit From: Anne P. Mitchell, Esq. Sent: September 25, 2004 3:40 AM To: ietf-mxcomp@imc.org Subject: Microsoft Statement regarding Sender I.D. Update and Plans (forwarded by request) Thank you for posting the Speizle letter. Although the Microsoft patent applications are quite broad, I took solace from the good faith representations made in the IPR filings and to the MARID list as to the actual scope of these claims. On September 21, 2004, a press spokesperson for Microsoft is reported to have sent an email to Internetnews which read: |"The SPF technical alternative is just now becoming a real |focus for the IETF. It is premature for the standards |participants to disclose any IP they may own related to |SPF. If SPF continues to work its way through the process, |there will likely be a point where Microsoft and others |will [be] asked to identify any essential IP claims and |Microsoft will follow the IETF guidelines for disclosure at |that time." http://www.internetnews.com/dev-news/article.php/3409971 This reported statement was cause for concern upon my part. I had hoped that Microsoft would clarify matters and simply confirm the previous good faith representations. Unfortunately, I remain concerned. Let me explain. In the letter, Craig Speizle writes: |"I would also like to clarify several misstatements |pertaining to our license and patents. From the onset, |Microsoft has confirmed that any potential patent rights |that Microsoft may eventually be granted will be provided |to all users, implementers and distributors of the Sender |ID specification under Microsoft's royalty free license. |Microsoft will not revoke its offer to extend this license |to anyone now and in perpetuity." The phrase "the Sender ID specification," is not defined in this paragraph, except by reference to "Microsoft's royalty free license." In the second paragraph of the letter, Craig Speizle writes: |"After discussion with the IETF MARID chairs, we jointly |agreed to move forward with a proposal that provides |implementers the choice of utilizing PRA or MAIL FROM for |the Sender ID check mechanism." And in the third paragraph of the letter, Craig Speizle writes: |"While we would have preferred a single technical mechanism |as the standard, we believe the specification to allow |multiple scopes in the protocol is a reasonable approach, |providing choice and flexibility." The patent applications are quite broad in scope. Even though the term "Sender ID specification" is presently defined in "Microsoft's royalty free license," there is nothing in the letter to preclude Microsoft from amending this definition to fit with any patent rights which Microsoft may subsequently be granted. We are therefore left with two possible interpretations of the meaning of the phrase "Sender ID specifications" in the letter: 1. "Sender ID specification" means: (i) the original caller-id specification; (ii) the marid-core and marid-pra specification as defined in Microsoft's draft patent license; (iii) any amendments to the marid-core and marid-pra specifications or equivalent substitutions thereof, but which are not based on SMTP mailfrom, EHELO/HELO or the IP address, as may occur in obtaining IETF-experimental status and IETF-standard track for these specifications. 2. "Sender ID specification" means: (i) the original caller-id specification; (ii) the marid-core and marid-pra specification as defined in Microsoft's existing draft patent license; (iii) the marid-mailfrom specification; (iv) any IETF - experimental set of protocols involving either mailfrom or pra checking based on the existing or any amended specification; (iv) any IETF - standard set of protocols involving mailfrom or pra checking based on the existing or any amended specification; (v) any other method of sender authentication which falls within the scope of Microsoft's patent rights and forms part of the "Sender ID check mechanism." I also note that: * Microsoft's existing draft patent license is not compatible with the Open Standards Alliance model. On what is meant by the Open Standards Alliance model, a conference was held Fairmont Scottsdale Princess resort in Arizona during September 13 - 14, 2004. The conference title: "Open Source, Open Standards: Maximising Utility While Managing Exposure" The conference was organized by the Open Standards Alliance. http://www.openstandardsalliance.org/ At the conference, Larry Rosen gave a keynote speech on the issue of the compatibility of Open Standards with Open Source software licensing. I quote from the official conference statement: |"Larry Rosen proposed five normative principles for open |standards that are compatible with Open Source software |licensing. | |The five principles of open source software are: | |1. Licensees are free to use open source software for any |purpose whatsoever. | |2. Licensees are free to make copies of open source |software and to distribute them without payment of |royalties to a licensor. | |3. Licensees are free to create derivative works of open |source software, and to distribute them without payment of |royalties to a licensor. | |4. Licensees are free to access and use the source code of |open source software. | |5. Licensees are free to combine open source and other |software. | |Compatible principles | |Mr Rosen put forward compatible principles for Open |Standards: | |1. Everyone is free to copy and distribute the official |specification for an open standard under an open source |license. | |2. Everyone is free to make or use embodiments of an open |standard under unconditional licenses to patent claims |necessary to practice that standard. | |3. Everyone is free to distribute externally, sell, offer |for sale, have made, or import embodiments of an open |standard under patent licenses that may be conditioned only |on reciprocal licenses to any of the licensee's patent |claims necessary to practice that standard. | |4. A patent license for an open standard may be terminated |as to any licensee who sues the licensor or any other |licensee for infringement of patent claims necessary to |practice that standard. | |5. All patent licenses necessary to practice an open |standard are worldwide, royalty-free, non-exclusive, |perpetual, and sub-licensable." * I believe it is fundamental that open standards which are subject to patents and/or patent claims must be subject to actual or draft patent licenses which are compatible with open source licensing standards as set out in the Open Standards Alliance model to ensure the continued vibrancy of the Internet. * Email is presently one of the core reasons people use the Internet. * Based on what has already transpired, I suggest it is self evident that any proposal which supports PRA will run into trouble, during any public comment process prescribed by the IETF as long as Microsoft persists in requiring a patent license which is not compatible with the Open Standards Alliance model. In the circumstances, I believe it is incumbent upon Microsoft to confirm that: * "Sender ID specification" means: (i) the original caller-id specification; (ii) the marid-core and marid-pra specification as defined in Microsoft's draft patent license; and (iii) any amendments to the marid-core and marid-pra specifications or equivalent substitutions thereof, but which are not based on SMTP mailfrom, EHELO/HELO or the IP address, as may occur in obtaining IETF-experimental status and IETF-standard track for these specifications. * "Microsoft's royalty free license" will be fully compatible with the Open Standards Alliance model. Otherwise, it is highly likely there will be a hue and cry during the public comment process of any experimental proposal put forward by Microsoft as called for under sections 4.2.3 and 6.1.2 of RFC 2026. But perhaps more importantly, without fully clarifying matters, in my opinion, based on what has transpired to date, Microsoft runs the risk of placing the IETF's credibility in jeopardy as a standards organization. Having made these comments, I add that I have every reason to consider Craig Speizle is personally acting in good faith, based on legal guidance and in what is perceived as Microsoft's best interest. However, given the potentially contentious nature of this matter, along with the import to email as a viable means of communication and the risk to the IETF itself, I call upon Microsoft, as one of the leading software firms in the world, to fully clarify matters for the record beyond a shadow of a doubt. John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.767 / Virus Database: 514 - Release Date: 21/09/2004 From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 12:13:48 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 MAA10355 for ; Mon, 27 Sep 2004 12:13:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RFcLsm097542; Mon, 27 Sep 2004 08:38:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RFcLVd097541; Mon, 27 Sep 2004 08:38:21 -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 i8RFcKDg097535 for ; Mon, 27 Sep 2004 08:38:20 -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 i8RFcMJr026448; Mon, 27 Sep 2004 08:38:23 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 08:38:22 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'John Glube'" , ietf-mxcomp@imc.org, craigspi@microsoft.com, amitchell@isipp.com Subject: RE: Microsoft Statement regarding Sender I.D. Update and Plans (f orwarded by request) Date: Mon, 27 Sep 2004 08:38:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > * I believe it is fundamental that open standards which are > subject to patents and/or patent claims must be subject to > actual or draft patent licenses which are compatible with > open source licensing standards as set out in the Open > Standards Alliance model to ensure the continued vibrancy > of the Internet. Well maybe what you learn from all of this is that maybe you did not choose the best way to achieve your goal. It was your idea to play chicken with this issue. Don't complain about the all too predictable result. From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 13:05:40 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 NAA13216 for ; Mon, 27 Sep 2004 13:05:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RGTRRk000905; Mon, 27 Sep 2004 09:29:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RGTRb5000904; Mon, 27 Sep 2004 09:29:27 -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 i8RGTQ7c000897 for ; Mon, 27 Sep 2004 09:29:26 -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 i8RGTOER020543; Mon, 27 Sep 2004 09:29:27 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Sep 2004 09:29:24 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "Hallam-Baker, Phillip" , "'John Glube'" , "'ietf-mxcomp@imc.org'" , "'craigspi@microsoft.com'" , "'amitchell@isipp.com'" Subject: RE: Microsoft Statement regarding Sender I.D. Update and Plans (f orwarded by request) Date: Mon, 27 Sep 2004 09:29:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In case there is some ambiguity here, my comment was directed at John. You don't always get what you want. But if you try sometimes you just might find you get what you need. > -----Original Message----- > From: Hallam-Baker, Phillip > Sent: Monday, September 27, 2004 11:38 AM > To: 'John Glube'; ietf-mxcomp@imc.org; craigspi@microsoft.com; > amitchell@isipp.com > Subject: RE: Microsoft Statement regarding Sender I.D. Update > and Plans > (forwarded by request) > > > > > * I believe it is fundamental that open standards which are > > subject to patents and/or patent claims must be subject to > > actual or draft patent licenses which are compatible with > > open source licensing standards as set out in the Open > > Standards Alliance model to ensure the continued vibrancy > > of the Internet. > > Well maybe what you learn from all of this is that maybe you > did not choose the best way to achieve your goal. > > It was your idea to play chicken with this issue. Don't complain > about the all too predictable result. > From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 13:19: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 NAA14085 for ; Mon, 27 Sep 2004 13:19:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RGrHE7002383; Mon, 27 Sep 2004 09:53:17 -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 i8RGrHqW002382; Mon, 27 Sep 2004 09:53:17 -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 i8RGrHAr002375 for ; Mon, 27 Sep 2004 09:53:17 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8RGrKcd031285; Mon, 27 Sep 2004 09:53:20 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'ietf-mxcomp@imc.org'" , "'craigspi@microsoft.com'" , "'John Glube'" From: "Anne P. Mitchell, Esq." Subject: Re: Microsoft Statement regarding Sender I.D. Update and Plans (f orwarded by request) Date: Mon, 27 Sep 2004 09:53:19 -0700 To: "Hallam-Baker, Phillip" 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 > You don't always get what you want. > But if you try sometimes you just might find you get what you need. Wow..that'd make a great song... Anne From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 13:27:57 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 NAA14769 for ; Mon, 27 Sep 2004 13:27: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 i8RGsLaj002480; Mon, 27 Sep 2004 09:54:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RGsL2w002479; Mon, 27 Sep 2004 09:54:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8RGsJ6e002447 for ; Mon, 27 Sep 2004 09:54:20 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-10.tower-48.messagelabs.com!1096304056!5281207 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 17736 invoked from network); 27 Sep 2004 16:54:16 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-10.tower-48.messagelabs.com with SMTP; 27 Sep 2004 16:54:16 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Sep 2004 17:54:15 +0100 Received: (qmail 1688 invoked from network); 26 Sep 2004 16:51:19 -0000 Received: from unknown (HELO ?10.191.100.8?) (10.191.100.8) by matt?dev.int.star.co.uk with SMTP; 26 Sep 2004 16:51:19 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: craigspi@microsoft.com, ietf-mxcomp@imc.org, amitchell@isipp.com, "'John Glube'" From: Matt Sergeant Subject: Re: Microsoft Statement regarding Sender I.D. Update and Plans (f orwarded by request) Date: Mon, 27 Sep 2004 17:54:17 +0100 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 27 Sep 2004 16:54:15.0781 (UTC) FILETIME=[9F59C150:01C4A4B2] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Sep 2004, at 16:38, Hallam-Baker, Phillip wrote: >> * I believe it is fundamental that open standards which are >> subject to patents and/or patent claims must be subject to >> actual or draft patent licenses which are compatible with >> open source licensing standards as set out in the Open >> Standards Alliance model to ensure the continued vibrancy >> of the Internet. > > Well maybe what you learn from all of this is that maybe you > did not choose the best way to achieve your goal. > > It was your idea to play chicken with this issue. Don't complain > about the all too predictable result. Played chicken? Can you be any more insulting? Some of us travelled 6000 miles for a one day event to try and persuade Microsoft to do the right thing. This wasn't playing chicken. Some of us worked really bloody hard at this only for MS to stand their ground and waste all our efforts. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 13:34:09 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 NAA15112 for ; Mon, 27 Sep 2004 13:34: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 i8RH41i9002940; Mon, 27 Sep 2004 10:04: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 i8RH4142002939; Mon, 27 Sep 2004 10:04:01 -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 i8RH40iX002931 for ; Mon, 27 Sep 2004 10:04:00 -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 1CByuk-0004vy-C3 for ietf-mxcomp@imc.org; Mon, 27 Sep 2004 12:04:01 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 27 Sep 2004 12:03:50 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 27 Sep 2004 08:38:21 -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: Microsoft Statement regarding Sender I.D. Update and Plans (f orwarded by request) 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.6 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: >> * I believe it is fundamental that open standards which are >> subject to patents and/or patent claims must be subject to >> actual or draft patent licenses which are compatible with >> open source licensing standards as set out in the Open >> Standards Alliance model to ensure the continued vibrancy >> of the Internet. > > Well maybe what you learn from all of this is that maybe you > did not choose the best way to achieve your goal. I dunno about John Glube, but I for one am *much* happier to have no de-jure standard than a standard that most of the MTAs on the internet can't (effectively) use. This is especially true when there is a de-facto standard that not only is compatible with most MTAs, but implmentations have been made available for the vast majority of MTAs. > It was your idea to play chicken with this issue. Don't complain > about the all too predictable result. Again, I can't speak for John Glube, but I don't think he, or anyone else who supported F/OSS MTAs, was playing chicken. MS was told many times that objections would be raised if their license was not compatible with F/OSS MTAs. At the interim meeting, Jim assured us that it was. (Or, would be, as the license had not been released at that time.) While I'm disappointed that Harry and Jim were not able to get the MS lawyers to do the right thing, and I'm disappointed that Ted Hardie shut down the working group, I think that all people who really want to see an end to email forgery have won this current battle. If the SenderID I-Ds had advanced, they would have just created huge market confusion with the massive deployment problems that the license creates. The war, of course, is not over. The IETF (Ted, and maybe the former co-chairs?), Meng, and MS (Harry, Jim, Bob, et al) appear to have learned nothing from what has happened. They have done an end-run around the working group last call by closing down the working group, but they are still pushing ahead with the PRA under the current license. Apparently, they think that when the "individual" I-Ds are submitted to the IESG and there is an IETF-wide last-call, things will go better. I don't see it. One definition of insanity is doing the same thing again and again and expecting different results. Under this definition, Ted, Meng, Harry, Jim, et al, are acting quite insane. I see four choices: 1) Forget about getting a de-jure standard. 2) Drop the PRA. 3) Change the PRA license to be compatible with F/OSS MTAs. 4) Find one or more widely accepted alternative to the PRA that covers the 2822.From: identity so that people can reasonably choose between the PRA and the alternatives. Ted, Meng, Harry, Jim et al: PLEASE! Wake up and smell the coffee! We need a anti-forgery system that protects the 2822.From: identity, we don't need another two-week blowup when the IESG last-call happens. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 14:03: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 OAA17263 for ; Mon, 27 Sep 2004 14:03: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 i8RGYTPE001205; Mon, 27 Sep 2004 09:34:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RGYTk4001204; Mon, 27 Sep 2004 09:34:29 -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 i8RGYTRD001194 for ; Mon, 27 Sep 2004 09:34:29 -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 81E12414CA; Mon, 27 Sep 2004 09:34:30 -0700 (PDT) Subject: RE: Microsoft Statement regarding Sender I.D. Update and Plans (forwarded by request) From: Douglas Otis To: John Glube Cc: MARID , craigspi@microsoft.com, amitchell@isipp.com In-Reply-To: <000001c4a485$48495e70$6c62fea9@ibmrkydk2ufvdd> References: <000001c4a485$48495e70$6c62fea9@ibmrkydk2ufvdd> Content-Type: text/plain Message-Id: <1096302870.26214.46.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 27 Sep 2004 09:34:30 -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 Mon, 2004-09-27 at 04:29, John Glube wrote: > From: Anne P. Mitchell, Esq. > Sent: September 25, 2004 3:40 AM > To: ietf-mxcomp@imc.org > Subject: Microsoft Statement regarding Sender I.D. Update and > Plans (forwarded by request) > > Thank you for posting the Speizle letter. > > Although the Microsoft patent applications are quite broad, > I took solace from the good faith representations made in > the IPR filings and to the MARID list as to the actual > scope of these claims. > > On September 21, 2004, a press spokesperson for Microsoft > is reported to have sent an email to Internetnews which > read: > > |"The SPF technical alternative is just now becoming a real > |focus for the IETF. It is premature for the standards > |participants to disclose any IP they may own related to > |SPF. If SPF continues to work its way through the process, > |there will likely be a point where Microsoft and others > |will [be] asked to identify any essential IP claims and > |Microsoft will follow the IETF guidelines for disclosure at > |that time." > > http://www.internetnews.com/dev-news/article.php/3409971 > > This reported statement was cause for concern upon my part. > > I had hoped that Microsoft would clarify matters and simply > confirm the previous good faith representations. Regardless of the promised arrangements Microsoft may claim in various news articles, the rights of this IPR, if granted, could be sold to an entity with a considerably different stance. There is an inherent risk obtaining an address list rather than a name list for such a large array of hosts. There is an inherent risk using a text script parser which may constrain the source port processing this information from several DNS servers. The use of scripts, to lookup hundreds of records for addresses, creates a high risk for a denial of service attack aimed at disabling the check, and allows just a DSL connection to poison the DNS cache. This scheme still allows spoofing, and phishing, but now with possibility of false assurances. Those publishing this scheme also risk being exploited and unfairly having their mailbox address blocked. Using scripts, offers to DNS what they offered to mail. Mail is not a browser, and is not run at the behest of the user, but rather for total strangers. Lack of security has largely fostered the current situation. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 14:20: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 OAA18214 for ; Mon, 27 Sep 2004 14:20: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 i8RHkwv1005945; Mon, 27 Sep 2004 10:46: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 i8RHkwan005944; Mon, 27 Sep 2004 10:46:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RHkv29005937 for ; Mon, 27 Sep 2004 10:46:57 -0700 (PDT) (envelope-from shedevil@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so3839689rnl for ; Mon, 27 Sep 2004 10:46:57 -0700 (PDT) Received: by 10.38.3.58 with SMTP id 58mr209142rnc; Mon, 27 Sep 2004 10:46:57 -0700 (PDT) Received: by 10.38.92.2 with HTTP; Mon, 27 Sep 2004 10:46:57 -0700 (PDT) Message-ID: Date: Mon, 27 Sep 2004 10:46:57 -0700 From: "Anne P. Mitchell, Esq. " Reply-To: amitchell@isipp.com To: IETF MARID WG Subject: Re: Microsoft Statement regarding Sender I.D. Update and Plans (f orwarded by request) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > The war, of course, is not over. The IETF (Ted, and maybe the former > co-chairs?), Meng, and MS (Harry, Jim, Bob, et al) appear to have > learned nothing from what has happened. They have done an end-run > around the working group last call by closing down the working group, This is actually something which has me a bit confused; Craig's letter said "After discussion with the IETF MARID chairs, we jointly agreed to move forward with a proposal that provides implementers the choice of utilizing PRA or MAIL FROM for the Sender ID check mechanism. While the working group has recently shut down, we continue to work with the chairs and key stakeholders to move forward." To me this made it sound like Microsoft and the Chairs of the MARID group had been working together privately behind the scenes and even before the group was shut down, and that Microsoft continues to working with the Chairs (are they still chairs if the group no longer exists?) and "key stakeholders" behind the scenes to advance (something). Can someone please clarify this for me? Thanks, Anne From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 14:57:57 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 OAA21366 for ; Mon, 27 Sep 2004 14:57: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 i8RIRwc6008538; Mon, 27 Sep 2004 11:27: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 i8RIRw5d008537; Mon, 27 Sep 2004 11:27:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RIRwfk008517 for ; Mon, 27 Sep 2004 11:27:58 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i8RIRi8U012052; Mon, 27 Sep 2004 11:27:44 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Marshall Rose Subject: Re: Microsoft Statement regarding Sender I.D. Update and Plans (f orwarded by request) Date: Mon, 27 Sep 2004 11:27:41 -0700 To: amitchell@isipp.com 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 Sep 27, 2004, at 10:46, Anne P. Mitchell, Esq. wrote: > To me this made it sound like Microsoft and the Chairs of the MARID > group had been working together privately behind the scenes and even > before the group was shut down, and that Microsoft continues to > working with the Chairs (are they still chairs if the group no longer > exists?) and "key stakeholders" behind the scenes to advance > (something). > > Can someone please clarify this for me? sure. the wording is more conversational than precise, which is not uncommon for press releases, interviews, and other "reporting". working group chairs and ADs often have discussions with various parties in order to better understand their positions, and to suggest possible ways they might achieve a compromise with other various parties. nothing gets decided for the working group in such conversations. for example, i seem to recall an interim meeting, a design team meeting, and half-a-dozen conference calls with a whole gallery of characters, in order to get some basis for consensus. several of these meetings/calls led to various people suggesting different approaches on the mailing list, for comment. nothing particularly unusual or suspect about any of this. independently, it became clear to the ADs and the WG chairs, solely on the basis of the mailing list discussions that consensus wasn't possible. /mtr From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 15:00: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 PAA21602 for ; Mon, 27 Sep 2004 15:00:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RIJrDx008029; Mon, 27 Sep 2004 11:19: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 i8RIJrKo008028; Mon, 27 Sep 2004 11:19: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 i8RIJqsP008014 for ; Mon, 27 Sep 2004 11:19: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 i8RIXuTZ008624; Mon, 27 Sep 2004 11:33:56 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8RIXunt008621; Mon, 27 Sep 2004 11:33:56 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 27 Sep 2004 11:33:56 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org cc: spf-discuss@v2.listbox.com Subject: Alternatives drafts for SUBMITTER identity Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1747400512-1662785239-1096309698=:1935" 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. ---1747400512-1662785239-1096309698=:1935 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hello, As I have mentioned I have worked on alternatives draft for SUBMITTER concept. It actually ended up being two alternatives. When I originally started I was working on it based on certain assumptions of what would be covered by Microsoft pending patent and these assumptions are proven to be wrong (they either covered less or they covered more then I expected based on whoever is interpreting it). So based partially on some assumptions, I worked on draft that introduces new concept of email networks and uses Responsible Submitter identity to identify email message passing between different networks. In this concept submitter is represented by both RFC2821 SUBMITTER and by RFC2822 Submitted-By header. I descirbed summary of this concept in: http://www.imc.org/ietf-mxcomp/mail-archive/msg04726.html The end result I'm not entirely too happy with - it ended up being too complex and it appears proper combination of RFC2821 and RFC2822 is actually quite difficult to achieve. I'll most likely not be submitting this draft unless there is an interest on this concept from others in the community. The draft is 30 pages long (70% new text) and available at: http://www.elan.net/~william/emailsecurity/draft-leibzon-email-networks-submitter-00.txt For second draft which I started working on about week ago, I have focused on SUBMITTER as being only RFC2821 identity (in the next message I'll mention how I propose to bring this data into RFC2822 headers, but that is separate concept not entirely based on SUBMITTER). The draft is primarily combination of original SUBMITTER with some text from marid-core draft and with description on SPF verification for "submit" scope/identity. The draft is 18 pages and represents about 30% new text and ended up being a lot better then the first one, so I intend to send it to RFC-editor for publication and for consideration by the directorate (that is to be formed to determine future of MARID documents) as alternative to original MARID submitter encoumbered by requirement of Microsoft PRA. The draft is included with this text and is also available at http://www.elan.net/~william/emailsecurity/draft-leibzon-responsible-submitter-00.txt With PDF version available at http://www.elan.net/~william/emailsecurity/draft-leibzon-responsible-submitter-00.pdf Please review this text and send me your comments on this draft by Monday October 4th as that is when I intend to send it to RFC-editor. And If original authors of MARID SUBMITTER draft want to work further on this, I'd be more then happy to give the draft to them as input for new document assuming they agree with me to keep it completely separated from PRA. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ ---1747400512-1662785239-1096309698=:1935 Content-Type: TEXT/PLAIN; NAME="draft-leibzon-responsible-submitter-00.txt" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="draft-leibzon-responsible-submitter-00.txt" Content-Transfer-Encoding: BASE64 DQ0KICAgTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFcuIExlaWJ6b24NDQogICBJbnRlcm5ldCBE cmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RWxhbiBOZXR3b3Jrcw0NCiAgIERvY3VtZW50OiBkcmFmdC1sZWliem9uLXJl c3BvbnNpYmxlLXN1Ym1pdHRlci0wMC50eHQNDQogICBFeHBpcmVzOiAgQXBy aWwgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9j dG9iZXIgMjAwNA0NCg0NCg0NCg0NCiAgICAgICAgIAkgIFJlc3BvbnNpYmxl IFN1Ym1pdHRlciBvZiBhbiBFLW1haWwgTWVzc2FnZQ0NCg0NCg0NCg0NClN0 YXR1cyBvZiB0aGlzIE1lbW8NDQoNDQogICBCeSBzdWJtaXR0aW5nIHRoaXMg SW50ZXJuZXQtRHJhZnQsIEkgY2VydGlmeSB0aGF0IGFueSBhcHBsaWNhYmxl DQ0KICAgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggSSBh bSBhd2FyZSBoYXZlIGJlZW4gZGlzY2xvc2VkLA0NCiAgIG9yIHdpbGwgYmUg ZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIEkgYmVjb21lIGF3YXJlIHdp bGwgYmUNDQogICBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBSRkMg MzY2OC4gW1NURF0NDQoNDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtp bmcgZG9jdW1lbnRzIG9mIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMNDQogICBh cmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhl ciBncm91cHMgbWF5IGFsc28NDQogICBkaXN0cmlidXRlIHdvcmtpbmcgZG9j dW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NDQoNDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVt IG9mIHNpeCBtb250aHMNDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxh Y2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0N CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlDQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0 ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0NCg0N CiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBi ZSBhY2Nlc3NlZCBhdA0NCiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p ZXRmLzFpZC1hYnN0cmFjdHMudHh0DQ0KICAgVGhlIGxpc3Qgb2YgSW50ZXJu ZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dA0NCiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4N DQoNDQoNDQpDb3B5cmlnaHQgTm90aWNlDQ0KDQ0KICAgQ29weXJpZ2h0IChD KSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNCkuIEFsbCBSaWdodHMgUmVz ZXJ2ZWQuDQ0KDQ0KDQ0KQWJzdHJhY3QNDQoNDQogICBUaGlzIG1lbW8gZGVm aW5lcyBhbiBleHRlbnNpb24gdG8gdGhlIFNpbXBsZSBNYWlsIFRyYW5zZmVy IFByb3RvY29sDQ0KICAgKFNNVFApIHNlcnZpY2UsIHdoaWNoIGFsbG93cyBh biBTTVRQIGNsaWVudCB0byBzcGVjaWZ5IHRoZQ0NCiAgIHJlc3BvbnNpYmxl IHN1Ym1pdHRlciBvZiBhbiBlLW1haWwgbWVzc2FnZS4gIFRoZSByZXNwb25z aWJsZQ0NCiAgIHN1Ym1pdHRlciBpcyB0aGUgZS1tYWlsIGFkZHJlc3Mgb2Yg dGhlIGVudGl0eSBtb3N0IHJlY2VudGx5DQ0KICAgcmVzcG9uc2libGUgZm9y IGludHJvZHVjaW5nIGEgbWVzc2FnZSBpbnRvIHRoZSB0cmFuc3BvcnQgc3Ry ZWFtLg0NCiAgIFRoaXMgZXh0ZW5zaW9uIGhlbHBzIHJlY2VpdmluZyBlLW1h aWwgc2VydmVycyBlZmZpY2llbnRseSBkZXRlcm1pbmUNDQogICB3aGV0aGVy IHRoZSBTTVRQIGNsaWVudCBpcyBhdXRob3JpemVkIHRvIHRyYW5zbWl0IG1h aWwgb24gYmVoYWxmIG9mDQ0KICAgdGhlIHJlc3BvbnNpYmxlIHN1Ym1pdHRl cidzIGRvbWFpbi4NDQoNDQoNDQoNDQoNDQoNDQoNDQoNDQpMZWliem9uICAg ICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMV0NDQoNDQogICAgICAgICAgUmVzcG9uc2libGUg U3VibWl0dGVyIG9mIGFuIEUtbWFpbCBNZXNzYWdlICAgICAgICBPY3RvYmVy IDIwMDQNDQoNDQoNDQpDb252ZW50aW9ucyBVc2VkIGluIFRoaXMgRG9jdW1l bnQNDQoNDQogICBJbiBleGFtcGxlcywgIkM6IiBhbmQgIlM6IiBpbmRpY2F0 ZSBsaW5lcyBzZW50IGJ5IHRoZSBjbGllbnQgYW5kDQ0KICAgc2VydmVyIHJl c3BlY3RpdmVseS4NDQoNDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQ0K ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1B WSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNDQogICBkb2N1bWVudCBhcmUg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQy0yMTE5IFtL RVlXT1JEU10uDQ0KDQ0KDQ0KDQ0KVGFibGUgb2YgQ29udGVudHMNDQoNDQog ICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zDQ0KICAgMi4gVGhlIFNVQk1JVFRF UiBTZXJ2aWNlIEV4dGVuc2lvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uNA0NCiAgIDMuIFRoZSBTVUJNSVRURVIgS2V5d29yZCBvZiB0aGUg RUhMTyBDb21tYW5kLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNDQogICA0LiBU aGUgU1VCTUlUVEVSIFBhcmFtZXRlciBvZiB0aGUgTUFJTCBDb21tYW5kLi4u Li4uLi4uLi4uLi4uLi4uLi40DQ0KICAgICAgNC4xIFNldHRpbmcgdGhlIFNV Qk1JVFRFUiBQYXJhbWV0ZXIgVmFsdWUuLi4uLi4uLi4uLi4uLi4uLi4uLi4u NA0NCiAgICAgIDQuMiBQcm9jZXNzaW5nIHRoZSBTVUJNSVRURVIgUGFyYW1l dGVyLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNDQogICA1LiBBdXRob3Jp emluZyBVc2Ugb2YgUmVzcG9uc2libGUgU3VibWl0dGVyIEFkZHJlc3MuLi4u Li4uLi4uLi4uLi41DQ0KICAgICAgNS4xIFB1Ymxpc2hpbmcgRE5TIEF1dGhv cml6YXRpb24gUmVjb3Jkcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0NCiAg ICAgIDUuMiBDaGVja2luZyBETlMgQXV0aG9yaXphdGlvbiBSZWNvcmRzLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNDQogICAgICA1LjMgSW50ZXJwcmV0 aW5nIHRoZSBSZXN1bHRzIG9mIFNQRiBWZXJpZmljYXRpb24uLi4uLi4uLi4u Li4uLi42DQ0KICAgICAgICA1LjMuMSAgTm9uZS4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0NCiAgICAgICAg NS4zLjIgIE5ldXRyYWwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjcNDQogICAgICAgIDUuMy4zICBQYXNzLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43 DQ0KICAgICAgICA1LjMuNCAgRmFpbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0NCiAgICAgICAgNS4zLjUg IFNvZnRGYWlsLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjcNDQogICAgICAgIDUuMy42ICBUZW1wRXJyb3IuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQ0KICAg ICAgICA1LjMuNSAgUGVybUVycm9yLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uOA0NCiAgICAgIDUuNC4gU2F2aW5nIFZl cmlmaWNhdGlvbiBSZXN1bHRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjgNDQogICAgICAgIDUuNC4xIERpc3BsYXlpbmcgVmVyaWZpY2F0aW9u IFJlc3VsdHMgaW4gTVVBLi4uLi4uLi4uLi4uLi4uLi44DQ0KICAgNi4gRXhh bXBsZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uOQ0NCiAgICAgIDYuMSBNYWlsIFN1Ym1pc3Npb24u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkN DQogICAgICA2LjIgTWFpbCBGb3J3YXJkaW5nLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQ0KICAgICAgNi4zIE1haWwg TGlzdC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xMQ0NCiAgICAgIDYuNCBNb2JpbGUgVXNlci4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTINDQogICAg ICA2LjUgR3Vlc3QgRS1tYWlsIFNlcnZpY2UuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjEzDQ0KICAgICAgNi42IFNVQk1JVFRFUiBV c2VkIG9uIGEgTm9uLURlbGl2ZXJ5IFJlcG9ydC4uLi4uLi4uLi4uLi4uLi4u Li4xMw0NCiAgIDcuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQNDQogICAgICA3LjEg RE5TIEF0dGFja3MuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjE0DQ0KICAgICAgNy4yIFRDUCBBdHRhY2tzLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNA0N CiAgICAgIDcuMyBBZGRyZXNzIFNwYWNlIEhpamFja2luZy4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUNDQogICA4LiBJQU5BIENvbnNp ZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjE1DQ0KICAgOS4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNg0NCiAgICAg IDkuMSBOb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTYNDQogICAgICA5LjIgSW5mb3JtYXRpdmUg UmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjE2DQ0KICAgMTAuIEFja25vd2xlZGdtZW50cy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNw0NCiAgIDExLiBBdXRo b3JzJyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMTcNDQogICAxMi4gRnVsbCBDb3B5cmlnaHQgU3RhdGVt ZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4DQ0K DQ0KDQ0KTGVpYnpvbiAgICAgICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwg MjAwNSAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQ0KDQ0KICAgICAg ICAgIFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBvZiBhbiBFLW1haWwgTWVzc2Fn ZSAgICAgICAgT2N0b2JlciAyMDA0DQ0KDQ0KDQ0KMS4gSW50cm9kdWN0aW9u DQ0KDQ0KICAgVGhlIHByYWN0aWNlIG9mIGZhbHNpZnlpbmcgdGhlIGlkZW50 aXR5IG9mIHRoZSBzZW5kZXIgb2YgYW4gZS1tYWlsDQ0KICAgbWVzc2FnZSwg Y29tbW9ubHkgY2FsbGVkICJzcG9vZmluZyIsIGlzIGEgcHJldmFsZW50IHRh Y3RpYyB1c2VkIGJ5DQ0KICAgc2VuZGVycyBvZiB1bnNvbGljaXRlZCBjb21t ZXJjaWFsIGUtbWFpbCBvciAic3BhbSIuICBUaGlzIGZvcm0gb2YNDQogICBh YnVzZSBoYXMgaGlnaGxpZ2h0ZWQgdGhlIG5lZWQgdG8gaW1wcm92ZSBpZGVu dGlmaWNhdGlvbiBvZiB0aGUNDQogICAicmVzcG9uc2libGUgc3VibWl0dGVy IiBvZiBhbiBlLW1haWwgbWVzc2FnZS4NDQoNDQogICBUaGlzIGRvY3VtZW50 IHNvbHZlcyB0aGUgcHJvYmxlbSBieSBpbnRyb2R1Y2luZyBSZXNwb25zaWJs ZSBTdWJtaXR0ZXINDQogICBlbWFpbCBwYXJhbWV0ZXIgd2hpY2ggU01UUCBj bGllbnQgY2FuIHVzZSB0byBzcGVjaWZ5IGVtYWlsIGFkZHJlc3MgDQ0KICAg b2YgdGhlIGVudGl0eSBtb3N0IHJlY2VudGx5IHJlc3BvbnNpYmxlIGZvciBp bmplY3RpbmcgYSBtZXNzYWdlIGludG8NDQogICB0aGUgZS1tYWlsIHRyYW5z cG9ydCBzdHJlYW0uIA0NCg0NCiAgIFRoaXMgcGFyYW1ldGVyIGFuZCB2ZXJp ZmljYXRpb24gbWVjaGFuaXNtcyBvZiB0aGlzIGRvY3VtZW50IGFsbG93IG9u ZQ0NCiAgIHRvIGFuc3dlciB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uOg0NCg0N CiAgICAgICBXaGVuIGEgbWVzc2FnZSBpcyB0cmFuc2ZlcnJlZCB2aWEgU01U UCBiZXR3ZWVuIHR3byBVTlJFTEFURUQNDQogICAgICAgcGFydGllcywgZG9l cyB0aGUgU01UUCBjbGllbnQgaG9zdCBoYXZlIHBlcm1pc3Npb24gdG8gc2Vu ZCBtYWlsDQ0KICAgICAgIG9uIGJlaGFsZiBvZiB0aGUgbWFpbGJveCB0aGF0 IGFsbGVnZWRseSBjYXVzZWQgdGhlIG1vc3QgcmVjZW50DQ0KICAgICAgIGlu dHJvZHVjdGlvbiBvZiB0aGUgbWVzc2FnZSBpbnRvIHRoZSBtYWlsIGRlbGl2 ZXJ5IHN5c3RlbT8NDQoNDQogICBBcyBzZWVuIGZyb20gdGhlIHF1ZXN0aW9u LCB0aGlzIG1lY2hhbmlzbSBhcHBsaWVzIHRvIHVucmVsYXRlZA0NCiAgIHBh cnRpZXM6ICBpdCBpcyB1c2VmdWwgYXQgdGhlIHBvaW50IHdoZXJlIGEgbWVz c2FnZSBwYXNzZXMgYWNyb3NzIHRoZQ0NCiAgIEludGVybmV0IGZyb20gb25l IG9yZ2FuaXphdGlvbiB0byBhbm90aGVyLiAgSXQgaXMgYmV5b25kIHRoZSBz Y29wZSBvZg0NCiAgIHRoaXMgZG9jdW1lbnQgdG8gZGVzY3JpYmUgYXV0aGVu dGljYXRpb24gbWVjaGFuaXNtcyB0aGF0IGNhbiBiZQ0NCiAgIGRlcGxveWVk IHdpdGhpbiBhbiBvcmdhbml6YXRpb24uDQ0KDQ0KICAgVGhpcyBzcGVjaWZp Y2F0aW9uIHVzZXMgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBbU01UUF0gdG8g ZGVzY3JpYmUgYW4NDQogICBleHRlbnNpb24gdG8gdGhlIFNNVFAgcHJvdG9j b2wuIFVzaW5nIHRoaXMgZXh0ZW5zaW9uLCBhbiBTTVRQIGNsaWVudA0NCiAg IGNhbiBzcGVjaWZ5IHRoZSBlLW1haWwgYWRkcmVzcyBvZiB0aGUgZW50aXR5 IG1vc3QgcmVjZW50bHkgcmVzcG9uc2libGUNDQogICBmb3Igc3VibWl0dGlu ZyB0aGUgbWVzc2FnZSB0byB0aGUgU01UUCBjbGllbnQgaW4gYSBuZXcgU1VC TUlUVEVSDQ0KICAgcGFyYW1ldGVyIG9mIHRoZSBTTVRQIE1BSUwgY29tbWFu ZC4gIFNNVFAgc2VydmVycyBjYW4gdXNlIHRoaXMNDQogICBpbmZvcm1hdGlv biB0byB2ZXJpZnkgdGhhdCB0aGUgU01UUCBjbGllbnQgaXMgYXV0aG9yaXpl ZCB0byB0cmFuc21pdA0NCiAgIGUtbWFpbCBvbiBiZWhhbGYgb2YgdGhlIElu dGVybmV0IGRvbWFpbiBjb250YWluZWQgaW4gdGhlIFNVQk1JVFRFUg0NCiAg IHBhcmFtZXRlci4NDQoNDQogICBBcyBzcGVjaWZpZWQgYWJvdmUsIHRoZSB2 ZXJpZmljYXRpb24gbWVjaGFuaXNtcyBvZiB0aGlzIGRvY3VtZW50DQ0KICAg c2Vla3MgdG8gYXV0aGVudGljYXRlIHRoZSBtYWlsYm94IGFzc29jaWF0ZWQg d2l0aCB0aGUgTU9TVCBSRUNFTlQNDQogICBpbnRyb2R1Y3Rpb24gb2YgYSBt ZXNzYWdlIGludG8gdGhlIG1haWwgZGVsaXZlcnkgc3lzdGVtLiBJbiBzaW1w bGUNDQogICBjYXNlcywgdGhpcyBpcyB3aG8gdGhlIG1haWwgaXMgZnJvbS4g SG93ZXZlciwgaW4gdGhlIGNhc2Ugb2YgYQ0NCiAgIHRoaXJkLXBhcnR5IG1h aWxlciwgYSBmb3J3YXJkZXIgb3IgYSBtYWlsaW5nIGxpc3Qgc2VydmVyLCB0 aGUgYWRkcmVzcw0NCiAgIGJlaW5nIGF1dGhlbnRpY2F0ZWQgaXMgdGhhdCBv ZiB0aGUgdGhpcmQgcGFydHksIHRoZSBmb3J3YXJkZXIgb3IgdGhlDQ0KICAg bWFpbGluZyBsaXN0Lg0NCg0NCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMg bWVhbnMgdG8gYXV0aGVudGljYXRlIHRoZSBET01BSU4gb2YgdGhlDQ0KICAg YXBwcm9wcmlhdGUgZW1haWwgYWRkcmVzczsgaXQgaXMgbm90IGRpcmVjdGVk IGF0IHRoZSBsb2NhbC1wYXJ0LiANDQogICBBIGRvbWFpbiBvd25lciBnZXRz IHRvIGRldGVybWluZSB3aGljaCBTTVRQIGNsaWVudHMgc3BlYWsgb24gYmVo YWxmDQ0KICAgb2YgYWRkcmVzc2VzIHdpdGhpbiB0aGUgZG9tYWluOyBhIHJl c3BvbnNpYmxlIGRvbWFpbiBvd25lciBzaG91bGQgbm90DQ0KICAgYXV0aG9y aXplIFNNVFAgY2xpZW50cyB0aGF0IHdpbGwgbGllIGFib3V0IGxvY2FsIHBh cnRzLg0NCg0NCg0NCg0NCkxlaWJ6b24gICAgICAgICAgICAgICAgRXhwaXJl cyAtIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0N Cg0NCiAgICAgICAgICBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgb2YgYW4gRS1t YWlsIE1lc3NhZ2UgICAgICAgIE9jdG9iZXIgMjAwNA0NCg0NCg0NCjIuIFRo ZSBTVUJNSVRURVIgU2VydmljZSBFeHRlbnNpb24NDQoNDQogICBUaGUgZm9s bG93aW5nIFNNVFAgc2VydmljZSBleHRlbnNpb24gaXMgaGVyZWJ5IGRlZmlu ZWQ6DQ0KDQ0KICAgKDEpICBUaGUgbmFtZSBvZiB0aGlzIFNNVFAgc2Vydmlj ZSBleHRlbnNpb24gaXMgIlJlc3BvbnNpYmxlDQ0KICAgICAgICBTdWJtaXR0 ZXIiOw0NCg0NCiAgICgyKSAgVGhlIEVITE8ga2V5d29yZCB2YWx1ZSBhc3Nv Y2lhdGVkIHdpdGggdGhpcyBleHRlbnNpb24gaXMNDQogICAgICAgICJTVUJN SVRURVIiOw0NCg0NCiAgICgzKSAgVGhlIFNVQk1JVFRFUiBrZXl3b3JkIGhh cyBubyBwYXJhbWV0ZXJzOw0NCg0NCiAgICg0KSAgTm8gYWRkaXRpb25hbCBT TVRQIHZlcmJzIGFyZSBkZWZpbmVkIGJ5IHRoaXMgZXh0ZW5zaW9uOw0NCg0N CiAgICg1KSAgQW4gb3B0aW9uYWwgcGFyYW1ldGVyIGlzIGFkZGVkIHRvIHRo ZSBNQUlMIGNvbW1hbmQgdXNpbmcgdGhlDQ0KICAgICAgICBlc210cC1rZXl3 b3JkICJTVUJNSVRURVIiLCBhbmQgaXMgdXNlZCB0byBzcGVjaWZ5IHRoZSBl LW1haWwNDQogICAgICAgIGFkZHJlc3Mgb2YgdGhlIGVudGl0eSByZXNwb25z aWJsZSBmb3Igc3VibWl0dGluZyB0aGUgbWVzc2FnZSBmb3INDQogICAgICAg IGRlbGl2ZXJ5Ow0NCg0NCiAgICg2KSAgVGhpcyBleHRlbnNpb24gaXMgYXBw cm9wcmlhdGUgZm9yIHRoZSBzdWJtaXNzaW9uIHByb3RvY29sDQ0KICAgICAg ICBbU1VCTUlUXS4NDQoNDQoNDQozLiBUaGUgU1VCTUlUVEVSIEtleXdvcmQg b2YgdGhlIEVITE8gQ29tbWFuZA0NCg0NCiAgIEFuIFNNVFAgc2VydmVyIGlu Y2x1ZGVzIHRoZSBTVUJNSVRURVIga2V5d29yZCBpbiBpdHMgRUhMTyByZXNw b25zZSB0bw0NCiAgIHRlbGwgdGhlIFNNVFAgY2xpZW50IHRoYXQgdGhlIFNV Qk1JVFRFUiBzZXJ2aWNlIGV4dGVuc2lvbiBpcw0NCiAgIHN1cHBvcnRlZC4N DQoNDQogICBUaGUgU1VCTUlUVEVSIGtleXdvcmQgaGFzIG5vIHBhcmFtZXRl cnMuDQ0KDQ0KDQ0KNC4gVGhlIFNVQk1JVFRFUiBQYXJhbWV0ZXIgb2YgdGhl IE1BSUwgQ29tbWFuZA0NCg0NCiAgIFRoZSBzeW50YXggb2YgdGhlIFNVQk1J VFRFUiBwYXJhbWV0ZXIgaXM6DQ0KDQ0KICAgICAgIlNVQk1JVFRFUj0iIE1h aWxib3gNDQoNDQogICB3aGVyZSBNYWlsYm94IGlzIHRoZSBBQk5GIFtBQk5G XSBwcm9kdWN0aW9uIGRlZmluZWQgaW4gU2VjdGlvbiA0LjEuMg0NCiAgIG9m IFtTTVRQXS4gIENoYXJhY3RlcnMgc3VjaCBhcyBTUCwgIisiIGFuZCAiPSIg d2hpY2ggbWF5IG9jY3VyIGluDQ0KICAgTWFpbGJveCBidXQgYXJlIG5vdCBw ZXJtaXR0ZWQgaW4gRVNNVFAgcGFyYW1ldGVyIHZhbHVlcyBNVVNUIGJlDQ0K ICAgZW5jb2RlZCBhcyAieHRleHQiIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9u IDQgb2YgW0RTTl0uDQ0KDQ0KNC4xIFNldHRpbmcgdGhlIFNVQk1JVFRFUiBQ YXJhbWV0ZXIgVmFsdWUNDQoNDQogICBUaGUgcHVycG9zZSBvZiB0aGUgU1VC TUlUVEVSIHBhcmFtZXRlciBpcyB0byBhbGxvdyB0aGUgU01UUCBjbGllbnQg dG8NDQogICBpbmRpY2F0ZSB0byB0aGUgc2VydmVyIHRoZSBhZGRyZXNzIG9m IHRoZSBlbnRpdHkgbW9zdCByZWNlbnRseQ0NCiAgIHJlc3BvbnNpYmxlIGZv ciBpbmplY3RpbmcgYSBtZXNzYWdlIGludG8gdGhlIGUtbWFpbCB0cmFuc3Bv cnQgc3RyZWFtLg0NCg0NCiAgIEluIGNhc2Ugb2YgZW1haWwgc3VibWlzc2lv biBieSBlbmQtdXNlciB0aGlzIGFkZHJlc3MgY2FuIGJlIGZvdW5kIGluDQ0K ICAgIlNlbmRlcjoiIGhlYWRlciBzaW5jZSBSRkMyODIyIHNwZWNpZmllcyB0 aGF0IFNlbmRlciBoZWFkZXIgcmVwcmVzZW50cw0NCg0NCkxlaWJ6b24gICAg ICAgICAgICAgICAgRXhwaXJlcyAtIEFwcmlsIDIwMDUgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA0XQ0NCg0NCiAgICAgICAgICBSZXNwb25zaWJsZSBT dWJtaXR0ZXIgb2YgYW4gRS1tYWlsIE1lc3NhZ2UgICAgICAgIE9jdG9iZXIg MjAwNA0NCg0NCiAgICJhZ2VudCByZXNwb25zaWJsZSBmb3IgYWN0dWFsIHRy YW5zbWlzc2lvbiBvZiB0aGUgbWVzc2FnZSIgYW5kIGlmDQ0KICAgU2VuZGVy IGlzIG5vdCBwcmVzZW50IHRoZW4gcmVzcG9uc2libGUgcGFydHkgaXMgZW1h aWwgYXV0aG9yIGxpc3RlZA0NCiAgIGluICJGcm9tOiIgaGVhZGVyLiBJbiBj YXNlIG9mIGVtYWlsIGxpc3QsIHRoZSByZXNwb25zaWJsZSBwYXJ0eSBpcw0N CiAgIG1haWwgbGlzdCBhbmQgdGhlIGFkZHJlc3Mgc2hvdWxkIGJlIHRoYXQg b2YgZW1haWwgbGlzdCBpdHNlbGYuIEluDQ0KICAgY2FzZSBvZiBmb3J3YXJk aW5nIHNlcnZpY2UsIHRoZSBhZGRyZXNzIHNob3VsZCBiZSB0aGF0IG9mIHRo ZQ0NCiAgIGZvcndhcmRpbmcgYWdlbnQgb3IgdGhhdCBvZiBhIHVzZXIgb2Yg dGhhdCBmb3J3YXJkaW5nIGFnZW50LCB3aG9zZQ0NCiAgIHNldHRpbmdzIGNh dXNlZCBlbWFpbCByZXRyYW5zbWlzc2lvbi4NDQoNDQogICBTTVRQIHNlcnZl cnMgd2hpY2ggYXJlIGludm9sdmVkIGluIHJldHJhbnNtaXNzaW9uIG9mIHRo ZSBtZXNzYWdlIGJ1dA0NCiAgIHdoaWNoIGRvIG5vdCBjYXVzZSBjaGFuZ2Ug aW4gdGhlIGRpcmVjdGlvbiBvZiBTTVRQIHRyYW5zbWlzc2lvbg0NCiAgIFNI T1VMRCB1c2UgU1VCTUlUVEVSIHZhbHVlIHRoZXkgcmVjZWl2ZWQgZHVyaW5n IGluY29taW5nIFNNVFANDQogICB0cmFuc21pc3Npb24gYXMgdmFsdWUgZm9y IG91dGdvaW5nIFNNVFAgdHJhbnNtaXNzaW9uLiBJZiB0aGVyZSB3YXMNDQog ICBubyBTVUJNSVRURVIgTUFJTCBwYXJhbWV0ZXIgZHVyaW5nIGluY29taW5n IHRyYW5zbWlzc2lvbiwgdGhlbiBTTVRQDQ0KICAgc2VydmVyIE1VU1QgTk9U IHVzZSBTVUJNSVRURVIgZm9yIG91dGdvaW5nIHRyYW5zbWlzc2lvbiB1bmxl c3MgaXQNDQogICBjYW4gZmluZCBlbWFpbCBhZGRyZXNzIG9mIHRoZSBlbnRp dHkgd2hpY2ggbGFzdCBjYXVzZWQgaW50cm9kdWN0aW9uDQ0KICAgb2YgYSBt ZXNzYWdlIGludG8gdGhlIGVtYWlsIGRlbGl2ZXJ5IHN5c3RlbSBieSBvdGhl ciBtZWFucy4NDQoNDQogICBBbiBTTVRQIGNsaWVudCB0aGF0IHN1cHBvcnRz IHRoZSBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgZXh0ZW5zaW9uIGFuZA0NCiAg IHRoYXQgY2FuIHNldCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgdmFsdWUgTVVT VCBpbmNsdWRlIHRoZSBTVUJNSVRURVINDQogICBwYXJhbWV0ZXIgb24gYWxs IG1lc3NhZ2VzLiBUaGlzIGluY2x1ZGVzIG1lc3NhZ2VzIGNvbnRhaW5pbmcg YSBudWxsDQ0KICAgcmV2ZXJzZS1wYXRoIGluIHRoZSBNQUlMIGNvbW1hbmQu DQ0KDQ0KNC4yIFByb2Nlc3NpbmcgdGhlIFNVQk1JVFRFUiBQYXJhbWV0ZXIN DQoNDQogICBSZWNlaXZlcnMgb2YgZS1tYWlsIG1lc3NhZ2VzIHNlbnQgd2l0 aCB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciBTSE9VTEQNDQogICBwZXJmb3Jt IHN1Y2ggdGVzdHMsIGluY2x1ZGluZyB0aG9zZSBkZWZpbmVkIGluIHNlY3Rp b24gNSBvZiB0aGlzDQ0KICAgZG9jdW1lbnQsIGFzIGFyZSBkZWVtZWQgbmVj ZXNzYXJ5IHRvIGRldGVybWluZSB3aGV0aGVyIHRoZSBjb25uZWN0aW5nDQ0K ICAgU01UUCBjbGllbnQgaXMgYXV0aG9yaXplZCB0byB0cmFuc21pdCBlLW1h aWwgbWVzc2FnZXMgb24gYmVoYWxmIG9mIHRoZQ0NCiAgIGRvbWFpbiBwYXJ0 IG9mIHRoZSBTVUJNSVRURVIgYWRkcmVzcy4NDQoNDQogICBJZiB0aGVzZSB0 ZXN0cyBpbmRpY2F0ZSB0aGF0IHRoZSBjb25uZWN0aW5nIFNNVFAgY2xpZW50 IGlzIG5vdA0NCiAgIGF1dGhvcml6ZWQgdG8gdHJhbnNtaXQgZS1tYWlsIG1l c3NhZ2VzIG9uIGJlaGFsZiBvZiB0aGUgU1VCTUlUVEVSDQ0KICAgZG9tYWlu LCB0aGUgcmVjZWl2aW5nIFNNVFAgc2VydmVyIFNIT1VMRCByZWplY3QgdGhl IG1lc3NhZ2UgYW5kIHdoZW4NDQogICByZWplY3RpbmcgTVVTVCB1c2UgIjU1 MCA1LjcuMSBTdWJtaXR0ZXIgbm90IGFsbG93ZWQuIg0NCg0NCiAgIE5vdGUg dGhhdCB0aGUgcHJlc2VuY2Ugb2YgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIg b24gdGhlIE1BSUwgY29tbWFuZA0NCiAgIE1VU1QgTk9UIGNoYW5nZSB0aGUg ZWZmZWN0aXZlIHJldmVyc2UtcGF0aCBvZiBhIG1lc3NhZ2UuICBBbnkNDQog ICBkZWxpdmVyeSBzdGF0dXMgbm90aWZpY2F0aW9ucyBtdXN0IGJlIHNlbnQg dG8gdGhlIHJldmVyc2UtcGF0aCwgaWYNDQogICBvbmUgZXhpc3RzLCBhcyBw ZXIgc2VjdGlvbiAzLjcgb2YgW1NNVFBdIHJlZ2FyZGxlc3Mgb2YgdGhlIHBy ZXNlbmNlDQ0KICAgb2YgYSBTVUJNSVRURVIgcGFyYW1ldGVyLiAgSWYgdGhl IHJldmVyc2UtcGF0aCBpcyBudWxsLCBkZWxpdmVyeQ0NCiAgIHN0YXR1cyBu b3RpZmljYXRpb25zIE1VU1QgTk9UIGJlIHNlbnQgdG8gdGhlIFNVQk1JVFRF UiBhZGRyZXNzLg0NCg0NCg0NCjUuIEF1dGhvcml6aW5nIFVzZSBvZiBSZXNw b25zaWJsZSBTdWJtaXR0ZXIgQWRkcmVzcw0NCg0NCiAgIFJlc3BvbnNpYmxl IFN1Ym1pdHRlciBwcm92aWRlcyBpbmZvcm1hdGlvbiByZWdhcmRpbmcgcGFy dHkgbW9zdCANDQogICByZWNlbnRseSByZXNwb25zaWJsZSBmb3IgaW50cm9k dWN0aW9uIG9mIHRoZSBtZXNzYWdlIGludG8gZW1haWwNDQogICB0cmFuc3Bv cnQgc3RyZWFtLiBXaGVuIHN1Y2ggaW5mb3JtYXRpb24gaXMgdHJhbnNtaXR0 ZWQgdG8gYW4gU01UUA0NCiAgIHNlcnZlciBvZiBkaWZmZXJlbnQgb3JnYW5p emF0aW9uLCB0byBiZSBhYmxlIHRvIHJlbHkgb24gdGhpcw0NCiAgIGluZm9y bWF0aW9uLCB0aGVyZSBuZWVkcyBhIHdheSB0aGF0IHN1Y2ggc2VydmVyIGNh biBjb25maXJtIHRoYXQNDQogICBhZGRyZXNzIHVzZWQgZG9lcyBpbmRlZWQg YmVsb25nIHRvIHRoZSBwYXJ0eSB0aGF0IGlzIGFmZmlsaWF0ZWQNDQogICB3 aXRoIG1vc3QgcmVjZW50IGludHJvZHVjdGlvbiBvZiB0aGUgbWVzc2FnZS4g U3VjaCBhZmZpbGlhdGlvbg0NCg0NCkxlaWJ6b24gICAgICAgICAgICAgICAg RXhwaXJlcyAtIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgICAgICBbUGFn ZSA1XQ0NCg0NCiAgICAgICAgICBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgb2Yg YW4gRS1tYWlsIE1lc3NhZ2UgICAgICAgIE9jdG9iZXIgMjAwNA0NCg0NCiAg IGNhbiBiZSBjb25maXJtZWQgYnkgbWVhbnMgb2YgdGhlIFNQRiBkbnMgbG9v a3VwIG9uIHRoZSBkb21haW4gcGFydA0NCiAgIG9mIHRoZSBSZXNwb25zaWJs ZSBTdWJtaXR0ZXIgZW1haWwgYWRkcmVzcyBhcyBmb3VuZCBpbiBTVUJNSVRU RVINDQogICBwYXJhbWV0ZXIuIFNQRiBwcm90b2NvbCBbU1BGLVBST1RPQ09M XSBkZXNjcmliZXMgYSBzeXN0ZW0gdGhhdA0NCiAgIGFsbG93cyBkb21haW4g b3duZXIgdG8gcHVibGlzaCBlbWFpbCBwb2xpY3kgcmVjb3JkcyB0aGF0IGNh biBiZSB1c2VkDQ0KICAgdG8gY29uZmlybSBzdWNoIGFmZmlsaWF0aW9uIGFu ZCBjb25maXJtIGlmIFNNVFAgQ2xpZW50IGlzIGFsbG93ZWQgdG8NDQogICB1 c2UgZ2l2ZW4gZG9tYWluIGFzIHBhcnQgb2YgaXRzIGVtYWlsIHRyYW5zbWlz c2lvbiBwYXJhbWV0ZXJzLiANDQoNDQoNDQo1LjEgUHVibGlzaGluZyBETlMg QXV0aG9yaXphdGlvbiBSZWNvcmRzDQ0KICANDQogICBEb21haW5zIHRoYXQg YXJlIHVzZWQgYXMgcGFydCBvZiB0aGUgUmVzcG9uc2libGUgU3VibWl0dGVy IGFkZHJlc3MNDQogICBTSE9VTEQgcHVibGlzaCBTUEYgRE5TIEF1dGhvcml6 YXRpb24gcmVjb3JkcyB0aGF0IGFsbG93IHRvIHZlcmlmeSANDQogICBpcCBh ZGRyZXNzZXMgb2YgaG9zdHMgdGhhdCBhcmUgYXV0aG9yaXplZCB0byB1c2Ug Z2l2ZW4gZG9tYWluIHdoZW4NDQogICBzZXR0aW5nIFNVQk1JVFRFUiBwYXJh bWV0ZXIuIFNQRiByZWNvcmRzIHVzZWQgZm9yIHB1Ymxpc2hpbmcgdGhpcw0N CiAgIGluZm9ybWF0aW9uIE1VU1QgdXNlICJzdWJtaXQiIHNjb3BlIGlkZW50 aWZpZXIuDQ0KDQ0KICAgRG9tYWlucyBTSE9VTEQgcHVibGlzaCBTUEYgcmVj b3JkcyB0aGF0IGVuZCBpbiAiLWFsbCIgb3IgcmVkaXJlY3QNDQogICB0byBv dGhlciByZWNvcmRzIHRoYXQgZG8sIHNvIHRoYXQgYSBkZWZpbml0aXZlIGRl dGVybWluYXRpb24gb2YNDQogICBhdXRob3JpemF0aW9uIGNhbiBiZSBtYWRl Lg0NCg0NCiAgIEFuIGV4YW1wbGUgb2YgU1BGIGF1dGhvcml6YXRpb24gcmVj b3JkIGZvciBkb21haW4gZXhhbXBsZS5jb20gdGhhdA0NCiAgIGFsbG93cyB0 byB1c2UgdGhpcyBkb21haW4gaW4gUmVzcG9uc2libGUgU3VibWl0dGVyIGVt YWlsIGFkZHJlc3MgYnkNDQogICBhbGwgc2VydmVycyBhbmQgY2xpZW50cyBs b2NhdGVkIGluIDE5Mi4xNjguMC4wLzE2IGlwIGJsb2NrIGlzOg0NCiAgICAg ZXhhbXBsZS5jb20uCSBJTiAgU1BGICAiU1BGMi4wL3N1Ym1pdCAraXA0OjE5 Mi4xNjguMC4wLzE2IC1hbGwiDQ0KDQ0KDQ0KNS4yIENoZWNraW5nIEROUyBB dXRob3JpemF0aW9uIFJlY29yZHMNDQoNDQogICBGb3IgYW4gU01UUCBTZXJ2 ZXIgdG8gdGVzdCBhdXRob3JpemF0aW9uIG9mIFNNVFAgQ2xpZW50IHRvIHVz ZQ0NCiAgIGNlcnRhaW4gZG9tYWluIGFzIHBhcnQgb2YgdGhlIFNVQk1JVFRF UiBwYXJhbWV0ZXIsIHRoZSBTTVRQIFNlcnZlcg0NCiAgIE1VU1QgZXZhbHVh dGUgdGhlIHJlc3VsdHMgb2YgY2hlY2tfaG9zdCgpIGZ1bmN0aW9uIGFzIGRl ZmluZWQgaW4NDQogICBbU1BGLVBST1RPQ09MXSB3aXRoIGFyZ3VtZW50cyBh cyBmb2xsb3dzOg0NCg0NCiAgICAgICA8c2NvcGU+ICAgLSB0aGUgInN1Ym1p dCIgc2NvcGUgaWRlbnRpZmllcg0NCiAgICAgICA8aXA+ICAgICAgLSB0aGUg aXAgYWRkcmVzcyBvZiB0aGUgU01UUCBjbGllbnQgaG9zdA0NCiAgICAgICA8 ZG9tYWluPiAgLSB0aGUgZG9tYWluIHBvcnRpb24gb2YgdGhlIFNVQk1JVFRF UiBwYXJhbWV0ZXINDQoJIDxzZW5kZXI+ICAtIHRoZSBmdWxsIGVtYWlsIGFk ZHJlc3MgaW4gU1VCTUlUVEVSIHBhcmFtZXRlcg0NCg0NCiAgIElmIFNNVFAg Q2xpZW50IHByb3ZpZGVkIFNVQk1JVFRFUiBhcmd1bWVudCB0byBNQUlMIGNv bW1hbmQgdGhlbiBTTVRQDQ0KICAgQ2xpZW50IFNIT1VMRCBwZXJmb3JtIGF1 dGhvcml6YXRpb24gY2hlY2sgZHVyaW5nIHRoZSB0aW1lIG9mIFNNVFANDQog ICB0cmFuc2FjdGlvbi4gVGhlIGNoZWNrIGNhbiBiZSBwZXJmb3JtZWQgZGly ZWN0bHkgYXQgdGhlIHRpbWUgb2YgTUFJTA0NCiAgIGNvbW1hbmQgb3IgaXQg bWF5YmUgZWFzaWVyIHRvIGRlbGF5IHRoZSBjaGVjayB0byBsYXRlciBzdGFn ZSBvZiBTTVRQDQ0KICAgdHJhbnNtaXNzaW9uLg0NCg0NCg0NCjUuMyBJbnRl cnByZXRpbmcgdGhlIFJlc3VsdHMgb2YgU1BGIFZlcmlmaWNhdGlvbg0NCg0N CiAgIFRoZSBjaGVja19ob3N0KCkgZnVuY3Rpb24gb2YgU1BGIHZlcmlmaWNh dGlvbiBjYW4gcmV0dXJuIG9uZSBvZg0NCiAgIHNldmVuIHJlc3VsdCBhcyBh IG91dGNvbWUgb2YgdmVyaWZpY2F0aW9uIGF0dGVtcHQgYW5kIG1heSBhbHNv DQ0KICAgcmV0dXJuIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gKHN1Y2ggYXMg ImV4cGxhbmF0aW9uIHN0cmluZyIpLg0NCiAgIFRoaXMgc2VjdGlvbiBkZXNj cmliZXMgaG93IHNvZnR3YXJlIHBlcmZvcm1pbmcgYXV0aG9yaXphdGlvbg0N CiAgIHNob3VsZCBpbnRlcnByZXQgdGhlc2UgcmVzdWx0cy4NDQoNDQpMZWli em9uICAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNl0NDQoNDQogICAgICAgICAgUmVzcG9u c2libGUgU3VibWl0dGVyIG9mIGFuIEUtbWFpbCBNZXNzYWdlICAgICAgICBP Y3RvYmVyIDIwMDQNDQoNDQo1LjMuMSAgTm9uZQ0NCg0NCiAgIFRoaXMgaXMg YSByZXN1bHQgaWYgbm8gU1BGIHJlY29yZHMgZm9yICJzdWJtaXQiIHNjb3Bl IHdlcmUgcHVibGlzaGVkDQ0KICAgZm9yIGRvbWFpbi4gTm8gY29uY2x1c2lv biBjYW4gYmUgbWFkZSBpZiBTTVRQIENsaWVudCBpcyBhdXRob3JpemVkDQ0K ICAgb3Igbm90LiBBbiBTTVRQIHNlcnZlciByZWNlaXZpbmcgb25lIG9mIHRo ZXNlIHJlc3VsdHMgU0hPVUxEIE5PVCByZWplY3QNDQogICB0aGUgbWVzc2Fn ZSBmb3IgdGhpcyByZWFzb24gYWxvbmUsIGJ1dCBNQVkgc3ViamVjdCB0aGUg bWVzc2FnZSB0bw0NCiAgIGhlaWdodGVuZWQgc2NydXRpbnkgYnkgb3RoZXIg ZW1haWwgc2VjdXJpdHkgbWVhc3VyZXMsIGFuZCBNQVkgcmVqZWN0DQ0KICAg dGhlIG1lc3NhZ2UgYXMgYSByZXN1bHQgb2YgdGhpcyBoZWlnaHRlbmVkIHNj cnV0aW55Lg0NCg0NCjUuMy4yICBOZXV0cmFsDQ0KDQ0KICAgVGhlIE5ldXRy YWwgcmVzdWx0IE1VU1QgYmUgdHJlYXRlZCBleGFjdGx5IGxpa2UgYSBOb25l IHJlc3VsdC4NDQoNDQo1LjMuMiAgUGFzcw0NCg0NCiAgIEEgUGFzcyByZXN1 bHQgbWVhbnMgdGhlIGNsaWVudCBpcyBhdXRob3JpemVkIHRvIHVzZSB0aGUg ZG9tYWluIGFzIHBhcnQNDQogICBvZiBSZXNwb25zaWJsZSBTdWJtaXR0ZXIg YWRkcmVzcy4gQW4gU01UUCBzZXJ2ZXIgcmVjZWl2aW5nIHRoaXMgcmVzdWx0 DQ0KICAgU0hPVUxEIHRyZWF0IHRoZSBtZXNzYWdlIGFzIGF1dGhlbnRpYywg YnV0IG1heSBzdGlsbCB3YW50IHRvIHRlc3Qgb3RoZXINDQogICBwYXJhbWV0 ZXJzIG9mIGVtYWlsIG1lc3NhZ2UgYW5kIG1heSBhY2NlcHQgb3IgcmVqZWN0 IHRoZSBtZXNzYWdlDQ0KICAgZGVwZW5kaW5nIG9uIHJlc3VsdHMgb2YgdGhl c2UgdGVzdHMgYW5kIGJhc2VkIG9uIG90aGVyIHBvbGljaWVzDQ0KDQ0KNS4z LjQgIEZhaWwNDQoNDQogICBBIEZhaWwgcmVzdWx0IG1lYW5zIHRoZSBjbGll bnQgSVMgTk9UIGF1dGhvcml6ZWQgdG8gdXNlIHRoZSBkb21haW4NDQogICBh cyBwYXJ0IG9mIFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBBZGRyZXNzLiBBbiBT TVRQIHNlcnZlciByZWNlaXZpbmcNDQogICB0aGlzIHJlc3VsdCBTSE9VTEQg Tk9UIGFjY2VwdCBlbWFpbCBhbmQgd2hlbiBkb2luZyBzbyBNVVNUIHVzZSA1 NTANDQogICByZXBseSBjb2RlIHRvIGluZGljYXRlIHRoYXQgZW1haWwgaXMg cmVqZWN0ZWQgKHNlZSBzZWN0aW9uIDQuMiBvZg0NCiAgIHRoaXMgZG9jdW1l bnQpLg0NCg0NCiAgIE5vdGUgdGhhdCBTUEYgY2hlY2sgbWF5IHByb3ZpZGUg YW4gImV4cGxhbmF0aW9uIHN0cmluZyIgYXMgcGFydCBvZg0NCiAgIGl0cyBy ZXN1bHQgYW5kIHN1Y2ggc3RyaW5nIG1heSBjb250YWluIGEgVVJMLiBUaGlz IGV4cGxhbmF0aW9uIGNvbWVzDQ0KICAgZnJvbSB0aGUgZG9tYWluIHRoYXQg cHVibGlzaGVkIFNQRiByZWNvcmQgYW5kIGlmIFNNVFAgU2VydmVyIHdhbnRz DQ0KICAgdXNlIHRoaXMgZXhwbGFuYXRpb24gc3RyaW5nIHdoZW4gY29uc3Ry dWN0aW5nIDU1MCByZWplY3Rpb24gbWVzc2FnZSwNDQogICB0aGVuIFNNVFAg U2VydmVyIG11c3QgY2F1dGlvbiB0aGUgdXNlciB0aGF0IHRoaXMgdGV4dCBp cyBub3QgdHJ1c3RlZC4NDQoNDQogICBFeGFtcGxlIG9mIHJlcGx5IG1lc3Nh Z2Ugd2hlbiBTUEYgYXV0aG9yaXphdGlvbiBmYWlsZWQgaXMgYXMgZm9sbG93 czoNDQoNDQogICAgICA1NTAtNS43LjEgU3VibWl0dGVyIG5vdCBhbGxvd2Vk IC0gU1BGIHZlcmlmaWNhdGlvbiBmYWlsZWQNDQogICAgICA1NTAtVGhlIGRv bWFpbiBleGFtcGxlLmNvbSBzYWlkOg0NCgk1NTAgUGxlYXNlIHNlZSBodHRw Oi8vd3d3LmV4YW1wbGUuY29tL21haWxwb2xpY3kuaHRtbA0NCg0NCjUuMy41 ICBTb2Z0RmFpbA0NCg0NCiAgICBBIHJlc3VsdCBvZiBTb2Z0RmFpbCBzaG91 bGQgYmUgdHJlYXRlZCBhcyBzb21ld2hlcmUgYmV0d2VlbiBGYWlsIGFuZA0N CiAgICBOZXV0cmFsLiBUaGlzIHZhbHVlIGlzIHVzZWQgYnkgZG9tYWlucyBh cyBpbnRlcm1lZGlhdGUgc3RhdGUgZHVyaW5nDQ0KICAgIHJvbGwtb3V0IG9m IHB1Ymxpc2hpbmcgcmVjb3Jkcy4gVGhlIGRvbWFpbiBiZWxpZXZlcyB0aGUg aG9zdCBpc24ndA0NCiAgICBhdXRob3JpemVkIGJ1dCBpcyBub3Qgd2lsbGlu ZyB0byBtYWtlIHRoYXQgc3Ryb25nIG9mIGEgc3RhdGVtZW50Lg0NCiAgICBT TVRQIFNlcnZlcnMgU0hPVUxEIE5PVCByZWplY3QgdGhlIG1lc3NhZ2UgYmFz ZWQgb24gdGhpcyByZXN1bHQgYWxvbmUNDQogICAgYnV0IE1BWSBzdWJqZWN0 IHRoZSBtZXNzYWdlIHRvIGNsb3NlciBzY3J1dGlueSBhbmQgcnVuIG90aGVy IHRlc3RzDQ0KICAgIHRvIHZlcmlmeSBtZXNzYWdlIHRyYW5zbWlzc2lvbiBp cyBhdXRob3JpemVkIGFuZCBNQVkgcmVqZWN0IHRoZSANDQogICAgbWVzc2Fn ZSBkZXBlbmRpbmcgb24gcmVzdWx0cyBvZiB0aGVzZSB0ZXN0cyBhbmQgYmFz ZWQgb24gb3RoZXINDQogICAgcG9saWNpZXMuDQ0KDQ0KTGVpYnpvbiAgICAg ICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDddDQ0KDQ0KICAgICAgICAgIFJlc3BvbnNpYmxlIFN1 Ym1pdHRlciBvZiBhbiBFLW1haWwgTWVzc2FnZSAgICAgICAgT2N0b2JlciAy MDA0DQ0KDQ0KNS4zLjYgIFRlbXBFcnJvcg0NCg0NCiAgICBBIHJlc3VsdCBv ZiBUZW1wRXJyb3IgbWVhbnMgdGhhdCB0aGVyZSB3YXMgZW5jb3VudGVyZWQg dHJhbnNpZW50DQ0KICAgIGVycm9yIHdoaWxlIHBlcmZvcm1pbmcgdGhlIGNo ZWNrLiBTTVRQIFNlcnZlciBjYW4gY2hvb3NlIHRvIGFjY2VwdA0NCiAgICBv ciB0ZW1wb3JhcmlseSByZWplY3QgdGhlIG1lc3NhZ2UuIElmIHRoZSBzZXJ2 ZXIgY2hvb3NlcyB0byBhY2NlcHQNDQogICAgdGhlIG1lc3NhZ2UsIGl0IG11 c3QgdHJlYXQgaXQgYXMgaWYgdGhlIHJlc3VsdCB3YXMgTm9uZS4gSWYgdGhl DQ0KICAgIFNNVFAgc2VydmVyIGlzIHJlamVjdGluZyB0aGUgbWVzc2FnZSB0 aGVuIGl0IE1VU1QgdXNlIHJlcGx5IGNvZGUNDQogICAgb2YgNDUwIHRvIGlu ZGljYXRlIHRlbXBvcmFyeSBlcnJvci4NDQoNDQo1LjMuNyAgUGVybUVycm9y DQ0KDQ0KICAgIEEgcmVzdWx0IG9mIFBlcm1FcnJvciBtZWFucyB0aGF0IGRv bWFpbidzIHB1Ymxpc2hlZCByZWNvcmRzIGNvdWxkDQ0KICAgIG5vdCBiZSBj b3JyZWN0bHkgaW50ZXJwcmV0ZWQuIFNNVFAgU2VydmVyIG1heSBjaG9vc2Ug dG8gcmVqZWN0IHRoZQ0NCiAgICBtZXNzYWdlIHdpdGggNTUwIHJlcGx5IGNv ZGUgb3IgbWF5IGNob29zZSB0byBhY2NlcHQgdGhlIG1lc3NhZ2UNDQogICAg YmFzZWQgb24gaXRzIHBvbGljaWVzIGFuZCBiYXNlZCBvbiB2ZXJpZmljYXRp b24gb2Ygb3RoZXIgcGFyYW1ldGVycw0NCiAgICBvZiB0aGUgbWVzc2FnZS4g VGhpcyByZXN1bHQgc2hvdWxkIGJlIHRyZWF0ZWQgc2ltaWxhciB0byBTb2Z0 RmFpbA0NCiAgICBidXQgaXQgaXMgYWNjZXB0YWJsZSB0byByZWplY3QgdGhl IG1lc3NhZ2UgYmFzZWQgb24gdGhpcyByZXN1bHQNDQogICAgYWxvbmcgaWYg bm8gb3RoZXIgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZSBtZXNzYWdlIGNh biBiZSB2ZXJpZmllZC4NDQoNDQoNDQo1LjQuIFNhdmluZyBWZXJpZmljYXRp b24gUmVzdWx0cw0NCg0NCiAgIEluIG9yZGVyIHRvIHByZXNlcnZlIHJlc3Vs dHMgb2YgU1BGIHZlcmlmaWNhdGlvbiBhbmQgdGhlIHZhbHVlIG9mDQ0KICAg UmVzcG9uc2libGUgU3VibWl0dGVyIGF0IHRoZSB0aW1lIG9mIHZlcmlmaWNh dGlvbiwgU01UUCBzZXJ2ZXJzIA0NCiAgIFNIT1VMRCBhZGQgQXV0aGVudGlj YXRpb24tUmVzdWx0cyBoZWFkZXIgYXMgZGVmaW5lZCBpbiBbQVVUSC1TVEFU VVNdLiANDQoNDQogICBJbiBBdXRoZW50aWNhdGlvbi1SZXN1bHRzIGhlYWRl ciwgdGhlIGF1dGhlbnRpY2F0aW9uIHR5cGUgaXMgU1BGIHdpdGgNDQogICBT UEYgYXV0aGVudGljYXRpb24gbWV0aG9kICJzcGYvc3VibWl0Ii4gVGhlIHZh bHVlIG9mIFNVQk1JVFRFUiBzaG91bGQNDQogICBiZSBhZGRlZCB0byB0aGUg bGlzdCBvZiBpZGVudGl0eSBoZWFkZXJzICh0aGV5IGZvbGxvdyB0aGUgbmFt ZSBvZiB0aGUNDQogICBzeXN0ZW0gZG9pbmcgYXV0aGVudGljYXRpb24pIGFz IGhlYWRlciAiZW52ZWxvcGUtc3VibWl0dGVyIi4gVGhlIHNhbWUNDQogICBh ZGRyZXNzIHNob3VsZCBhbHNvIGJlIGVudGVyZWQgaW4gdGhlIGNvbW1lbnRh cnkgcGFydCBvZiAic3BmL3N1Ym1pdCINDQogICBhcyBpbmZvcm1hdGlvbiBw YXJhbWV0ZXIgImF1dGgtbmFtZSIuDQ0KDQ0KICAgRXhhbXBsZSBvZiBBdXRo ZW50aWNhdGlvbi1SZXN1bHRzIGhlYWRlciBpcyBhcyBmb2xsb3dzOg0NCg0N CglBdXRoZW50aWNhdGlvbi1SZXN1bHRzOiAgdGVzdC1zeXN0ZW0uZXhhbXBs ZS5jb20gDQ0KICAgICAgICBmcm9tPXVzZXJAZXhhbXBsZS5jb20gZW52ZWxv cGUtc3VibWl0dGVyPXVzZXJAZXhhbXBsZS5jb20gOw0NCiAgICAgICAgU1BG PXBhc3MgKGF1dGgtaXA9MTAuMC4wLjEwDQ0KICAgICAgICAgIFNQRi9zdWJt aXQ9cGFzcyAoYXV0aC1uYW1lPXVzZXJAZXhhbXBsZS5jb20pKQ0NCg0NCjUu NC4xIERpc3BsYXlpbmcgVmVyaWZpY2F0aW9uIFJlc3VsdHMgaW4gTVVBDQ0K DQ0KICAgV2hlbiBkaXNwbGF5aW5nIGEgcmVjZWl2ZWQgbWVzc2FnZSwgYW4g TVVBIFNIT1VMRCBjaGVjayBtZXNzYWdlIGZvcg0NCiAgIEF1dGhlbnRpY2F0 aW9uLVJlc3VsdHMgaGVhZGVycyBhbmQgaWYgbGFzdCBlbnRlcmVkIHN1Y2gg aGVhZGVyIGlzDQ0KICAgcHJvY2VlZGVkIG9ubHkgYnkgUmVjZWl2ZWQgYW5k IFJldHVybi1QYXRoIHRyYWNlIGhlYWRlcnMgd2hpY2ggYXBwZWFyDQ0KICAg dG8gaGF2ZSBiZWVuIGFkZGVkIGJ5IE1EQSBvciBieSBvdGhlciBNVEFzIHdo aWNoIGFyZSBrbm93biB0byBiZSBvbg0NCiAgIHRoZSBzYW1lIG5ldHdvcmsg YXMgTVVBLCB0aGVuIE1VQSBzaG91bGQgZGlzcGxheSB0aGUgdmFsdWUgb2YN DQogICBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgYXMgZm91bmQgaW4gImVudmVs b3BlLXN1Ym1pdHRlciIgYXMgd2VsbCBhcw0NCiAgIGRpc3BsYXkgdG8gdGhl IHVzZXIgdGhlIHJlc3VsdHMgb2YgU1BGIHZlcmlmaWNhdGlvbi4gDQ0KDQ0K ICAgSWYgZW1haWwgYWRkcmVzcyBvZiBSZXNwb25zaWJsZSBTdWJtaXR0ZXIg aXMgdGhlIHNhbWUgYXMgYWRkcmVzcyBpbg0NCiAgIG9uZSBvZiB0aGUgIkZy b206IiBoZWFkZXJzLCB0aGVuIE1VQSBzaG91bGQgc2hvdyB0aGF0IGVtYWls IGFkZHJlc3MgDQ0KICAgDQ0KTGVpYnpvbiAgICAgICAgICAgICAgICBFeHBp cmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhd DQ0KDQ0KICAgICAgICAgIFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBvZiBhbiBF LW1haWwgTWVzc2FnZSAgICAgICAgT2N0b2JlciAyMDA0DQ0KICAgDQ0KICAg YXMgZW1haWwgb3JpZ2luIGFuZCBpbmRpY2F0ZSBieSBzb21lIG1lYW5zIHRo YXQgaXQgaGFzIGJlZW4gU1BGLQ0NCiAgIHZlcmlmaWVkIGJhc2VkIG9uIHN1 Ym1pdHRlciBpZGVudGl0eS4gSWYgaGVhZGVyICJGcm9tOiIgYWRkcmVzcyBp cw0NCiAgIG5vdCB0aGUgc2FtZSwgdGhlbiBvcmlnaW4gb2YgdGhlIGVtYWls IHNob3VsZCBiZSBpbmRpY2F0ZWQgYXMgYmVpbmcNDQogICB0aGF0IG9mIFJl c3BvbnNpYmxlIFN1Ym1pdHRlciB3aXRoIGVtYWlsIGxpc3RlZCBhcyBoYXZp bmcgYmVlbiBzZW50DQ0KICAgb24gYmVoYWxmIG9mIHRoZSBwYXJ0eSBsaXN0 ZWQgaW4gIkZyb206IiBoZWFkZXIuIEl0IHNob3VsZCBiZSBtYWRlDQ0KICAg Y2xlYXIgdGhhdCBvbmx5IFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBwYXJ0IG9m IHRoZSBlbWFpbCBvcmlnaW4gaGFzDQ0KICAgYmVlbiBTUEYtdmVyaWZpZWQg YW5kIG5vdCB0aGUgaGVhZGVyICJGcm9tOiIgYWRkcmVzcyBwYXJ0Lg0NCg0N CiAgIE1VQSBtYXkgYWxzbyB3YW50IHRvIGZpbmQgZW52ZWxvcGUtc3VibWl0 dGVyIHZhbHVlcyBmcm9tIGFsbA0NCiAgICJBdXRoZW50aWNhdGlvbi1SZXN1 bHRzOiIgaGVhZGVycyBhcyB3ZWxsIGFzICJTZW5kZXI6IiBhbmQgYWxsDQ0K ICAgIkZyb206IiBoZWFkZXJzIGFuZCBkaXNwbGF5IHRoZW0gYXMgYWRkcmVz c2VzIHJlc3BvbnNpYmxlIGZvcg0NCiAgIHRyYW5zbWlzc2lvbiBvZiB0aGUg bWVzc2FnZS4NDQoNDQoNDQo2LiBFeGFtcGxlcw0NCg0NCiAgIFRoaXMgc2Vj dGlvbiBwcm92aWRlcyBleGFtcGxlcyBvZiBob3cgdGhlIFNVQk1JVFRFUiBw YXJhbWV0ZXIgd291bGQNDQogICBiZSB1c2VkLiAgVGhlIGZvbGxvd2luZyBk cmFtYXRpcyBwZXJzb25hZSBhcHBlYXIgaW4gdGhlIGV4YW1wbGVzOg0NCg0N CiAgIGFsaWNlQGV4YW1wbGUuY29tOiAgICAgICAgIHRoZSBvcmlnaW5hbCBz ZW5kZXIgb2YgZWFjaCBlLW1haWwgbWVzc2FnZQ0NCg0NCiAgIGJvYkBjb21w YW55LmNvbS5leGFtcGxlOiAgIHRoZSBmaW5hbCByZWNpcGllbnQgb2YgZWFj aCBlLW1haWwNDQoNDQogICBib2JAYWxtYW1hdGVyLmVkdS5leGFtcGxlOiBh biBlbWFpbCBhZGRyZXNzIHVzZWQgYnkgQm9iIHdoaWNoIGhlIGhhcw0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbmZpZ3VyZWQgdG8gZm9y d2FyZCBtYWlsIHRvIGhpcyBvZmZpY2UNDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBhY2NvdW50IGF0IGJvYkBjb21wYW55LmNvbS5leGFtcGxl DQ0KDQ0KICAgYWxpY2VAbW9iaWxlLm5ldC5leGFtcGxlOiAgYW4gZS1tYWls IGFjY291bnQgcHJvdmlkZWQgdG8gQWxpY2UgYnkgaGVyDQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgbW9iaWxlIGUtbWFpbCBuZXR3b3JrIGNh cnJpZXINDQoNDQogICBsaXN0QG1haWxsaXN0Lm9yZy5leGFtcGxlOiBhIG1h aWwgbGlzdCB3aGljaCBib3RoIEJvYiBhbmQgQWxpY2UNDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhcmUgc3Vic2NyaWJlZCB0bw0NCg0NCg0N CjYuMSBNYWlsIFN1Ym1pc3Npb24NDQoNDQogICBVbmRlciBub3JtYWwgY2ly Y3Vtc3RhbmNlcywgQWxpY2Ugd291bGQgY29uZmlndXJlIGhlciBNVUEgdG8g c3VibWl0DQ0KICAgaGVyIG1lc3NhZ2UgdG8gdGhlIG1haWwgc3lzdGVtIHVz aW5nIHRoZSBTVUJNSVQgcHJvdG9jb2wgW1NVQk1JVF0uDQ0KICAgVGhlIE1V QSB3b3VsZCB0cmFuc21pdCB0aGUgbWVzc2FnZSB3aXRob3V0IHRoZSBTVUJN SVRURVIgcGFyYW1ldGVyLg0NCiAgIFRoZSBTVUJNSVQgc2VydmVyIHdvdWxk IHZhbGlkYXRlIHRoYXQgdGhlIE1VQSBpcyBhbGxvd2VkIHRvIHN1Ym1pdCBh DQ0KICAgbWVzc2FnZSB0aHJvdWdoIHNvbWUgZXh0ZXJuYWwgc2NoZW1lLCBw ZXJoYXBzIFNNVFAgQXV0aGVudGljYXRpb24NDQogICBbU01UUEFVVEhdLiAg VGhlIFNVQk1JVCBzZXJ2ZXIgd291bGQgdGhlbiBleHRyYWN0IGhlciBhZGRy ZXNzIGZyb20gdGhlDQ0KICAgUkZDIDI4MjIgaGVhZGVyICJTZW5kZXIiIG9y IGlmIGl0IG1pc3NpbmcgdGhlbiBvdXQgb2YgZmlyc3QgIkZyb206Ig0NCiAg IGhlYWRlciBhbmQgaXQgd291bGQgc2V0IFNVQk1JVFRFUiBwYXJhbWV0ZXIg dG8gdGhpcyBhZGRyZXNzIGZvcg0NCiAgIHN1YnNlcXVlbnQgdHJhbnNtaXNz aW9ucyBvZiB0aGUgbWVzc2FnZS4NDQoNDQogICBOb3RlIHRoYXQgc2V0dGlu ZyBTVUJNSVRURVIgcGFyYW1ldGVyIGJhc2VkIG9uIHZhbHVlcyBvZiAiU2Vu ZGVyIiBhbmQNDQogICAiRnJvbSIgaGVhZGVyIHNob3VsZCBiZSBkb25lIE9O TFkgaWYgU01UUCBTZXJ2ZXIgaXMgY2VydGFpbiB0aGF0IG1haWwNDQogICBz dWJtaXNzaW9uIGlzIHRha2luZyBwbGFjZSwgaS5lLiBpZiBlaXRoZXIgU1VC TUlUIHByb3RvY29sIGlzIHVzZWQgb3INDQogICBpZiBTTVRQIHByb3RvY29s IHdpdGggU01UUCBhdXRoZW50aWNhdGlvbiBbU01UUEFVVEhdIGlzIHVzZWQu DQ0KIA0NCg0NCg0NCkxlaWJ6b24gICAgICAgICAgICAgICAgRXhwaXJlcyAt IEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0NCg0N CiAgICAgICAgICBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgb2YgYW4gRS1tYWls IE1lc3NhZ2UgICAgICAgIE9jdG9iZXIgMjAwNA0NCg0NCjYuMiBNYWlsIEZv cndhcmRpbmcNDQoNDQogICBXaGVuIEFsaWNlIHNlbmRzIGEgbWVzc2FnZSB0 byBCb2IncyBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUgYWNjb3VudCwNDQogICBT TVRQIHNlc3Npb24gZnJvbSBoZXIgU1VCTUlUIHNlcnZlciBtaWdodCBsb29r IHNvbWV0aGluZyBsaWtlIHRoaXM6DQ0KDQ0KICAgICAgUzogMjIwIGFsbWFt YXRlci5lZHUuZXhhbXBsZSBFU01UUCBzZXJ2ZXIgcmVhZHkNDQogICAgICBD OiBFSExPIGV4YW1wbGUuY29tDQ0KICAgICAgUzogMjUwLWFsbWFtYXRlci5l ZHUuZXhhbXBsZQ0NCiAgICAgIFM6IDI1MC1EU04NDQogICAgICBTOiAyNTAt QVVUSA0NCiAgICAgIFM6IDI1MC1TVUJNSVRURVINDQogICAgICBTOiAyNTAg U0laRQ0NCiAgICAgIEM6IE1BSUwgRlJPTTo8YWxpY2VAZXhhbXBsZS5jb20+ IFNVQk1JVFRFUj1hbGljZUBleGFtcGxlLmNvbQ0NCiAgICAgIFM6IDI1MCA8 YWxpY2VAZXhhbXBsZS5jb20+IHNlbmRlciBvaw0NCiAgICAgIEM6IFJDUFQg VE86PGJvYkBhbG1hbWF0ZXIuZWR1LmV4YW1wbGU+DQ0KICAgICAgUzogMjUw IDxib2JAYWxtYW1hdGVyLmVkdS5leGFtcGxlPiByZWNpcGllbnQgb2sNDQog ICAgICBDOiBEQVRBDQ0KICAgICAgUzogMzU0IG9rYXksIHNlbmQgbWVzc2Fn ZQ0NCiAgICAgIEM6IChtZXNzYWdlIGJvZHkgZ29lcyBoZXJlKQ0NCiAgICAg IEM6IC4NDQogICAgICBTOiAyNTAgbWVzc2FnZSBhY2NlcHRlZA0NCiAgICAg IEM6IFFVSVQNDQogICAgICBTOiAyMjEgZ29vZGJ5ZQ0NCg0NCiAgIFRoZSBh bG1hbWF0ZXIuZWR1LmV4YW1wbGUgTVRBIG11c3Qgbm93IGZvcndhcmQgdGhp cyBtZXNzYWdlIHRvDQ0KICAgYm9iQGNvbXBhbnkuY29tLmV4YW1wbGUuICBB bHRob3VnaCB0aGUgb3JpZ2luYWwgc2VuZGVyIG9mIHRoZSBtZXNzYWdlDQ0K ICAgaXMgYWxpY2VAZXhhbXBsZS5jb20sIEFsaWNlIGlzIG5vdCByZXNwb25z aWJsZSBmb3IgdGhpcyBtb3N0IHJlY2VudA0NCiAgIHJldHJhbnNtaXNzaW9u IG9mIHRoZSBtZXNzYWdlLiAgVGhhdCByb2xlIGlzIGZpbGxlZCBieQ0NCiAg IGJvYkBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUgd2hvIGVzdGFibGlzaGVkIHRo ZSBmb3J3YXJkaW5nIG9mIG1haWwgdG8NDQogICBib2JAY29tcGFueS5jb20u ZXhhbXBsZS4gIFRoZXJlZm9yZSBmb3IgYWxtYW1hdGVyLmVkdS5leGFtcGxl IE1UQQ0NCiAgIGEgbmV3IG1lc3NhZ2UgcmVzcG9uc2libGUgc3VibWl0dGVy IGlzIGJvYkBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUsDQ0KICAgYW5kIGl0IHNl dHMgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIgYWNjb3JkaW5nbHkuICANDQoN DQogICAgICBTOiAyMjAgY29tcGFueS5jb20uZXhhbXBsZSBFU01UUCBzZXJ2 ZXIgcmVhZHkNDQogICAgICBDOiBFSExPIGFsbWFtYXRlci5lZHUuZXhhbXBs ZQ0NCiAgICAgIFM6IDI1MC1jb21wYW55LmNvbS5leGFtcGxlDQ0KICAgICAg UzogMjUwLURTTg0NCiAgICAgIFM6IDI1MC1TVUJNSVRURVINDQogICAgICBT OiAyNTAgU0laRQ0NCiAgICAgIEM6IE1BSUwgRlJPTTo8YWxpY2VAZXhhbXBs ZS5jb20+DQ0KICAgICAgICAgICAgICBTVUJNSVRURVI9Ym9iQGFsbWFtYXRl ci5lZHUuZXhhbXBsZQ0NCiAgICAgIFM6IDI1MCA8YWxpY2VAZXhhbXBsZS5j b20+IHNlbmRlciBvaw0NCiAgICAgIEM6IFJDUFQgVE86PGJvYkBjb21wYW55 LmNvbS5leGFtcGxlPg0NCiAgICAgIFM6IDI1MCA8Ym9iQGNvbXBhbnkuY29t LmV4YW1wbGU+IHJlY2lwaWVudCBvaw0NCiAgICAgIEM6IERBVEENDQogICAg ICBTOiAzNTQgb2theSwgc2VuZCBtZXNzYWdlDQ0KICAgICAgQzogUmVjZWl2 ZWQgQnk6IC4uLg0NCiAgICAgIEM6IChtZXNzYWdlIGJvZHkgZ29lcyBoZXJl KQ0NCiAgICAgIEM6IC4NDQogICAgICBTOiAyNTAgbWVzc2FnZSBhY2NlcHRl ZA0NCiAgICAgIEM6IFFVSVQNDQogICAgICBTOiAyMjEgZ29vZGJ5ZQ0NCg0N CkxlaWJ6b24gICAgICAgICAgICAgICAgRXhwaXJlcyAtIEFwcmlsIDIwMDUg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0NCg0NCiAgICAgICAgICBS ZXNwb25zaWJsZSBTdWJtaXR0ZXIgb2YgYW4gRS1tYWlsIE1lc3NhZ2UgICAg ICAgIE9jdG9iZXIgMjAwNA0NCg0NCjYuMyBNYWlsIExpc3QNDQoNDQogICBX aGVuIEFsaWNlIHNlbmRzIGEgbWVzc2FnZSB0byBsaXN0QG1haWxsaXN0Lm9y Zy5leGFtcGxlLCBhbiBvcmlnaW5hbA0NCiAgIFNNVFAgc2Vzc2lvbiBmcm9t IGhlciBTVUJNSVQgc2VydmVyIG1pZ2h0IGxvb2sgc29tZXRoaW5nIGxpa2Ug dGhpczoNDQoNDQogICAgICBTOiAyMjAgbWFpbGxpc3Qub3JnLmV4YW1wbGUg RVNNVFAgc2VydmVyIHJlYWR5DQ0KICAgICAgQzogRUhMTyBleGFtcGxlLmNv bQ0NCiAgICAgIFM6IDI1MC1tYWlsbGlzdC5vcmcuZXhhbXBsZQ0NCiAgICAg IFM6IDI1MC1EU04NDQogICAgICBTOiAyNTAtQVVUSA0NCiAgICAgIFM6IDI1 MC1TVUJNSVRURVINDQogICAgICBTOiAyNTAgU0laRQ0NCiAgICAgIEM6IE1B SUwgRlJPTTo8YWxpY2VAZXhhbXBsZS5jb20+IFNVQk1JVFRFUj1hbGljZUBl eGFtcGxlLmNvbQ0NCiAgICAgIFM6IDI1MCA8YWxpY2VAZXhhbXBsZS5jb20+ IHNlbmRlciBvaw0NCiAgICAgIEM6IFJDUFQgVE86PGxpc3RAbWFpbGxpc3Qu b3JnLmV4YW1wbGU+DQ0KICAgICAgUzogMjUwIDxsaXN0QG1haWxsaXN0Lm9y Zy5leGFtcGxlPiByZWNpcGllbnQgb2sNDQogICAgICBDOiBEQVRBDQ0KICAg ICAgUzogMzU0IG9rYXksIHNlbmQgbWVzc2FnZQ0NCiAgICAgIEM6IChtZXNz YWdlIGJvZHkgZ29lcyBoZXJlKQ0NCiAgICAgIEM6IC4NDQogICAgICBTOiAy NTAgbWVzc2FnZSBhY2NlcHRlZA0NCiAgICAgIEM6IFFVSVQNDQogICAgICBT OiAyMjEgZ29vZGJ5ZQ0NCg0NCiAgIFRoZSBtYWlsIGxpc3Qgc29mdHdhcmUg cnVuIGF0IG1haWxsaXN0Lm9yZy5leGFtcGxlIG11c3Qgbm93IGZvcndhcmQN DQogICB0aGlzIG1lc3NhZ2UgdG8gYWxsIG1haWwgbGlzdCBzdWJzY3JpYmVy cyBpbmNsdWRpbmcgQm9iLiBNYWlsIGxpc3QNDQogICBpcyBub3cgcmVzcG9u c2libGUgZm9yIG5ldyBpbnRyb2R1Y3Rpb24gb2YgdGhlIG1lc3NhZ2UgaW50 byBlbWFpbA0NCiAgIGRlbGl2ZXJ5LiBUaGVyZWZvcmUgZm9yIG1haWxsaXN0 Lm9yZy5leGFtcGxlIE1UQSBhIG5ldyBtZXNzYWdlDQ0KICAgcmVzcG9uc2li bGUgc3VibWl0dGVyIGlzIG1haWwgbGlzdCBhZGRyZXNzIGxpc3RAbWFpbGxp c3Qub3JnLmV4YW1wbGUsDQ0KICAgYW5kIGl0IHNldHMgdGhlIFNVQk1JVFRF UiBwYXJhbWV0ZXIgYWNjb3JkaW5nbHkuIFRoZSBmb2xsb3dpbmcgc2hvd3MN DQogICBob3cgU01UUCBzZXNzaW9uIG9mIG1haWxsaXN0IHNlbmRpbmcgdGhl IG1lc3NhZ2UgdG8gaXRzIHN1YnNjcmliZXIgDQ0KICAgYm9iQGNvbXBhbnku Y29tLmV4YW1wbGUgbWlnaHQgbG9vayBsaWtlOg0NCg0NCiAgICAgIFM6IDIy MCBjb21wYW55LmNvbS5leGFtcGxlIEVTTVRQIHNlcnZlciByZWFkeQ0NCiAg ICAgIEM6IEVITE8gbWFpbGxpc3Qub3JnLmV4YW1wbGUgDQ0KICAgICAgUzog MjUwLWNvbXBhbnkuY29tLmV4YW1wbGUNDQogICAgICBTOiAyNTAtRFNODQ0K ICAgICAgUzogMjUwLVNVQk1JVFRFUg0NCiAgICAgIFM6IDI1MCBTSVpFDQ0K ICAgICAgQzogTUFJTCBGUk9NOjxhbGljZUBleGFtcGxlLmNvbT4NDQogICAg ICAgICAgICAgIFNVQk1JVFRFUj1saXN0QG1haWxsaXN0Lm9yZy5leGFtcGxl DQ0KICAgICAgUzogMjUwIDxhbGljZUBleGFtcGxlLmNvbT4gc2VuZGVyIG9r DQ0KICAgICAgQzogUkNQVCBUTzo8Ym9iQGNvbXBhbnkuY29tLmV4YW1wbGU+ DQ0KICAgICAgUzogMjUwIDxib2JAY29tcGFueS5jb20uZXhhbXBsZT4gcmVj aXBpZW50IG9rDQ0KICAgICAgQzogREFUQQ0NCiAgICAgIFM6IDM1NCBva2F5 LCBzZW5kIG1lc3NhZ2UNDQogICAgICBDOiBSZWNlaXZlZCBCeTogLi4uDQ0K ICAgICAgQzogKG1lc3NhZ2UgYm9keSBnb2VzIGhlcmUpDQ0KICAgICAgQzog Lg0NCiAgICAgIFM6IDI1MCBtZXNzYWdlIGFjY2VwdGVkDQ0KICAgICAgQzog UVVJVA0NCiAgICAgIFM6IDIyMSBnb29kYnllDQ0KDQ0KTGVpYnpvbiAgICAg ICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMTFdDQ0KDQ0KICAgICAgICAgIFJlc3BvbnNpYmxlIFN1 Ym1pdHRlciBvZiBhbiBFLW1haWwgTWVzc2FnZSAgICAgICAgT2N0b2JlciAy MDA0DQ0KDQ0KDQ0KNi40IE1vYmlsZSBVc2VyDQ0KDQ0KICAgQWxpY2UgaXMg YXQgdGhlIGFpcnBvcnQgYW5kIHVzZXMgaGVyIG1vYmlsZSBlLW1haWwgZGV2 aWNlIHRvIHNlbmQgYQ0NCiAgIG1lc3NhZ2UgdG8gQm9iLiAgVGhlIG1lc3Nh Z2UgdHJhdmVscyB0aHJvdWdoIHRoZSBjYXJyaWVyIG5ldHdvcmsNDQogICBw cm92aWRlZCBieSBtb2JpbGUubmV0LmV4YW1wbGUsIGJ1dCBBbGljZSB1c2Vz IGhlciBleGFtcGxlLmNvbQ0NCiAgIGFkZHJlc3Mgb24gdGhlIEZyb20gbGlu ZSBvZiBhbGwgaGVyIG1lc3NhZ2VzIHNvIHRoYXQgcmVwbGllcyBnbyB0bw0N CiAgIGhlciBvZmZpY2UgbWFpbGJveC4NDQoNDQogICBIZXJlIGlzIGFuIGV4 YW1wbGUgb2YgdGhlIFNNVFAgc2Vzc2lvbiBiZXR3ZWVuIHRoZSBNVEFzIGF0 DQ0KICAgY29uc29saWRhdGVkbWVzc2FuZ2VyLm5ldCBhbmQgYWxtYW1hdGVy LmVkdS5leGFtcGxlLg0NCg0NCiAgICAgIFM6IDIyMCBhbG1hbWF0ZXIuZWR1 LmV4YW1wbGUgRVNNVFAgc2VydmVyIHJlYWR5DQ0KICAgICAgQzogRUhMTyBt b2JpbGUubmV0LmV4YW1wbGUNDQogICAgICBTOiAyNTAtYWxtYW1hdGVyLmVk dS5leGFtcGxlDQ0KICAgICAgUzogMjUwLURTTg0NCiAgICAgIFM6IDI1MC1B VVRIDQ0KICAgICAgUzogMjUwLVNVQk1JVFRFUg0NCiAgICAgIFM6IDI1MCBT SVpFDQ0KICAgICAgQzogTUFJTCBGUk9NOjxhbGljZUBleGFtcGxlLmNvbT4N DQogICAgICAgICAgICAgIFNVQk1JVFRFUj1hbGljZUBtb2JpbGUubmV0LmV4 YW1wbGUNDQogICAgICBTOiAyNTAgPGFsaWNlQGV4YW1wbGUuY29tPiBzZW5k ZXIgb2sNDQogICAgICBDOiBSQ1BUIFRPOjxib2JAYWxtYW1hdGVyLmVkdS5l eGFtcGxlPg0NCiAgICAgIFM6IDI1MCA8Ym9iQGFsbWFtYXRlci5lZHUuZXhh bXBsZT4gcmVjaXBpZW50IG9rDQ0KICAgICAgQzogREFUQQ0NCiAgICAgIFM6 IDM1NCBva2F5LCBzZW5kIG1lc3NhZ2UNDQogICAgICBDOiBTZW5kZXI6IGFs aWNlQG1vYmlsZS5uZXQuZXhhbXBsZQ0NCiAgICAgIEM6IFJlY2VpdmVkIEJ5 OiAuLi4NDQogICAgICBDOiAobWVzc2FnZSBib2R5IGdvZXMgaGVyZSkNDQog ICAgICBDOiAuDQ0KICAgICAgUzogMjUwIG1lc3NhZ2UgYWNjZXB0ZWQNDQog ICAgICBDOiBRVUlUDQ0KICAgICAgUzogMjIxIGdvb2RieWUNDQoNDQogICBO b3RlIHRoYXQgbW9iaWxlLm5ldC5leGFtcGxlIHVzZXMgdGhlIFNVQk1JVFRF UiBwYXJhbWV0ZXIgdG8NDQogICBkZXNpZ25hdGUgYWxpY2VAbW9iaWxlLm5l dC5leGFtcGxlIGFzIHRoZSByZXNwb25zaWJsZSBzdWJtaXR0ZXIgZm9yDQ0K ICAgdGhpcyBtZXNzYWdlLiAgRnVydGhlciB0aGlzIE1UQSBhbHNvIGluc2Vy dHMgYSBTZW5kZXIgaGVhZGVyIGFzDQ0KICAgcmVxdWlyZWQgYnkgUkZDMjgy MiB0byBzaG93IHRoYXQgYWxpY2VAbW9iaWxlLm5ldCBpcyB0aGUgYWN0dWFs DQ0KICAgYWdlbnQgcmVzcG9uc2libGUgZm9yIHRoaXMgZW1haWwgdHJhbnNt aXNzaW9uLg0NCg0NCiAgIExpa2V3aXNlLCBjb252ZW50aW9uYWwgSVNQcyBt YXkgYWxzbyBjaG9vc2UgdG8gdXNlIHRoZSBTVUJNSVRURVINDQogICBwYXJh bWV0ZXIgdG8gZGVzaWduYXRlIGFzIHRoZSByZXNwb25zaWJsZSBzdWJtaXR0 ZXIgdGhlIHVzZXIncw0NCiAgIGFkZHJlc3Mgb24gdGhlIElTUCdzIG5ldHdv cmsgaWYgdGhhdCBhZGRyZXNzIGlzIGRpZmZlcmVudCBmcm9tIHRoZQ0NCiAg IE1BSUwgRlJPTSBhZGRyZXNzLg0NCg0NCiAgIFdoZW4gdGhlIG1lc3NhZ2Ug aXMgc3Vic2VxdWVudGx5IGZvcndhcmRlZCBieSB0aGUNDQogICBhbG1hbWF0 ZXIuZWR1LmV4YW1wbGUgTVRBLCB0aGF0IE1UQSB3aWxsIHJlcGxhY2UgdGhl IFNVQk1JVFRFUg0NCiAgIHBhcmFtZXRlciB3aXRoIGJvYkBhbG1hbWF0ZXIu ZWR1LmV4YW1wbGUgYXMgaW4gc2VjdGlvbiA2LjIgYW5kIGFkZA0NCiAgIG5l dyBTdWJtaXR0ZWQtQnkgaGVhZGVyIHRvIGluZGljYXRlIGVtYWlsIGZvcndh cmRpbmcgYnkgTVRBLg0NCg0NCg0NCg0NCg0NCkxlaWJ6b24gICAgICAgICAg ICAgICAgRXhwaXJlcyAtIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgICAg IFtQYWdlIDEyXQ0NCg0NCiAgICAgICAgICBSZXNwb25zaWJsZSBTdWJtaXR0 ZXIgb2YgYW4gRS1tYWlsIE1lc3NhZ2UgICAgICAgIE9jdG9iZXIgMjAwNA0N Cg0NCg0NCjYuNSBHdWVzdCBFLW1haWwgU2VydmljZQ0NCg0NCiAgIFdoaWxl IG9uIGEgYnVzaW5lc3MgdHJpcCwgQWxpY2UgdXNlcyB0aGUgYnJvYWRiYW5k IGFjY2VzcyBmYWNpbGl0aWVzDQ0KICAgcHJvdmlkZWQgYnkgdGhlIEV4ZW1w bGFyIEhvdGVsIHRvIGNvbm5lY3QgdG8gdGhlIEludGVybmV0IGFuZCBzZW5k IGUtDQ0KICAgbWFpbC4gIFRoZSBob3RlbCByb3V0ZXMgYWxsIG91dGJvdW5k IGUtbWFpbCB0aHJvdWdoIGl0cyBvd24gU01UUA0NCiAgIHNlcnZlciwgZW1h aWwuaG90ZWwuY29tLmV4YW1wbGUuDQ0KDQ0KICAgVGhlIFNNVFAgc2Vzc2lv biBmb3IgQWxpY2UncyBtZXNzYWdlIHRvIEJvYiBmcm9tIHRoZSBFeGVtcGxh ciBIb3RlbA0NCiAgIHdvdWxkIGxvb2sgbGlrZSB0aGlzOg0NCg0NCiAgICAg IFM6IDIyMCBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUgRVNNVFAgc2VydmVyIHJl YWR5DQ0KICAgICAgQzogRUhMTyBlbWFpbC5ob3RlbC5jb20uZXhhbXBsZQ0N CiAgICAgIFM6IDI1MC1hbG1hbWF0ZXIuZWR1LmV4YW1wbGUNDQogICAgICBT OiAyNTAtRFNODQ0KICAgICAgUzogMjUwLUFVVEgNDQogICAgICBTOiAyNTAt U1VCTUlUVEVSDQ0KICAgICAgUzogMjUwIFNJWkUNDQogICAgICBDOiBNQUlM IEZST006PGFsaWNlQGV4YW1wbGUuY29tPg0NCiAgICAgICAgICAgICAgU1VC TUlUVEVSPWd1ZXN0LnNlcnZpY2VzQGVtYWlsLmhvdGVsLmNvbS5leGFtcGxl DQ0KICAgICAgUzogMjUwIDxhbGljZUBleGFtcGxlLmNvbT4gc2VuZGVyIG9r DQ0KICAgICAgQzogUkNQVCBUTzo8Ym9iQGFsbWFtYXRlci5lZHUuZXhhbXBs ZT4NDQogICAgICBTOiAyNTAgPGJvYkBhbG1hbWF0ZXIuZWR1LmV4YW1wbGU+ IHJlY2lwaWVudCBvaw0NCiAgICAgIEM6IERBVEENDQogICAgICBTOiAzNTQg b2theSwgc2VuZCBtZXNzYWdlDQ0KICAgICAgQzogU2VuZGVyOiBndWVzdC5z ZXJ2aWNlc0BlbWFpbC5ob3RlbC5jb20uZXhhbXBsZQ0NCiAgICAgIEM6IFJl Y2VpdmVkIEJ5OiAuLi4NDQogICAgICBDOiAobWVzc2FnZSBib2R5IGdvZXMg aGVyZSkNDQogICAgICBDOiAuDQ0KICAgICAgUzogMjUwIG1lc3NhZ2UgYWNj ZXB0ZWQNDQogICAgICBDOiBRVUlUDQ0KICAgICAgUzogMjIxIGdvb2RieWUN DQoNDQogICBOb3RlIHRoYXQgZW1haWwuaG90ZWwuY29tLmV4YW1wbGUgdXNl cyB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciB0bw0NCiAgIGRlc2lnbmF0ZSBh IGdlbmVyaWMgYWNjb3VudCBndWVzdC5zZXJ2aWNlc0BlbWFpbC5ob3RlbC5j b20uZXhhbXBsZSBhcw0NCiAgIHRoZSByZXNwb25zaWJsZSBzdWJtaXR0ZXIg YWRkcmVzcyBmb3IgdGhpcyBtZXNzYWdlLiAgQSBnZW5lcmljDQ0KICAgYWNj b3VudCBpcyB1c2VkIHNpbmNlIEFsaWNlIGhlcnNlbGYgZG9lcyBub3QgaGF2 ZSBhbiBhY2NvdW50IGF0IHRoYXQNDQogICBkb21haW4uICBGdXJ0aGVybW9y ZSBlbWFpbC5ob3RlbC5jb20uZXhhbXBsZSBhbHNvIGFkZHMgbmV3IFNlbmRl cg0NCiAgIGhlYWRlciB0byBpbmRpY2F0ZSB0aGF0IGl0IGlzIHNlbmRpbmcg dGhlIG1lc3NhZ2Ugb24gYmVoYWxmIG9mDQ0KICAgYWxpY2VAZXhhbXBsZS5j b20gKGlmIG1lc3NhZ2UgYWxyZWFkeSBjb250YWlucyAiU2VuZGVyOiIgaGVh ZGVyLA0NCiAgIHRoZW4gdGhhdCBhZGRyZXNzIHNob3VsZCBiZSBwcmVzZXJ2 ZWQgaW4gIk9yaWdpbmFsLVNlbmRlcjoiIGhlYWRlcikNDQoNDQogICBBcyBi ZWZvcmUsIHdoZW4gdGhlIG1lc3NhZ2UgaXMgc3Vic2VxdWVudGx5IGZvcndh cmRlZCBieSB0aGUNDQogICBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUgTVRBLCB0 aGF0IE1UQSB3aWxsIHJlcGxhY2UgdGhlIFNVQk1JVFRFUg0NCiAgIHBhcmFt ZXRlciB3aXRoIGJvYkBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUgYXMgaW4gc2Vj dGlvbiA2LjIuDQ0KDQ0KDQ0KNi42IFNVQk1JVFRFUiBVc2VkIG9uIGEgTm9u LURlbGl2ZXJ5IFJlcG9ydA0NCg0NCiAgIEFsaWNlIHNlbmRzIGFuIGluY29y cmVjdGx5IGFkZHJlc3NlZCBlLW1haWwgbWVzc2FnZSBhbmQgcmVjZWl2ZXMg YQ0NCiAgIG5vbi1kZWxpdmVyeSByZXBvcnQgZnJvbSBhIFNVQk1JVFRFUi1j b21wbGlhbnQgc2VydmVyLg0NCg0NCg0NCkxlaWJ6b24gICAgICAgICAgICAg ICAgRXhwaXJlcyAtIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDEzXQ0NCg0NCiAgICAgICAgICBSZXNwb25zaWJsZSBTdWJtaXR0ZXIg b2YgYW4gRS1tYWlsIE1lc3NhZ2UgICAgICAgIE9jdG9iZXIgMjAwNA0NCg0N CiAgICAgIFM6IDIyMCBleGFtcGxlLmNvbSBFU01UUCBzZXJ2ZXIgcmVhZHkN DQogICAgICBDOiBFSExPIGFsbWFtYXRlci5lZHUuZXhhbXBsZQ0NCiAgICAg IFM6IDI1MC1leGFtcGxlLmNvbQ0NCiAgICAgIFM6IDI1MC1EU04NDQogICAg ICBTOiAyNTAtQVVUSA0NCiAgICAgIFM6IDI1MC1TVUJNSVRURVINDQogICAg ICBTOiAyNTAgU0laRQ0NCiAgICAgIEM6IE1BSUwgRlJPTTo8PiBTVUJNSVRU RVI9bWFpbGVyLWRhZW1vbkBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUNDQogICAg ICBTOiAyNTAgT0sNDQogICAgICBDOiBSQ1BUIFRPOjxhbGljZUBleGFtcGxl LmNvbT4NDQogICAgICBTOiAyNTAgT0sNDQogICAgICBDOiBEQVRBDQ0KICAg ICAgUzogMzU0IE9LLCBzZW5kIG1lc3NhZ2UNDQogICAgICBDOiAobWVzc2Fn ZSBib2R5IGdvZXMgaGVyZSkNDQogICAgICBDOiAuDQ0KICAgICAgUzogMjUw IG1lc3NhZ2UgYWNjZXB0ZWQNDQogICAgICBDOiBRVUlUDQ0KICAgICAgUzog MjIxIGdvb2RieWUNDQoNDQoNDQo3LiBTZWN1cml0eSBDb25zaWRlcmF0aW9u cw0NCg0NCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIFNNVFAgZXh0ZW5z aW9uIG1lY2hhbmlzbSB0byBhbGxvdyBTTVRQIGNsaWVudA0NCiAgIHRvIGlk ZW50aWZ5IHRoZSBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgb2YgYW4gZS1tYWls IG1lc3NhZ2UgYW5kIHRvDQ0KICAgZW5hYmxlIFNNVFAgc2VydmVycyB0byBw ZXJmb3JtIGVmZmljaWVudCB2YWxpZGF0aW9uIG9mIHRoYXQgaWRlbnRpdHkN DQogICB3aGljaCBhbGxvd3MgdG8gY2F0Y2ggYW5kIGZpbHRlciBvdXQgc3Bv b2ZlZCBlbWFpbCwgd2hpY2ggaXMgdG9kYXkgYQ0NCiAgIHBlcnZhc2l2ZSBz ZWN1cml0eSBwcm9ibGVtIGluIHRoZSBJbnRlcm5ldC4NDQoNDQogICBBc3N1 bWluZyB0aGF0IHRoaXMgZXh0ZW5zaW9uIGFuZCB2ZXJpZmljYXRpb24gbWVj aGFuaXNtcyBhcmUgd2lkZWx5DQ0KICAgZGVwbG95ZWQsIHRoZSBmb2xsb3dp bmcgc2VjdGlvbnMgZGVzY3JpYmUgY291bnRlci1hdHRhY2tzIHRoYXQgY291 bGQNDQogICBiZSB1c2VkIHRvIGRlZmVhdCB0aGlzIHN5c3RlbTogDQ0KDQ0K DQ0KNy4xIEROUyBBdHRhY2tzDQ0KDQ0KICAgU1BGIHZlcmlmaWNhdGlvbiBt ZWNoYW5pc20gaXMgZW50aXJlbHkgZGVwZW5kZW50IG9uIEROUyBsb29rdXBz LCBhbmQNDQogICBpcyB0aGVyZWZvcmUgb25seSBhcyBzZWN1cmUgYXMgRE5T LiAgQW4gYXR0YWNrZXIgYmVudCBvbiBzcG9vZmluZw0NCiAgIG1lc3NhZ2Vz IGNvdWxkIGF0dGVtcHQgdG8gZ2V0IGhpcyBtZXNzYWdlcyBhY2NlcHRlZCBi eSBzZW5kaW5nIGZvcmdlZA0NCiAgIGFuc3dlcnMgdG8gRE5TIHF1ZXJpZXMu DQ0KDQ0KICAgQW4gTVRBIGNvdWxkIGxhcmdlbHkgZGVmZWF0IHN1Y2ggYW4g YXR0YWNrIGJ5IHVzaW5nIGEgcHJvcGVybHkNDQogICBwYXJhbm9pZCBETlMg cmVzb2x2ZXIuICBETlNTRUMgbWF5IHVsdGltYXRlbHkgcHJvdmlkZSBhIHdh eSB0bw0NCiAgIGNvbXBsZXRlbHkgbmV1dHJhbGl6ZSB0aGlzIGNsYXNzIG9m IGF0dGFja3MuDQ0KDQ0KNy4yIFRDUCBBdHRhY2tzDQ0KDQ0KICAgVGhpcyBt ZWNoYW5pc20gaXMgZGVzaWduZWQgdG8gYmUgdXNlZCBpbiBjb25qdW5jdGlv biB3aXRoIFNNVFAgb3Zlcg0NCiAgIFRDUC4gIEEgc3VmZmljaWVudGx5IHJl c291cmNlZnVsIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gc2VuZCBUQ1AN DQogICBwYWNrZXRzIHdpdGggZm9yZ2VkIGZyb20tYWRkcmVzc2VzLCBhbmQg dGh1cyBleGVjdXRlIGFuIGVudGlyZSBTTVRQDQ0KICAgc2Vzc2lvbiB0aGF0 IGFwcGVhcnMgdG8gY29tZSBmcm9tIHNvbWV3aGVyZSBvdGhlciB0aGFuIGl0 cyB0cnVlDQ0KICAgb3JpZ2luLg0NCg0NCg0NCkxlaWJ6b24gICAgICAgICAg ICAgICAgRXhwaXJlcyAtIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgICAg IFtQYWdlIDE0XQ0NCg0NCiAgICAgICAgICBSZXNwb25zaWJsZSBTdWJtaXR0 ZXIgb2YgYW4gRS1tYWlsIE1lc3NhZ2UgICAgICAgIE9jdG9iZXIgMjAwNA0N Cg0NCiAgIFN1Y2ggYW4gYXR0YWNrIHJlcXVpcmVzIGd1ZXNzaW5nIHdoYXQg VENQIHNlcXVlbmNlIG51bWJlcnMgYW4gU01UUA0NCiAgIHNlcnZlciB3aWxs IHVzZS4gSXQgYWxzbyByZXF1aXJlcyB0cmFuc21pdHRpbmcgY29tcGxldGVs eSBpbiB0aGUNDQogICBibGluZCAtIHRoZSBhdHRhY2sgd2lsbCBiZSB1bmFi bGUgaGVhciBhbnkgb2YgdGhlIHNlcnZlcidzIHNpZGUgb2YNDQogICB0aGUg Y29udmVyc2F0aW9uLg0NCg0NCiAgIEF0dGFja3Mgb2YgdGhpcyBzb3J0IGNh biBiZSBhbWVsaW9yYXRlZCBpZiBJUCBnYXRld2F5cyByZWZ1c2UgdG8NDQog ICBmb3J3YXJkIHBhY2tldHMgd2hlbiB0aGUgc291cmNlIGFkZHJlc3MgaXMg Y2xlYXJseSBib2d1cy4NDQoNDQo3LjMgQWRkcmVzcyBTcGFjZSBIaWphY2tp bmcNDQoNDQogICBUaGlzIHN5c3RlbSBhc3N1bWVzIHRoZSBpbnRlZ3JpdHkg b2YgSVAgYWRkcmVzcyBzcGFjZSBmb3INDQogICBkZXRlcm1pbmluZyB3aGV0 aGVyIGEgZ2l2ZW4gY2xpZW50IGlzIGF1dGhvcml6ZWQgdG8gc2VuZCBtZXNz YWdlcw0NCiAgIGJhc2VkIG9uIHByb3ZpZGVkIFJlc3BvbnNpYmxlIFN1Ym1p dHRlciBpZGVudGl0eS4gIEluIGFkZGl0aW9uIHRvDQ0KICAgdGhlIFRDUCBh dHRhY2sgZ2l2ZW4gaW4gc2VjdGlvbiA2LjIsIGEgc3VmZmljaWVudGx5IHJl c291cmNlZnVsDQ0KICAgYXR0YWNrZXIgbWlnaHQgYmUgYWJsZSB0byBhbHRl ciB0aGUgSVAgcm91dGluZyBzdHJ1Y3R1cmUgdG8gcGVybWl0DQ0KICAgdHdv LXdheSBjb21tdW5pY2F0aW9uIHVzaW5nIGEgc3BlY2lmaWVkIElQIGFkZHJl c3MuICBJdCB3b3VsZCB0aGVuDQ0KICAgYmUgcG9zc2libGUgdG8gZXhlY3V0 ZSBhbiBTTVRQIHNlc3Npb24gdGhhdCBhcHBlYXJzIHRvIGNvbWUgZnJvbSBh bg0NCiAgIGF1dGhvcml6ZWQgYWRkcmVzcywgd2l0aG91dCB0aGUgbmVlZCB0 byBndWVzcyBUQ1Agc2VxdWVuY2UgbnVtYmVycw0NCiAgIG9yIHRyYW5zbWl0 IGluIHRoZSBibGluZC4NDQoNDQogICBTdWNoIGFuIGF0dGFjayBtaWdodCBv Y2N1ciBpZiB0aGUgYXR0YWNrZXIgb2J0YWluZWQgYWNjZXNzIHRvIGENDQog ICByb3V0ZXIgd2hpY2ggcGFydGljaXBhdGVzIGluIGV4dGVybmFsIEJHUCBy b3V0aW5nLiAgU3VjaCBhIHJvdXRlcg0NCiAgIGNvdWxkIGFkdmVydGlzZSBh IG1vcmUgc3BlY2lmaWMgcm91dGUgdG8gYSByb2d1ZSBTTVRQIGNsaWVudCwN DQogICB0ZW1wb3JhcmlseSBvdmVycmlkaW5nIHRoZSBsZWdpdGltYXRlIG93 bmVyIG9mIHRoZSBhZGRyZXNzLg0NCg0NCg0NCjguIElBTkEgQ29uc2lkZXJh dGlvbnMNDQoNDQogICBJQU5BIGlzIGhlcmVieSByZXF1ZXN0ZWQgdG8gcmVn aXN0ZXIgdGhlIFNVQk1JVFRFUiBTTVRQIHNlcnZpY2UNDQogICBleHRlbnNp b24uDQ0KDQ0KDQ0KOS4gUmVmZXJlbmNlcw0NCg0NCjkuMSBOb3JtYXRpdmUg UmVmZXJlbmNlcw0NCg0NCiAgICBbQUJORl0gICAgICAgICBDcm9ja2VyLCBE LiBhbmQgUi4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYgZm9yDQ0KICAgICAg ICAgICAgICAgICAgIFN5bnRheCBTcGVjaWZpY2F0aW9uczogQUJORiIsIFJG QyAyMjM0LCBOb3ZlbWJlciAxOTk3DQ0KDQ0KICAgIFtEU05dICAgICAgICAg IE1vb3JlLCBLLiwgIlNpbXBsZSBNYWlsIFRyYW5zZmVyIFByb3RvY29sIChT TVRQKQ0NCiAgICAgICAgICAgICAgICAgICBTZXJ2aWNlIEV4dGVuc2lvbiBm b3IgRGVsaXZlcnkgU3RhdHVzIE5vdGlmaWNhdGlvbnMNDQogICAgICAgICAg ICAgICAgICAgKERTTnMpIiwgUkZDIDM0NjEsIEphbnVhcnkgMjAwMy4NDQoN DQogICAgW0tFWVdPUkRTXSAgICAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMg Zm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQ0KICAgICAgICAgICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1h cmNoIDE5OTcuDQ0KDQ0KICAgIFtNU0ctRk9STUFUXSAgIFJlc25pY2ssIFAu LCBFZC4sICJJbnRlcm5ldCBNZXNzYWdlIEZvcm1hdCIsIFJGQw0NCiAgICAg ICAgICAgICAgICAgICAyODIyLCBBcHJpbCAyMDAxLg0NCg0NCiAgICBbU01U UF0gICAgICAgICBLbGVuc2luLCBKLiwgIlNpbXBsZSBNYWlsIFRyYW5zZmVy IFByb3RvY29sIiwgUkZDDQ0KICAgICAgICAgICAgICAgICAgIDI4MjEsIEFw cmlsIDIwMDEuDQ0KDQ0KDQ0KTGVpYnpvbiAgICAgICAgICAgICAgICBFeHBp cmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTVd DQ0KDQ0KICAgICAgICAgIFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBvZiBhbiBF LW1haWwgTWVzc2FnZSAgICAgICAgT2N0b2JlciAyMDA0DQ0KDQ0KDQ0KICAg IFtTTVRQQVVUSF0gICAgIE1leWVycywgSi4sICJTTVRQIFNlcnZpY2UgRXh0 ZW5zaW9uIGZvcg0NCiAgICAgICAgICAgICAgICAgICBBdXRoZW50aWNhdGlv biIsIFJGQyAyNTU0LCBNYXJjaCAxOTk5Lg0NCg0NCiAgICBbU1BGLVBST1RP Q09MXSBXb25nLCBNIGFuZCBNLiBMZW50Y3puZXIsICJTUEYgUmVjb3JkOiBG b3JtYXQgYW5kDQ0KICAgICAgICAgICAgICAgICAgIEludGVycHJldGF0aW9u IiwgZHJhZnQtaWV0Zi1tYXJpZC1wcm90b2NvbC0wMw0NCiAgICAgICAgICAg ICAgICAgICAod29yayBpbiBwcm9ncmVzcyksIFNlcHRlbWJlciAyMDA0DQ0K DQ0KICAgIFtTVERdICAgICAgICAgIEJyYWRuZXIsIFMuLCAiSW50ZWxsZWN0 dWFsIFByb3BlcnR5IFJpZ2h0cyBpbiBJRVRGDQ0KICAgICAgICAgICAgICAg ICAgIFRlY2hub2xvZ3kiLCBCQ1AgNzksIFJGQyAzNjY4LCBGZWJydWFyeSAy MDA0Lg0NCg0NCiAgICBbU1VCTUlUXSAgICAgICBHZWxsZW5zLCBSLiBhbmQg Si4gS2xlbnNpbiwgIk1lc3NhZ2UgU3VibWlzc2lvbiIsIFJGQw0NCiAgICAg ICAgICAgICAgICAgICAyNDc2LCBEZWNlbWJlciAxOTk4Lg0NCg0NCjkuMiBJ bmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQ0KDQ0KICAgIFtBVVRILVNUQVRVU10g IEt1Y2hlcmF3eSwgTS4gUy4sICJNZXNzYWdlIEhlYWRlciBmb3IgSW5kaWNh dGluZw0NCiAgICAgICAgICAgICAgICAgICBTZW5kZXIgQXV0aGVudGljYXRp b24gU3RhdHVzIiwgZHJhZnQta3VjaGVyYXd5LXNlbmRlcg0NCiAgICAgICAg ICAgICAgICAgICAtYXV0aC1oZWFkZXItMDAgKHdvcmsgaW4gcHJvZ3Jlc3Mp LCBTZXB0ZW1iZXIgMjAwNA0NCg0NCiAgICBbRE1QXQkJIEZlY3lrIEcuLCAi RGVzaWduYXRlZCBNYWlsZXJzIFByb3RvY29sIiwNDQogICAgICAgICAgICAg ICAgICAgZHJhZnQtZmVjeWstZG1wLTAyLnR4dCAod29yayBpbiBwcm9ncmVz cyksIE1heSAyMDA0DQ0KDQ0KICAgIFtSTVhdICAgICAgICAgIERhbmlzY2gs IEguLCAiVGhlIFJNWCBETlMgUlIgYW5kIG1ldGhvZCBmb3IgbGlnaHR3ZWln aHQNDQogICAgICAgICAgICAgICAgICAgU01UUCBzZW5kZXIgYXV0aG9yaXph dGlvbiIsIGRyYWZ0LWRhbmlzY2gtZG5zLXJyLQ0NCiAgICAgICAgICAgICAg ICAgICBzbXRwLTA0ICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMDQNDQoN DQogICAgW0dyZWVuXSAgICAgICAgR3JlZW4sIEQuLCAiRG9tYWluLUF1dGhv cml6ZWQgU01UUCBNYWlsIiwNDQogICAgICAgICAgICAgICAgICAgaHR0cDov L29wcy5pZXRmLm9yZy9saXN0cy9uYW1lZHJvcHBlcnMvDQ0KICAgICAgICAg ICAgICAgICAgIG5hbWVkcm9wcGVycy4yMDAyL21zZzAwNjU2Lmh0bWwsIEp1 bmUgMjAwMg0NCg0NCiAgICBbVml4aWVdICAgICAgICBWaXhpZSwgUC4sICJS ZXB1ZGlhdGluZyBNYWlsLUZyb20iLA0NCiAgICAgICAgICAgICAgICAgICBo dHRwOi8vb3BzLmlldGYub3JnL2xpc3RzL25hbWVkcm9wcGVycy8NDQogICAg ICAgICAgICAgICAgICAgbmFtZWRyb3BwZXJzLjIwMDIvbXNnMDA2NTguaHRt bCwgSnVuZSAyMDAyDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0K DQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KTGVpYnpvbiAgICAgICAgICAg ICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgICAg W1BhZ2UgMTZdDQ0KDQ0KICAgICAgICAgIFJlc3BvbnNpYmxlIFN1Ym1pdHRl ciBvZiBhbiBFLW1haWwgTWVzc2FnZSAgICAgICAgT2N0b2JlciAyMDA0DQ0K DQ0KDQ0KMTAuIEFja25vd2xlZGdtZW50cw0NCg0NCiAgIFRoaXMgdGV4dCBp cyBiYXNlZCBwcmltYXJpbHkgb24gZHJhZnQtaWV0Zi1tYXJpZC1zdWJtaXR0 ZXItMDMNDQogICBkb2N1bWVudCB3cml0dGVuIGJ5IEVyaWMgQWxsbWFuIGFu ZCBIYXJyeSBLYXR6IGFuZCBpbiBwYXJ0IG9uIA0NCiAgIGRyYWZ0LWlldGYt bWFyaWQtY29yZS0wMyB3cml0dGVuIGJ5IEppbSBMeW9uIGFuZCBNZW5nIFdl bmcgV29uZw0NCg0NCiAgIFRoZSBpZGVhIG9mIHVzaW5nIGEgRE5TIHJlY29y ZCB0byBjaGVjayB0aGUgbGVnaXRpbWFjeSBvZiBhbiBlbWFpbA0NCiAgIHdh cyBwcmV2aW91c2x5IGRpc2N1c3NlZCBpbiBbUk1YXSBkcmFmdCBieSBIYWRt dXQgRGFuaXNjaCBhbmQgaW4NDQogICBbRE1QXSBkcmFmdCBieSBHb3Jkb24g RmVjeWsuIFRoaXMgaWRlYSB0cmFjZXMgaXRzIGFuY2VzdHJ5IHRvDQ0KICAg IlJlcHVkaWF0aW5nIE1haWwtRnJvbSIgW1ZpeGllXSBkcmFmdCBieSBQYXVs IFZpeGllICh3aG8gYmFzZWQgaXQNDQogICBvbiBzdWdnZXN0aW9uIGJ5IEpp bSBNaWxsZXIpIGFuZCB0byAiRG9tYWluLUF1dGhvcml6ZWQgU01UUCBNYWls Ig0NCiAgIFtHcmVlbl0gZHJhZnQgYnkgRGF2aWQgR3JlZW4gd2hvIGZpcnN0 IGludHJvZHVjZWQgdGhpcyBjb25jZXB0IG9uDQ0KICAgbmFtZWRyb3BwZXJz IG1haWxsaXN0IGluIDIwMDIuDQ0KDQ0KICAgVGhlIGF1dGhvciB3b3VsZCBh bHNvIGxpa2UgdG8gdGhhbmsgYWxsIHRoZSBwYXJ0aWNpcGFudHMgb2YgdGhl IElFVEYNDQogICBNQVJJRCB3b3JraW5nIGdyb3VwIGFuZCBTUEYtZGlzY3Vz cyBtYWlsIGxpc3QuIFNwZWNpYWwgcmVjb2duaXRpb24gaXMNDQogICBvd2Vk IHRvIHRoZSBmb2xsb3dpbmcgaW5kaXZpZHVhbHMgZm9yIHRoZWlyIGNvbW1l bnRzIGFuZCBzdWdnZXN0aW9ucw0NCiAgIG9uIHRoZSBjb25jZXB0cyB0aGF0 IHdlbnQgaW50byB0aGlzIGRvY3VtZW50Og0NCg0NCiAgICAgUm9iZXJ0IEF0 a2luc29uLCBTaW1vbiBBdHR3ZWxsLCBSb3kgQmFkYW1pLCBHcmVnIENvbm5v ciwgTmVkIEZyZWVkLA0NCiAgICAgRGF2ZSBDcm9ja2VyLCBNYXR0aGV3IEVs dmV5LCBUb255IEZpbmNoLCBNYXJrIExlbnRjem5lciwgSmltIEx5b24sDQ0K ICAgICBCcnVjZSBNY01pbGxhbiwgU2FtIE5lZWx5LCBEYXJ5bCBPZG5lcnQs IE1lbmcgV2VuZyBXb25nLA0NCiAgICAgTWFyZ2FyZXQgT2xzb24sIFBldGUg UmVzbmljaywgSGVjdG9yIFNhbnRvcywgTmljayBTaGVsbmVzcywNDQogICAg IFJhbmQgV2Fja2VyLCBBbmRyZXcgTmV3dG9uLCBKaW0gRmVudG9uLCBTdGVw aGFuZSBCb3J0em1leWVyLg0NCg0NCg0NCjExLiBBdXRob3JzJyBBZGRyZXNz ZXMNDQoNDQogICBXaWxsaWFtIExlaWJ6b24NDQogICBFbGFuIE5ldHdvcmtz DQ0KICAgNTAwIExhdXJlbHdvb2QgUmQsIFN1aXRlIDEyDQ0KICAgU2FudGEg Q2xhcmEsIENBIDk1MDU0DQ0KICAgVVNBDQ0KDQ0KICAgRS1tYWlsOiB3aWxs aWFtQGVsYW4ubmV0ICAgDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0K DQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KDQ0KTGVpYnpvbiAgICAgICAgICAgICAg ICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgMTddDQ0KDQ0KICAgICAgICAgIFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBv ZiBhbiBFLW1haWwgTWVzc2FnZSAgICAgICAgT2N0b2JlciAyMDA0DQ0KDQ0K DQ0KMTIuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0NCg0NCiAgIENvcHly aWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQpLiAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0DQ0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5z ZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4IGFuZA0N CiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMg cmV0YWluIGFsbCB0aGVpciByaWdodHMuDQ0KDQ0KICAgVGhpcyBkb2N1bWVu dCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHBy b3ZpZGVkIG9uIGFuDQ0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRS SUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQ0K ICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQg U09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQ0KICAgRU5HSU5FRVJJTkcgVEFT SyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJ TVBMSUVELA0NCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNDQogICBJTkZPUk1BVElP TiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkg SU1QTElFRA0NCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9S IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0NCg0NCiAgIElu dGVsbGVjdHVhbCBQcm9wZXJ0eQ0NCg0NCiAgIFRoZSBJRVRGIHRha2VzIG5v IHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2Yg YW55DQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhl ciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkDQ0KICAgdG8gcGVydGFp biB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9s b2d5IGRlc2NyaWJlZA0NCiAgIGluIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4 dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0N CiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2Vz IGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0NCiAgIG1hZGUgYW55IGluZGVw ZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuIElu Zm9ybWF0aW9uDQ0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0 IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0NCiAgIGZvdW5k IGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0NCg0NCiAgIENvcGllcyBvZiBJUFIg ZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQg YW55DQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2 YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0NCiAgIGF0dGVtcHQgbWFk ZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBm b3IgdGhlIHVzZSBvZg0NCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5 IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQ0KICAgc3BlY2lmaWNh dGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQ UiByZXBvc2l0b3J5IGF0DQ0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIu DQ0KDQ0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0 eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0NCiAgIGNvcHlyaWdo dHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIg cHJvcHJpZXRhcnkNDQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5v bG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNDQogICB0 aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9u IHRvIHRoZSBJRVRGIGF0IGlldGYtDQ0KICAgaXByQGlldGYub3JnLg0NCg0N Cg0NCkFja25vd2xlZGdlbWVudA0NCg0NCiAgIEZ1bmRpbmcgZm9yIHRoZSBS RkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0 aGUNDQogICBJbnRlcm5ldCBTb2NpZXR5Lg0NCg0NCg0NCg0NCg0NCg0NCg0N Cg0NCg0NCg0NCkxlaWJ6b24gICAgICAgICAgICAgICAgRXhwaXJlcyAtIEFw cmlsIDIwMDUgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE4XSAgIA0NCg== ---1747400512-1662785239-1096309698=:1935-- From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 15:29: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 PAA24826 for ; Mon, 27 Sep 2004 15:29:32 -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 i8RIqSXw010144; Mon, 27 Sep 2004 11:52: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 i8RIqSrR010143; Mon, 27 Sep 2004 11:52:28 -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 i8RIqPpp010126 for ; Mon, 27 Sep 2004 11:52:27 -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 i8RJ6XLN010887; Mon, 27 Sep 2004 12:06:33 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8RJ6XhZ010884; Mon, 27 Sep 2004 12:06:33 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 27 Sep 2004 12:06:33 -0700 (PDT) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: ietf-mxcomp@imc.org Subject: Processed-By (or Transmitted-By) header concept 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: I also started working on draft that tries to deal with a problem that when email message passes through forwarders, email lists and other similar systems those systems make changes to important email headers and to envelope and its difficult to tell at later time what changes they have made (or if these changes happened at all) and who is to be considered responsible for making these changes. The concept introduces new header "Processed-By" (alternative name "Transmitted-By", let me know which name you like better) and this header is to be used to list name of the system making changes to email message, email address of responsible party and list of headers that are being changed. Together with it introduced are Original-???? headers which are to be used to preserve original values of the headers that are being changed. For RFC2821 envelope parameters that are changed Original-Envelope-??? headers can be used. Additionally "New-????" headers maybe used to list how these headers were changed (this is intended primarily for RFC2821 envelope data). It is intended that Processed-By header would be added by any system that is changing destination of email message or its source. Below I'm going to give some example of how these header might be used by forwarders and by email lists, etc: ---------------------------------------------------------------------- 1. Mail List (changes to envelope and to header to and sender): Processed-By: odin.ietf.org (ip=[132.151.1.176]) on-behalf-of ietf@megatron.ietf.org changes-to List-ID,Sender,CC, Envelope-Recepient,Envelope-ReturnPath,Envelope-Submitter process-type maillist (list-id=) ; New-Envelope-Recepient: william@elan.net New-Envelope-ReturnPath: ietf@ietf.org New-Envelope-Submitter: ietf@ietf.org Original-Envelope-Recepient: ietf@ietf.org Original-Envelope-ReturnPath: user@example.com Original-Envelope-Submitter: user@example.com Original-To: ietf@ietf.org Original-Sender: secretary@example.org 2. Forwarding system that does not change RFC2821 Mail From Processed-By: mail.forwader-example.com (ip=[10.0.0.10]) on-behalf-of my.forwarding.address@forwarder-example.com changes-to Envelope-Recepient,Envelope-Submitter process-type forwarding New-Envelope-Recepient: william@elan.net New-Envelope-Submitter: my.forwarding.address@forwarder-example.com Original-Envelope-Recepient: my.forwarding.address@forwader-example.com Original-Envelope-Submitter: user@sender-example.com 3. An outgoing SMTP proxy system that sits in the hotel and is to be used by all guests (sets Sender header and RFC2821 submitter) Processed-By: proxy.hotel-example.com (ip=[10.0.0.10]) on-behalf-of postmaster@hotel-example.com changes-to Sender,Envelope-Submitter process-type smtp-proxy New-Envelope-Submitter: postmaster@hotel-example.com Original-Envelope-Submitter: user@sender-example.com Original-Sender: secretary@example.org ---------------------------------------------------------------------- Please let me know what you think of this concept and if you think it would be usefull and send me your comments and suggestions. And I do expect to have draft available describing this within one or two weeks. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 16:10: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 QAA27381 for ; Mon, 27 Sep 2004 16:10: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 i8RJdSCa014609; Mon, 27 Sep 2004 12:39: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 i8RJdSWW014608; Mon, 27 Sep 2004 12:39:28 -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 i8RJdSSk014602 for ; Mon, 27 Sep 2004 12:39:28 -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 4B456414C5; Mon, 27 Sep 2004 12:39:32 -0700 (PDT) Subject: Re: Processed-By (or Transmitted-By) header concept From: Douglas Otis To: "william(at)elan.net" Cc: spf-discuss@v2.listbox.com, MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1096313971.26214.54.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 27 Sep 2004 12:39:32 -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 Mon, 2004-09-27 at 12:06, william(at)elan.net wrote: > I also started working on draft that tries to deal with a problem that > when email message passes through forwarders, email lists and other > similar systems those systems make changes to important email headers > and to envelope and its difficult to tell at later time what changes > they have made (or if these changes happened at all) and who is to be > considered responsible for making these changes. > > The concept introduces new header "Processed-By" (alternative name > "Transmitted-By", let me know which name you like better) and this > header is to be used to list name of the system making changes to > email message, email address of responsible party and list of > headers that are being changed. Together with it introduced are > Original-???? headers which are to be used to preserve original > values of the headers that are being changed. For RFC2821 envelope > parameters that are changed Original-Envelope-??? headers can be used. > Additionally "New-????" headers maybe used to list how these headers > were changed (this is intended primarily for RFC2821 envelope data). > > It is intended that Processed-By header would be added by any > system that is changing destination of email message or its source. > > Below I'm going to give some example of how these header might > be used by forwarders and by email lists, etc: > > ---------------------------------------------------------------------- > 1. Mail List (changes to envelope and to header to and sender): > > Processed-By: odin.ietf.org (ip=[132.151.1.176]) > on-behalf-of ietf@megatron.ietf.org > changes-to List-ID,Sender,CC, > Envelope-Recepient,Envelope-ReturnPath,Envelope-Submitter > process-type maillist (list-id=) ; > New-Envelope-Recepient: william@elan.net > New-Envelope-ReturnPath: ietf@ietf.org > New-Envelope-Submitter: ietf@ietf.org > Original-Envelope-Recepient: ietf@ietf.org > Original-Envelope-ReturnPath: user@example.com > Original-Envelope-Submitter: user@example.com > Original-To: ietf@ietf.org > Original-Sender: secretary@example.org > > 2. Forwarding system that does not change RFC2821 Mail From > > Processed-By: mail.forwader-example.com (ip=[10.0.0.10]) > on-behalf-of my.forwarding.address@forwarder-example.com > changes-to Envelope-Recepient,Envelope-Submitter > process-type forwarding > New-Envelope-Recepient: william@elan.net > New-Envelope-Submitter: my.forwarding.address@forwarder-example.com > Original-Envelope-Recepient: my.forwarding.address@forwader-example.com > Original-Envelope-Submitter: user@sender-example.com > > > 3. An outgoing SMTP proxy system that sits in the hotel and is to > be used by all guests (sets Sender header and RFC2821 submitter) > > Processed-By: proxy.hotel-example.com (ip=[10.0.0.10]) > on-behalf-of postmaster@hotel-example.com > changes-to Sender,Envelope-Submitter > process-type smtp-proxy > New-Envelope-Submitter: postmaster@hotel-example.com > Original-Envelope-Submitter: user@sender-example.com > Original-Sender: secretary@example.org > ---------------------------------------------------------------------- > > Please let me know what you think of this concept and if you think it > would be usefull and send me your comments and suggestions. And I do > expect to have draft available describing this within one or two weeks. Assuming any identity added will need to undergo authentication, how would this identity be substantially different than that already possible employing the EHLO domain? This EHLO information is already present within the initial exchange and recorded within the messages headers. Once authenticated, this EHLO name allows safe mail channel assertions without the need to obtain an extensive address list. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 16:12: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 QAA27518 for ; Mon, 27 Sep 2004 16:12: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 i8RJh6NA014825; Mon, 27 Sep 2004 12:43: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 i8RJh6Db014824; Mon, 27 Sep 2004 12:43: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 i8RJh5Dk014809 for ; Mon, 27 Sep 2004 12:43: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 i8RJvET5017182; Mon, 27 Sep 2004 12:57:14 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8RJvEi5017179; Mon, 27 Sep 2004 12:57:14 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 27 Sep 2004 12:57:14 -0700 (PDT) From: "william(at)elan.net" To: Douglas Otis cc: spf-discuss@v2.listbox.com, MARID Subject: Re: Processed-By (or Transmitted-By) header concept In-Reply-To: <1096313971.26214.54.camel@ddev.mail-abuse.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Assuming any identity added will need to undergo authentication, how > would this identity be substantially different than that already > possible employing the EHLO domain? This EHLO information is already > present within the initial exchange and recorded within the messages > headers. Once authenticated, this EHLO name allows safe mail channel > assertions without the need to obtain an extensive address list. Processed-By and Original- and New- are not identity headers. They are all trace headers (like Received and Return-Path) intended to be used by email agents that have made changes to either destination or source (this being either the envelope parameters and rfc2822 email address headers) of email transmission and would like a standard way to record this information in email message -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 17:04:09 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 RAA07502 for ; Mon, 27 Sep 2004 17:04: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 i8RKUAnu017898; Mon, 27 Sep 2004 13:30:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RKUABv017897; Mon, 27 Sep 2004 13:30:10 -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 i8RKUAW7017889 for ; Mon, 27 Sep 2004 13:30: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 2DB55414C5; Mon, 27 Sep 2004 13:30:15 -0700 (PDT) Subject: Re: Processed-By (or Transmitted-By) header concept From: Douglas Otis To: "william(at)elan.net" Cc: spf-discuss@v2.listbox.com, MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1096317014.26214.72.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 27 Sep 2004 13:30:15 -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 Mon, 2004-09-27 at 12:57, william(at)elan.net wrote: > > Assuming any identity added will need to undergo authentication, how > > would this identity be substantially different than that already > > possible employing the EHLO domain? This EHLO information is already > > present within the initial exchange and recorded within the messages > > headers. Once authenticated, this EHLO name allows safe mail channel > > assertions without the need to obtain an extensive address list. > > Processed-By and Original- and New- are not identity headers. > They are all trace headers (like Received and Return-Path) intended > to be used by email agents that have made changes to either destination > or source (this being either the envelope parameters and rfc2822 email > address headers) of email transmission and would like a standard way to > record this information in email message Should the EHLO domain be authenticated, then whether a change has been made to any headers or not still allows the message source to be traced. The EHLO domain can be selectively presented based upon a desire to reference a particular domain. The authentication of the EHLO domain also allows the mailbox domain a simply reference to a name list as a means to indicate the nominal mail channel without risk of this information being exploited. Such an exploit is possible with SPF or Sender-ID, especially where the lists are left open and yet used within a gate-keeper function. It would make it easier if you could describe the problem being solved. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 19:16: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 TAA19302 for ; Mon, 27 Sep 2004 19:16: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 i8RMpVdU028308; Mon, 27 Sep 2004 15:51:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RMpVg1028307; Mon, 27 Sep 2004 15:51:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.76.151] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RMpU8C028299 for ; Mon, 27 Sep 2004 15:51:30 -0700 (PDT) (envelope-from jimlyon@exchange.microsoft.com) Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Mon, 27 Sep 2004 15:51:27 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Sep 2004 15:51:24 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7408.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Alternatives drafts for SUBMITTER identity Date: Mon, 27 Sep 2004 15:51:36 -0700 Message-ID: Thread-Topic: Alternatives drafts for SUBMITTER identity thread-index: AcSkwh/ualkj3/YKTc6LCct+zJQPmAAIl4rw From: "Jim Lyon" To: "william\(at\)elan.net" , Cc: X-OriginalArrivalTime: 27 Sep 2004 22:51:24.0424 (UTC) FILETIME=[83D13080:01C4A4E4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8RMpU8C028300 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit William, Regarding draft-leibzon-responsible-submitter-00, please pick a name other than SUBMITTER for the SMTP extension and parameter. It will be a real mess if we have two competing documents specifying different definitions for the same extension. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 20:24:24 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 UAA25699 for ; Mon, 27 Sep 2004 20: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 i8RNuZ8g032278; Mon, 27 Sep 2004 16:56: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 i8RNuZKi032277; Mon, 27 Sep 2004 16:56:35 -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 i8RNuYZZ032269 for ; Mon, 27 Sep 2004 16:56:34 -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 i8S0AbMC031814; Mon, 27 Sep 2004 17:10:37 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8S0AbrL031811; Mon, 27 Sep 2004 17:10:37 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 27 Sep 2004 17:10:37 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: ietf-mxcomp@imc.org, Subject: RE: Alternatives drafts for SUBMITTER identity 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 Mon, 27 Sep 2004, Jim Lyon wrote: > William, > > Regarding draft-leibzon-responsible-submitter-00, please pick a name > other than SUBMITTER for the SMTP extension and parameter. It will be a > real mess if we have two competing documents specifying different > definitions for the same extension. 1. Its actually quite easy to make marid-submitter draft to be compatible with my responsible-submitter draft. Major thing that is necessary is to require double-checking on if SUBMITTER value is same as your PRA (derived from headers) ONLY IF there is spf2.0/pra policy record available for domain part of SUBMITTER. In such a case, you can assume that known that on his network all servers that use SUBMITTER also comply with Sender ID and added whatever headers you like, where as if they published spf2.0/submit scope records you can assume they might not have done so. The only other issue of some importance is that in my responsible-submitter draft, the recomendation for smtp proxy servers (as in hotel "Guest E-Mail Service" example) is to add Sender header where as in marid-submitter it said that Resent-From is to be used. For all other cases I conviniently avoided specifying what exactly are supposed to be headers added (although you'll see a definitive recomendation about that in my next draft). 2. As per above my recomendation in regards to resolving difference between marid-submitter and responsible-submitter is to have you rewrite your concept to reference responsible-submitter instead of marid-submitter. You can do it by rewriting new core+PRA draft so that it requires checking of RFC2822 headers PRA value only if SPF2.0/pra policy record is published. In such case you can write also that such PRA MUST be equivalent to SUBMITTER when it is present during SMTP session and make recomendation for MTAs to verify SUBMITTER parameter value based on either SPF2.0/pra or SPF2.0/submit policy record during SMTP session. Basicly what I'm asking is for you to consider rewrite of Sender ID concept where it references submitter-draft instead of submitter referencing marid-core and pra. Both are equivalent ways of doing the same concept and should be able to coexist. 3. Unless you make changes to SenderID drafts as I recommended above, I would have absolutly no problem in giving IETF directorate and implementors a choice between what they want to accept and use: - an encoumbered solution that is based upon incorrect use of existing RFC2822 concepts and has IPR requirement that does not allow to be used in open-source SMTP servers OR - a solution that is entirely within RFC2821 framework and does not break existing SMTP standards and does not have patent problems (as long as we assume that SPF classic which is also RFC2821 does not have have similar patent issues) --- 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 Sep 27 21:00: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 VAA27828 for ; Mon, 27 Sep 2004 21:00:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8S0Jplr033695; Mon, 27 Sep 2004 17:19: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 i8S0Jp4x033694; Mon, 27 Sep 2004 17:19:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.76.149] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8S0JkuF033668 for ; Mon, 27 Sep 2004 17:19:51 -0700 (PDT) (envelope-from jimlyon@exchange.microsoft.com) Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Mon, 27 Sep 2004 17:19:33 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Sep 2004 17:19:34 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7408.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Alternatives drafts for SUBMITTER identity Date: Mon, 27 Sep 2004 17:20:08 -0700 Message-ID: Thread-Topic: Alternatives drafts for SUBMITTER identity thread-index: AcSk7amk3raGwkZVTUWWmfdlcSlRtAAAYs+w From: "Jim Lyon" To: "william\(at\)elan.net" Cc: , X-OriginalArrivalTime: 28 Sep 2004 00:19:34.0575 (UTC) FILETIME=[D4FE2BF0:01C4A4F0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8S0JpuF033689 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit William, SUBMITTER as defined by your draft is a different concept than SUBMITTER as defined by draft-ietf-marid-submitter-xx. Related, but different. Your argument is that all would be well if we dropped the semantics specified by draft-ietf-marid-submiter, and changed the specs to use the semantics you supply. While this might make everything fine from your perspective, it doesn't from mine. I for one decline your invitation. Your comment that we should give the IETF and implementers a choice about which to use is exactly on point. The easiest way to do so is to have different extensions, so that MTAs in conversation know exactly what is meant by each other. Since the name SUBMITTER is already in use by draft-ietf-marid-submitter, please choose another name. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Mon Sep 27 21:00: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 VAA27845 for ; Mon, 27 Sep 2004 21:00: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 i8S0f6FF035373; Mon, 27 Sep 2004 17:41:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8S0f6TN035371; Mon, 27 Sep 2004 17:41: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 i8S0f5r8035364 for ; Mon, 27 Sep 2004 17:41: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 i8S0tIXn002777; Mon, 27 Sep 2004 17:55:18 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8S0tHTZ002774; Mon, 27 Sep 2004 17:55:17 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 27 Sep 2004 17:55:17 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: ietf-mxcomp@imc.org, Subject: RE: Alternatives drafts for SUBMITTER identity 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 Mon, 27 Sep 2004, Jim Lyon wrote: > William, > > SUBMITTER as defined by your draft is a different concept than SUBMITTER > as defined by draft-ietf-marid-submitter-xx. Related, but different. I disagree especially since I used exactly the same text as in marid-core and marid-submitter to specify this concept. > Your argument is that all would be well if we dropped the semantics > specified by draft-ietf-marid-submiter, and changed the specs to use the > semantics you supply. While this might make everything fine from your > perspective, it doesn't from mine. I for one decline your invitation. Your choice... > Your comment that we should give the IETF and implementers a choice > about which to use is exactly on point. The easiest way to do so is to > have different extensions, so that MTAs in conversation know exactly > what is meant by each other. I do not believe that MTAs would ever specify different SUBMITTER value based on the text of these drafts, so having them add two different submitter parameters with exactly same value during MAIL is just not necessary. > Since the name SUBMITTER is already in use by > draft-ietf-marid-submitter, please choose another name. If IESG makes recomendation to me at later point to make changes to semantics and name, I'll of course do so, but it'll not happen at this time. --- Again I invite you to reconsider the issues of difference and invite you to work together on something that will be acceptable to both FOSS world and those who want to support Microsoft solution while allowing both to share in common points, concepts and semantics. I note that when putting this draft together I specifially took parts of the SenderID that did not have any major technical or IPR issues as such I consider those to be a subpart that is the closest to having had consensus of the working group. Considering that responsible-submitter represents a subpart of former SenderID concept, it should be fairly easy for you to extend on these parts and this would allow everyone to benefit from the former MARID concepts and to have shared common parts (like we have with SPF record format) instead of trying to force a complete choice. --- 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 Sep 27 21:30: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 VAA29247 for ; Mon, 27 Sep 2004 21:30: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 i8S0xpWv036335; Mon, 27 Sep 2004 17:59: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 i8S0xpAM036334; Mon, 27 Sep 2004 17:59:51 -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.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8S0xnCZ036328 for ; Mon, 27 Sep 2004 17:59:50 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.2) for ietf-mxcomp@imc.org; Mon, 27 Sep 2004 21:04:57 -0400 Received: from ([65.10.117.66]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.2) with SMTP id 2503894937; Mon, 27 Sep 2004 21:04:55 -0400 Message-ID: <010001c4a4f5$ec95ce80$6401a8c0@hdev1> From: "Hector Santos" To: "william\(at\)elan.net" , "Jim Lyon" Cc: , References: Subject: Re: Alternatives drafts for SUBMITTER identity Date: Mon, 27 Sep 2004 20:55:58 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 William, I agree with Jim from the standpoint there is a conflict here in regards to "protesting" a patent application, yet at the same time, giving it some level of credence. In my view, this plays into the favor of the patentee. I should note that I don't believe there is a claim to be made to restrict the usage of the ESMTP return path modifier, hence for this reason and many other similar reasons along the same line, the patent applications have little to no enforcement quality. It really doesn't any deserve any more attention that it already got. I should also note MS simply has no say over SPF. As a early implementer of SPF in our commercial mail products, rest assured that legal and IP issues were fully examined before SPF were considered at the time, which was clearly before any MS introduction into the picture. The legal facts are such; SPF, which is based on prior art itself, was introduced in early 2003, making it not eligible for patentability today, and therefore can not be claimed by anyone also with current applications. Rest assured, if this was not the case, and indeed MS does have a claim to SPF, it would be PULLED immediately from our product line and we would investigate the legal avenue to recoup the lost of development and engineering cost put into it over the last year. This is why I am fully confident there is nothing to worry about here as far as SPF. With that said, if an alternative is being pursued, don't approach it with a MS angle Approach it from the standpoint of SMTP purity and basic operations. These are elements that are natural to all parties, with standard and/or BCP in place. This is what needs to be part of any protest information provided to the patent examiner. It will help him examine the Muskush-type claims of these applications to see that there is a community between all claims that without these common elements, not only will the patent process will not work, but the industry will fail to function as well. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "william(at)elan.net" To: "Jim Lyon" Cc: ; Sent: Monday, September 27, 2004 8:10 PM Subject: RE: Alternatives drafts for SUBMITTER identity > > > On Mon, 27 Sep 2004, Jim Lyon wrote: > > > William, > > > > Regarding draft-leibzon-responsible-submitter-00, please pick a name > > other than SUBMITTER for the SMTP extension and parameter. It will be a > > real mess if we have two competing documents specifying different > > definitions for the same extension. > > 1. Its actually quite easy to make marid-submitter draft to be > compatible with my responsible-submitter draft. Major thing > that is necessary is to require double-checking on if SUBMITTER > value is same as your PRA (derived from headers) ONLY IF there > is spf2.0/pra policy record available for domain part of SUBMITTER. > In such a case, you can assume that known that on his network all > servers that use SUBMITTER also comply with Sender ID and added > whatever headers you like, where as if they published spf2.0/submit > scope records you can assume they might not have done so. > > The only other issue of some importance is that in my > responsible-submitter draft, the recomendation for smtp proxy > servers (as in hotel "Guest E-Mail Service" example) is to add > Sender header where as in marid-submitter it said that Resent-From > is to be used. For all other cases I conviniently avoided specifying > what exactly are supposed to be headers added (although you'll > see a definitive recomendation about that in my next draft). > > 2. As per above my recomendation in regards to resolving difference > between marid-submitter and responsible-submitter is to have you > rewrite your concept to reference responsible-submitter instead > of marid-submitter. You can do it by rewriting new core+PRA > draft so that it requires checking of RFC2822 headers PRA value > only if SPF2.0/pra policy record is published. In such case you > can write also that such PRA MUST be equivalent to SUBMITTER when > it is present during SMTP session and make recomendation for MTAs > to verify SUBMITTER parameter value based on either SPF2.0/pra or > SPF2.0/submit policy record during SMTP session. > > Basicly what I'm asking is for you to consider rewrite of > Sender ID concept where it references submitter-draft instead of > submitter referencing marid-core and pra. Both are equivalent > ways of doing the same concept and should be able to coexist. > > 3. Unless you make changes to SenderID drafts as I recommended above, > I would have absolutly no problem in giving IETF directorate and > implementors a choice between what they want to accept and use: > - an encoumbered solution that is based upon incorrect use of existing > RFC2822 concepts and has IPR requirement that does not allow to be > used in open-source SMTP servers OR > - a solution that is entirely within RFC2821 framework and does not > break existing SMTP standards and does not have patent problems > (as long as we assume that SPF classic which is also RFC2821 does > not have have similar patent issues) > > --- > 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 Sep 27 22:00: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 WAA01830 for ; Mon, 27 Sep 2004 22:00: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 i8S1VTC1038368; Mon, 27 Sep 2004 18:31:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8S1VT6Q038367; Mon, 27 Sep 2004 18:31:29 -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 i8S1VSli038361 for ; Mon, 27 Sep 2004 18:31:28 -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 i8S1jfwo007981; Mon, 27 Sep 2004 18:45:41 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8S1jf1k007978; Mon, 27 Sep 2004 18:45:41 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 27 Sep 2004 18:45:41 -0700 (PDT) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: ietf-mxcomp@imc.org Subject: Re: [spf-discuss] Re: Alternative draft for SUBMITTER identity In-Reply-To: <010001c4a4f5$ec95ce80$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 Mon, 27 Sep 2004, Hector Santos wrote: > William, > > I agree with Jim from the standpoint there is a conflict here in regards to > "protesting" a patent application, yet at the same time, giving it some > level of credence. In my view, this plays into the favor of the patentee. How so? I took the draft that Microsoft has no IPR claims on (since Microsoft person was co-author, if it was not so, he would have had to file IPR document in regards to that draft). However that draft in itself was referencing as requirement another draft (PRA) that had known IPR issues. I removed the requirement of Submitter identity being the same as patent-encumbered PRA identity and made SUBMITTER to be purely RFC2821 identity on part with ReturnPath. Situation is such that Microsoft can not claim have patent claims on this draft unless it is at the same time willing to put claims on SPF (which as you say they will not be able to do). So the result is that we have subpart of SenderID that: 1. Provides information about entity that was last involved in reintroduction of message into transport stream. This is what many wanted. 2. Does not require checking RFC2822 headers to find this identity. 3. Does not require forwarders to add new headers in a way that is not compatible with RFC2822 5. Can be implemented by every MTA no matter if they can use GNU license or commercial license for their product This is not in conflict with Microsoft SenderID concept as that can be easily build upon it by requirying finding PRA identity from headers to be the same as SUBMITTER identity. To make certain that is what publisher wanted to be checked it is easily possible to do it by means of SPF policy records which do use different scope. I note that, as indicated in another post, I made best effort to take concepts of SenderID that did not have any major technical or IPR issues. I believe this allows the concept to be implemented worldwide while if that is not done, we'd have situation that Responsible Submitter identity would not be provided by majority of MTA servers. What I have done should in fact greatly help Microsoft itself by allowing Responsible Submitter identity to be present and certainly determined in a lot more cases then what it otherwise would have been. --- 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 Sep 27 22:49: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 WAA03833 for ; Mon, 27 Sep 2004 22:49: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 i8S2M0xv041501; Mon, 27 Sep 2004 19:22:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8S2M09O041500; Mon, 27 Sep 2004 19:22:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8S2Lx54041494 for ; Mon, 27 Sep 2004 19:21:59 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i8S2WUUX009959; Mon, 27 Sep 2004 22:32:31 -0400 From: To: "'Jim Lyon'" , "'william(at)elan.net'" Cc: , Subject: OT: RE: Alternatives drafts for SUBMITTER identity Date: Mon, 27 Sep 2004 22:19:40 -0400 Message-ID: <002e01c4a501$9c8aa9e0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002F_01C4A4E0.157909E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Importance: Normal X-MS-TNEF-Correlator: 00000000C8689303D474D71196E900201855F5B324FFFF02 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C4A4E0.157909E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Well now that's ironic, MS asking someone to "not use/change something someone else defined". What's next, MS saying "please don't use FUD"? :) Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Jim Lyon > Sent: Monday, September 27, 2004 8:20 PM > To: william(at)elan.net > Cc: ietf-mxcomp@imc.org; spf-discuss@v2.listbox.com > Subject: RE: Alternatives drafts for SUBMITTER identity > > > > William, > > SUBMITTER as defined by your draft is a different concept > than SUBMITTER > as defined by draft-ietf-marid-submitter-xx. Related, but different. > > Your argument is that all would be well if we dropped the semantics > specified by draft-ietf-marid-submiter, and changed the specs > to use the > semantics you supply. While this might make everything fine from your > perspective, it doesn't from mine. I for one decline your invitation. > > Your comment that we should give the IETF and implementers a choice > about which to use is exactly on point. The easiest way to > do so is to > have different extensions, so that MTAs in conversation know exactly > what is meant by each other. > > Since the name SUBMITTER is already in use by > draft-ietf-marid-submitter, please choose another name. > > > -- Jim Lyon > ------=_NextPart_000_002F_01C4A4E0.157909E0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IikCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHCQAbABYAEwAAAAEAKQEB A5AGAKgJAAAqAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA AAAAAwA2AAAAAAAeAHAAAQAAADMAAABPVDogUkU6IEFsdGVybmF0aXZlcyBkcmFmdHMgZm9yIFNV Qk1JVFRFUiBpZGVudGl0eQAAAgFxAAEAAAAWAAAAAcSlAZp6m/DZW92vSeWnJ0Exb8xbhwAAAgEd DAEAAAAeAAAAU01UUDpURVJSWUBHUkVBVEdVTEZIT01FUy5DT00AAAALAAEOAAAAAEAABg4AQuuD AaXEAQIBCg4BAAAAGAAAAAAAAADIaJMD1HTXEZbpACAYVfWzQoUAAAMAFA4BAAAACwAfDgEAAAAD AAYQtkN5rgMABxB7BAAAHgAIEAEAAABlAAAAV0VMTE5PV1RIQVRTSVJPTklDLE1TQVNLSU5HU09N RU9ORVRPIk5PVFVTRS9DSEFOR0VTT01FVEhJTkdTT01FT05FRUxTRURFRklORUQiV0hBVFNORVhU LE1TU0FZSU5HIlBMRQAAAAACAQkQAQAAAM8EAADLBAAAlwcAAExaRnVE4E/VAwAKAHJjcGcxMjXi MgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl 9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFCzCwkBZDM2FlALp2MBMJAgV2VsAyBubwfg0nQT 4HQnBCBpA2ADAERjLAXSYXNrC4BnVCBzA3BlAiBlHbBvrCAiHYAFQHUUEC8T0X8fIB+wH1IdwB8a HUAUECDnAQELgAmAIi4KogqECoAeVx3UH6AO0B6Tc2F5dR8SIgtQZR7gIlECICcBIDMgRlVEIj8g KCA6KSMKVASQcnlbJkAIkGwEgSMETQBwYdMg0AXAU28BgHcKwB+wyERldh1Ab3AHgAIw2R7QbmQp 0QtQbwbAKmENIwRHGCAd4CBHdWxYZiBIH2EEIC8QwHPmaB/QA6BXbwRwBCAsk7cjBA6wJ8FACcEd 4GcsUWpoLKIuBaBtCuMKgEYAYXg6ICg0MTYIKSA0MOAtOTA4RjUjCiMEPiAtMvJP/QUQZwuAB0AF 0AeQJMAg0Hsy8zJ2RgNhMLAdkB+gckYtCJAAMC1teC/hcJZAAMADEC4HcGMuBbDaZzJ2WzaSH9A6 NX82i2RdTwOgQmUT4CxhT8UscEoHcCBMeQIgMnbXBmACMDCwTQIgZCTQHpCbBmAFMGUG0BKBMjce kEEB0DA0IDg6AdAg1FBNMnZUODAgA/AdUGkHMG0oHeApHUAAcC7nH6ArdTLQQ2MwsDi6NuWqOx9A cDjgZAQAYyBQoHNAdjIuP4BzAlCMb3gv0juXdWJqBZDpPEFSRTCwQTgQBJEd4MZpKgAEIGRyYQGA BCADAhApMVVCTUlUVBxFUh4gAQACMGl0edcydkgvMoVXP2QsSK5HCPMe4CJmIGIn4DtgCHBGRNse IAQgYSJgBpBmBJAqYvkFoG5jPQFJFx3BA6BHBz8ydkxMRlM4pQrAR6Atc81EwG1H8C6RLXhD4Cag llJAAQ6wZB6QYnUFQPdOJyL1SQhZTTIKwC9AKlPvTdEdwh7QHVF3CGAoMEzgfR+wdx1CBpBYkUZB KjBwv0zBHcAg4T0wAHBF8GMuJf8y0EKQBZAGkAiQUb9SyQSQ/x6QKqIglFm1WzEEIU9WH+C/JhJZ 0VqnWiZNEh9AdVmA/Gx5U9EjwAMQX9JN0VNA5mctMGKwYWsiASoAJ9D/IUQikkawA2FNEzJ2WZAU AP9bMUXyHpBH8CWhB5Al0mRz91NAH6BT0UlGsx+SBYE/gPcfoU0jC4B2R/BF4QIgVW//VnMv4SpT V4NZIS0gWCMzcMMqAFnDSUVURiqTB3DfJUEqUmWRTfET0G8N4GAX/wGgCGBr4SFQE9Bfdk3RDsD9 ANB0YcBoEWVwbtBVQSag/lRZ4SVhCJBDoD9AJNAfwu8ydiWwH0FXQ28ydhPgbMHfTigOwQnwAJAC IHMekHQB+VeDTVQtEGkhTrJjgSTA+WmSIGsdgnD1MnZv8CwR/2KSJWAqcUzxJWBwISAgWeD6cmnf UwuATvBZwyjwB4DrRvpN4Wwr8WQn4HeBJhJ/TPBzV1wPUyYekCVFbrFv/yJBAHB7I30Te38yeDsP IwQCfYZgAAMAEBAAAAAAAwAREAEAAAAeAEIQAQAAAFEAAAA8Q0I3NDc5MUJBQ0RFODg0OEE4RjEz RDYxQjU0QzVFQzk4MUI1QUZAZGYtZmlkby1tc2cuZXhjaGFuZ2UuY29ycC5taWNyb3NvZnQuY29t PgAAAAADAACACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAKYAIIAYAAAAAAMAAAAAAAABG AAAAAFKFAADwEwAAHgAqgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AB4AK4AI IAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeACyACCAGAAAAAADAAAAAAAAARgAA AAA3hQAAAQAAAAEAAAAAAAAAHgAtgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAA AAsALoAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAvgAggBgAAAAAAwAAAAAAAAEYAAAAA AYUAAAAAAAALADCACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMYAIIAYAAAAAAMAAAAAA AABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALADOACCAGAAAA AADAAAAAAAAARgAAAAAGhQAAAAAAAAsANIALIAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA1 gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAAAAACAfgPAQAAABAAAADIaJMD1HTXEZbpACAYVfWz AgH6DwEAAAAQAAAAyGiTA9R01xGW6QAgGFX1swIB+w8BAAAATQAAAAAAAAA4obsQBeUQGqG7CAAr KlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcbWFpbFxvdXRsb29rbmV3Mi5w c3QAAAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwQzg2ODkzMDNENDc0RDcx MTk2RTkwMDIwMTg1NUY1QjMyNEZGRkYwMgAAAACHcQ== ------=_NextPart_000_002F_01C4A4E0.157909E0-- From owner-ietf-mxcomp@mail.imc.org Tue Sep 28 04:43: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 EAA06479 for ; Tue, 28 Sep 2004 04:43:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8S89XDR030889; Tue, 28 Sep 2004 01:09:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8S89XPb030888; Tue, 28 Sep 2004 01:09:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8S89Vur030852 for ; Tue, 28 Sep 2004 01:09:32 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-6.tower-82.messagelabs.com!1096358961!1943306 X-StarScan-Version: 5.2.10; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 22879 invoked from network); 28 Sep 2004 08:09:22 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-6.tower-82.messagelabs.com with SMTP; 28 Sep 2004 08:09:22 -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 ; Tue, 28 Sep 2004 09:09:25 +0100 Subject: Re: Processed-By (or Transmitted-By) header concept To: "william(at)elan.net" Cc: ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Danny Angus Date: Tue, 28 Sep 2004 09:09:25 +0100 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 28/09/2004 09:09:25 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: William, The problem I see with this is that multiple hops cannot be used in conjunction with New-xx and Original-xx headers. What you'd have to do would be to use a single header which both identifies the hop that changed the headers and records the change. Lets assume that the regular headers are rewritten and therefore contain the "new" values, so we only really need to preserve the history. That can be accomodated in the "Processed by" by simply inserting the original values for the fields logged as changed. Processed-By: odin.ietf.org (ip=[132.151.1.176]) on-behalf-of ietf@megatron.ietf.org changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue process-type maillist (list-id=) ; As for the name, call it like it is. If this is to address the issues of automatic (c.f. by a users explicit action) re-insertion of messages into the delivery system call it "Reinserted-by" But... also add a timestamp so we can accurately order these things Reinserted-By: odin.ietf.org (ip=[132.151.1.176]) on-behalf-of ietf@megatron.ietf.org changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue process-type maillist (list-id=) ; Tue, 28 Sep 2004 00:43:21 -0700 (PDT) At the end of the day though it still looks like a mechanism by which someone could fabricate a whole imagined history for a message, rather than anything upon which we could rely. d. --- Danny Angus (apache james) > Together with it introduced are > Original-???? headers which are to be used to preserve original > values of the headers that are being changed. *************************************************************************** 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 Tue Sep 28 11:33: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 LAA00042 for ; Tue, 28 Sep 2004 11:33: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 i8SEr6CW011628; Tue, 28 Sep 2004 07:53: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 i8SEr6SK011627; Tue, 28 Sep 2004 07:53:06 -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 i8SEr56Z011621 for ; Tue, 28 Sep 2004 07:53:05 -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 77322414C4; Tue, 28 Sep 2004 07:53:08 -0700 (PDT) Subject: Re: Processed-By (or Transmitted-By) header concept From: Douglas Otis To: Danny Angus Cc: "william(at)elan.net" , MARID , spf-discuss@v2.listbox.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1096383187.27129.26.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 28 Sep 2004 07:53:08 -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 Tue, 2004-09-28 at 01:09, Danny Angus wrote: > William, > > The problem I see with this is that multiple hops cannot be used in > conjunction with New-xx and Original-xx headers. > What you'd have to do would be to use a single header which both identifies > the hop that changed the headers and records the change. > > Lets assume that the regular headers are rewritten and therefore contain > the "new" values, so we only really need to preserve the history. > That can be accomodated in the "Processed by" by simply inserting the > original values for the fields logged as changed. > > Processed-By: odin.ietf.org (ip=[132.151.1.176]) > on-behalf-of ietf@megatron.ietf.org > changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, > > Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue > > process-type maillist (list-id=) ; > > As for the name, call it like it is. If this is to address the issues of > automatic (c.f. by a users explicit action) re-insertion of messages into > the delivery system call it > "Reinserted-by" > > > But... also add a timestamp so we can accurately order these things > > Reinserted-By: odin.ietf.org (ip=[132.151.1.176]) > on-behalf-of ietf@megatron.ietf.org > changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, > > Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue > > process-type maillist (list-id=) ; Tue, 28 Sep 2004 > 00:43:21 -0700 (PDT) > > At the end of the day though it still looks like a mechanism by which > someone could fabricate a whole imagined history for a message, rather than > anything upon which we could rely. Rather than attempting to chain MAIL FROM to MAIL FROM with a series of new headers there is a much easier way to arrive at your goal. (Assuming the goal is to track the user.) Although currently the HELO domain is being ignored as it is seldom authenticated, it does establish an identity which does relate to the author of the message. The HELO domain indicates their choice of provider. You can use either the MAIL FROM or the FROM mailbox domain to reference a simple name list that can be obtained in a single lookup which includes the roots for all the nominal providers for this mailbox domain. _helo.my-mailbox-domain.com. PTR my-isp.com. PTR my-other-isp.com PTR coffee-shop.com PTR hotel.com PTR office.com For more details see: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt The information you need to establish this daisy chain already exist within the current SMTP protocol. It only requires that the HELO domain authentication be repaired. (Thanks to Dave Crocker, this is being done with CSV.) And a simple name list as in the example. Unlike SPF, declaring this list "open-ended" will not invite spoofing. I assure you this technique never requires a sequence of queries as is needed for SPF. This technique provides the SAME information that could be obtained using either SPF or Sender-ID for that matter. In fact, the list could be designated to be valid for the PRA mailbox domain. Rather than using a generic label like _mpr or _helo as in the example, there could be lists such as with labels using _mailfrom, _from, or _pra for that matter. If the goal is to decide if the message is being spoofed, then this accomplish that goal in a much safer manner. Using a script to provide a comprehensive address list for a vast array of hosts will demand constant maintenance or excessive lookups. The alternative is to simply list the names of the domains being used. Even CSV just uses names and therefore does not require the address to be defined. (This is a function of the record.) The need for a parser also risks constraining the source port for the DNS query and then walking through a sequence of domain name servers is absolutely risky. Again, if you describe your goals and worry less about applying a series of band-aids, the goal can be safely achieved. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 28 14:23:04 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 OAA09533 for ; Tue, 28 Sep 2004 14:23: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 i8SHqhM6024946; Tue, 28 Sep 2004 10:52: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 i8SHqhe0024945; Tue, 28 Sep 2004 10:52:43 -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 i8SHqgAV024939 for ; Tue, 28 Sep 2004 10:52:42 -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 i8SI71aB019849; Tue, 28 Sep 2004 11:07:01 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8SI71cW019846; Tue, 28 Sep 2004 11:07:01 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 28 Sep 2004 11:07:01 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org, Subject: Article with Microsoft comments on future of Sender ID Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT I'll note that Microsoft is making incorrect statements regarding its "SenderID" framework. In fact MARID IETF working group HAS NOT "recommended to move forward with the framework as experimental", such recomendation would have required consensus of the WG and in fact majority of participants in the WG were completely against Sender ID and PRA documents to become either experimental or standard track RFC. What did happen is that IETF Area Director "asked" individual participants to submit their proposals to IETF for review by yet to be formed IETF directorate that will then decide if they are worth moving forward to become EXERIMENTAL RFC based on their value and based on if they are or not in conflict with existing IETF standards. http://www.pointnclickinc.com/articles09272004msftqanda.htm -------------------------------------------------------------- Released by permission from Microsoft Pointnclick, Inc Question: In the last week, reports spread that the IETF MARID rejected SenderID, then, on 9/21 MSFT stated that the IETF was in support SenderID. Then, the IETF terminated MARID, the group reportedly lacking support for SenderID authentication. Since the IETF's tepid support for SenderID was cited by AOL as a problem for developing a unified standard, do you think this opens the door to getting things back on track for a single standard again? Microsoft Answer: To clarify, Sender ID has not been rejected by the IETF. In fact, before it's closure, the IETF's MARID working group recommended to move forward with the framework as experimental and have the industry begin to test the proposal in real-world implementation. MARID also recommended Sender ID include an alternative spoof checking mechanism to the proposed PRA check to now also include a "MAIL FROM" check. We believe MARID's proposal to allow multiple scopes in the protocol is a reasonable approach to provide additional choice and flexibility and we will be publishing a revised specification for the industry later this week. We will continue our collaboration with industry stakeholders to help move this important authentication protocol forward. AOL's decision to conduct only "MAIL FROM" checks as outlined in the original SPF proposal reflects the kind of flexibility and room for choice provided by the IETF’s recommendation to broaden Sender ID framework. What's encouraging about AOL's announcement is that they will join us in publishing both records and we continue to recommend that all mail senders do the same. Sender ID remains a very promising framework. We have been deeply engaged with others in the industry to make changes to the spec that are consistent with the recommendations made by the MARID working group co-chairs early this month. Moving forward, we also continue to believe complementary technologies such as signing solutions and computational proofs will be important to address other technical aspects of spam that these IP-based authentication mechanisms do not address. From owner-ietf-mxcomp@mail.imc.org Tue Sep 28 14:43: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 OAA11083 for ; Tue, 28 Sep 2004 14:43:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SIADo6026290; Tue, 28 Sep 2004 11:10:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SIADax026289; Tue, 28 Sep 2004 11:10:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SIAC5s026271 for ; Tue, 28 Sep 2004 11:10:12 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 28 Sep 2004 14:10:08 -0400 id 003C828F.4159A900.000066D0 From: "Scott Hollenbeck" To: "'william\(at\)elan.net'" , ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com Subject: RE: Article with Microsoft comments on future of Sender ID Date: Tue, 28 Sep 2004 14:10:01 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F93E@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8SIAC5s026283 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > What did happen is that IETF Area Director "asked" individual > participants to submit their proposals to IETF for review by > yet to be > formed IETF directorate that will then decide if they are > worth moving > forward to become EXERIMENTAL RFC based on their value and > based on if > they are or not in conflict with existing IETF standards. Speaking of incorrect statements... ;-) IETF Directorates do not make decisions. I know that some people think they do, but they have no decision making power. They exist to provide focused review at the request of members of the IESG. The IESG ultimately decides if a proposal will be published as an experimental RFC. -Scott- (the other Apps AD) From owner-ietf-mxcomp@mail.imc.org Tue Sep 28 15:34: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 PAA16489 for ; Tue, 28 Sep 2004 15:34:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SJ6Qxj030544; Tue, 28 Sep 2004 12:06:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SJ6Qrc030543; Tue, 28 Sep 2004 12:06:26 -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 i8SJ6PZG030536 for ; Tue, 28 Sep 2004 12:06:25 -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 i8SJKg7a022907; Tue, 28 Sep 2004 12:20:42 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8SJKfEH022904; Tue, 28 Sep 2004 12:20:42 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 28 Sep 2004 12:20:41 -0700 (PDT) From: "william(at)elan.net" To: Scott Hollenbeck cc: ietf-mxcomp@imc.org, Subject: RE: Article with Microsoft comments on future of Sender ID In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F93E@vsvapostal8.vcorp.ad.vrsn.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 Tue, 28 Sep 2004, Scott Hollenbeck wrote: > Speaking of incorrect statements... ;-) > > IETF Directorates do not make decisions. I know that some people think they > do, but they have no decision making power. They exist to provide focused > review at the request of members of the IESG. The IESG ultimately decides > if a proposal will be published as an experimental RFC. > > -Scott- > (the other Apps AD) Thank you for your correction :) And correct me if I'm wrong :), but the same also applies to the IETF Working Group as neither WG nor chairs of WG make decisions about documents going to standard or experimental status, instead they make recomendation to IESG which is the ultimate decision maker on status of IETF documents and which is supposed to make these decisions based on both recomendation of the WG and based on comments received from other IETF participants during last call for the documents. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Tue Sep 28 16:30: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 QAA22391 for ; Tue, 28 Sep 2004 16:30:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SJxn86034232; Tue, 28 Sep 2004 12:59: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 i8SJxnTS034231; Tue, 28 Sep 2004 12:59:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SJxmKT034224 for ; Tue, 28 Sep 2004 12:59:48 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 28 Sep 2004 15:53:47 -0400 id 003C828F.4159C14B.00007A37 From: "Scott Hollenbeck" To: "'william\(at\)elan.net'" Cc: ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com Subject: RE: Article with Microsoft comments on future of Sender ID Date: Tue, 28 Sep 2004 15:53:40 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F942@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8SJxmKT034226 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > And correct me if I'm wrong :), but the same also applies to the IETF > Working Group as neither WG nor chairs of WG make decisions about > documents going to standard or experimental status, instead they make > recomendation to IESG which is the ultimate decision maker on status > of IETF documents and which is supposed to make these > decisions based on > both recomendation of the WG and based on comments received > from other > IETF participants during last call for the documents. Not exactly. It's more typical for working group document status decisions to be made as part of the working group chartering process. The expected working group outputs (documents, including their standards track status) are documented in the charter. IETF review is part of the chartering process, so the issue of document status is ultimately one discussed within and recommended by the community. Changes can be made over time; we have processes for that. The IESG does have final approval authority, though. The situation is a bit different when a working group is unable to complete the work outlined in the charter; see section 4 of RFC 2418. At that point the documents can be abandoned as unfinished work or they can be pursued as individual submissions outside of the working group. RFC 2026 describes the options. -Scott- From owner-ietf-mxcomp@mail.imc.org Tue Sep 28 16: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 QAA23175 for ; Tue, 28 Sep 2004 16:40: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 i8SJCpX1031125; Tue, 28 Sep 2004 12:12: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 i8SJCpY5031124; Tue, 28 Sep 2004 12:12:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from amgod.boxhost.net (dogma.boxhost.net [195.218.96.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SJCoSj031112 for ; Tue, 28 Sep 2004 12:12:50 -0700 (PDT) (envelope-from jm@jmason.org) Received: from radish.jmason.org (localhost [127.0.0.1]) by amgod.boxhost.net (Postfix) with ESMTP id 26F66310493; Tue, 28 Sep 2004 20:13:46 +0100 (IST) Received: by radish.jmason.org (Postfix, from userid 1000) id 52E6559005B; Tue, 28 Sep 2004 12:12:37 -0700 (PDT) Received: from jmason.org (localhost [127.0.0.1]) by radish.jmason.org (Postfix) with ESMTP id 4F2FC358149; Tue, 28 Sep 2004 12:12:37 -0700 (PDT) To: Danny Angus Cc: "william(at)elan.net" , ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com Subject: Re: Processed-By (or Transmitted-By) header concept In-Reply-To: From: jm@jmason.org (Justin Mason) X-Gpg-Key-Fingerprint: 0A48 2D8B 0B52 A87D 0E8A 6ADD 4137 1B50 6E58 EF0A 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 . Date: Tue, 28 Sep 2004 12:12:37 -0700 Message-Id: <20040928191237.52E6559005B@radish.jmason.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Danny Angus writes: > William, > > The problem I see with this is that multiple hops cannot be used in > conjunction with New-xx and Original-xx headers. > What you'd have to do would be to use a single header which both identifies > the hop that changed the headers and records the change. > > Lets assume that the regular headers are rewritten and therefore contain > the "new" values, so we only really need to preserve the history. > That can be accomodated in the "Processed by" by simply inserting the > original values for the fields logged as changed. > > Processed-By: odin.ietf.org (ip=[132.151.1.176]) > on-behalf-of ietf@megatron.ietf.org > changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, > > Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue > > process-type maillist (list-id=) ; > > As for the name, call it like it is. If this is to address the issues of > automatic (c.f. by a users explicit action) re-insertion of messages into > the delivery system call it > "Reinserted-by" > > But... also add a timestamp so we can accurately order these things > > Reinserted-By: odin.ietf.org (ip=[132.151.1.176]) > on-behalf-of ietf@megatron.ietf.org > changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, > > Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue > > process-type maillist (list-id=) ; Tue, 28 Sep 2004 > 00:43:21 -0700 (PDT) > > At the end of the day though it still looks like a mechanism by which > someone could fabricate a whole imagined history for a message, rather than > anything upon which we could rely. I think that's unavoidable in a lot of cases -- the best approach to deal with that is to either - (a) do not trust anything that wasn't added by a machine on your own network, or - (b) know where your "trust boundaries" lie, and stop looking once the message has gone one step beyond that boundary, since any other tracking info is possibly forged. This is the approach we take in SpamAssassin when dealing with Received headers. - --j. > d. > > --- > Danny Angus > (apache james) > > > Together with it introduced are > > Original-???? headers which are to be used to preserve original > > values of the headers that are being changed. > > *************************************************************************** > 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. > > ************************************************************************** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBWbelQTcbUG5Y7woRAinfAJ9baMvdKH5H1Z42n2BBoiPRBRMXfQCcCLmH z4v5dh3Jc5MdwYuD6/Hmb18= =tnhX -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Tue Sep 28 17:24:44 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 RAA25169 for ; Tue, 28 Sep 2004 17:24: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 i8SKtPFf039825; Tue, 28 Sep 2004 13:55: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 i8SKtPl9039824; Tue, 28 Sep 2004 13:55:25 -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 i8SKtOPG039813 for ; Tue, 28 Sep 2004 13:55:24 -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 58636414C4; Tue, 28 Sep 2004 13:55:27 -0700 (PDT) Subject: Re: Processed-By (or Transmitted-By) header concept From: Douglas Otis To: Justin Mason Cc: Danny Angus , "william(at)elan.net" , MARID , spf-discuss@v2.listbox.com In-Reply-To: <20040928191237.52E6559005B@radish.jmason.org> References: <20040928191237.52E6559005B@radish.jmason.org> Content-Type: text/plain Message-Id: <1096404926.27332.13.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 28 Sep 2004 13:55:27 -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 Tue, 2004-09-28 at 12:12, Justin Mason wrote: > Danny Angus writes: > > William, > > > > The problem I see with this is that multiple hops cannot be used in > > conjunction with New-xx and Original-xx headers. > > What you'd have to do would be to use a single header which both identifies > > the hop that changed the headers and records the change. > > > > Lets assume that the regular headers are rewritten and therefore contain > > the "new" values, so we only really need to preserve the history. > > That can be accomodated in the "Processed by" by simply inserting the > > original values for the fields logged as changed. > > > > Processed-By: odin.ietf.org (ip=[132.151.1.176]) > > on-behalf-of ietf@megatron.ietf.org > > changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, > > > > Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue > > > > process-type maillist (list-id=) ; > > > > As for the name, call it like it is. If this is to address the issues of > > automatic (c.f. by a users explicit action) re-insertion of messages into > > the delivery system call it > > "Reinserted-by" > > > > But... also add a timestamp so we can accurately order these things > > > > Reinserted-By: odin.ietf.org (ip=[132.151.1.176]) > > on-behalf-of ietf@megatron.ietf.org > > changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, > > > > Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue > > > > process-type maillist (list-id=) ; Tue, 28 Sep 2004 > > 00:43:21 -0700 (PDT) > > > > At the end of the day though it still looks like a mechanism by which > > someone could fabricate a whole imagined history for a message, rather than > > anything upon which we could rely. > > I think that's unavoidable in a lot of cases -- the best approach to > deal with that is to either > > - (a) do not trust anything that wasn't added by a machine on > your own network, or > > - (b) know where your "trust boundaries" lie, and stop looking > once the message has gone one step beyond that boundary, since > any other tracking info is possibly forged. > > This is the approach we take in SpamAssassin when dealing with > Received headers. This is also a good reason to reconsider the use of an authenticated HELO domain and Received headers. This name never relies upon anything beyond the adjacent agent outside the local domain. It is dead simple for a mailbox domain to reference a list of root names for all approved mail transfer agents. Use this information, obtained in one DNS query, to detect spoofing. No address entries are needed to support this mechanism and open-ended lists are not a problem. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Sep 28 19:56:22 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 TAA06271 for ; Tue, 28 Sep 2004 19:56:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SNQfdg052945; Tue, 28 Sep 2004 16:26: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 i8SNQfQF052944; Tue, 28 Sep 2004 16:26: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 i8SNQeRN052938 for ; Tue, 28 Sep 2004 16:26:40 -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 i8SNf2XB002578; Tue, 28 Sep 2004 16:41:03 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8SNf2LE002575; Tue, 28 Sep 2004 16:41:02 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 28 Sep 2004 16:41:02 -0700 (PDT) From: "william(at)elan.net" To: Danny Angus cc: ietf-mxcomp@imc.org, 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 Tue, 28 Sep 2004, Danny Angus wrote: > William, > > The problem I see with this is that multiple hops cannot be used in > conjunction with New-xx and Original-xx headers. > What you'd have to do would be to use a single header which both identifies > the hop that changed the headers and records the change. I'll have recomendations how they can, basicly saying that Original-* headers that follow Processed-By and that are specifically mentioned in Processed-By changed list should be considered to be part of the same trace data. > Lets assume that the regular headers are rewritten and therefore contain > the "new" values, so we only really need to preserve the history. > That can be accomodated in the "Processed by" by simply inserting the > original values for the fields logged as changed. > > Processed-By: odin.ietf.org (ip=[132.151.1.176]) > on-behalf-of ietf@megatron.ietf.org > changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, > > Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue > > process-type maillist (list-id=) ; I partially agree with it, especially as it concerns envelope data. I note that RFC2821 identities are in standard mailbox format and its easier to add them as part of the header line, but RFC2822 headers have more complex structure and its difficult to encapsulate them as part of trace header, so I prefer to simly allow MTAs to copy them as is into "Original-" header. So my solution is thus that changes to envelope data would be reported as part of the Processed-By header (just like it is done currently in Received headers) but that Original-xxx headers stay for reporting values that RFC2822 headers had before they were changed. Youre suggestion about timestamp is also appropriate and I already thought it might be good idea myself before too. So here is example of new format that I propose for this trace header: Processed-By: odin.ietf.org (ip=[132.151.1.176]) on-behalf-of ietf@megatron.ietf.org original-envelope recepient=ietf@ietf.org, return-path=user@example.com, submitter=user@example.com new-envelope recepient=william@elan.net, return-path=ietf@ietf.org, submitter=ietf@ietf.org changed-headers To, List-ID, Sender, CC process-type maillist (list-id=) ; Tue, 28 Sep 2004 00:43:21 -0700 (PDT) Original-To: ietf@ietf.org Original-Sender: secretary@example.org I'll note that NOT ALL headers that are listed in "changed-headers" are present as separate Original-* headers. Those that are not present are considered to have been added rather then changed, so of the above the two headers that have been changed are "To" and "Sender" while "CC" and "List-ID" have beed added by mail list but there were not previously in the email message data. This brings the question if it is better to separate these into "changed-headers" and "added-headers"? > As for the name, call it like it is. If this is to address the issues of > automatic (c.f. by a users explicit action) re-insertion of messages into > the delivery system call it "Reinserted-by" The header is intended for use by MTAs doing automated procesing during transmission of the message, not by processes done by MUA. In fact the text might even state that if user-action forwarding is done than it maybe more appropriate to use Resent- headers instead of Procesed-By header. That is why my original name was "Trasmitted-By" - it reflects that changes are being done during transmission of the message, however the name does not well show that header informs about changes in message parameters, so I think I'm going to continue with "Processed-By" name. > At the end of the day though it still looks like a mechanism by which > someone could fabricate a whole imagined history for a message, rather than > anything upon which we could rely. That is obsolutely true and I'll have to mention this in the "Security Considerations" section. So this header is nothing more then new kind trace header like Received that is intended to aid systems that are trying to see what happened to the message in transit and they are supposed to view this with the same level of believe as received headers. However if ultimately we develop an automated email signature system than it would be possible to provide by means of encryption algorithm to confirm that headers were indeed added by whoever claimed it and then its a matter if you trust that system to report what happened to email in truthfull way or not. On this note, in the next version of MTA Signatures proposal, I'll have a better way to sign trace headers (actually it'll look closer to Yahoo DK with header signature line that will reflect signing of multiple headers proceeding the line - but with actual encryption data being still in the separate PKCS7 MIME attachment). --- 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 Tue Sep 28 19:56:22 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 TAA06272 for ; Tue, 28 Sep 2004 19:56:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SNUjKo053186; Tue, 28 Sep 2004 16:30: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 i8SNUjEO053185; Tue, 28 Sep 2004 16:30: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 i8SNUixb053179 for ; Tue, 28 Sep 2004 16:30: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 i8SNj7nE002839; Tue, 28 Sep 2004 16:45:07 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8SNj7Yk002836; Tue, 28 Sep 2004 16:45:07 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 28 Sep 2004 16:45:07 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org, 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: And FYI - I really do appreciate all suggestions I received both public and private ones. They are all very helpfull and even if I do not respond to you directly, I'm gratefull for you participation in development of this idea. William On Tue, 28 Sep 2004, william(at)elan.net wrote: > On Tue, 28 Sep 2004, Danny Angus wrote: > > > William, > > > > The problem I see with this is that multiple hops cannot be used in > > conjunction with New-xx and Original-xx headers. > > What you'd have to do would be to use a single header which both identifies > > the hop that changed the headers and records the change. > > I'll have recomendations how they can, basicly saying that Original-* > headers that follow Processed-By and that are specifically mentioned in > Processed-By changed list should be considered to be part of the same > trace data. > > > Lets assume that the regular headers are rewritten and therefore contain > > the "new" values, so we only really need to preserve the history. > > That can be accomodated in the "Processed by" by simply inserting the > > original values for the fields logged as changed. > > > > Processed-By: odin.ietf.org (ip=[132.151.1.176]) > > on-behalf-of ietf@megatron.ietf.org > > changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue, > > > > Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue > > > > process-type maillist (list-id=) ; > > I partially agree with it, especially as it concerns envelope data. > I note that RFC2821 identities are in standard mailbox format and its > easier to add them as part of the header line, but RFC2822 headers > have more complex structure and its difficult to encapsulate them > as part of trace header, so I prefer to simly allow MTAs to copy them > as is into "Original-" header. > > So my solution is thus that changes to envelope data would be reported > as part of the Processed-By header (just like it is done currently > in Received headers) but that Original-xxx headers stay for reporting > values that RFC2822 headers had before they were changed. > > Youre suggestion about timestamp is also appropriate and I already thought > it might be good idea myself before too. So here is example of new format > that I propose for this trace header: > > Processed-By: odin.ietf.org (ip=[132.151.1.176]) > on-behalf-of ietf@megatron.ietf.org > original-envelope recepient=ietf@ietf.org, > return-path=user@example.com, submitter=user@example.com > new-envelope recepient=william@elan.net, > return-path=ietf@ietf.org, submitter=ietf@ietf.org > changed-headers To, List-ID, Sender, CC > process-type maillist (list-id=) ; > Tue, 28 Sep 2004 00:43:21 -0700 (PDT) > Original-To: ietf@ietf.org > Original-Sender: secretary@example.org > > > I'll note that NOT ALL headers that are listed in "changed-headers" > are present as separate Original-* headers. Those that are not present > are considered to have been added rather then changed, so of the above > the two headers that have been changed are "To" and "Sender" while > "CC" and "List-ID" have beed added by mail list but there were not > previously in the email message data. This brings the question if it is > better to separate these into "changed-headers" and "added-headers"? > > > As for the name, call it like it is. If this is to address the issues of > > automatic (c.f. by a users explicit action) re-insertion of messages into > > the delivery system call it "Reinserted-by" > > The header is intended for use by MTAs doing automated procesing > during transmission of the message, not by processes done by MUA. > In fact the text might even state that if user-action forwarding > is done than it maybe more appropriate to use Resent- headers > instead of Procesed-By header. That is why my original name was > "Trasmitted-By" - it reflects that changes are being done during > transmission of the message, however the name does not well show > that header informs about changes in message parameters, so I think > I'm going to continue with "Processed-By" name. > > > At the end of the day though it still looks like a mechanism by which > > someone could fabricate a whole imagined history for a message, rather than > > anything upon which we could rely. > > That is obsolutely true and I'll have to mention this in the "Security > Considerations" section. So this header is nothing more then new kind > trace header like Received that is intended to aid systems that are > trying to see what happened to the message in transit and they are > supposed to view this with the same level of believe as received headers. > > However if ultimately we develop an automated email signature system > than it would be possible to provide by means of encryption algorithm > to confirm that headers were indeed added by whoever claimed it and > then its a matter if you trust that system to report what happened > to email in truthfull way or not. > > On this note, in the next version of MTA Signatures proposal, I'll have a > better way to sign trace headers (actually it'll look closer to Yahoo DK > with header signature line that will reflect signing of multiple headers > proceeding the line - but with actual encryption data being still in the > separate PKCS7 MIME attachment). > > --- > 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 Wed Sep 29 01:18: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 BAA27000 for ; Wed, 29 Sep 2004 01:18:45 -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 i8T4efld096220; Tue, 28 Sep 2004 21:40: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 i8T4efsj096219; Tue, 28 Sep 2004 21:40:41 -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 i8T4edtI096202 for ; Tue, 28 Sep 2004 21:40:40 -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 B22D8C22751; Wed, 29 Sep 2004 00:09:22 -0400 (EDT) X-Sasl-enc: UgIhk6AcjZuPVvQrBU92sQ 1096430962 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend2.messagingengine.com (Postfix) with ESMTP id F3EB877B; Wed, 29 Sep 2004 00:09:20 -0400 (EDT) Message-ID: <415A35CB.80004@elvey.com> Date: Tue, 28 Sep 2004 21:10:51 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis , MXCOMP Subject: Re: Make CSV backwards compatible with legacy SPF records? References: <415215F7.7090105@elvey.com> <1095911060.13180.168.camel@ddev.mail-abuse.org> <41527800.4000405@elvey.com> <1095935943.5443.139.camel@localhost.localdomain> In-Reply-To: <1095935943.5443.139.camel@localhost.localdomain> 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 On 9/23/2004 12:15 AM, Matthew Elvey sent forth electrons to convey: > > Aha! I found the post with the relevant stats. They're from March, though. Also, my recollection was off - domains using the ten most popular SPF records included only 1/2 of the total domains with records. > http://www.imc.org/ietf-mxcomp/mail-archive/msg00644.html Something reasonably recent would be great. > > Anyway, let's consider the top ten (which I've reordered a bit) from wayne: > Arrgh - here's that without the rewrapping: Columns are: Popularity rank of such records; # of such records; record value. 1 1097 v=spf1 mx -all 3 463 v=spf1 a mx ptr -all 4 429 v=spf1 a mx -all 9 131 v=spf1 a mx ?all 6 306 v=spf1 a -all The above would generally take 1-3 UDP DNS queries to resolve. 5 325 v=spf1 -all 7 171 v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.example.com -all 8 131 v=spf1 include:example.org ~all 10 130 v=spf1 ?all These are equivalent to the null set, for the purposes of my proposal. 2 804 v=spf1 ip4:a.b.c.d/32 ip4:a.b.c.d/32 a ptr mx -all This is probably no longer in the top ten. On Thu, 23 Sep 2004 03:39:03 -0700, "Douglas Otis" said: > On Thu, 2004-09-23 at 00:15, Matthew Elvey wrote: > > > > > > >> Huh? The question is about the record given, which has none of these > > >> problems. ( foo.dom. IN TXT "v=spf1 mx -all" ) > > > > > > There is a good overview here. > > > http://www.securityfocus.com/guest/17905 > > > > Yes, a good refresher. Anyway it leads me to believe that the record > > only suffers from a problem that also afflicts CSV and that a good bind9 > > or djbdns config can handle. > > I would agree that someone making an effort could protect their DNS > servers, but the risks parsing script in DNS TXT records traipsing from > DNS server to DNS server does not compare to a single lookup of a binary > record. I got that the first time you said it. Matching to a fixed set of, say a dozen allowed strings does not make a script. That would allow a large fraction of SPF records to be used for the purposes of my proposal. > > > > By limiting the mechanism to a single DNS lookup to a single DNS server, > > > the exposure is much less. > > > > Ok, it is a little less. The risk is also low to start with. (Birthday > > attacks aren't common, AFAIK; I've never logged one.) It's even lower > > to nonexistent given recent/patched/secure DNS software and systems > > (e.g. a split-split configuration). > > This is entering a new territory where DNS is used to authorize > transactions with a cost incentive to defeat these protections. Yes, > one could use carefully configured DNS servers to minimize this risk. > This should not overlook the fact this risk was not necessary however. No there are already reasonable scenarios where there are cost incentives to defeat these protections. Phishing, for example - if http://www.marktwainbank.com points to a phisher's site. > > > > For what it is worth, SPF "requires" more than a single record be read > > > perhaps from many different DNS servers. This opens a sizable can of > > > worms. > > > > Clearly, I need to better explain my scheme, as it still seems unclear > > to you that what SPF "requires" isn't relevant to my proposal! > > Please, can you give up using this as an opportunity to bash SPF? It's > > OT. (Note the changed Subject:). > > Using SPF records is not relevant to what is required of SPF? > > If SPF was limited to CIDR notation and the MX record, then the value of > SPF would increase significantly as a white-listing tool. Much of the > label construction macros and exists syntax reduce SPF's value and will > likely serve to obfuscate a ploy that hides zombies. So therefore you'd like to not use useful information that might be found in SPF records, just because it might be seen as legitimizing the components of SFP records that you feel are unhelpful to the effort. > > > > Example: Mailbox.tld has SPF records that define the entire address > > > space for three of their providers where they outsource some of their > > > mail, and their own. I contend reputation should be based upon what you > > > have control over. That would mean it would not be to your advantage to > > > include the machines of these other providers in a reputation > > > assessment. > > > > Ah, I did say ip4 (and therefore CIDR ranges) might be OK. > > (I did suggest subsequently in mail to John Leslie that perhaps just > > +ip4:a.b.c.d/32 might be OK, note the /32!) > > Perhaps even that isn't a good idea, as > > > > mailbox.dom spf ip4:[isp1's smtp]/32,ip4:[isp2's smtp]/32,ip4:[isp3's smtp] -all > > > > enables me to inappropriately stake my domain's reputation on the > > ability of ISPs 1-3 to keep their smtp servers from being used to spam. > > HOWEVER: It's already the case that such SPF records are > > inappropriate. If I don't have high confidence in the ISPs, then the > > appropriate record would be: > > > > mailbox.dom spf ?ip4:[isp1's smtp]/32, ?ip4:[isp2's smtp]/32, ?ip4:[isp3's smtp] -all > > and this record would be equivalent to the null set in my scheme: my proposal ignores ~anything and ?anything. > > Similarly, anyone creating a record like > > > > > mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self. > I [DO NOT] think the motive for using SPF > records for this purpose is well founded. If the MTA is not willing to > provide a significantly strong identifier, it does not make sense to > start guessing what is meant by the SPF records. I argue that it does make sense to do so, and can be done safely. > The fall back would be > using the address. The IP address? Sure, that's an option. (I note that RBL entries in a sense are MARID - they indicate MAPS' opinion as to whether a MTAs should be Authorized by MAPS' users to transmit mail to them, expressed as Records In the Dns.) > There can be no implied contract where a domain > becomes accountable for the actions of others trusted to send their > mail. > > A provider lax in their security should not be allowed to hide behind > their customer's domains. Should the provider wish to force the > customer to accept this risk, they can ask to have the customer setup a > CSV-CSA record that enables their servers. You do not want this > accountability to be implied as you suggest. I DO NOT SUGGEST THIS. WTF? How many times do I have to say it? > > > [mailbox.dom] will suffer the consequences of doing something so dumb, > > if one of the 3 ISPs seriously fails keep their smtp servers from > > being used to spam using mailbox.dom. The domain will get blacklisted > > (in other words, its reputation will fall), and the spoofing will > > stop. > > SPF requires the addresses of the entire mail channel. It is odd that > you would call that dumb. No, you still don't get it. You ignore or don't understand the difference between + and ? in an SPF1 record, as defined in the I-D / explained a couple paragraphs down. Once again, I think this would be dumb: > mailbox.dom spf ip4:[isp1's smtp]/32,ip4:[isp2's smtp]/32,ip4:[isp3's smtp] -all not this: > mailbox.dom spf ?ip4:[isp1's smtp]/32, ?ip4:[isp2's smtp]/32, ?ip4:[isp3's smtp] -all > > > The rules that accept only closed SPF components still do not achieve a > > > goal of assessing only the administrator accountable. > > > > The rules I am refining do achieve that goal. Arguably, they do so > > better than CSV, because they'll work for most domains that haven't > > bothered to set up a CSV record. Heck, using the SPF 'best guess' may > > be appropriate where there's no SPF or CSV record - the A&R system will > > reflect reality if this guess allows much spam through. > > I would hope it never comes to groping through various TXT script > records looking for a clue. I understand what you are attempting, but > there are risks getting this wrong. It is not worth the risk. Let's agree to disagree and move on. (Or at least let's move this thread to ) - Please reply there; I won't post further here on this thread.) > > > > > > > Just removing open elements will not achieve the desired goal as it does > > > not provide the same set. > > > > That's not a logical argument. The ultimate desired goal is to address > > the spam problem. It may or may not be material to achievement of that > > goal to get "the same set". > > There are significant liabilities getting this wrong. Well, duh. That statement is true whenever one is doing something important. So we proceed thoughtfully and get it right. > > > > SPF does not have the concept of administrative versus authorized. I would say it does. I would say that ? is for servers that are tentatively authorized, and + is for servers that are administered by the entity owning the domain. + normally indicates a server that the domain claims is administered responsibly; ? indicates a server that it isn't sure is administered responsibly, but neverleless does not want to deny the ability to use the domain. > > > There is nothing in the syntax that would allow the differentiation. See above. > > > In > > > addition, the EHLO name can express any label to select any record. > > > > a record for aol.com is still differentiable from one for > > dhcp234.234.dialup.aol.com! > > But either label may appear within the EHLO response. You want a label > that can only be used for the single purpose of indicating the > administration of the MTA. From this information, it is a small matter > to establish the mailbox-domain/mail-channel association. For many domains this info isn't available. And until CSV takes off, it makes sense to use the available info in a responsible manner as I propose. Especially if the pressure to publish SPF records continues to increase. From owner-ietf-mxcomp@mail.imc.org Wed Sep 29 05:07: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 FAA10336 for ; Wed, 29 Sep 2004 05:07: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 i8T8eVJr002674; Wed, 29 Sep 2004 01:40:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8T8eVtY002673; Wed, 29 Sep 2004 01:40:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8T8eUkZ002580 for ; Wed, 29 Sep 2004 01:40:31 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-9.tower-82.messagelabs.com!1096447217!1985324 X-StarScan-Version: 5.2.10; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 8125 invoked from network); 29 Sep 2004 08:40:17 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-9.tower-82.messagelabs.com with SMTP; 29 Sep 2004 08:40:17 -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 ; Wed, 29 Sep 2004 09:40:19 +0100 Subject: Re: [Maybe Spam] Re: Processed-By (or Transmitted-By) header concept To: "william(at)elan.net" Cc: ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Danny Angus Date: Wed, 29 Sep 2004 09:40:19 +0100 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 29/09/2004 09:40:19 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: William, > So here is example of new format > that I propose for this trace header: Processed-By: odin.ietf.org (ip=[132.151.1.176]) on-behalf-of ietf@megatron.ietf.org original-envelope recepient=ietf@ietf.org, return-path=user@example.com, submitter=user@example.com new-envelope recepient=william@elan.net, return-path=ietf@ietf.org, submitter=ietf@ietf.org changed-headers To, List-ID, Sender, CC process-type maillist (list-id=) ; Tue, 28 Sep 2004 00:43:21 -0700 (PDT) Original-To: ietf@ietf.org Original-Sender: secretary@example.org I think it is too much (header bloat, to coin a phrase), but I don't have anything very constructive to say at this point beyond that fact that I believe we should take every step to avoid duplication of information in (or between) the envelope or(/and) the message headers. Meaning that I would prefer (simply as a purist) a standard which mandated existing optional behaviour, rather than duplicate the optional with a mandatory alternative. Instead of MAY add some piece of data to an existing header type, make it SHOULD instead and already those people who implement the option will be compliant with that new thing and messages won't bloat. >The header is intended for use by MTAs doing automated procesing >during transmission of the message, not by processes done by MUA. >In fact the text might even state that if user-action forwarding >is done than it maybe more appropriate to use Resent- headers >instead of Procesed-By header. Ok I already got this, it relates to .forward, .aliases and mailinglist scenarios. The only reason we believe that we can't use Resent headers...: " Resent fields SHOULD be added to any message that is reintroduced by a user into the transport system. A separate set of resent fields SHOULD be added each time this is done." ... is ...: " They MUST NOT be used in the normal processing of replies or other such automatic actions on messages." So if there is any requirement at all it is to handle "automatic actions on a message by which that message is automatically reintroduced _on behalf of_ a user into the transport system" Hence I still maintain that "Reinserted" or "Reintroduced" would disambiguate the purpose of the headers, and compliment "Resent". I agree with your brief analysis of security, in particular with the point that it would be no less trustworthy than any existing mechanism. However I will continue to question the value of having such a big new burden (the transport and processing of all that new data) without there being any mechanism to ensure that it has any real added-value for the recipient at all. 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 Wed Sep 29 14:43:34 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 OAA27660 for ; Wed, 29 Sep 2004 14:43:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TI9aWa040096; Wed, 29 Sep 2004 11:09:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TI9aRf040094; Wed, 29 Sep 2004 11:09:36 -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 i8TI9aFt040066 for ; Wed, 29 Sep 2004 11:09:36 -0700 (PDT) (envelope-from matthew@elvey.com) Received: from web3.messagingengine.com (web3.internal [10.202.2.212]) by frontend1.messagingengine.com (Postfix) with ESMTP id 7050FC245A6; Wed, 29 Sep 2004 14:09:36 -0400 (EDT) Received: by web3.messagingengine.com (Postfix, from userid 99) id 3AF3E1534; Wed, 29 Sep 2004 14:09:37 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.001; A1.64; B3.05; Q3.03) References: Subject: Re: [Maybe Spam] Re: Processed-By (or Transmitted-By) header concept In-Reply-To: To: "MXCOMP" , spf-discuss@v2.listbox.com Date: Wed, 29 Sep 2004 11:09:37 -0700 From: "Matthew Elvey" X-Sasl-Enc: ST9G1PxqD3HzPQUuuQ0Rgw 1096481377 Message-Id: <1096481377.4891.205422239@webmail.messagingengine.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pretty much what Danny Angus said: I strongly prefer a standard which adds mandates that improve consistency, and mandates existing optional behaviour, rather than duplicates the optional with a mandatory alternative. Instead of MAY add some piece of data to an existing header type, make it SHOULD or MUST instead and already those people who implement the option will be compliant with that new thing. An example: Virtually all MTAs *that send mail directly over the public Internet* (note the qualifier) already send a FQDN in their HELO(EHLO). Mandating an appropriate FQDN in HELO is something that many border MTAs already enforce and would be good to codify in such a standard (which would be forbidding something 2821 allows). Broad CSV deployment will make this a MUST on the public Internet whether a consistent (forwarder/remailer/list) header info standard or the CSV standard mandate it or not. > > s/sniping/snipping/ -Freudian slip? :) > I see no evidence that the proposed header has any real added-value for the recipient at all. From owner-ietf-mxcomp@mail.imc.org Wed Sep 29 15:46: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 PAA03168 for ; Wed, 29 Sep 2004 15:46: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 i8TJJQ8S051487; Wed, 29 Sep 2004 12:19:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TJJQiL051486; Wed, 29 Sep 2004 12:19:26 -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 i8TJJPCh051479 for ; Wed, 29 Sep 2004 12:19:25 -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 i8TJXlc0006380; Wed, 29 Sep 2004 12:33:49 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8TJXhuO006377; Wed, 29 Sep 2004 12:33:43 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 29 Sep 2004 12:33:43 -0700 (PDT) From: "william(at)elan.net" To: Matthew Elvey cc: MXCOMP , Subject: Re: [Maybe Spam] Re: Processed-By (or Transmitted-By) header concept In-Reply-To: <1096481377.4891.205422239@webmail.messagingengine.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 Wed, 29 Sep 2004, Matthew Elvey wrote: > Pretty much what Danny Angus said: > I strongly prefer a standard which adds mandates that improve > consistency, and mandates existing optional behaviour, rather than > duplicates the optional with a mandatory alternative. > Instead of MAY add some piece of data to an existing header type, make > it SHOULD or MUST instead and already those people who implement the > option will be compliant with that new thing. Did I ever say this was a mandatory or alternative to anything? Just like information put in the received lines is not mandatory but is considered to be "good behavior" so would this be good behavior for systems that change source and destination addresses in transit. It is definetly not going to be MUST at best SHOULD for old values and MAY for new values (although i prefer SHOULD...) I also note that information provided by the construct is currently not available at all. This is its value, as it allows to see changes made to email source and destination in consistant way. As far as amount of data, over 50% of emails (especially the shorter ones) are user to user (source to destination) direct and would not have this line, the other emails mostly pass through one or two forwarding hops which already add tons of Received and X- lines, at best this would add 25% extra header data to such emails. And in any case, all this data is completely ignored by most end-users who are not techs and are not interested in how email got to them. Also all email signing systems will add A LOT MORE data to emails just by the fact that full signatures takes a lot more space. I'm not against it and infact based on the amount of email data that ISP processe, it seems that percent of SMTP traffic over overall traffic decreased (inspite of increasing amount of spam). What happened is that ISP infrastructure has been upgraded with a lot bigger pipes both on the ISP networks and to end-users who now often have DSL and cable and email use which was big deal during dialup still remains but for DSL subscriber the real use of internet is now P2P, MP3 downloads, gaming, HTML surfing with a lot more graphics, etc. So we should not see ideas that cause increase in size of emails as big deal for network infrastructure - it'll have minimum impact on it and most it could is increase size of email box storage but with advancement of storage devices and hard drives of 300GB now on the market (as opposed to 30GB 5 years ago), this also woule have no serious impact. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Sep 30 02:28: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 CAA14942 for ; Thu, 30 Sep 2004 02:28: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 i8U5rXoE057733; Wed, 29 Sep 2004 22:53:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8U5rXnI057732; Wed, 29 Sep 2004 22:53:33 -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 i8U5rWfl057715 for ; Wed, 29 Sep 2004 22:53:32 -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 264BB414C4; Wed, 29 Sep 2004 22:53:40 -0700 (PDT) Subject: Re: Make CSV backwards compatible with legacy SPF records? From: Douglas Otis To: Matthew Elvey Cc: MXCOMP In-Reply-To: <415A35CB.80004@elvey.com> References: <415215F7.7090105@elvey.com> <1095911060.13180.168.camel@ddev.mail-abuse.org> <41527800.4000405@elvey.com> <1095935943.5443.139.camel@localhost.localdomain> <415A35CB.80004@elvey.com> Content-Type: text/plain Message-Id: <1096523619.28969.651.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 29 Sep 2004 22:53:39 -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 Tue, 2004-09-28 at 21:10, Matthew Elvey wrote: > On 9/23/2004 12:15 AM, Matthew Elvey sent forth electrons to convey: > > > Aha! I found the post with the relevant stats. They're from March, > > though. Also, my recollection was off - domains using the ten most > > popular SPF records included only 1/2 of the total domains with > > records. > > http://www.imc.org/ietf-mxcomp/mail-archive/msg00644.html Something > > reasonably recent would be great. > > > > Anyway, let's consider the top ten (which I've reordered a bit) from > > wayne: > > > > Arrgh - here's that without the rewrapping: > > Columns are: > Popularity rank of such records; # of such records; record value. > > 1 1097 v=spf1 mx -all > 3 463 v=spf1 a mx ptr -all > 4 429 v=spf1 a mx -all > 9 131 v=spf1 a mx ?all > 6 306 v=spf1 a -all > > The above would generally take 1-3 UDP DNS queries to resolve. This would take a minimum of 2 DNS lookups and require a script parser which entails its own risks. Your goal of being able to use existing SPF records overlooks the very important point SPF does not identify the administrator of the mail transfer agent. These SPF records are only to authorize the sending of messages for specific mailbox domains. These SPF records may entail addresses beyond the control the administrator of the mailbox domain. It is pointless to make proclamations regarding the significance of the "+", the range of a label, or the scope of CIDR notation and the mailbox domain administrator's implied acceptance of liabilities. You are the one guessing what is implied by the addresses. You are the one alleging this implied agreement in supplying these addresses. You are the one that will take the full brunt of being wrong. At best, it remains a guess what is being declared by the addresses. SPF does not do this better. SPF does not do this in a safer way. SPF does not do this in a more expedient way. These examples of SPF records do nothing that can not already be assumed and do nothing to overcome the reason this approach failed with SMTP, and why there is an exception. > 5 325 v=spf1 -all > 7 171 v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.example.com -all > 8 131 v=spf1 include:example.org ~all > 10 130 v=spf1 ?all > > These are equivalent to the null set, for the purposes of my proposal. What is the point excluding an "include" but not a CIDR address? What is the point suggesting the shorthand "mx" and "a" notation offers any additional benefit. > 2 804 v=spf1 ip4:a.b.c.d/32 ip4:a.b.c.d/32 a ptr mx -all > > This is probably no longer in the top ten. > > On Thu, 23 Sep 2004 03:39:03 -0700, "Douglas Otis" wrote: > > On Thu, 2004-09-23 at 00:15, Matthew Elvey wrote: > > > > > > > > > >> Huh? The question is about the record given, which has none of these > > > >> problems. ( foo.dom. IN TXT "v=spf1 mx -all" ) > > > > > > > > There is a good overview here. > > > > http://www.securityfocus.com/guest/17905 > > > > > > Yes, a good refresher. Anyway it leads me to believe that the record > > > only suffers from a problem that also afflicts CSV and that a good bind9 > > > or djbdns config can handle. > > > > I would agree that someone making an effort could protect their DNS > > servers, but the risks parsing script in DNS TXT records traipsing from > > DNS server to DNS server does not compare to a single lookup of a binary > > record. > > I got that the first time you said it. > Matching to a fixed set of, say a dozen allowed strings does not make a > script. That would allow a large fraction of SPF records to be used > for the purposes of my proposal. The translation of a set of textual constructs with specific syntax constitutes script in my book. Using a name list based upon the results of CSV allows for both a safe and simple scheme that accomplishes the same ends as SPF, but without having to express a single address. No addresses are entered for CSV, and no addresses would need to be entered to define the mail channel for a mailbox domain using a name list. None. There would be no need to daisy-chain new headers to connect MailFrom to MailFrom either. The Received headers logging the authenticated EHLO information actually provides more reliable information without changing a single element of SMTP. All that is needed is CSV and a name list. This would allow anyone to know when the message was possibly being spoofed without inviting spoofing and still allow mail to be accepted from outside the mail channel. > > > > By limiting the mechanism to a single DNS lookup to a single DNS server, > > > > the exposure is much less. > > > > > > Ok, it is a little less. The risk is also low to start with. (Birthday > > > attacks aren't common, AFAIK; I've never logged one.) It's even lower > > > to nonexistent given recent/patched/secure DNS software and systems > > > (e.g. a split-split configuration). > > > > This is entering a new territory where DNS is used to authorize > > transactions with a cost incentive to defeat these protections. Yes, > > one could use carefully configured DNS servers to minimize this risk. > > This should not overlook the fact this risk was not necessary however. > > No there are already reasonable scenarios where there are cost > incentives to defeat these protections. > Phishing, for example - if http://www.marktwainbank.com points to a > phisher's site. > > > > > For what it is worth, SPF "requires" more than a single record be read > > > > perhaps from many different DNS servers. This opens a sizable can of > > > > worms. > > > > > > Clearly, I need to better explain my scheme, as it still seems unclear > > > to you that what SPF "requires" isn't relevant to my proposal! > > > Please, can you give up using this as an opportunity to bash SPF? It's > > > OT. (Note the changed Subject:). > > > > Using SPF records is not relevant to what is required of SPF? > > > > If SPF was limited to CIDR notation and the MX record, then the value of > > SPF would increase significantly as a white-listing tool. Much of the > > label construction macros and exists syntax reduce SPF's value and will > > likely serve to obfuscate a ploy that hides zombies. > > So therefore you'd like to not use useful information that might be > found in SPF records, just because it might be seen as legitimizing the > components of SFP records that you feel are unhelpful to the effort. You obviously do not understand the significant risk when making these types of guesses or alleging acceptance of accountability. > > > > Example: Mailbox.tld has SPF records that define the entire address > > > > space for three of their providers where they outsource some of their > > > > mail, and their own. I contend reputation should be based upon what you > > > > have control over. That would mean it would not be to your advantage to > > > > include the machines of these other providers in a reputation > > > > assessment. > > > > > > Ah, I did say ip4 (and therefore CIDR ranges) might be OK. > > > (I did suggest subsequently in mail to John Leslie that perhaps just > > > +ip4:a.b.c.d/32 might be OK, note the /32!) > > > Perhaps even that isn't a good idea, as > > > > > > mailbox.dom spf ip4:[isp1's smtp]/32,ip4:[isp2's smtp]/32,ip4:[isp3's smtp] -all > > > > > > enables me to inappropriately stake my domain's reputation on the > > > ability of ISPs 1-3 to keep their smtp servers from being used to spam. > > > HOWEVER: It's already the case that such SPF records are > > > inappropriate. If I don't have high confidence in the ISPs, then the > > > appropriate record would be: > > > > > > mailbox.dom spf ?ip4:[isp1's smtp]/32, ?ip4:[isp2's smtp]/32, ?ip4:[isp3's smtp] -all > > > and this record would be equivalent to the null set in my scheme: > > > my proposal ignores ~anything and ?anything. > > > Similarly, anyone creating a record like > > > > > > > mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self. > > > > I [DO NOT] think the motive for using SPF > > records for this purpose is well founded. If the MTA is not willing to > > provide a significantly strong identifier, it does not make sense to > > start guessing what is meant by the SPF records. > > > I argue that it does make sense to do so, and can be done safely. What happens when the scheme can not be defended beyond being used to sort mail? I doubt any reputation service would last very long making these guesses and allegations. > > The fall back would be using the address. > > The IP address? Sure, that's an option. (I note that RBL entries in a > sense are MARID - they indicate MAPS' opinion as to whether a MTAs > should be Authorized by MAPS' users to transmit mail to them, expressed > as Records In the Dns.) The mechanism used for the reputation service does not need to be based upon DNS. But the identity does need to be as strongly authenticated as the IP address. > > There can be no implied contract where a domain becomes accountable > > for the actions of others trusted to send their mail. > > Ah, but it is what you are asserting. : ) > > A provider lax in their security should not be allowed to hide behind > > their customer's domains. Should the provider wish to force the > > customer to accept this risk, they can ask to have the customer setup a > > CSV-CSA record that enables their servers. You do not want this > > accountability to be implied as you suggest. > > I DO NOT SUGGEST THIS. WTF? How many times do I have to say it? You can attempt to reduce the scope of the SPF records by tossing out those elements that appear to be under different administrators. How does this help? When you create a "maybe" condition resulting from a culling of the information, who is at fault either way? This scheme becomes damned by the gray. CSV is purely black and white. Why add uncertainty and risk to a mechanism? > > > [mailbox.dom] will suffer the consequences of doing something so dumb, > > > if one of the 3 ISPs seriously fails keep their smtp servers from > > > being used to spam using mailbox.dom. The domain will get blacklisted > > > (in other words, its reputation will fall), and the spoofing will > > > stop. > > > > SPF requires the addresses of the entire mail channel. It is odd that > > you would call that dumb. > > > No, you still don't get it. You ignore or don't understand the > difference between + and ? in an SPF1 record, as defined in the I-D / > explained a couple paragraphs down. > > Once again, I think this would be dumb: > > > mailbox.dom spf ip4:[isp1's smtp]/32,ip4:[isp2'ssmtp]/32,ip4:[isp3's smtp] -all > > not this: > > mailbox.dom spf ?ip4:[isp1's smtp]/32, ?ip4:[isp2's smtp]/32,?ip4:[isp3's smtp] -all If one of the goals is to still allow mail to enter outside the mail channel, why would that be dumb? Some would rather trade reliable delivery and a signature for this "must fit" approach. At least using a name list still allows a safe way to note when a message is outside the mail channel without inviting a world of spoofers taking a ride on your reputation. > > > > The rules that accept only closed SPF components still do not achieve a > > > > goal of assessing only the administrator accountable. > > > > > > The rules I am refining do achieve that goal. Arguably, they do so > > > better than CSV, because they'll work for most domains that haven't > > > bothered to set up a CSV record. Heck, using the SPF 'best guess' may > > > be appropriate where there's no SPF or CSV record - the A&R system will > > > reflect reality if this guess allows much spam through. > > > > I would hope it never comes to groping through various TXT script > > records looking for a clue. I understand what you are attempting, but > > there are risks getting this wrong. It is not worth the risk. > > Let's agree to disagree and move on. (Or at least let's move this > thread to > ) - Please reply there; I won't post > further here on this thread.) > > > > > > > > > > Just removing open elements will not achieve the desired goal as it does > > > > not provide the same set. > > > > > > That's not a logical argument. The ultimate desired goal is to address > > > the spam problem. It may or may not be material to achievement of that > > > goal to get "the same set". > > > > There are significant liabilities getting this wrong. > > Well, duh. That statement is true whenever one is doing something > important. So we proceed thoughtfully and get it right. > > > > > > SPF does not have the concept of administrative versus authorized. > > I would say it does. I would say that ? is for servers that are > tentatively authorized, and + is for servers that are administered by > the entity owning the domain. + normally indicates a server that the > domain claims is administered responsibly; ? indicates a server that > it isn't sure is administered responsibly, but never [the] less does > not want to deny the ability to use the domain. You are making assumptions how this syntax can be applied. Obviously the manner of application is not under the control of the sender. The sender will be obliged to use whatever it takes to achieve their goal of having mail accepted. I do not see how the recipient can infer levels of accountability for the mailbox domain administrator. Do they get a free pass when they declare their SPF records with a different domain name than the mailbox domain, or in the case of CSV, a different HELO name? Reusing SPF records allows EHLO spoofing to use these records in unintended ways. > > > > There is nothing in the syntax that would allow the differentiation. > > See above. > > > > > In addition, the EHLO name can express any label to select any > > > > record. > > > > > > a record for aol.com is still differentiable from one for > > > dhcp234.234.dialup.aol.com! > > > > But either label may appear within the EHLO response. You want a label > > that can only be used for the single purpose of indicating the > > administration of the MTA. From this information, it is a small matter > > to establish the mailbox-domain/mail-channel association. > > For many domains this info isn't available. And until CSV takes off, it > makes sense to use the available info in a responsible manner as I > propose. Especially if the pressure to publish SPF records continues to > increase. Once an authenticated HELO name is made visible to the recipient as a type of postmark, there will be plenty of motivation to publish these CSV records to earn greater trust. Name based reputation will also enable significant protection from filtering. All of this while making fewer DNS record lookups. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Thu Sep 30 03:36:44 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 DAA23092 for ; Thu, 30 Sep 2004 03:36: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 i8U73Y9M099585; Thu, 30 Sep 2004 00:03:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8U73Yme099584; Thu, 30 Sep 2004 00:03:34 -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 i8U73Xtf099545 for ; Thu, 30 Sep 2004 00:03:33 -0700 (PDT) (envelope-from matthew@elvey.com) Received: from web1.messagingengine.com (web1.internal [10.202.2.210]) by frontend1.messagingengine.com (Postfix) with ESMTP id 68A50C2D15B for ; Thu, 30 Sep 2004 03:03:30 -0400 (EDT) Received: by web1.messagingengine.com (Postfix, from userid 99) id 91D7F1567; Thu, 30 Sep 2004 03:03:30 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.001; A1.64; B3.05; Q3.03) References: <415215F7.7090105@elvey.com> <1095911060.13180.168.camel@ddev.mail-abuse.org> <41527800.4000405@elvey.com> <1095935943.5443.139.camel@localhost.localdomain> <415A35CB.80004@elvey.com> <1096523619.28969.651.camel@ddev.mail-abuse.org> Subject: Re: Make CSV backwards compatible with legacy SPF records? In-Reply-To: <1096523619.28969.651.camel@ddev.mail-abuse.org> To: "MXCOMP" Date: Thu, 30 Sep 2004 00:03:30 -0700 From: "Matthew Elvey" X-Sasl-Enc: 4mXTcXaXjNZgN0dhRj7Ikg 1096527810 Message-Id: <1096527810.18119.205461738@webmail.messagingengine.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 29 Sep 2004 22:53:39 -0700, "Douglas Otis" : made a large number of false statements and provided no new logic, but rehashed a bunch of old arguments that previous posts already address. I trust that folks reading the thread (if there are any) can make their own evaluation as to whether this proposal makes sense. I see only repeat performances of the exact same arguments if I continue to argue. Doug also failed to move the thread, which I requested, as it was appropriate. What is to say here has been said. Matthew said: > > Let's agree to disagree and move on. (Or at least let's move this > > thread to > > ) - Please reply there; I won't post > > further here on this thread [assuming you do respect that request].) From owner-ietf-mxcomp@mail.imc.org Thu Sep 30 04:45: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 EAA28706 for ; Thu, 30 Sep 2004 04:45: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 i8U8KR52043312; Thu, 30 Sep 2004 01:20:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8U8KRqO043311; Thu, 30 Sep 2004 01:20:27 -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 i8U8KPXi043226 for ; Thu, 30 Sep 2004 01:20:26 -0700 (PDT) (envelope-from Danny_Angus@slc.co.uk) X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-14.tower-78.messagelabs.com!1096532418!2179375 X-StarScan-Version: 5.2.10; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 10846 invoked from network); 30 Sep 2004 08:20:18 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-14.tower-78.messagelabs.com with SMTP; 30 Sep 2004 08:20:18 -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 ; Thu, 30 Sep 2004 09:20:17 +0100 Subject: Re: [spf-discuss] Re: [Maybe Spam] Re: Processed-By (or Transmitted-By) header concept To: spf-discuss@v2.listbox.com Cc: MXCOMP , "william(at)elan.net" X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Danny Angus Date: Thu, 30 Sep 2004 09:20:18 +0100 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 30/09/2004 09:20:17 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: William, > Did I ever say this was a mandatory or alternative to anything? > Just like information put in the received lines is not mandatory but > is considered to be "good behavior" so would this be good behavior > for systems that change source and destination addresses in transit. > It is definetly not going to be MUST at best SHOULD for old values > and MAY for new values (although i prefer SHOULD...) My problem is that no matter how finely crafted this may be it will be of very little practical use, 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'm arguing exactly that we _should_ be replacing MAY with MUST or SHOULD in existing specifications before creating a new header with a broad scope which I suspect overlaps to some degree with many other _optional_ parts of existing rfc's at various stages. The net result would be that there would be a well supported set of standards created from the de-facto behaviour of the majority, and probably a clearly identifiable gap which may indeed need addressed in terms of new specifications for new headers. What I fail to see the benefit of is a new trace header that duplicates existing information, involves the transmission of significant extra data (by significant I mean that we are considering doubling the header involved in every change), is not mandatory and would in practice be unreliable for all but the last hop. > I also note that information provided by the construct is currently > not available at all. This is its value, as it allows to see changes > made to email source and destination in consistant way. 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 a far more useful (but not complete I grant you) picture would emerge. >As far as amount of data, over 50% of emails (especially the shorter ones) >are user to user (source to destination) direct and would not have this >line, the other emails mostly pass through one or two forwarding hops >which already add tons of Received and X- lines, at best this would add >25% extra header data to such emails. And in any case, all this data is >completely ignored by most end-users who are not techs and are not >interested in how email got to them. My point is that this information increases network traffic and MTA load for _little_ gain. > Also all email signing systems will add A LOT MORE data to emails just > by the fact that full signatures takes a lot more space. But here there is a quantifiable gain. This extra data guarantees quality, signature data provides reliablity and enables security and trust. > I'm not against > it and infact based on the amount of email data that ISP processe, it >seems that percent of SMTP traffic over overall traffic decreased (inspite >of increasing amount of spam). What happened is that ISP infrastructure >has been upgraded with a lot bigger pipes both on the ISP networks and to >end-users who now often have DSL and cable and email use which was big >deal during dialup still remains but for DSL subscriber the real use >of internet is now P2P, MP3 downloads, gaming, HTML surfing with a lot >more graphics, etc. So we should not see ideas that cause increase in >size of emails as big deal for network infrastructure - it'll have >minimum impact on it and most it could is increase size of email box >storage but with advancement of storage devices and hard drives of >300GB now on the market (as opposed to 30GB 5 years ago), this also >woule have no serious impact. Somewhere in every system's people is a guy who's job it is to cost and justify bandwidth provision, home users buy what is available, business users purchase bandwidth to satisfy their need, if that need is increased as a result of increased message header sizes you'd better be prepared to justify that increase in terms of security, savings available elsewhere, or fixing a problem. I mean no disrespect to you, I wouldn't be saying these things if I felt that your proposals were way off beam and lacked merit, I have ideas of my own which are complimentary to and compatible with your overall plan, and they also benefit from enhanced traceability so you could say that I understand the reasons behind this requirement. But I diverge from the point, more of this later. In the meantime however, I believe that the answer to this part of the problem is to build consistency into the specifications of the headers which already exist, and not to introduce a new one until we have found the minimum data we require from it that we don't have the opportunity to calculate from data contained elsewhere. 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 Thu Sep 30 17:01: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 RAA02343 for ; Thu, 30 Sep 2004 17:01: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 i8UKUiQV044686; Thu, 30 Sep 2004 13:30: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 i8UKUijG044685; Thu, 30 Sep 2004 13:30:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miranda.server-plant.co.uk (miranda.server-plant.co.uk [193.110.88.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8UKUgVa044665 for ; Thu, 30 Sep 2004 13:30:43 -0700 (PDT) (envelope-from johnp@idimo.com) Received: from idimo2 ([62.87.75.169]) (authenticated) by miranda.server-plant.co.uk (8.11.6/8.11.2) with ESMTP id i8UKUZb15671 for ; Thu, 30 Sep 2004 21:30:36 +0100 Message-ID: <00a101c4a72c$57faa460$984d573e@idimo2> From: "jpinkerton" To: References: Subject: IPR issues bieng tested in court in Europe - and London, England is the worlds biggest hub Date: Thu, 30 Sep 2004 22:30:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit IPR issues bieng tested in court in Europe http://news.bbc.co.uk/2/low/business/3703316.stm London, England is the worlds biggest hub http://news.bbc.co.uk/2/low/technology/3700290.stm Slainte, JohnP. johnp@idimo.com ICQ 313355492 From owner-ietf-mxcomp@mail.imc.org Thu Sep 30 18:23:55 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 SAA09197 for ; Thu, 30 Sep 2004 18:23: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 i8ULvkEC050257; Thu, 30 Sep 2004 14:57: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 i8ULvkdd050256; Thu, 30 Sep 2004 14:57:46 -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 i8ULvjtT050250 for ; Thu, 30 Sep 2004 14:57:45 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i8ULvoaD023109 for ; Thu, 30 Sep 2004 14:57:50 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Sep 2004 14:57:50 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: ietf-mxcomp@imc.org Subject: RE: IPR issues bieng tested in court in Europe - and London, Engl and is the worlds biggest hub Date: Thu, 30 Sep 2004 14:57:49 -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: Hey guys, most engineers are opposed to incest, software patents and folk dancing[*]. But that does not mean that we have to go into a protracted discussion of such in this forum. > -----Original Message----- > From: jpinkerton [mailto:johnp@idimo.com] > Sent: Thursday, September 30, 2004 4:30 PM > To: ietf-mxcomp@imc.org > Subject: IPR issues bieng tested in court in Europe - and London, > England is the worlds biggest hub > > > > IPR issues bieng tested in court in Europe > > > http://news.bbc.co.uk/2/low/business/3703316.stm > > > London, England is the worlds biggest hub > > > http://news.bbc.co.uk/2/low/technology/3700290.stm > > > > Slainte, > > JohnP. > johnp@idimo.com > ICQ 313355492 > From owner-ietf-mxcomp@mail.imc.org Thu Sep 30 19:30:49 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 TAA13648 for ; Thu, 30 Sep 2004 19:30:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8UN6O9R059445; Thu, 30 Sep 2004 16:06: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 i8UN6OiQ059444; Thu, 30 Sep 2004 16:06:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8UN6JVQ059284 for ; Thu, 30 Sep 2004 16:06:23 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: IPR issues bieng tested in court in Europe - and London, England is the worlds biggest hub MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 30 Sep 2004 18:06:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D055434@srv1.pan-am.ca> Thread-Topic: IPR issues bieng tested in court in Europe - and London, England is the worlds biggest hub Thread-Index: AcSnPk5rnVlGe2hvRi6kbg00PnCYxwAA7WkA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8UN6NVQ059433 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Hey guys, most engineers are opposed to incest, software > patents and folk > dancing[*]. But that does not mean that we have to go into a > protracted discussion of such in this forum. Not like it hasn't been done before or anything. IPR is what finally doomed MARID after all. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins.