From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 03:37:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02765 for ; Tue, 1 Feb 2005 03:37:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j117wXx4004989; Mon, 31 Jan 2005 23:58:33 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j117wX06004988; Mon, 31 Jan 2005 23:58:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (exim@baythorne.infradead.org [81.187.226.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j117w8gF004752 for ; Mon, 31 Jan 2005 23:58:22 -0800 (PST) (envelope-from SRS0+cc2af3005edc5511f01d+527+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by baythorne.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1Cvsuw-0004zP-Bb; Tue, 01 Feb 2005 07:57:46 +0000 Subject: Re: So here it is one year later... From: David Woodhouse To: Douglas Otis Cc: Hector Santos , ietf-mxcomp@imc.org In-Reply-To: <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain Date: Tue, 01 Feb 2005 07:57:46 +0000 Message-Id: <1107244666.783.346.camel@baythorne.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) 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 Mon, 2005-01-31 at 18:23 -0800, Douglas Otis wrote: > I should also note that BATV does not require any outside service to > address abusive bounce messages. Although SES is similar, it > introduces some security concerns by way of its syntax. The syntax of each can be treated as if it's entirely opaque, and SES without any form of validation at the _receiving_ side is then indistinguishable from BATV in all but cosmetics, surely? What are the security concerns of which you speak? -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 03:42:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03047 for ; Tue, 1 Feb 2005 03:42:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j118KU45013265; Tue, 1 Feb 2005 00:20:30 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j118KUJJ013264; Tue, 1 Feb 2005 00:20:30 -0800 (PST) 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 j118KUUn013252 for ; Tue, 1 Feb 2005 00:20:30 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.41] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j118KROA018391 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Feb 2005 00:20:28 -0800 Subject: Re: So here it is one year later... From: Douglas Otis To: David Woodhouse Cc: ietf-mxcomp@imc.org In-Reply-To: <1107244666.783.346.camel@baythorne.infradead.org> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> <1107244666.783.346.camel@baythorne.infradead.org> Content-Type: text/plain Message-Id: <1107246027.31605.15.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 01 Feb 2005 00:20:27 -0800 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, 2005-01-31 at 23:57, David Woodhouse wrote: > On Mon, 2005-01-31 at 18:23 -0800, Douglas Otis wrote: > > I should also note that BATV does not require any outside service to > > address abusive bounce messages. Although SES is similar, it > > introduces some security concerns by way of its syntax. > > The syntax of each can be treated as if it's entirely opaque, and SES > without any form of validation at the _receiving_ side is then > indistinguishable from BATV in all but cosmetics, surely? > > What are the security concerns of which you speak? This was raised on the CLEAR mailing list by William Leibzon and responded to by Tony Finch. Follow the thread. http://mipassoc.org/pipermail/ietf-clear/2004-November/000133.html To discuss this issue, it would be best done on the CLEAR reflector: http://mipassoc.org/mailman/listinfo/ietf-clear -Doug From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 04:11:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05540 for ; Tue, 1 Feb 2005 04:11:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j118mSpf022976; Tue, 1 Feb 2005 00:48:28 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j118mSRP022975; Tue, 1 Feb 2005 00:48:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (exim@baythorne.infradead.org [81.187.226.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j118mRi3022960 for ; Tue, 1 Feb 2005 00:48:27 -0800 (PST) (envelope-from SRS0+cc2af3005edc5511f01d+527+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by baythorne.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1Cvthy-00055S-HE; Tue, 01 Feb 2005 08:48:26 +0000 Subject: Re: So here it is one year later... From: David Woodhouse To: Douglas Otis Cc: ietf-mxcomp@imc.org In-Reply-To: <1107246027.31605.15.camel@bash.adsl-64-142-13-68> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> <1107244666.783.346.camel@baythorne.infradead.org> <1107246027.31605.15.camel@bash.adsl-64-142-13-68> Content-Type: text/plain; charset=UTF-8 Date: Tue, 01 Feb 2005 08:48:26 +0000 Message-Id: <1107247706.783.373.camel@baythorne.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) 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, 2005-02-01 at 00:20 -0800, Douglas Otis wrote: > > What are the security concerns of which you speak? > > This was raised on the CLEAR mailing list by William Leibzon and > responded to by Tony Finch. Follow the thread. > > http://mipassoc.org/pipermail/ietf-clear/2004-November/000133.html Ah yes; I had seen that but discarded it as irrelevant in the context of BATV -- BATV alone doesn't really offer the _recipient_ much benefit along those lines anyway. Referring to the examples in message 000146.html, it's obvious that with BATV the attacker could just send a mail from 'batv=INVALIDBATVTAG/victim@domain' anyway, and the recipient would have no means to validate that. In the context of SES it's slightly more relevant, but really not by far. It involves a naïve user actually looking in the message headers for the reverse-path and _incorrectly_ identifying it as an SES localpart, thus having faith in it. (If the MUA were to be modified to show SES/BATV reverse-paths more prominently, of course it wouldn't have the false positives that wetware can have). In general, users don't do that. Either they're capable of telling the difference, or they're not going to be looking in the headers for it anyway. The middle ground is relatively rare. It also involves the domain owner/admin actually permitting that kind of reverse-path to be used in outgoing mail, and authorising it as valid if it's sent from elsewhere. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 05:19:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10412 for ; Tue, 1 Feb 2005 05:19:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j119nGjC044586; Tue, 1 Feb 2005 01:49:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j119nGw4044585; Tue, 1 Feb 2005 01:49:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j119nFZ6044547 for ; Tue, 1 Feb 2005 01:49:15 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1Cvuee-0007xN-2I for ietf-mxcomp@imc.org; Tue, 01 Feb 2005 03:49:09 -0600 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> <1107244666.783.346.camel@baythorne.infradead.org> <1107246027.31605.15.camel@bash.adsl-64-142-13-68> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Tue, 01 Feb 2005 03:49:03 -0600 In-Reply-To: <1107246027.31605.15.camel@bash.adsl-64-142-13-68> (Douglas Otis's message of "Tue, 01 Feb 2005 00:20:27 -0800") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-6.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +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 <1107246027.31605.15.camel@bash.adsl-64-142-13-68> Douglas Otis writes: > This was raised on the CLEAR mailing list [...] > > To discuss this issue, it would be best done on the CLEAR reflector: Wait, you don't want CSV issues discussed on the MARID list even though CSV was adopted by MARID? But you keep bring up SPF discussions here instead of on SPF-discuss even though MARID never adopted SPF? *sigh* -wayne From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 05:35:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12074 for ; Tue, 1 Feb 2005 05:35:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11A2BYo048281; Tue, 1 Feb 2005 02:02:11 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11A2BjQ048280; Tue, 1 Feb 2005 02:02:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11A2AiQ048268 for ; Tue, 1 Feb 2005 02:02:10 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1CvurC-0008F9-K4 for ietf-mxcomp@imc.org; Tue, 01 Feb 2005 04:02:09 -0600 To: "IETF MARID WG" References: From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Tue, 01 Feb 2005 04:02:02 -0600 In-Reply-To: (william elan net's message of "Mon, 31 Jan 2005 14:22:59 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-6.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +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: > On Mon, 31 Jan 2005, wayne wrote: > >> > DK and SPF have different failure modes. I don't think this is a >> > competition situation. A system with both schemes is much more >> > effective than either on its own. >> [snip] > > The are complimentary but they work and protect different parts of email > message. That means each one must be able to work on its own independant > of the other one and authentication should work properly on each layer. > You can not have failure scenario of one system being depdending on the > authentication in another layer - this is just a bad security architecture. You certainly have a point here and but I think you over state it a little bit. If both SPF and the crypto systems (DK/IIM/SES/etc.) agree on the results, then you have much more reliable whitelisting *or* blacklisting. If SPF passes and the crytpo system fails, then that is good evidence that the email came from a mailing list. Combined with other evidence, and you can get pretty good results. If SPF fails and the crypto system passes, then that is good evidence that the email came from a forwarder. Combined with other evidence, and you can get pretty good results. > That means if we want to use SPF and mail signatures for anything other > then whitelisting (i.e. to get rid of actual bad messages and find bad > senders), we must find ways to deal with SPF forwarding problems on the > SMTP session layer and must have MASS signatures that work with mail lists. Yes, SPF *MUST* continue to work on the forwarding problem so that you don't have just "good evidence", and the same for the crypto systems. However, I don't think either kind of system will ever be able to completely solve their weaknesses. I still think, and have said so many times over the last year or so, that these systems can complement each other. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 09:01:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03866 for ; Tue, 1 Feb 2005 09:01:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11DQv8r021543; Tue, 1 Feb 2005 05:26:57 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11DQvVL021541; Tue, 1 Feb 2005 05:26:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j11DQuSX021534 for ; Tue, 1 Feb 2005 05:26:57 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Tue, 01 Feb 2005 08:25:50 -0500 Received: from ([68.215.51.253]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3887677562; Tue, 01 Feb 2005 08:25:48 -0500 Message-ID: <004c01c50861$365fdff0$6401a8c0@hdev1> From: "Hector Santos" To: "Douglas Otis" Cc: References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> Subject: Re: So here it is one year later... Date: Tue, 1 Feb 2005 08:23:17 -0500 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: "Douglas Otis" To: "Hector Santos" Cc: Sent: Monday, January 31, 2005 9:23 PM Subject: Re: So here it is one year later... > On Mon, 2005-01-31 at 16:50 -0500, Hector Santos wrote: > > Please Doug. > > > > You can't guarantee that an immediate router will be CSV compliant. So you > > have the same heterogeneous/mixed policy issues as SPF and all the rest of > > the proposals. > > If the sending SMTP client publishes a CSV-CSA record, then this client > is both authenticated and authorized by the HELO domain. The "chain of trust" issues with SPF applies to CSV as well. What about the downlink? Once the message is received, it is your responsibility to deliver it. My sender went directly to you, the MDA. If you decide to route it instead, then you have to maintain the chain of trust. You can not guarantee this transaction when you become the sender. > > In addition, you have a MUCH higher overhead than most as you based on > > state point #1 - HELO/EHLO. > > Authenticating the HELO is done within a single lookup with CSV. How > can this be a higher overhead? I don't think you really understand the implementation issues of your own proposal. Maybe you do and are just turning a blind eye. > > Now why would I want to do a HELO CSV check without determining: > > > > - Check to see if the sender is valid, > > - Final vs Route > > MASS is addressing the need to safely authenticate the administrator of > originating sender domain. .... You didn't answer the middle-ware, chain of trust issue, and you didn't address the above. Delay verification is a REQUIREMENT, not a BCP for all DNS based authorization ideas.. I have statistic proof with over 1 year of product operations in thousands of installed sites: http://www.winserver.com/spamstats. The functional model of CSV is: EPV = CSV(helo, ip) which fails to take into the account the validity of the other process environment parameters, MailFrom, RcptTo. That my friend, is a overhead issue. > > But what if the SMTP operator does not want to use your new MAPS CSV/DNA > > service? What if you go out of business? What if you get enough support > > headaches from thousands of smaller systems that you decide to raise the > > price to filter out these bothersome clientele? > > This seems to be putting the cart before the horse. No. It is called business and practical product experience. You are proposing an idea infested (wrongly placed) with capitalistic commercial concepts, which I don't mind saying, you will be among the first to benefit from as the first DNA commercial service. PR problem #1. Therefore, if we were support and implement CSV, we would have to include a disclaimer for any Anti-Spam CSV support statement; "Batteries Not Included. DNA Service Subscription Required." We are not going to add what is suppose to be a "technical" solution with subscription concepts behind it. Period. PR problem #2. My Advice? Dave should take Doug out of the CSV promotion picture. You don't do CSV any justice. Dont' get me wrong. I'm for making a buck as much as the next guy. But the "Email Problem" needs an open standard technical solution free of 3rd party dependencies. It is a duel tier process. Transport security must be done using SMTP first. Main Content Security is an separate issue, however, there can be a tie in of the two, but not dependent on it. The point is, if you send me mail, I must be able to trust the transaction before I accept your payload. Authenticating the payload is an ADMINISTRATIVE concept. Using a CSV authorization domain is not sufficient WITHOUT looking at the 2821.Mail From as well as 2821.RCPTTO. Therefore, as it has been emperically proven, using HELO by itself would be wasteful overhead without taken all process environment parameters into consideration. I have PROOF of this issue. Doug. All you are doing is making assertions of the opposite and you have no proof to show I am wrong. 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 Tue Feb 1 09:58:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11667 for ; Tue, 1 Feb 2005 09:58:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11E7HHL024995; Tue, 1 Feb 2005 06:07:17 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11E7HLc024994; Tue, 1 Feb 2005 06:07:17 -0800 (PST) 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 j11E7GWk024988 for ; Tue, 1 Feb 2005 06:07:17 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Tue, 01 Feb 2005 09:06:14 -0500 Received: from ([68.215.51.253]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3890101828; Tue, 01 Feb 2005 09:06:12 -0500 Message-ID: <006901c50866$db4d74a0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MARID WG" References: Subject: Re: So here it is one year later... Date: Tue, 1 Feb 2005 09:03:45 -0500 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 Wayne, A good well-though out system would factor out "mailing list" or other considerations. What is a mailing list anyway? It is just a new "agent" into mail stream. In my view, the real problem is the unfortunate direction where more and more systems are disrespecting the decades old tradition of not screwing around with the Mail Integrity. 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: Tuesday, February 01, 2005 5:02 AM Subject: Re: So here it is one year later... > > In "william(at)elan.net" writes: > > > On Mon, 31 Jan 2005, wayne wrote: > > > >> > DK and SPF have different failure modes. I don't think this is a > >> > competition situation. A system with both schemes is much more > >> > effective than either on its own. > >> [snip] > > > > The are complimentary but they work and protect different parts of email > > message. That means each one must be able to work on its own independant > > of the other one and authentication should work properly on each layer. > > You can not have failure scenario of one system being depdending on the > > authentication in another layer - this is just a bad security architecture. > > You certainly have a point here and but I think you over state it a > little bit. > > If both SPF and the crypto systems (DK/IIM/SES/etc.) agree on the > results, then you have much more reliable whitelisting *or* > blacklisting. > > If SPF passes and the crytpo system fails, then that is good evidence > that the email came from a mailing list. Combined with other > evidence, and you can get pretty good results. > > If SPF fails and the crypto system passes, then that is good evidence > that the email came from a forwarder. Combined with other evidence, > and you can get pretty good results. > > > > That means if we want to use SPF and mail signatures for anything other > > then whitelisting (i.e. to get rid of actual bad messages and find bad > > senders), we must find ways to deal with SPF forwarding problems on the > > SMTP session layer and must have MASS signatures that work with mail lists. > > Yes, SPF *MUST* continue to work on the forwarding problem so that you > don't have just "good evidence", and the same for the crypto systems. > However, I don't think either kind of system will ever be able to > completely solve their weaknesses. > > > I still think, and have said so many times over the last year or so, > that these systems can complement each other. > > > -wayne > > From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 13:25:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03276 for ; Tue, 1 Feb 2005 13:25:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11HvFvn042790; Tue, 1 Feb 2005 09:57:15 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11HvFdM042789; Tue, 1 Feb 2005 09:57:15 -0800 (PST) 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 j11HvBoC042779 for ; Tue, 1 Feb 2005 09:57:11 -0800 (PST) (envelope-from fenton@cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2005 09:59:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j11Hv2RO025399; Tue, 1 Feb 2005 09:57:03 -0800 (PST) Received: from [10.32.245.100] (stealth-10-32-245-100.cisco.com [10.32.245.100]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j11Hql1U008080; Tue, 1 Feb 2005 09:52:47 -0800 Message-ID: <41FFC2EC.7010703@cisco.com> Date: Tue, 01 Feb 2005 09:57:00 -0800 From: Jim Fenton User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hector Santos CC: IETF MARID WG Subject: Re: So here it is one year later... References: <41FE92AD.5090501@cisco.com> <000d01c507dd$0c861d90$6401a8c0@hdev1> In-Reply-To: <000d01c507dd$0c861d90$6401a8c0@hdev1> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107280367.934286"; x:"432200"; a:"rsa-sha1"; b:"nofws:1045"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"RdlUOMPBw3+IEnqiiZCWitTvVqZevTAr1+G22w0wJ28reV5TPC6frmKYkNfAe++L9jp4intT" "FMDlbVJlMLOLT7Q55PINJaCrEz6UBjjMVPqlULDhjX9zSuuP9Q0e7LxDB/TgHll9WjonU6S5rHE" "oYcu7bu/x6SxT+TZ3tKsv0uc="; c:"Date: Tue, 01 Feb 2005 09:57:00 -0800"; c:"From: Jim Fenton "; c:"Subject: Re: So here it is one year later..." IIM-VERIFY: s:"y"; v:"y"; r:"60"; 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: Content-Transfer-Encoding: 7bit I think I'll stick with the "in layman terms" part of the message because that's most clearly stated: Hector Santos wrote: >In layman terms: > >What if my SMTP mail server detects a non-DK/IIM ready message? > > IMO, it will be a very long time (if ever) before a "typical" mail server will be able to take some action such as rejecting a message based on a missing signature, except possibly when the originating domain advertises that it signs all of its mail. >You need to answer that question otherwise what is the use of using DK/IIM >if a system still needs to work and be ready for non-DK/IIM messages? > > It's another message classification criterion, and when present enables reputation and accreditation based on who the signer is. >Now of course, it might work well in an exclusive CISCO corporate/enterprise >settings, a big pat on the back, an exciting marketing and promotion largely >based on "hope" I can imagine for your big customer base. But this is not >a standard across the board. > > I hope it's obvious that's not Cisco's intent. But it should be possible with standards-based message authentication for anyone to more accurately whitelist their suppliers, customers, and partners, to make sure that their messages never get lost. -Jim From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 14:54:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12301 for ; Tue, 1 Feb 2005 14:54:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11JQ8fO049557; Tue, 1 Feb 2005 11:26:08 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11JQ8D0049556; Tue, 1 Feb 2005 11:26:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j11JQ7T5049549 for ; Tue, 1 Feb 2005 11:26:07 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Tue, 01 Feb 2005 14:25:00 -0500 Received: from ([68.215.51.253]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3909228281; Tue, 01 Feb 2005 14:24:59 -0500 Message-ID: <014601c50893$6331a5e0$6401a8c0@hdev1> From: "Hector Santos" To: "Jim Fenton" Cc: "IETF MARID WG" References: <41FE92AD.5090501@cisco.com> <000d01c507dd$0c861d90$6401a8c0@hdev1> <41FFC2EC.7010703@cisco.com> Subject: Using DK/IIM [was: Re: So here it is one year later...] Date: Tue, 1 Feb 2005 14:22:31 -0500 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 Jim, these are legit questions: 1) Who is the signer? MUA or MSA? 2) How should a MDA handle the following: 2a) A domain with DK/IIM published information but a non-DK/IIM payload? 2b) A non-DK/IIM domain? 2c) Broken DK/IIM message? 3) What is the role of the intermediatary router MTA? 4) What is the relationship of the transport parameters; IP, HELO, MAILFROM and RCPTO with a DK/IIM ready payload? What upfront logic can be used? 5) Since a MDA requires to view the PAYLOAD to validate the DK/IIM, what is the policy for POST-SMTP failed DK/IIM results? 6) Finally, how should gateway transformation systems handle DK/IIM payloads which may get stripped. For example, a console based mail system only needs two parts: The main headers: From: To: Subject: Date: and the body: text body 6a) How does this change the mail reader, online and offline? For example, should the presentation software display some "Red Warning Icon" suggesting "Possible Invalid Message?" Thanks Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "Jim Fenton" To: "Hector Santos" Cc: "IETF MARID WG" Sent: Tuesday, February 01, 2005 12:57 PM Subject: Re: So here it is one year later... > > I think I'll stick with the "in layman terms" part of the message > because that's most clearly stated: > > Hector Santos wrote: > > >In layman terms: > > > >What if my SMTP mail server detects a non-DK/IIM ready message? > > > > > IMO, it will be a very long time (if ever) before a "typical" mail > server will be able to take some action such as rejecting a message > based on a missing signature, except possibly when the originating > domain advertises that it signs all of its mail. > > >You need to answer that question otherwise what is the use of using DK/IIM > >if a system still needs to work and be ready for non-DK/IIM messages? > > > > > It's another message classification criterion, and when present enables > reputation and accreditation based on who the signer is. > > >Now of course, it might work well in an exclusive CISCO corporate/enterprise > >settings, a big pat on the back, an exciting marketing and promotion largely > >based on "hope" I can imagine for your big customer base. But this is not > >a standard across the board. > > > > > I hope it's obvious that's not Cisco's intent. But it should be > possible with standards-based message authentication for anyone to more > accurately whitelist their suppliers, customers, and partners, to make > sure that their messages never get lost. > > -Jim > > From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 16:13:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21002 for ; Tue, 1 Feb 2005 16:13:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Kkjo0054690; Tue, 1 Feb 2005 12:46:45 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11KkjXm054689; Tue, 1 Feb 2005 12:46:45 -0800 (PST) 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 j11Kkjcv054680 for ; Tue, 1 Feb 2005 12:46:45 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 5EB22414E2; Tue, 1 Feb 2005 12:46:40 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: Hector Santos Cc: ietf-mxcomp@imc.org In-Reply-To: <004c01c50861$365fdff0$6401a8c0@hdev1> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> <004c01c50861$365fdff0$6401a8c0@hdev1> Content-Type: text/plain Date: Tue, 01 Feb 2005 12:46:26 -0800 Message-Id: <1107290787.6836.171.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 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, 2005-02-01 at 08:23 -0500, Hector Santos wrote: > On Mon, 2005-1-31 at 9:23 -0500, Douglas Otis wrote: > > On Mon, 2005-01-31 at 16:50 -0500, Hector Santos wrote: > > > > > > Please Doug. > > > > > > You can't guarantee that an immediate router will be CSV > > > compliant. So you have the same heterogeneous/mixed policy issues > > > as SPF and all the rest of the proposals. > > > > If the sending SMTP client publishes a CSV-CSA record, then this client > > is both authenticated and authorized by the HELO domain. > > The "chain of trust" issues with SPF applies to CSV as well. CSV does not make assurances for MAILFROM or FROM mailbox-domains. The HELO identifies the administrator of the specific MTA. It is the administrator trusted and not millions of users that may be using the server. When there is a problem, ONLY the administrator is able to rectify the situation. In essence, mail is not secure and the source of a message is not assured beyond the immediate server. It is wrong to assume a "chain of trust" is maintained, as this could be injurious to those assumed to be the source of the message. MASS avoids the fallacy of a "chain of trust" by using a digital signature. SPF assumes identities are checked at each stage against a lengthy resolution of path registrations. There is also no consensus which mailbox-domain is checked, if any, even assuming these checks were practical and safe. Schlitt's SPF draft says to use some identity as an alternative without indicating whether this is the PRA identity or something else. : ( > What about the downlink? Once the message is received, it is your > responsibility to deliver it. My sender went directly to you, the MDA. If > you decide to route it instead, then you have to maintain the chain of > trust. You can not guarantee this transaction when you become the sender. Most MTAs only accept mail from anonymous sources being sent to their immediate domains. Most MTAs also decide whether to accept from an anonymous source based upon reputations of the IP address. Without such checks, few could afford the bandwidth needed to permit legitimate mail. You are describing a practice that could put the reputation of the MTA IP address at risk. A reputation service should never consider an unauthenticated identity within the message as being culpable. > > > In addition, you have a MUCH higher overhead than most as you > > > based on state point #1 - HELO/EHLO. > > > > Authenticating the HELO is done within a single lookup with CSV. How > > can this be a higher overhead? > > I don't think you really understand the implementation issues of your own > proposal. Maybe you do and are just turning a blind eye. Information provided by SPF only indicates who may have sent the message, and not who actually sent it. Resolving issues of abuse by way of SPF is potentially injurious to mailbox-domain owners. CSV ensures accountability remains with those administering servers and not a possibly hapless customer. Essentially SPF is a weapon that does not always shoot straight and therefore should not be used as an abatement tool. SPF does not eliminate the need for administrators to control access to their servers nor remove the need to watch for abusive accounts. In addition, SPF is a paper tiger easily destroyed. MASS however is attempting to safely provide a real means to control use of the sender mailbox-domain. MASS provides this domain control to protect users, whereas CSV and BATV protect networks. SPF is unable to offer any real protection for either users and definitely not networks. > > > Now why would I want to do a HELO CSV check without determining: > > > > > > - Check to see if the sender is valid, > > > - Final vs Route > > > > MASS is addressing the need to safely authenticate the administrator of > > originating sender domain. .... > > You didn't answer the middle-ware, chain of trust issue, and you didn't > address the above. The use of a digital signature avoids false assumptions of there being a "chain of trust" as the mail channel is not secure. > Delay verification is a REQUIREMENT, not a BCP for all DNS based > authorization ideas.. I have statistic proof with over 1 year of product > operations in thousands of installed sites: > http://www.winserver.com/spamstats. > > The functional model of CSV is: > > EPV = CSV(helo, ip) > > which fails to take into the account the validity of the other process > environment parameters, MailFrom, RcptTo. That my friend, is a overhead > issue. Inordinate overhead must not be placed upon the receiving MTA. CSV delegates source control overhead onto the administrator accountable for the server. There are many tools to assist in their effort. Monitoring the SMTP error logs, unusual traffic patterns, as well as abuse reporting. CSV helps ensure this reporting is directed to the accountable administrator. SPF alone will not abate abuse, while it may produce victims as it is applied in conjunction with reputations. Spammers will simply adapt and take advantage of these false assumptions being made by SPF. > > > But what if the SMTP operator does not want to use your new MAPS > > > CSV/DNA service? What if you go out of business? What if you > > > get enough support headaches from thousands of smaller systems > > > that you decide to raise the price to filter out these bothersome > > > clientele? > > > > This seems to be putting the cart before the horse. > > No. It is called business and practical product experience. You are > proposing an idea infested (wrongly placed) with capitalistic commercial > concepts, which I don't mind saying, you will be among the first to benefit > from as the first DNA commercial service. CSV is offering an authenticated name for the sending MTA that helps in many ways with respect to dealing with the email abuse problem. The transition to the use of names will likely be an immediate benefit to those already providing vouching services. > PR problem #1. Therefore, if we were support and implement CSV, we > would have to include a disclaimer for any Anti-Spam CSV support > statement; "Batteries Not Included. DNA Service Subscription > Required." We are not going to add what is suppose to be a > "technical" solution with subscription concepts behind it. Period. An immediate benefit of CSV comes from being able to associate an authenticated name with the immediate sending MTA. MASS offers the feature that allows control over the sender mailbox-domain regardless of the immediate sending MTA. The blunt instrument provided by CSV protects the network from grossly negligent administrators. MASS should be able to protect users from those wishing to spoof sender mailbox-domains. MASS/CSV can work together in a unified name basis for guarding mail. SPF will not remove the need for some form of reputation/vouching service, nor remove the need for some form of network protection. > Dont' get me wrong. I'm for making a buck as much as the next guy. But > the "Email Problem" needs an open standard technical solution free of > 3rd party dependencies. It is a duel tier process. Transport > security must be done using SMTP first. Main Content Security is an > separate issue, however, there can be a tie in of the two, but not > dependent on it. There were several companies touting reputations services at the FTC Email Authentication Summit. I was not promoting such a service. I was insisting upon adoption of a safe and accurate means to assess abuse. I remain convinced MASS and CLEAR are considering viable solutions. > The point is, if you send me mail, I must be able to trust the transaction > before I accept your payload. Authenticating the payload is an > ADMINISTRATIVE concept. Authenticating the payload is the subject of an ongoing effort in MASS. I want to see MASS succeed in providing an effective solution that can protect the sender mailbox-domain. > Using a CSV authorization domain is not sufficient WITHOUT looking at the > 2821.Mail From as well as 2821.RCPTTO. Therefore, as it has been > emperically proven, using HELO by itself would be wasteful overhead without > taken all process environment parameters into consideration. Holding the sending domain accountable offers substantial relief without a need to sort through millions of users employing various mailbox-domains within thousands of various providers. There is a fair amount of experience that supports this view. > I have PROOF of this issue. Doug. All you are doing is making assertions of > the opposite and you have no proof to show I am wrong. This is not the proper venue for product related data. Most of the benefits claimed by SPF are related to changes in behavior, and not cessation of abuse. As an immediate source for relief, BATV would be more effective in preventing the unwanted bounce traffic as this can be done unilaterally. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 16:23:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23896 for ; Tue, 1 Feb 2005 16:23:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11L0Cwa055748; Tue, 1 Feb 2005 13:00:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11L0CaL055747; Tue, 1 Feb 2005 13:00:12 -0800 (PST) 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 j11L0CTC055737 for ; Tue, 1 Feb 2005 13:00:12 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id BC145414EC for ; Tue, 1 Feb 2005 13:00:07 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: IETF MARID WG In-Reply-To: References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> <1107244666.783.346.camel@baythorne.infradead.org> <1107246027.31605.15.camel@bash.adsl-64-142-13-68> Content-Type: text/plain Date: Tue, 01 Feb 2005 12:59:54 -0800 Message-Id: <1107291594.6836.183.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 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, 2005-02-01 at 03:49 -0600, wayne wrote: > In <1107246027.31605.15.camel@bash.adsl-64-142-13-68> Douglas Otis writes: > > > This was raised on the CLEAR mailing list [...] > > > > To discuss this issue, it would be best done on the CLEAR reflector: > > Wait, you don't want CSV issues discussed on the MARID list even > though CSV was adopted by MARID? But you keep bring up SPF > discussions here instead of on SPF-discuss even though MARID never > adopted SPF? Do you really want me to interact with those on the SPF-discuss mailing list? I suggested that the best forum to discuss this BATV/SES syntax was on the CLEAR list server. I see David made a minor error in his statement, as example, but I am not the person most conversant on this subject. I encouraged William to propose his concepts, but Tony raised some legitimate concerns. It would be beneficial to find consensus on this syntax. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 17:22:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08546 for ; Tue, 1 Feb 2005 17:22:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11LkOX7059494; Tue, 1 Feb 2005 13:46:24 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11LkOIb059493; Tue, 1 Feb 2005 13:46:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j11LkNXs059476 for ; Tue, 1 Feb 2005 13:46:23 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Tue, 01 Feb 2005 16:45:03 -0500 Received: from ([68.215.118.15]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3917631531; Tue, 01 Feb 2005 16:45:02 -0500 Message-ID: <001501c508a6$f2dc14b0$6401a8c0@hdev1> From: "Hector Santos" To: "Douglas Otis" Cc: References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> <004c01c50861$365fdff0$6401a8c0@hdev1> <1107290787.6836.171.camel@SJC-Office-DHCP-156.mail-abuse.org> Subject: Re: So here it is one year later... Date: Tue, 1 Feb 2005 16:42:28 -0500 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 Is this a CANNED reply message? It sure reads like it. Look, CSV does not pass the test for consideration. That might explain why no commercial vendor has implemented it. And we were not talking about MASS. We are talking about the fallacy of CSV being immune to heterogeneous/mix policy topologies and lacks overhead issues. You are wrong in both cases. I think you are saying MASS solves these problems for CSV. Well, that's a PAYLOAD solution so it doesn't address the heterogeneous/mix policies and overhead issues at the SMTP level. So I believe you are incorrect here as well. Anyway, I don't wish to get another canned reply, so I think I'll stop here.:-) Thanks for the chat 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: "Hector Santos" Cc: Sent: Tuesday, February 01, 2005 3:46 PM Subject: Re: So here it is one year later... > > On Tue, 2005-02-01 at 08:23 -0500, Hector Santos wrote: > > On Mon, 2005-1-31 at 9:23 -0500, Douglas Otis wrote: > > > On Mon, 2005-01-31 at 16:50 -0500, Hector Santos wrote: > > > > > > > > Please Doug. > > > > > > > > You can't guarantee that an immediate router will be CSV > > > > compliant. So you have the same heterogeneous/mixed policy issues > > > > as SPF and all the rest of the proposals. > > > > > > If the sending SMTP client publishes a CSV-CSA record, then this client > > > is both authenticated and authorized by the HELO domain. > > > > The "chain of trust" issues with SPF applies to CSV as well. > > CSV does not make assurances for MAILFROM or FROM mailbox-domains. The > HELO identifies the administrator of the specific MTA. It is the > administrator trusted and not millions of users that may be using the > server. When there is a problem, ONLY the administrator is able to > rectify the situation. In essence, mail is not secure and the source of > a message is not assured beyond the immediate server. It is wrong to > assume a "chain of trust" is maintained, as this could be injurious to > those assumed to be the source of the message. > > MASS avoids the fallacy of a "chain of trust" by using a digital > signature. SPF assumes identities are checked at each stage against a > lengthy resolution of path registrations. There is also no consensus > which mailbox-domain is checked, if any, even assuming these checks were > practical and safe. Schlitt's SPF draft says to use some identity as an > alternative without indicating whether this is the PRA identity or > something else. : ( > > > What about the downlink? Once the message is received, it is your > > responsibility to deliver it. My sender went directly to you, the MDA. If > > you decide to route it instead, then you have to maintain the chain of > > trust. You can not guarantee this transaction when you become the sender. > > Most MTAs only accept mail from anonymous sources being sent to their > immediate domains. Most MTAs also decide whether to accept from an > anonymous source based upon reputations of the IP address. Without such > checks, few could afford the bandwidth needed to permit legitimate mail. > You are describing a practice that could put the reputation of the MTA > IP address at risk. A reputation service should never consider an > unauthenticated identity within the message as being culpable. > > > > > In addition, you have a MUCH higher overhead than most as you > > > > based on state point #1 - HELO/EHLO. > > > > > > Authenticating the HELO is done within a single lookup with CSV. How > > > can this be a higher overhead? > > > > I don't think you really understand the implementation issues of your own > > proposal. Maybe you do and are just turning a blind eye. > > Information provided by SPF only indicates who may have sent the > message, and not who actually sent it. Resolving issues of abuse by way > of SPF is potentially injurious to mailbox-domain owners. CSV ensures > accountability remains with those administering servers and not a > possibly hapless customer. Essentially SPF is a weapon that does not > always shoot straight and therefore should not be used as an abatement > tool. SPF does not eliminate the need for administrators to control > access to their servers nor remove the need to watch for abusive > accounts. In addition, SPF is a paper tiger easily destroyed. MASS > however is attempting to safely provide a real means to control use of > the sender mailbox-domain. > > MASS provides this domain control to protect users, whereas CSV and BATV > protect networks. SPF is unable to offer any real protection for either > users and definitely not networks. > > > > > Now why would I want to do a HELO CSV check without determining: > > > > > > > > - Check to see if the sender is valid, > > > > - Final vs Route > > > > > > MASS is addressing the need to safely authenticate the administrator of > > > originating sender domain. .... > > > > You didn't answer the middle-ware, chain of trust issue, and you didn't > > address the above. > > The use of a digital signature avoids false assumptions of there being a > "chain of trust" as the mail channel is not secure. > > > Delay verification is a REQUIREMENT, not a BCP for all DNS based > > authorization ideas.. I have statistic proof with over 1 year of product > > operations in thousands of installed sites: > > http://www.winserver.com/spamstats. > > > > The functional model of CSV is: > > > > EPV = CSV(helo, ip) > > > > which fails to take into the account the validity of the other process > > environment parameters, MailFrom, RcptTo. That my friend, is a overhead > > issue. > > Inordinate overhead must not be placed upon the receiving MTA. CSV > delegates source control overhead onto the administrator accountable for > the server. There are many tools to assist in their effort. Monitoring > the SMTP error logs, unusual traffic patterns, as well as abuse > reporting. CSV helps ensure this reporting is directed to the > accountable administrator. SPF alone will not abate abuse, while it may > produce victims as it is applied in conjunction with reputations. > Spammers will simply adapt and take advantage of these false assumptions > being made by SPF. > > > > > But what if the SMTP operator does not want to use your new MAPS > > > > CSV/DNA service? What if you go out of business? What if you > > > > get enough support headaches from thousands of smaller systems > > > > that you decide to raise the price to filter out these bothersome > > > > clientele? > > > > > > This seems to be putting the cart before the horse. > > > > No. It is called business and practical product experience. You are > > proposing an idea infested (wrongly placed) with capitalistic commercial > > concepts, which I don't mind saying, you will be among the first to benefit > > from as the first DNA commercial service. > > CSV is offering an authenticated name for the sending MTA that helps in > many ways with respect to dealing with the email abuse problem. The > transition to the use of names will likely be an immediate benefit to > those already providing vouching services. > > > PR problem #1. Therefore, if we were support and implement CSV, we > > would have to include a disclaimer for any Anti-Spam CSV support > > statement; "Batteries Not Included. DNA Service Subscription > > Required." We are not going to add what is suppose to be a > > "technical" solution with subscription concepts behind it. Period. > > An immediate benefit of CSV comes from being able to associate an > authenticated name with the immediate sending MTA. MASS offers the > feature that allows control over the sender mailbox-domain regardless of > the immediate sending MTA. The blunt instrument provided by CSV > protects the network from grossly negligent administrators. MASS should > be able to protect users from those wishing to spoof sender > mailbox-domains. MASS/CSV can work together in a unified name basis for > guarding mail. SPF will not remove the need for some form of > reputation/vouching service, nor remove the need for some form of > network protection. > > > Dont' get me wrong. I'm for making a buck as much as the next guy. But > > the "Email Problem" needs an open standard technical solution free of > > 3rd party dependencies. It is a duel tier process. Transport > > security must be done using SMTP first. Main Content Security is an > > separate issue, however, there can be a tie in of the two, but not > > dependent on it. > > There were several companies touting reputations services at the FTC > Email Authentication Summit. I was not promoting such a service. I was > insisting upon adoption of a safe and accurate means to assess abuse. I > remain convinced MASS and CLEAR are considering viable solutions. > > > The point is, if you send me mail, I must be able to trust the transaction > > before I accept your payload. Authenticating the payload is an > > ADMINISTRATIVE concept. > > Authenticating the payload is the subject of an ongoing effort in MASS. > I want to see MASS succeed in providing an effective solution that can > protect the sender mailbox-domain. > > > Using a CSV authorization domain is not sufficient WITHOUT looking at the > > 2821.Mail From as well as 2821.RCPTTO. Therefore, as it has been > > emperically proven, using HELO by itself would be wasteful overhead without > > taken all process environment parameters into consideration. > > Holding the sending domain accountable offers substantial relief without > a need to sort through millions of users employing various > mailbox-domains within thousands of various providers. There is a fair > amount of experience that supports this view. > > > I have PROOF of this issue. Doug. All you are doing is making assertions of > > the opposite and you have no proof to show I am wrong. > > This is not the proper venue for product related data. Most of the > benefits claimed by SPF are related to changes in behavior, and not > cessation of abuse. As an immediate source for relief, BATV would be > more effective in preventing the unwanted bounce traffic as this can be > done unilaterally. > > -Doug > > From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 19:41:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23193 for ; Tue, 1 Feb 2005 19:41:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120CPFc068835; Tue, 1 Feb 2005 16:12:25 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j120CPUB068834; Tue, 1 Feb 2005 16:12:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailshell.com (www15.mailshell.com [209.157.66.245]) by above.proper.com (8.12.11/8.12.9) with SMTP id j120COuv068819 for ; Tue, 1 Feb 2005 16:12:24 -0800 (PST) (envelope-from mxcomp@brycer.com) Received: (qmail 17014 invoked by uid 99); 2 Feb 2005 00:12:13 -0000 Message-ID: <20050202001213.28059.qmail@mailshell.com> Date: Tue, 01 Feb 2005 16:11:48 -0800 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: So here it is one year later... References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> 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 What an amusing thread. Following along, it suggest this mailing list is secretly a humor list. At the least, it should be obvious why the WG accomplished nothing. "He's dead, Jim." Bryce Ryan From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 19:59:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24811 for ; Tue, 1 Feb 2005 19:59:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120ZIKg070210; Tue, 1 Feb 2005 16:35:18 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j120ZI1W070209; Tue, 1 Feb 2005 16:35:18 -0800 (PST) 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 j120ZH0E070192; Tue, 1 Feb 2005 16:35:17 -0800 (PST) (envelope-from fenton@cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2005 16:37:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j120Z9RO028160; Tue, 1 Feb 2005 16:35:10 -0800 (PST) Received: from [128.107.163.248] (dhcp-128-107-163-248.cisco.com [128.107.163.248]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j120UrQ1011895; Tue, 1 Feb 2005 16:30:54 -0800 Message-ID: <4200203C.3080407@cisco.com> Date: Tue, 01 Feb 2005 16:35:08 -0800 From: Jim Fenton User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hector Santos CC: IETF MARID WG , ietf-mailsig@imc.org Subject: Re: Using DK/IIM [was: Re: So here it is one year later...] References: <41FE92AD.5090501@cisco.com> <000d01c507dd$0c861d90$6401a8c0@hdev1> <41FFC2EC.7010703@cisco.com> <014601c50893$6331a5e0$6401a8c0@hdev1> In-Reply-To: <014601c50893$6331a5e0$6401a8c0@hdev1> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107304254.233836"; x:"432200"; a:"rsa-sha1"; b:"nofws:2064"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"OtSIayfn3ejlVdDBXkImC+7tWviLoD2wN6HBlyofUHTezXKDxNoznNjNxsHSgCuFyjFcs/jU" "Fp3/n3NhzFdh8mMCvHIprbJnanGtnBOQ5+eT/sbAsT9IYI8mFojeE/uPRZT6QPUIjUlqsjr5fw0" "7xrzdVv3eoWMqn2bdmn49b9A="; c:"Date: Tue, 01 Feb 2005 16:35:08 -0800"; c:"From: Jim Fenton "; c:"Subject: Re: Using DK/IIM [was: Re: So here it is one year later...]" IIM-VERIFY: s:"y"; v:"y"; r:"60"; 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: Content-Transfer-Encoding: 7bit This is almost entirely about message signing, so I'm going to at least copy ietf-mailsig, and we should probably move this thread off ietf-mxcomp. Hector Santos wrote: >Jim, these are legit questions: > >1) Who is the signer? MUA or MSA? > > MUA, MSA, or some other MTA along the way. >2) How should a MDA handle the following: > > What the recipient does with the results of message signing are really up to him/her, but here is what I would probably do: >2a) A domain with DK/IIM published information but a non-DK/IIM payload? > > If by "published information" you mean that the domain has published a policy that it signs all messages, then an unsigned message should at the very least be considered very suspect. I would probably just put it in the "spam folder". >2b) A non-DK/IIM domain? > > Do what you do today. >2c) Broken DK/IIM message? > > Same as an unsigned message. It will be trivial for attackers to create "broken" messages, so a broken signature is really not an indication of anything. >3) What is the role of the intermediatary router MTA? > > If it's just providing a message routing function, it does not need to be signature-aware. If it is manipulating the message, it may need to verify and re-sign the message. >4) What is the relationship of the transport parameters; IP, HELO, MAILFROM >and RCPTO with a DK/IIM ready payload? What upfront logic can be used? > > No relationship. DK/IIM deal only with the payload, and not SMTP itself (unlike the first revision of IIM which used MAILFROM). >5) Since a MDA requires to view the PAYLOAD to validate the DK/IIM, what is >the policy for POST-SMTP failed DK/IIM results? > > The policy I use is to color code the messages in my MUA using a filter that looks at the authentication results header. >6) Finally, how should gateway transformation systems handle DK/IIM payloads >which may get stripped. For example, a console based mail system only needs >two parts: > >The main headers: > > From: > To: > Subject: > Date: > >and the body: > > text body > > It could do any number of things, like modify the subject line (much as I hate this) or put a warning line at the beginning of the body. >6a) How does this change the mail reader, online and offline? For example, >should the presentation software display some "Red Warning Icon" suggesting >"Possible Invalid Message?" > > That would be nice, when we can get it. For now, I'm happy with coloring the summary line in my MUA, but I suspect that MUAs will come along that can do much more. -Jim From owner-ietf-mxcomp@mail.imc.org Tue Feb 1 20:30:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27894 for ; Tue, 1 Feb 2005 20:30:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1214VBK072325; Tue, 1 Feb 2005 17:04:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1214VCi072324; Tue, 1 Feb 2005 17:04:31 -0800 (PST) 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 j1214V8T072313 for ; Tue, 1 Feb 2005 17:04:31 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 7C067414E2; Tue, 1 Feb 2005 17:04:26 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: Hector Santos Cc: ietf-mxcomp@imc.org In-Reply-To: <001501c508a6$f2dc14b0$6401a8c0@hdev1> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> <004c01c50861$365fdff0$6401a8c0@hdev1> <1107290787.6836.171.camel@SJC-Office-DHCP-156.mail-abuse.org> <001501c508a6$f2dc14b0$6401a8c0@hdev1> Content-Type: text/plain Date: Tue, 01 Feb 2005 17:04:12 -0800 Message-Id: <1107306253.6836.286.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 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, 2005-02-01 at 16:42 -0500, Hector Santos wrote: > Is this a CANNED reply message? It sure reads like it. It sure feels like the same issues. > Look, CSV does not pass the test for consideration. That might > explain why no commercial vendor has implemented it. The goal for CSV is to reach consensus on a well considered design, run tests, and then attempt to pass muster with a standards effort before widely promoting it. Considering impacts upon existing infrastructure has been no small part of this process. It would seem proponents of SPF have concluded problems resulting from changes to the rules without record versioning is acceptable. Does it really matter the same view is held by the Sender-ID faction, as well as the SPF-Classic faction? The spf.org site makes it clear Sender-ID causes mail delivery problems. Schlitt's draft also makes it clear forwarded mail may be lost and "Tests against some other identity may also be used to override the test against the "MAIL FROM" identity." What other identity? Being this vague ensures there will never be a "chain of trust". This type of approach makes it impossible to judge, from the perspective of implementation, who is doing what. Forgive those that take a longer view. It seems SPF has already lost control over how these records are used. Breaking mail as a way to inflict change is not justified for a system that makes consumers rather than providers accountable. Lack of authenticating the message source, in the long run, may prove costly as these problem become apparent. > And we were not talking about MASS. We are talking about the fallacy of CSV > being immune to heterogeneous/mix policy topologies and lacks overhead > issues. You are wrong in both cases. You seem to be obsessing on having SPF replace the role of a responsible administrator. Alas, SPF can not be trusted to properly indicate the source of abuse. Please don't say this is not your concern, and that it is the victim's. > I think you are saying MASS solves these problems for CSV. The need to protect the sender's mailbox-domain can be safely provided by MASS. CSV never attempts to fulfill that role. CSV is the first protective phalanx for the network, based upon a name rather than an IP address. This could work in conjunction with a common name based reputation system. MASS will never offer protection for the network, whereas CSV can. SPF, with its high overhead, does not afford network protection advantages. > Well, that's a PAYLOAD solution so it doesn't address the heterogeneous/mix > policies and overhead issues at the SMTP level. So I believe you are > incorrect here as well. A minimal overhead at the SMTP level is definitely an advantage that CSV offers over SPF. The disagreement seems to be whether SPF provides greater benefit by excluding messages that do not comply to an expensive path registration. Forwarding is now defined as "illegitimate" and messages lost as a result of transparent interception at hotels and network kiosks is "acceptable" even though these are effective anti-spam deterrents. Will customers accept such problems and blame under the guise of defeating spam? -Doug From owner-ietf-mxcomp@mail.imc.org Wed Feb 2 08:52:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03835 for ; Wed, 2 Feb 2005 08:52:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12DGEas065532; Wed, 2 Feb 2005 05:16:14 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12DGEUe065531; Wed, 2 Feb 2005 05:16:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12DGCS9065509 for ; Wed, 2 Feb 2005 05:16:13 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1CwKM3-0004xq-09 for ietf-mxcomp@imc.org; Wed, 02 Feb 2005 14:15:35 +0100 Received: from du-001-156.access.de.clara.net ([212.82.227.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Feb 2005 14:15:34 +0100 Received: from nobody by du-001-156.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Feb 2005 14:15:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: So here it is one year later... Date: Wed, 02 Feb 2005 14:07:48 +0100 Organization: Lines: 117 Message-ID: <4200D0A4.7546@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.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: du-001-156.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gim-ietf-mxcomp@m.gmane.org X-MailScanner-To: ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > SPF may say, "Here is a comprehensive address list", when in > reality it can never be comprehensive. Of course it is. There are at most 512 IPs sending mail from whoever@xyzzy to somebody@elsewhere. The other 254*256*256*256 IPs don't do this, unless they are forwarding mail from me, and then it's something arranged by somebody@elsewhere. He's free to do whatever he likes, but of course he shouldn't check one of his relay IPs against "my" 512 IPs. And there at most 512 IPs who could say HELO xyzzy.claranet.de. In reality no MTA should do this, but for this minor detail SPF isn't good enough, maybe CSV could catch the remaining 512 IPs. BTW, can it ? > This is a problem created by the sender "v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all" isn't "a problem created by the sender", it's simply the truth. > SPF does not prevent spoofing of the domain, as many share > common providers If somebody authorized to use one of these 512 IPs spoofs "my" vanity domain, then I'm sure that the abuse desk of my ISP can solve this problem very quickly, otherwise they'd risk to lose a happy customer. And SPF offers solutions for this situation where necessary, e.g. some existing policies use ? instead of + for shared IPs. > there is no consensus which identities are checked against > such records (when these records are even examined) 2821-From and -HELO are checked. Anything else won't work as expected. Of course I can't force you to do "the right thing", you could check something else somewhere else, but why bother with DNS and SPF if you want some random rejects ? Try BLARS, its cheaper than SPF for this purpose. > CSV is intended to protect the network using the same name > basis. So far I haven't seen any spoofed HELO xyzzy.claranet.de in bogus "bounces to" me, so probably CSV would have done nothing at all for my problem. > This domain assertion is not constrained to zone cuts. After > lengthy consideration, it was determined this too would be > inappropriate. Can it identify HELO xyzzy.claranet.de as rubbish ? I've read the discussions about SPF's "zone cut" in CLEAR, and the Jan 4 plus Jan 6 entries in - but that doesn't explain the details. And I haven't found a case where `nslookup -q=ns sub.dom.ain.example` fails to find the "zone cut". > A well understood problem is not FUD Claiming that SPF causes mails to be lost is definitely FUD, Like the collection of monstrous lies in the PDF: BTW, I found that link on the page: > A script based language is inherently complex Yes, the macro language has its drawbacks, and the TINW in "we" had some problems to get it right for some obscure cases like a slash in a FQDN used as HELO. Actually that was in one of two relevant articles in MARID (with thanks to Julia and Margaret) OTOH Wayne now defined exactly 10 macro letters, 8 are used in sender policies, anything else is an error. That's not too complex. Don't try to convince me that the SPF "explanations" are ridiculous, I wouldn't disagree (one of the minor issues I hoped to get rid of in the former MARID WG, but here we are). [overall timeout] >> From the Schlitt's draft: ACK, error on my side, this "implementation detail" is still a part of the draft, and maybe I'll discuss it with Wayne on the SPF list, it's unnecessary. Of course there must be a way to report and log "local error conditions". In the lentczner-drafts the optional overall timeout was a very important part of "processing limits" and indirectly "security considerations", now it's on the same level as say a "sigterm". > The draft requires these 101 to 201 lookup limits depending > upon the mechanisms. If you have some local reasons to ignore a sender policy, then just do it. And if you want a documented reason to state that a sender policy is erroneous follow the spec. The latter is a reason to reject the mail with a PermError, the sender policy has to be fixed. > By checking per HELO, the rate CSV does a lookup is some > multiple less than SPF, and constrained to a single lookup > and not hundreds of lookups. This aspect is critical. For me it's critical that a forged "mail from me" is rejected, and CSV won't do this trick. If you think that the two lookups to check any "mail from me" are too much just don't do it. SPF worked for me as soon as some "important players" (defined from the POV of "my" spammer) implemented it, it's not critical if you don't use it. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Feb 2 10:04:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12423 for ; Wed, 2 Feb 2005 10:04:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12EXLhT072696; Wed, 2 Feb 2005 06:33:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12EXLK9072695; Wed, 2 Feb 2005 06:33:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j12EXKKd072689 for ; Wed, 2 Feb 2005 06:33:20 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Wed, 02 Feb 2005 09:32:13 -0500 Received: from ([65.10.37.252]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3978062281; Wed, 02 Feb 2005 09:32:13 -0500 Message-ID: <002801c50933$a5a84e60$6401a8c0@hdev1> From: "Hector Santos" To: , "Frank Ellermann" References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <4200D0A4.7546@xyzzy.claranet.de> Subject: Re: So here it is one year later... Date: Wed, 2 Feb 2005 09:26:06 -0500 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: Wednesday, February 02, 2005 8:07 AM Subject: Re: So here it is one year later... > > BTW, I found that link on the page: > Ha! How about this new "Think" protocol? When you think connection-oriented transport services, think TCP! When you think legacy protocols, think BOOTP! When bandwidth is cheaper than memory, think MIME! When you think impedence mismatch, think LDAP! Hilarious! Anyway, to the PlayPod radio host. GREAT IDEA!!! How about getting some developer viewpoints in your shows? 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 Feb 2 21:11:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10182 for ; Wed, 2 Feb 2005 21:11:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j131YEQD023377; Wed, 2 Feb 2005 17:34:14 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j131YEKK023376; Wed, 2 Feb 2005 17:34:14 -0800 (PST) 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 j131YEWv023356 for ; Wed, 2 Feb 2005 17:34:14 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 3842D414ED; Wed, 2 Feb 2005 17:34:07 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: Frank Ellermann Cc: ietf-mxcomp@imc.org In-Reply-To: <4200D0A4.7546@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <4200D0A4.7546@xyzzy.claranet.de> Content-Type: text/plain Date: Wed, 02 Feb 2005 17:33:52 -0800 Message-Id: <1107394433.6898.248.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 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, 2005-02-02 at 14:07 +0100, Frank Ellermann wrote: > Douglas Otis wrote: > > > SPF may say, "Here is a comprehensive address list", when in > > reality it can never be comprehensive. > > Of course it is. There are at most 512 IPs sending mail from > whoever@xyzzy to somebody@elsewhere. The other 254*256*256*256 > IPs don't do this, unless they are forwarding mail from me, and > then it's something arranged by somebody@elsewhere. He's free > to do whatever he likes, but of course he shouldn't check one > of his relay IPs against "my" 512 IPs. Today, mail is not checked for a path registration against some mailbox-domain, and forwarding works as expected. Now SPF allows any mailbox-domain to be checked against path registration, according to Schlitt's SPF draft. As a result, there is no assurance that a specific mailbox-domain was checked. Recipients would be guessing which mailbox-domain was used to authorize the message, assuming such authorization was required. The benefits of this process remains highly dubious. On the promise of a benefit, this scheme requires administrators to institute a program of white-listing servers that forward mail on behalf of their customers. Such white-listing practices permit undetected abuse, when these servers are excluded from the SPF rule-set (see draft). This system goes from some mailbox-domain may have been checked, to perhaps none, even when there is an SPF policy in place for the sending mailbox-domains. Of course, there is the vast number that still do not use SPF. Forwarding of mail involves three parties, the sender-domain, the recipient-domain, and the forwarding-domain. A) You want the sender-domain to register all servers used, which is not in keeping with the normal scale for a DNS response. B) The recipient domain then must white-list all forwarding-domains based upon information derived from their users. Once the recipient-domain also employs the SPF rule-set for accepting messages, these forwarded messages may become lost or rejected. Don't forget about the change made with respect to HELO, where now even the bounce may be refused. The needed feedback to know there is a problem may have been lost due to the zone-cut change. Do you still insist you can list all servers? You seem to be admitting that you are leaving some of this listing work to the recipient-domain, in that they must white-list forwarded accounts, some mailing-lists, perhaps some hotel and network kiosks, etc. etc. Why not admit that it is _impossible_ to include the entire list? > And there at most 512 IPs who could say HELO xyzzy.claranet.de. > In reality no MTA should do this, but for this minor detail SPF > isn't good enough, maybe CSV could catch the remaining 512 IPs. > BTW, can it ? CSV does not attempt to include all the IP addresses for an entire mailbox-domain, but instead limits a response to that of a single server. There is no difficulty created when more servers are used for a very large domain, even spanning millions of addresses. Each individual response is limited to that for a specific server. Even the DNS entry does not deal with addresses, as this process is automated within the SRV RR type. As a mail provider, the HELO could reflect which domain is generating the traffic (with the cooperation of the sending domain). If the desire is to isolate accountability, then the HELO technique could satisfy this need, while not breaking mail to the same extent as attempting to constrain mail to some mailbox-domain/IP address binding. Although this is a function provided by the sending domain policy, a bit within the CSV record could indicate the HELO will "always" be within the domain of the MAILFROM. The reason not to make this assertion is the same as why SPF should not make their assertions. It would always be a lie. The difference is that CSV scales and could achieve the same silly goal without abusing DNS. : ) > > This is a problem created by the sender > > "v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all" > isn't "a problem created by the sender", it's simply the truth. I would say it is only half of the truth. The other half is the need for random white-listing to keep from disrupting current widespread and legitimate practices. > > SPF does not prevent spoofing of the domain, as many share > > common providers > > If somebody authorized to use one of these 512 IPs spoofs "my" > vanity domain, then I'm sure that the abuse desk of my ISP can > solve this problem very quickly, otherwise they'd risk to lose > a happy customer. You may have authorized several providers to send mail on behalf of your domain, and discovered a problem by way of a poor reputation assessment or, even worse, your mail being filtered. You will likely find it difficult to learn where the problem originated and receive little cooperation from reputation or filtering services, as they protect sources. The several providers may not care whether you remain a happy customer when you ask them to do additional work. Perhaps they only consider Sender-ID a valid choice and you insist that logs be sorted for SPF specifics. After all, SPF/Sender-ID ensures the problem is yours and not theirs. Very likely, your recourse will be expensive and perhaps futile. > And SPF offers solutions for this situation where necessary, > e.g. some existing policies use ? instead of + for shared IPs. Providing a PTR list of CSV authenticated domains compared against a mailbox-domain would achieve these filtering goals without hundreds of DNS lookups, as potentially required by SPF. There is much less effort maintaining names than huge address lists, and this response would fit within the constraints of DNS. > > there is no consensus which identities are checked against > > such records (when these records are even examined) > > 2821-From and -HELO are checked. Anything else won't work as > expected. Of course I can't force you to do "the right thing", > you could check something else somewhere else, but why bother > with DNS and SPF if you want some random rejects ? Try BLARS, > its cheaper than SPF for this purpose. Schlitt's SPF draft: There are several possible ways that [an] authorization failure can be ameliorated. ... Tests against some other identity may also be used to override the test against the "MAIL FROM" identity. If MAILFROM doesn't work, then try an assortment of mailbox-domains. You can not say with any certainty, even for those following Schlitt's draft, that a specific mailbox-domain was checked. Some chain of trust! > > CSV is intended to protect the network using the same name > > basis. > > So far I haven't seen any spoofed HELO xyzzy.claranet.de in > bogus "bounces to" me, so probably CSV would have done nothing > at all for my problem. With a field not often checked, there is little reason to lie. Checking the HELO is not disruptive, as it does not affect the content of the envelope or the message. Using HELO to establish accountability protects the owners of the mailbox-domains from being falsely accused for having sent unauthenticated messages. Unlike other entities within the message, without a signature, only the HELO can be authenticated. SPF assertions assume a fallacious "chain of trust." Schlitt's draft makes a mockery of that concept. > > This domain assertion is not constrained to zone cuts. After > > lengthy consideration, it was determined this too would be > > inappropriate. > > Can it identify HELO xyzzy.claranet.de as rubbish ? I've read > the discussions about SPF's "zone cut" in CLEAR, and the Jan 4 > plus Jan 6 entries in > - but that doesn't explain the details. And I haven't found a > case where `nslookup -q=ns sub.dom.ain.example` fails to find > the "zone cut". There were several reasons for not using the zone-cut. There is some blood on the floor regarding this topic. Complying with the way domains and zones are used, how software is structured, and what is reasonable to expect of the server in some odd cases, were the major reasons in my view. For the most part, this draft is in its final stages. The design team wishes to present their finished version rather than a series of interim drafts. CSV is very much a team effort. > > A well understood problem is not FUD > > Claiming that SPF causes mails to be lost is definitely FUD, Odd, I would think that the mention of lost mail in Schlitt's SPF draft would have removed the uncertainty and doubt. I still think fear is well advised. : ) > Like the collection of monstrous lies in the PDF: > I would be interested to know what you find in error, besides too many slides. : ) > BTW, I found that link on the page: > Marshall and Andy fail to consider anything other than path registration in this bit of nostalgia. They are consistent. > > A script based language is inherently complex > > Yes, the macro language has its drawbacks, and the TINW in "we" > had some problems to get it right for some obscure cases like a > slash in a FQDN used as HELO. Actually that was in one of two > relevant articles in MARID (with thanks to Julia and Margaret) > > OTOH Wayne now defined exactly 10 macro letters, 8 are used in > sender policies, anything else is an error. That's not too > complex. Don't try to convince me that the SPF "explanations" > are ridiculous, I wouldn't disagree (one of the minor issues I > hoped to get rid of in the former MARID WG, but here we are). > > [overall timeout] > >> From the Schlitt's draft: > > ACK, error on my side, this "implementation detail" is still a > part of the draft, and maybe I'll discuss it with Wayne on the > SPF list, it's unnecessary. Of course there must be a way to > report and log "local error conditions". Let me remind you. A lookup may entail several queries to resolve the resource. The timeout for each query typically involves a timeout of 5 seconds with perhaps 2 or 3 retries which double the timeout after each. Waiting for a timeout to expire is how UDP is prevented from flooding a network during congestion. With the 101 lookup limit (higher for reverse DNS resolution), should an implementation attempt to resolve SPF in parallel, there may be many outstanding DNS queries not completed when everything starts anew for the next message. A slow DNS server could entail an average of 3 queries per lookup which totals 303 queries or about 25 minutes per message, without invoking a single timeout or lookup limit! This time could be more than doubled by using reverse DNS resolution. : ( > In the lentczner-drafts the optional overall timeout was a very > important part of "processing limits" and indirectly "security > considerations", now it's on the same level as say a "sigterm". This view overlooks the need for UDP exponential fallback! Think of the network and not just the program. > > The draft requires these 101 to 201 lookup limits depending > > upon the mechanisms. > > If you have some local reasons to ignore a sender policy, then > just do it. And if you want a documented reason to state that > a sender policy is erroneous follow the spec. The latter is a > reason to reject the mail with a PermError, the sender policy > has to be fixed. Why write a spec and then imply that it should not be followed? Don't you see a problem? > > By checking per HELO, the rate CSV does a lookup is some > > multiple less than SPF, and constrained to a single lookup > > and not hundreds of lookups. This aspect is critical. > > For me it's critical that a forged "mail from me" is rejected, > and CSV won't do this trick. If you think that the two lookups > to check any "mail from me" are too much just don't do it. SPF does NOT prevent mail from being mistaken as being from you. SPF normally checks the MAILFROM. MAILFROM is rarely seen by the user. CSV can authenticate the HELO domain, SPF can only determine that the message has been authorized by a domain. When one considers the need to stop spam, reputation is an important aspect of that effort. No reputation service should hold a domain culpable just because a message had been authorized. With the HELO authenticated, any abuse will be attributed to the correct entity. With SPF, you are using a weapon that does not always shoot straight. Unlike SPF, CSV is as accurate as the underlying infrastructure. > SPF worked for me as soon as some "important players" (defined > from the POV of "my" spammer) implemented it, it's not critical > if you don't use it. Take the longer view and considering what is needed to improve security and to better protect networks. There will be less mess than what may be created by the many potential exploits enabled by SPF. Although SPF may temporarily achieve some reductions in bounce traffic, BATV is a better immediate solution. MASS and CLEAR still represent viable and well considered solutions. SPF still should be discouraged. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Feb 21 08:16:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23455 for ; Mon, 21 Feb 2005 08:16:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LCRUpl094272; Mon, 21 Feb 2005 04:27:30 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LCRU68094271; Mon, 21 Feb 2005 04:27:30 -0800 (PST) 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 j1LCRBAs094073 for ; Mon, 21 Feb 2005 04:27:29 -0800 (PST) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id C64B726C094; Mon, 21 Feb 2005 13:26:51 +0100 (CET) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx2.nic.fr (Postfix) with ESMTP id AB27F26C071; Mon, 21 Feb 2005 13:26:50 +0100 (CET) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id j1LCQj4u1491754; Mon, 21 Feb 2005 13:26:45 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id 4D93416A9E3; Mon, 21 Feb 2005 13:26:45 +0100 (CET) Date: Mon, 21 Feb 2005 13:26:45 +0100 From: Stephane Bortzmeyer To: ietf@ietf.org, ietf-mxcomp@imc.org Subject: MARID back from the grave? Message-ID: <20050221122645.GA2332@nic.fr> References: <200502182020.PAA07999@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502182020.PAA07999@ietf.org> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040907i 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, Feb 18, 2005 at 03:20:40PM -0500, Internet-Drafts@ietf.org wrote a message of 103 lines which said: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. > > Title : Client SMTP Validation (CSV) > Author(s) : D. Crocker, et al. > Filename : draft-ietf-marid-csv-intro-02.txt 1) I thought that the MARID Working Group was disbanded several months ago? 2) What could be the connection with the AAA Working Group whose charter has nothing to do with "Client SMTP Validation"? From owner-ietf-mxcomp@mail.imc.org Mon Feb 21 08:56:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27508 for ; Mon, 21 Feb 2005 08:56:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LDHoJu012356; Mon, 21 Feb 2005 05:17:50 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LDHoIw012355; Mon, 21 Feb 2005 05:17:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LDHnwK012338 for ; Mon, 21 Feb 2005 05:17:50 -0800 (PST) (envelope-from harald@alvestrand.no) Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 50B316225C; Mon, 21 Feb 2005 14:17:48 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19399-01; Mon, 21 Feb 2005 14:17:46 +0100 (CET) Received: from [192.168.1.4] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 915D361BDA; Mon, 21 Feb 2005 14:17:46 +0100 (CET) Date: Mon, 21 Feb 2005 14:17:46 +0100 From: Harald Tveit Alvestrand To: Stephane Bortzmeyer , ietf@ietf.org, ietf-mxcomp@imc.org Subject: Re: MARID back from the grave? Message-ID: <689C221E10828695D7065A99@askvoll.hjemme.alvestrand.no> In-Reply-To: <20050221122645.GA2332@nic.fr> References: <200502182020.PAA07999@ietf.org> <20050221122645.GA2332@nic.fr> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is an error. --On mandag, februar 21, 2005 13:26:45 +0100 Stephane Bortzmeyer wrote: > > On Fri, Feb 18, 2005 at 03:20:40PM -0500, > Internet-Drafts@ietf.org wrote > a message of 103 lines which said: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Authentication, >> Authorization and Accounting Working Group of the IETF. >> >> Title : Client SMTP Validation (CSV) >> Author(s) : D. Crocker, et al. >> Filename : draft-ietf-marid-csv-intro-02.txt > > 1) I thought that the MARID Working Group was disbanded several months > ago? > > 2) What could be the connection with the AAA Working Group whose > charter has nothing to do with "Client SMTP Validation"? > > From owner-ietf-mxcomp@mail.imc.org Mon Feb 21 19:31:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04328 for ; Mon, 21 Feb 2005 19:31:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LNhkRr058762; Mon, 21 Feb 2005 15:43:46 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LNhkS8058761; Mon, 21 Feb 2005 15:43:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LNhJPE058739 for ; Mon, 21 Feb 2005 15:43:23 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbfujip7 (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j1LNgQg2021960; Mon, 21 Feb 2005 15:42:33 -0800 From: Dave Crocker To: Stephane Bortzmeyer , , X-Mailer: PocoMail 3.2 (2004) - Licensed Version X-URL: bbiw.net Reply-To: Dave Crocker Date: Tue, 22 Feb 2005 07:55:07 +0900 Message-ID: <20052227557.906038@bbfujip7> In-Reply-To: <20050221122645.GA2332@nic.fr> Delivery-Date: Tue, 22 Feb 2005 07:55:07 -0000 Subject: Re: MARID back from the grave? 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 Mon, 21 Feb 2005 13:26:45 +0100, Stephane Bortzmeyer wrote: > >  A New Internet-Draft is available from the on-line Internet-Drafts > >  directories. > > > >  This draft is a work item of the Authentication, Authorization and > >  Accounting Working Group of the IETF. > > > >          Title                : Client SMTP Validation (CSV) > >          Author(s)        : D. Crocker, et al. > >          Filename        : draft-ietf-marid-csv-intro-02.txt Frankly, we posted the documents under their existing names, because we missed the earlier deadline for new i-d's. The goal has always been to generate a new working group (CLEAR) but the administrative side of that ran into some problems. Rather than have the documents keep bouncing around the internet drafts namespace, it seemed more reasonable just to issue these as revisions to their existing names. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... WE'VE MOVED to:  www.bbiw.net From owner-ietf-mxcomp@mail.imc.org Tue Feb 22 05:40:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12191 for ; Tue, 22 Feb 2005 05:40:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M9xt0k080497; Tue, 22 Feb 2005 01:59:55 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1M9xtw9080496; Tue, 22 Feb 2005 01:59:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1M9xNQc080115 for ; Tue, 22 Feb 2005 01:59:27 -0800 (PST) (envelope-from dhc2@dcrocker.net) Received: from bbfujip7 (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j1M9wOiO032194; Tue, 22 Feb 2005 01:58:26 -0800 From: Dave Crocker To: Harald Tveit Alvestrand , Stephane Bortzmeyer , , X-Mailer: PocoMail 3.3 (2100) - Licensed Version X-URL: bbiw.net Reply-To: Dave Crocker Date: Tue, 22 Feb 2005 18:58:26 +0900 Message-ID: <2005222185826.456997@bbfujip7> In-Reply-To: <689C221E10828695D7065A99@askvoll.hjemme.alvestrand.no> Subject: Re: MARID back from the grave? 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 Mon, 21 Feb 2005 14:17:46 +0100, Harald Tveit Alvestrand wrote: >  This is an error. Harald, Please explain. I've looked over the documentation for I-D naming and do not see this case covered. What is particularly ironic is that these I-Ds began as individual submissions and we were asked to bring them in, under Marid, just in time for the working group to be disbanded. So it is a bit odd to think that having Marid go away means that we cannot get the documents published with a simple increment to their series number. Of course, we would have been glad to move them to the CLEAR working group, had it been chartered. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... WE'VE MOVED to:  www.bbiw.net From owner-ietf-mxcomp@mail.imc.org Tue Feb 22 05:40:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12209 for ; Tue, 22 Feb 2005 05:40:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1MACi56085047; Tue, 22 Feb 2005 02:12:44 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1MACiRL085046; Tue, 22 Feb 2005 02:12:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1MACh0R085025 for ; Tue, 22 Feb 2005 02:12:44 -0800 (PST) (envelope-from harald@alvestrand.no) Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4320761BE2; Tue, 22 Feb 2005 11:12:40 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19772-04; Tue, 22 Feb 2005 11:12:38 +0100 (CET) Received: from [192.168.1.145] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73BF861AD4; Tue, 22 Feb 2005 11:12:38 +0100 (CET) Date: Tue, 22 Feb 2005 11:12:36 +0100 From: Harald Tveit Alvestrand To: Dave Crocker , Stephane Bortzmeyer , ietf@ietf.org, ietf-mxcomp@imc.org Subject: Re: MARID back from the grave? Message-ID: <65970B2F01E0345DD70C2E8B@gloppen.hjemme.alvestrand.no> In-Reply-To: <2005222185826.456997@bbfujip7> References: <2005222185826.456997@bbfujip7> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1MACi0R085040 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dave, the announcement of this as a WG item for AAA is an error. It should not have been announced that way - it should have been announced as an individual submission. In the past, we have been inconsistent in whether or not we recommended that updates done after the WG's closing should be renamed to individual or not, and I think the secretariat has been consistent in not policing it. I think it is more clear to the audience what's going on if it's published as an individual; after all, there is no WG to give "WG review" for this document any more. But I have not given instructions to the secretariat to block those. Harald --On tirsdag, februar 22, 2005 18:58:26 +0900 Dave Crocker wrote: > On Mon, 21 Feb 2005 14:17:46 +0100, Harald Tveit Alvestrand wrote: >>   This is an error. > > Harald, > > Please explain. > > I've looked over the documentation for I-D naming and do not see this > case covered. > > What is particularly ironic is that these I-Ds began as individual > submissions and we were asked to bring them in, under Marid, just in time > for the working group to be disbanded. > > So it is a bit odd to think that having Marid go away means that we > cannot get the documents published with a simple increment to their > series number. > > Of course, we would have been glad to move them to the CLEAR working > group, had it been chartered. > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > +1.408.246.8253 > dcrocker  a t ... > WE'VE MOVED to:  www.bbiw.net > >