From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 01:22:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16609 for ; Thu, 1 Jul 2004 01:22:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6156Pi9004965; Wed, 30 Jun 2004 22:06:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6156PNj004964; Wed, 30 Jun 2004 22:06:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6156Oss004933 for ; Wed, 30 Jun 2004 22:06:24 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 71BA1132F4D; Thu, 1 Jul 2004 01:06:25 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 0FDAD61A; Thu, 1 Jul 2004 01:06:25 -0400 (EDT) Date: Thu, 1 Jul 2004 01:06:25 -0400 From: Meng Weng Wong To: John Levine Cc: ietf-mxcomp@imc.org Subject: Re: Who are we accrediting? Message-ID: <20040701050624.GY13225@dumbo.pobox.com> References: <20040701015906.14011.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040701015906.14011.qmail@xuxa.iecc.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jul 01, 2004 at 01:59:06AM -0000, John Levine wrote: | | I realize that opinions differ, but I would like to see a scheme like | CSV that uses an IP address to identify an MTA, and handle individual | messages using something like Domain Keys that authenticates the | message itself rather than a probably shared message source. | If Domain Keys signs messages at the MTA, the mix of good and bad mail you mentioned will all acquire a DK signature. Used in such a fashion, DK and SenderID both authenticate the probably shared message source. If we turn to per-user PGP, we end up with the same problem, just shifted one level up: viruses will read secret keys and keysniff passphrases, so PGP signatures emanating from an owned machine are worth nothing also. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 01:51:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17452 for ; Thu, 1 Jul 2004 01:50:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i615dMPZ018351; Wed, 30 Jun 2004 22:39:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i615dMIw018350; Wed, 30 Jun 2004 22:39:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i615dKxk018323 for ; Wed, 30 Jun 2004 22:39:21 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BfuI0-0001Qi-27 for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 00:39:26 -0500 To: "IETF MARID WG" From: wayne Reply-To: "IETF MARID WG" Date: Thu, 01 Jul 2004 00:39:15 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Obstacles between us and the finish line Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Deadlines for this working group are rapidly approaching. According to Andy's recent post, we have about 2 weeks (until 07/18) to finish things up. In my (oh so very humble) opinion, I see the following obstacles in the way: 1) Proposals must have solid I-Ds 2) Proposals must have working code 3) Proposals must have been tested on real world data 4) Proposals must have IP licensing terms that allow for use in both commercial and GPLed MTAs. 5) Proposals must not have gratuitous incompatibilities with an installed base. I have said from very early on that I think we may well need more than one RFC to handle the various identities. To be quite honest, I don't care if we have a dozen overlapping proposals, I think the market can easily decide which are useful. As such, I see the following proposals that may be considered: SPF-classic, CSV, Sender-ID and Unified-SPF. It appears to DMP, FSV, and Caller-ID are no longer being pushed by anyone. I'm going to go over all the proposals in a sec, but I think I should make a few comments on the requirements. 1) solid I-Ds: Proposals must have been gone over with many eyes, especially with developer's eyes when they are trying to implement the proposal. I think it is far too late to do anything with a proposal other than use it to implement code and make adjustments based on that experience. 2) working code, and 3) testing, I think are pretty obvious. 4) IP licensing: I'm not dogmatic about the GPL or commercial licenses, but there are significant MTAs and mail filters that fall under both kinds of licenses, and several others to boot. I think that any proposal that has incompatible IP licensing needs to be dropped. 5) Incompatibilities: Proposals such as SPF have a significant install base and doing things like moving the location of the TXT records, dropping macros, or using a different RR, etc. make no sense to me and will likely run into a buzz saw with SPF adopters. Ok, so how do the current proposals stack up? **** SPF-classic **** 1) solid I-D: Yes It was supposed to have been submitted as an experiemental RFC, but I don't know the status. 2) working code: Yes Lots of working code in fact. New announcements of commercial products using SPF a couple of times a week. 3) Tested: Yes It is being used to check millions of emails per day. 4) IP Licensing: No problems 5) gratuitous incompatibilities: None. I think SPF-classic should certainly be *one* of the proposals put forth by this working group. **** CSV **** 1) solid I-D: pretty good To the best of my knowledge, no one has tried to implement code based on it, but it appears to have been well reviewed by a fair number of people. I think there is time to get implementation experience if the backers hurry. 2) working code: none 3) testing: none 4) IP Licensing: No problems 5) gratuitous incompatibilities: None. I think that CSV could be one of the proposals, if its backers quickly start creating working code and doing testing. **** Sender-ID **** 1) solid I-D: No I have looked again at the draft-ietf-marid-core-01.txt I-D, and frankly, it is not even close to being in a state worth commenting on. It is hugely incomplete and incompatible with SPF, which it tries to be compatbile with. I can't see it becoming solid in the next couple of weeks. Heck, it still has the XML stuff in it and the changes from the -00 version are very minor. It appears that little work is being done on this and it is unlikely to be ready. The SUBMITTER I-D appears to be in better shape, but again, no one has tried using the I-D to implement the spec, so there could be significant errors. 2) working code: none In particular, the PRA and SUBMITTER are both on paper only. 3) testing: none I requested results of the PRA algorithm the first day that the Caller-ID spec was proposed to this working group. I made a point of raising the issue at the interim meeting. In the many months since then, nothing has been forth coming. I am getting seriously worried about this. 4) IP Licensing: problems It appears that the Sender-ID's license is incompatible with the GPL. This could, in theory, be fixed very quickly, but the issues of IP disclosure and licensing problems has been known since before the interim meeting and nothing has been done. 5) gratuitous incompatibilities: None. In theory, the only incompatiblity is that it tries to use existing SPF records for 2822 checks. Since SPF records were published with the idea that they would be used for 2821.FROM and 2821.HELO, there could be problems. In practice, there are many incompatiblities with the current Sender-ID spec and the SPF spec. While Sender-ID appears to be the RFC-apparent for this WG, I have very serious doubts that it will be in any shape to be advanced before the deadlines. I am beginning to think this proposal should be dropped as the backers of key parts appear to be moving way too slowly. **** Unified-SPF **** 1) solid I-D: fuzzy As Dave Crocker pointed out in a message earlier today, there is no Unified-SPF I-D. This needs to be fixed ASAP or this proposal must be dropped. Fortunately, the differences between SPF-classic and Unified-SPF are small enough that I think I-Ds could be written fairly quickly and yet remain pretty solid. 2) working code: none 3) testing: none 4) IP Licensing: No problems 5) gratuitous incompatibilities: None. The Unified-SPF proposal needs to make some changes to the SPF records in order to support the various scopes that it tries to cover. This can be solved several ways. I think that Unified-SPF has a chance to be a solid proposal, but the I-Ds need to be written and the changes to the SPF-classic code needs to be tested. **** DMP **** Ok, I said DMP isn't being pushed by anyone, but I'll list it anyway 1) solid I-D: Yes 2) working code: Yes 3) testing: Yes 4) IP Licensing: No problems 5) gratuitous incompatibilities: None. I think that DMP is in far better shape than most of the other proposals that appear to be much more likely to advanced by this working group. *boggle* Right now, I would say that SPF-classic and DMP are the only proposals that are ready for RFC consideration. For backers of other proposals: you have two weeks to finish. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 02:02:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19646 for ; Thu, 1 Jul 2004 02:02:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i615r8AT025060; Wed, 30 Jun 2004 22:53:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i615r8YZ025059; Wed, 30 Jun 2004 22:53:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i615r7J9025046 for ; Wed, 30 Jun 2004 22:53:07 -0700 (PDT) (envelope-from sb0-0600c6bbe6-johnl@iecc.com) Received: (qmail 6408 invoked by uid 100); 1 Jul 2004 05:53:14 -0000 Date: 1 Jul 2004 05:53:14 -0000 Message-ID: <20040701055314.6407.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: Who are we accrediting? In-Reply-To: <20040701050624.GY13225@dumbo.pobox.com> Organization: I.E.C.C., Trumansburg NY USA Cc: mengwong@dumbo.pobox.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >| I realize that opinions differ, but I would like to see a scheme like >| CSV that uses an IP address to identify an MTA, and handle individual >| messages using something like Domain Keys that authenticates the >| message itself rather than a probably shared message source. > >If Domain Keys signs messages at the MTA, the mix of good >and bad mail you mentioned will all acquire a DK signature. That entirely depends on the MTA's policy. If I set up my MTA to sign messages, I'd only sign the ones that I had some reason to trust, e.g., the sender AUTHed when it injected the message and it's a domain I know. Or, of course, a sufficiently robust sender like an internal mailing list server could sign them itself and my MTA just passes them along. But the point is that senders get to decide what messages they will vouch for, rather than recipients trying to guess from ever more complex SPF-ish descriptions what mail is good and what mail isn't. >If we turn to per-user PGP, we end up with the same problem, If we want PGP, we know where to find it. We all know about its key distribution problems, so unless I'm missing something, nobody's proposing it for MARID or son-of-MARID. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 02:12:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27665 for ; Thu, 1 Jul 2004 02:12:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61639l6030597; Wed, 30 Jun 2004 23:03:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61639Vu030596; Wed, 30 Jun 2004 23:03:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i616386Z030573 for ; Wed, 30 Jun 2004 23:03:08 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Obstacles between us and the finish line MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 1 Jul 2004 01:03:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8F5@srv1.pan-am.ca> Thread-Topic: Obstacles between us and the finish line Thread-Index: AcRfL8Lj0kMnb/jRR6umjQu0zEfNKgAAHVOg From: "Gordon Fecyk" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i616386Z030590 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Ok, I said DMP isn't being pushed by anyone, but I'll list it anyway > > 1) solid I-D: Yes > 2) working code: Yes > 3) testing: Yes > 4) IP Licensing: No problems > 5) gratuitous incompatibilities: None. > > I think that DMP is in far better shape than most of the other > proposals that appear to be much more likely to advanced by this > working group. *boggle* In some anti-spam mailing lists this would warrant a "C&C" warning. :-) But thanks for bringing this up. I was thinking about adding support for marid-submitter and portions of marid-core (notably the RFC2822 Resent-From: header) as I've asked about earlier. The end result will be fewer lookups per message - a minimum of one and maximum of two, compared to a maximum of *four* - thanks to the information provided through the above drafts. How about I throw that on the table and see who pokes at it? -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 02:28:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02451 for ; Thu, 1 Jul 2004 02:28:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i616JVWT036371; Wed, 30 Jun 2004 23:19:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i616JUnV036370; Wed, 30 Jun 2004 23:19:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i616JUZA036350 for ; Wed, 30 Jun 2004 23:19:30 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: by neko-base.nekodojo.org (Postfix, from userid 500) id 4A6151D656; Wed, 30 Jun 2004 23:19:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 497C31D651 for ; Wed, 30 Jun 2004 23:19:28 -0700 (PDT) Date: Wed, 30 Jun 2004 23:19:28 -0700 (PDT) From: Greg Connor To: ietf-mxcomp@imc.org Subject: Re: Comparing apples to multiple, hypothetical oranges In-Reply-To: <170501979.20040701075828@brandenburg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 1 Jul 2004, Dave Crocker wrote: > > By contrast, discussions about "SPF" frequently treat hypothetical > capabilities, deployed capabilities, and multiple specifications of > capabilities as if they were all the same, single, concrete > technology. Perhaps other folks can keep clear what is concrete and > what is vague, but I can't. I heartily agree with Dave, that it's easier to collaborate on documents than ideas. It's great to talk about ideas, but they must become documents at some point before meaningful consensus can be reached. Thus, the idea of "Unified SPF" needs a draft behind it. > It is always easy to appear to win an argument if one is not burdened > with the requirement to be concrete and stable, and abstract > hypotheticals are treated the same as reality. Easy, but not > technically productive. There is a healthy amount of disagreement and argument in our working group. I think this is overall a good thing. But, I'm certainly not out to "win" and I don't think you are either. We all "win" if we can all agree, or at least agree to support the group's output at the end. If SPF is being molded and morphed to take on CSV-like qualities here and there, CSV authors and supporters should consider this a form of flattery. :) > Specifications and undocumented concepts that are outside the working > group ought to remain outside. > > Undocumented concepts are, of course, fine to consider for inclusion > in the working group, but a concept is always vague and its utility is > typically not very high until it achieves relatively stable > documentation. The draft-ietf-marid-submitter specification is a > particularly good example of this process of incorporation. It went > quickly from basic idea to clear, concise, concrete specification. Now > folks can conduct concrete analysis on it. While I agree that "unified SPF" really needs a draft in order to talk details, I don't see anything wrong with talking about it as an "undocumented concept" for a while. Among other things, this is helpful in finding out whether there is enough interest in the idea to write the draft. So I will totally agree that a draft needs to be coughed up, but I wouldn't go so far as to say "Stop talking about concepts for which there is no draft". I don't think you are saying this either, but "restrict working group discussion to working group specifications" comes close. -- Greg Connor gconnor@nekodojo.org Everyone says that having power is a great responsibility. This is a lot of bunk. Responsibility is when someone can blame you if something goes wrong. When you have power you are surrounded by people whose job it is to take the blame for your mistakes. If they're smart, that is. -- Cerebus, "On Governing" From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 02:51:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03330 for ; Thu, 1 Jul 2004 02:51:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i616fmRk044597; Wed, 30 Jun 2004 23:41:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i616fmrn044596; Wed, 30 Jun 2004 23:41:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i616fllc044584 for ; Wed, 30 Jun 2004 23:41:48 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 02:45:37 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2474984860; Thu, 01 Jul 2004 02:45:36 -0400 Message-ID: <008701c45f36$82f762e0$6401a8c0@hdev1> From: "Hector Santos" To: "Andrew Newton" Cc: "IETF-MXCOMP" References: <20040630222643.3308.qmail@xuxa.iecc.com> <002901c45f01$c4d7f5b0$6401a8c0@hdev1> Subject: Re: CSV and STARTTLS Date: Thu, 1 Jul 2004 02:41:55 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Andrew Newton" To: "Hector Santos" Cc: "IETF-MXCOMP" Sent: Wednesday, June 30, 2004 9:56 PM Subject: Re: CSV and STARTTLS > On Jun 30, 2004, at 8:24 PM, Hector Santos wrote: > > The only possible reason I can think of is because it usually means > > exclusive arrangements which is already done with IP Relays tables or > > SMTP AUTH accounts. Any TLS security advantage is not guarantee between > > multi-hop routes. > > Not that I disagree with this observation, but couldn't it also apply > to CSV since it is doing the same thing? > > Or in other words, if it isn't worth it to authenticate via TLS because > SMTP is a hop-by-hop protocol, why is CSV authentication more > compelling? I am undestanding CVS correctly, CVS is based (and only cares for) in the trust and validation of the final MTA/MDA transaction with the presumption that the original submission was authenticated (required for a route(, and the routes themselves are trusted. Its the circle or chain of trust concept. Its a valid theoritical concept until we get into hetergenous mixing of servers which we have already experienced first hand with a real customer issue. Right or wrong, the customer had control in replacing long established legacy SMTP servers but was able to add the new "LMAP-ready" AntiSpam SMTP server as a primary host and smart host for the legacy servers. I don't think CVS will solve this because will assume the legacy server already did validations. In short, as I explained to the customer, installing a new $15K Advanced Home Security System [MARID Servers] with all the latest gadgets doesn't quite make sense when you still have the habit of leaving the front door key [non-MARID servers] under a potted plant on the porch. :-) -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 05:43:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09037 for ; Thu, 1 Jul 2004 05:43:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i619Qswk099406; Thu, 1 Jul 2004 02:26:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i619QsEg099405; Thu, 1 Jul 2004 02:26:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i619QrlS099394 for ; Thu, 1 Jul 2004 02:26:54 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 05:30:44 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2484891297; Thu, 01 Jul 2004 05:30:42 -0400 Message-ID: <00e801c45f4d$94020f60$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , References: <170501979.20040701075828@brandenburg.com> Subject: CVS Questions/Comments [was Re: Comparing apples to multiple, hypothetical oranges] Date: Thu, 1 Jul 2004 05:27:02 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A few rudimentary questions first: 1) Are there any CVS test sites to test/compare results? 2) Are there any DNA sites to test/compare results? 3) Do you have a list of CVS ready domains I can use for testing logic? 4) Is Acceditation required for CVS to be useful? In other words, is it useless without it? Comments on draft-ietf-marid-csv-csa-00 | 4. Mechanism | | The receiving SMTP server's authorization procedure is: | | 1. Obtain a domain name that is associated with the sending SMTP | client. A suggestion: A technical note should be added about possible syntax checking and domain literals and how this an appropiate place for an optimal and quick local domain spoof check. For example, - if the IP is a remote address and the client doman is santronics.com. I don't need to bother with any CVS valdation DNS overhead. Its an obvious spoof. - if the client domain is a bracketed IP liternal, it must match the sender IP. Its an obvious spoof. Both represent atleast 10-12% of my rejection rate. Comments on draft-ietf-marid-csv-intro-00: | 3. Design Goals | | o Identification by persistent domain name rather than transient IP | Address At first glace the term "persistent domain name" when used as analogy to a transient IP address, seem to imply that the client domain never changes from hop to hop as oppose to a IP changing from hop to hop. So if I understand the term "persistent domain name' it implies that a consistent domain name is used for CVS publishing and for SMTP Sender usage in its HELO/EHLO command? I think the term "Consistent" better applies. | Section 4.2 Authentication | | .... | What is missing is a useful means of authenticating MTA-MTA exchanges | over the open Internet. Prior arrangement between such a pair of | MTAs is antithetical to the history and operation of Internet mail. Can you give an example of where this is antithetical provided we are not talking about an open relay? An Internal Domain MTA-MTA implies inherent trust. An External domain MTA-MTA is an open relay. I can only see to be valid if the MTA-MTA are part of a "network" or network relationship. | Spontaneous communications are at the core of Internet design and | operation. So the challenge is to develop an authentication | mechanism that permits the necessary amount of accountability, | without imposing undue overhead or restrictions. Whats the suggestion for improving accountability? I guess what I ask asking or saying is that CVS breaks down if the MTA-MTA is not trusted so it might help to define what this means in terms of "Spontaneous communications." Is CVS authentication an "alternative" to the existing authentication method currently used as requirement for routing? | 9. Working Group Evaluation | | This section contains responses to the issues put forward by the | MARID working group chairs. | | 1. Amount of change in software components | | Client MTA's MUST put their registered domain name in EHLO | announcements. In addition to this, I see: 1) How CVS is implemented to work with STARTTLS and/or AUTH. It may require a delay until AUTH is established or the 2nd EHLO is sent for STARTTLS situations or CVS may change the SMTP extensions response. Your input would be appreciated. 2) SMTP servers need to maintain a list of acceditation services available. More be more available for my cheap sysop customers. 3) How #2 is considered may change or introduce a "Check and Egg" consideration. For example Section 1 says: | 1. Overview | | 3. Query a chosen Accreditation Service for the EHLO domain name | (see Domain Name Accreditation (DNA) [ID-Marid-CSVDNA]) | | 4. Query DNS for a SRV record under the EHLO domain name (see Client | SMTP Authorization (CSA) [ID-Marid-CSVCSA]) | | 5. Check the flags returned and check for a match in the list of | returned IP addresses It might be better to do 4 first before 3 and add SRV information to CSA to supply the preferred DNA site for the domain. The site must still be among the servers list of chosen sites the server will honor. If you don't to this, then the server will probably need to query server list of DNA sites looking for CSA authorization. Thats about it for now! Hope this helps. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 06:20:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11640 for ; Thu, 1 Jul 2004 06:20:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61A7ZIQ014569; Thu, 1 Jul 2004 03:07:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61A7Zlq014568; Thu, 1 Jul 2004 03:07:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i61A7Ypu014558 for ; Thu, 1 Jul 2004 03:07:34 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 06:11:21 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2487329750; Thu, 01 Jul 2004 06:11:21 -0400 Message-ID: <011501c45f53$4187ce40$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , References: <170501979.20040701075828@brandenburg.com> <00e801c45f4d$94020f60$6401a8c0@hdev1> Subject: Re: CVS Questions/Comments [was Re: Comparing apples to multiple, hypothetical oranges] Date: Thu, 1 Jul 2004 06:07:37 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Follow up with my review of the DNA specs: ----- Original Message ----- From: "Hector Santos" To: "Dave Crocker" ; Sent: Thursday, July 01, 2004 5:27 AM Subject: CVS Questions/Comments [was Re: Comparing apples to multiple, hypothetical oranges] > | 9. Working Group Evaluation > | > | This section contains responses to the issues put forward by the > | MARID working group chairs. > | > | 1. Amount of change in software components > | > | Client MTA's MUST put their registered domain name in EHLO > | announcements. > > In addition to this, I see: > > 2) SMTP servers need to maintain a list of acceditation services available. > Must be more available for my cheap sysop customers. Is this addressed in draft-ietf-marid-csv-dna-00 section "4. Listing Pointer Service Record Template" ?? Based on what I reading in: | 5. Accreditation Procedure | A receiving SMTP server validates a sending SMTP client by: | | 1. Obtaining the domain name of the client. | | 2. Determining that the name is being used by an authorized party. | | 3. Creating a list of accreditation services to query, both those | the client has registered and those obtained by the server | through other means -- such as those that perform block-listing | -- to query. | | 4. Querying those services for assessments of the host associated I would think that the CSA process is the best place for the domain to define who he is "Paying Big Bucks" to in order to authorized what I essentially call the domain "permit". The server is going to have to run a CSA process anyway so why have it go to DNA first? I'm thinking on how to "zoom" in as fast as possible with the less number of lookups. Mind you, I trying to get this all straight to see how to code it. Also, to reiterate, I don't care if the domain says "MAPS" or "ItsAllGood.Com" is its acceditation/DNA site. If I don't trust them or honor them, why should accept what the DNA site reports? Maybe the DNA site like MAPS who is profit oriented needs to have a profit-sharing strategy like maybe 1% to honor its member mail? I only raise this as one of the potential "troubling aspect" of the coupling of a acceditation CSA authorization agent. I agree something is required, but...... Another point. RBL works and is well established. It is going to be very hard to replace this with CVS. How can an RBL site work in conjunction with CVS/DNA/CSA? What if I run both and apply RBL, CVS/DNA/CSA passes the domain with flying colors but RBL is rejecting the IP? Dave et al, these are valid questions for implementators. I don't think it can ignored. Your advice is appreciated. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 07:49:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17227 for ; Thu, 1 Jul 2004 07:49:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61BWs6m029110; Thu, 1 Jul 2004 04:32:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61BWsDt029109; Thu, 1 Jul 2004 04:32:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61BWrCo029100 for ; Thu, 1 Jul 2004 04:32:53 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BfzoB-0002dg-Pe for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 12:32:51 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BfzoB-0001cl-HB for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 12:32:51 +0100 Date: Thu, 1 Jul 2004 12:32:51 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: MARID WG Subject: Re: CSV and STARTTLS In-Reply-To: <1088632784.4998.1710.camel@ddev.mail-abuse.org> Message-ID: References: <1088632784.4998.1710.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 30 Jun 2004, Douglas Otis wrote: > > I do not speak for the other authors, but there was a discussion > involving this issue that Dave Crocker had been addressing. It is my > understanding this needs to change to reflect StartTLS is stronger but > defines a different namespace which is why Dave indicates it does not > authenticate the HELO domain. He was working on the wording for this. Is this related to the distinction between service names and host names? For example, our MX records refer to mx.cam.ac.uk which is a service name which in turn refers to a number of hosts whose canonical host names (and EHLO greetings) are of the form XXXX.csi.cam.ac.uk. If we were to turn on opportunistic encryption for general SMTP with full certificate verification, we would have to obtain a server certificate for mx.cam.ac.uk for incoming email, and client certifcates for each of the XXXX names for outgoing email. I'm not sure if the behaviour of MTAs is sensible if they try to negotiate TLS but fail at the certificate verification stage. I'm not sure I know what sensible behaviour would be! Tony. -- f.a.n.finch http://dotat.at/ SELSEY BILL TO LYME REGIS: WEST 5 BACKING SOUTHWEST, PERHAPS INCREASING LOCALLY 6, LATER VEERING WEST 5 LOCALLY 6. SCATTERED SHOWERS WITH RAIN FOR A TIME. GOOD DECREASING OCCASIONALLY MODERATE OR POOR IN RAIN. MODERATE BUILDING ROUGH. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 08:13:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18711 for ; Thu, 1 Jul 2004 08:13:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61BxTgc032743; Thu, 1 Jul 2004 04:59:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61BxTsT032742; Thu, 1 Jul 2004 04:59:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61BxTuC032732 for ; Thu, 1 Jul 2004 04:59:29 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Bg0Dq-0005n3-KE for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 12:59:22 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Bg0Dq-0004CW-FG for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 12:59:22 +0100 Date: Thu, 1 Jul 2004 12:59:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: IETF MARID WG Subject: Re: Obstacles between us and the finish line In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 1 Jul 2004, wayne wrote: > > Ok, so how do the current proposals stack up? > > **** SPF-classic **** > 5) gratuitous incompatibilities: None. Incorrect. It breaks alias-forwarding. > **** CSV **** > 5) gratuitous incompatibilities: None. Correct. > **** Sender-ID **** > 5) gratuitous incompatibilities: None. Incorrect. See http://www.imc.org/ietf-mxcomp/mail-archive/msg02419.html > **** Unified-SPF **** > 5) gratuitous incompatibilities: None. Incorrect for the reasons stated for SPF-classic and Sender-ID above. > **** DMP **** > 1) solid I-D: Yes There appears to be a security problem caused by the way a failed MAIL FROM check may fall back to an EHLO check, allowing unintended forgery. Alternatively this is a source of troublesome interoperability problems if some servers fall back to EHLO and some don't. > 5) gratuitous incompatibilities: None. Wildcard MX records. Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE: WESTERLY 4 OR 5 BECOMING VARIABLE 3. OCCASIONAL RAIN. MODERATE WITH FOG PATCHES. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 08:59:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21472 for ; Thu, 1 Jul 2004 08:59:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61ChEqJ038929; Thu, 1 Jul 2004 05:43:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61ChEaI038928; Thu, 1 Jul 2004 05:43:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61ChDeD038922 for ; Thu, 1 Jul 2004 05:43:13 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Bg0uG-0001lx-4M for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 13:43:12 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Bg0uF-0008EA-GN; Thu, 01 Jul 2004 13:43:11 +0100 Date: Thu, 1 Jul 2004 13:43:11 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Hector Santos cc: ietf-mxcomp@imc.org Subject: Re: CVS Questions/Comments [was Re: Comparing apples to multiple, hypothetical oranges] In-Reply-To: <00e801c45f4d$94020f60$6401a8c0@hdev1> Message-ID: References: <170501979.20040701075828@brandenburg.com> <00e801c45f4d$94020f60$6401a8c0@hdev1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 1 Jul 2004, Hector Santos wrote: > > 4) Is Acceditation required for CVS to be useful? In other words, is it > useless without it? No more so than any of the other schemes we are discussing. They all assume that pervasive domain authentication will lead to accreditation and reputation services based on domains (RHSBLs), in addition to or as a replacement for the current IP address DNSBL schemes. > At first glace the term "persistent domain name" when used as analogy to a > transient IP address, seem to imply that the client domain never changes > from hop to hop as oppose to a IP changing from hop to hop. > > So if I understand the term "persistent domain name' it implies that a > consistent domain name is used for CVS publishing and for SMTP Sender usage > in its HELO/EHLO command? > > I think the term "Consistent" better applies. It's to do with persistence over time. An organization is likely to keep its domain name longer than its IP addresses, especially if it is small. This is made clear by the preceding paragraph: Increased topological, transfer and access complexities on the Internet are making IP Addresses increasingly problematic for use as identifiers. Instead they are viewed as appropriate only for the most transient task of delivering individual packets. > | What is missing is a useful means of authenticating MTA-MTA exchanges > | over the open Internet. Prior arrangement between such a pair of > | MTAs is antithetical to the history and operation of Internet mail. > > Can you give an example of where this is antithetical Receiving email from someone who you have never corresponded with before. > The server is going to have to run a CSA process anyway so why have it > go to DNA first? The checks can be done in either order or in parallel. If one of them fails the other is moot. > RBL works and is well established. It is going to be very hard to > replace this with CVS. How can an RBL site work in conjunction with > CVS/DNA/CSA? What if I run both and apply RBL, CVS/DNA/CSA passes the > domain with flying colors but RBL is rejecting the IP? I think this depends on the DNSBL in question. For example, if it's the SBL (list of addresses allocated to known spammers) or the CBL (list of known compromised machines) then CSV is moot. If it's a dynamic IP list (dial-ups and DSL lines) then a CSV pass would beat the blacklisting. The sysadmin will have to apply some intelligence to the configuration. Tony. -- f.a.n.finch http://dotat.at/ FORTH TYNE: SOUTHWEST BACKING SOUTH 3 OR 4 OCCASIONALLY 5. SHOWERS. GOOD. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 09:15:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22420 for ; Thu, 1 Jul 2004 09:15:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D27ku041887; Thu, 1 Jul 2004 06:02:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61D27KY041886; Thu, 1 Jul 2004 06:02:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D26BA041880 for ; Thu, 1 Jul 2004 06:02:06 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from pool-524.denpasar.indo.net.id (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i61D21l30684; Thu, 1 Jul 2004 06:02:02 -0700 Date: Thu, 1 Jul 2004 21:01:55 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <185759269.20040701210155@brandenburg.com> To: Matthew Elvey CC: MARID Subject: Re: Unified SPF overlaps with CSV In-Reply-To: <40E1F6AB.9050109@elvey.com> References: <1088527917.4998.117.camel@ddev.mail-abuse.org> <11967678.1088509187@Ryoga.corp.sgi.com> <1088544618.4998.249.camel@ddev.mail-abuse.org> <40E1F6AB.9050109@elvey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Matthew, ME> I struggled to understand Doug's post for a few minute, and then ME> considering the RHS of Doug's email address ("mail-abuse.org") made it ME> all clear. Unless the rules of the IETF have changed, postings are supposed to be evaluated on their content, not the historical context of the author. That latter approach is called ad hominem. It is particularly dangerous when used as the basis for argumentation. In any event, you fail to take not that Doug has a couple of other co-authors, each with very, very different backgrounds from Doug. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 09:15:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22439 for ; Thu, 1 Jul 2004 09:15:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D4a03042162; Thu, 1 Jul 2004 06:04:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61D4arD042161; Thu, 1 Jul 2004 06:04:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D4VDb042143 for ; Thu, 1 Jul 2004 06:04:36 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 28972170CD for ; Thu, 1 Jul 2004 09:11:21 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Comparing apples to multiple, hypothetical oranges In-Reply-To: Your message of "Thu, 01 Jul 2004 07:58:28 +0800." <170501979.20040701075828@brandenburg.com> Date: Thu, 01 Jul 2004 09:11:21 -0400 Message-Id: <20040701131121.28972170CD@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > The current effort to compare CSV "versus" SPF, prompts me to notice > that there is no working group effort on a specification called "SPF", > nevermind "Unified SPF", Sender ID, or whatever other variant names > and versions might be used. There are a couple of IETF working group > documents that derive from those outside efforts, but folks do not > seem to be referring to working group documents. If the SPF + CallerId can't submit a document by the IETF meeting cutoff (July 19, I think), then the chairs should declare all SPF-related discussions to be out of scope for MARID. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 09:22:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23077 for ; Thu, 1 Jul 2004 09:22:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D94GP042368; Thu, 1 Jul 2004 06:09:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61D94O4042367; Thu, 1 Jul 2004 06:09:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D946J042361 for ; Thu, 1 Jul 2004 06:09:04 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from pool-524.denpasar.indo.net.id (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i61D90l31209; Thu, 1 Jul 2004 06:09:01 -0700 Date: Thu, 1 Jul 2004 21:08:53 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1786510180.20040701210853@brandenburg.com> To: Andrew Newton CC: MARID WG Subject: Re: Differences between CSV and Sender-ID In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew, N> Is it clear to you that CSV has definite security advantages over AN> SPF/Sender-ID? 1. Which specification are you referring to, for the latter? The current candidates for names that folks from the SPF camp have been using are SPF, Unified SPF, SPF Classic and Sender ID. I might have missed one. In any event, none of those names appear as any working group document and no one from the SPF camp has yet made a definitive declaration of what specific document is being used for comparison with CSV. When this is remedied, it will be possible to answer substantive questions such as the one you asked here. 2. You do not ask about any operations (adoption, deployment, administration) differences, nor about performance (efficiency, scaling, etc.) differences. Nor do you ask about differences in impact on the email infrastructure. I hope these, too, are considered relevant. AN> I'm only asking these questions so that we can hopefully refine the AN> conversation on this topic. At the moment, stability of reference would be even better than refinement. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 09:34:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24494 for ; Thu, 1 Jul 2004 09:34:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61DIDhg043232; Thu, 1 Jul 2004 06:18:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61DIDKi043231; Thu, 1 Jul 2004 06:18:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61DIDWh043225 for ; Thu, 1 Jul 2004 06:18:13 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from pool-524.denpasar.indo.net.id (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i61DIBl31888; Thu, 1 Jul 2004 06:18:12 -0700 Date: Thu, 1 Jul 2004 21:17:47 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <703750666.20040701211747@brandenburg.com> To: Andrew Newton CC: MARID WG Subject: Re: CSV and STARTTLS In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew, AN> Does this imply that the strong authentication provided by certificate AN> validation of TLS is to be subjugated by CSV, which is most likely to AN> be weaker authentication? Your question is so confusing to me that I don't care whether of the other responses guess your meaning correctly. Since I believe that there is nothing in the CSV text that affects the nature of TLS, nevermind "subjugating" it, I would appreciate your clarifying your question thoroughly. Honest, I cannot comprehend how you arrived at such a question or what, exactly, it really means. AN> Also, I think many security-minded folks may disagree with the AN> characterization in the first paragraph. Opportunistic encryption with encryption is not the same as authentication, and server authentication is not the same as client authentication. does our spec need to include a short tutorial on the difference? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 09:34:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24526 for ; Thu, 1 Jul 2004 09:34:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61DMYqT043973; Thu, 1 Jul 2004 06:22:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61DMYXm043972; Thu, 1 Jul 2004 06:22:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61DMXJ6043966 for ; Thu, 1 Jul 2004 06:22:33 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from pool-524.denpasar.indo.net.id (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i61DMSl32153; Thu, 1 Jul 2004 06:22:28 -0700 Date: Thu, 1 Jul 2004 21:22:21 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1516519406.20040701212221@brandenburg.com> To: Douglas Otis CC: Andrew Newton , MARID WG Subject: CSV and alternative authentication techniques In-Reply-To: <1088632784.4998.1710.camel@ddev.mail-abuse.org> References: <1088632784.4998.1710.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas, DO> I do not speak for the other authors, but there was a discussion DO> involving this issue that Dave Crocker had been addressing. It is my DO> understanding this needs to change to reflect StartTLS is stronger but DO> defines a different namespace which is why Dave indicates it does not DO> authenticate the HELO domain. So far, I do not see how that issue relates to Andrew's question. I can imagine all sorts of possibilities, but would rather not guess. Since Doug raised the issue, but separate from Andrew's question (and, hence, the different subject line), the discussion of multiple host authentication techniques produced a basic hole, with the possibility that the authenticated identity could be different from the one asserted in HELO. This is a dangerous hole, indeed. The resolution is to use whatever domain is associated with the authentication, rather than the one in the HELO. And, yes, I do owe my co-authors some text. I'll take a break from the beach, tomorrow, and see about writing it. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 09:52:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26899 for ; Thu, 1 Jul 2004 09:52:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Det92045483; Thu, 1 Jul 2004 06:40:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61DetJH045482; Thu, 1 Jul 2004 06:40:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61DetiS045475 for ; Thu, 1 Jul 2004 06:40:55 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 01 Jul 2004 09:40:55 -0400 id 00058053.40E41467.000050F9 In-Reply-To: <703750666.20040701211747@brandenburg.com> References: <703750666.20040701211747@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <456546A6-CB64-11D8-9B31-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: MARID WG From: Andrew Newton Subject: Re: CSV and STARTTLS Date: Thu, 1 Jul 2004 09:40:52 -0400 To: Dave Crocker X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 1, 2004, at 9:17 AM, Dave Crocker wrote: > Since I believe that there is nothing in the CSV text that affects the > nature of TLS, nevermind "subjugating" it, I would appreciate your > clarifying your question thoroughly. Honest, I cannot comprehend how > you arrived at such a question or what, exactly, it really means. > From your draft: > When this is allowed, StartTLS loses any ability > to authenticate the relationship of the client to its claimed domain > name. -andy From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 10:05:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29276 for ; Thu, 1 Jul 2004 10:05:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61DsYs8046845; Thu, 1 Jul 2004 06:54:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61DsY2G046844; Thu, 1 Jul 2004 06:54:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from svrmail.roving.com (SVRMAIL.roving.com [208.198.98.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61DsXmr046830 for ; Thu, 1 Jul 2004 06:54:34 -0700 (PDT) (envelope-from molson@constantcontact.com) Received: from [192.168.254.208] ([192.168.254.208]) by svrmail.roving.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Jul 2004 09:54:30 -0400 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 01 Jul 2004 09:54:29 -0400 Subject: Re: Differences between CSV and Sender-ID From: "Olson, Margaret" To: Dave Crocker , Andrew Newton CC: MARID WG Message-ID: In-Reply-To: <1786510180.20040701210853@brandenburg.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jul 2004 13:54:30.0457 (UTC) FILETIME=[EE71EA90:01C45F72] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > From: Dave Crocker > > 1. Which specification are you referring to, for the latter? The > current candidates for names that folks from the SPF camp have been > using are SPF, Unified SPF, SPF Classic and Sender ID. I might have > missed one. In any event, none of those names appear as any working > group document and no one from the SPF camp has yet made a definitive > declaration of what specific document is being used for comparison > with CSV. When this is remedied, it will be possible to answer > substantive questions such as the one you asked here. I want to echo and reinforce this observation - I also no longer know what "SPF" means. I understand SenderID as the combination of the marid-core and marid-submitter proposals. I think I know what SPF classic is, but I am no longer sure since it appears that there are proposals to interpret spf v1 records in a variety of ways beyond the current definitions. This has caused me to ponder the wisdom of publishing SPF records. Margaret. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 10:19:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02392 for ; Thu, 1 Jul 2004 10:19:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61EBKZL048034; Thu, 1 Jul 2004 07:11:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61EBKYl048033; Thu, 1 Jul 2004 07:11:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rose.csi.cam.ac.uk (rose.csi.cam.ac.uk [131.111.8.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61EBJf0048027 for ; Thu, 1 Jul 2004 07:11:20 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Bg2Gu-00061v-GA for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 15:10:40 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Bg2Gt-0007u8-RE; Thu, 01 Jul 2004 15:10:39 +0100 Date: Thu, 1 Jul 2004 15:10:39 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Crocker cc: Douglas Otis , Andrew Newton , MARID WG Subject: Re: CSV and alternative authentication techniques In-Reply-To: <1516519406.20040701212221@brandenburg.com> Message-ID: References: <1088632784.4998.1710.camel@ddev.mail-abuse.org> <1516519406.20040701212221@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 1 Jul 2004, Dave Crocker wrote: > > Since Doug raised the issue, but separate from Andrew's question (and, > hence, the different subject line), the discussion of multiple host > authentication techniques produced a basic hole, with the possibility > that the authenticated identity could be different from the one > asserted in HELO. This is a dangerous hole, indeed. > > The resolution is to use whatever domain is associated with the > authentication, rather than the one in the HELO. I think I've already noted that SASL is usually used to authenticate a user name not a host name, so the potential for confusion and inadvertent spelunking is high. This is aside from the problems that it doesn't fulfill the requirement for avoiding prior arrangement stated in section 2.2 of the CSV doc, and that its organizational complexity is the square of the number of MTAs. The cost of TLS with trusted third parties is linear in both dollars and complexity. DNS-based authentication is free and scales linearly, and is extremely efficient in conjunction with CSA. (The above reasoning is why I think the CSV spec should not be over- complicated with consideration of multiple authentication methods because the alternatives are all substantially worse than using the DNS.) When the client states its identity multiple times should all of the statements agree? Should the server reject the client if they do not? These questions almost go away if TLS and SASL authentication are no longer considered relevant to CSV. However there should probably be some comment in the CSA specification about what the server does when the client says EHLO more than once. Tony. -- f.a.n.finch http://dotat.at/ ST DAVIDS HEAD TO COLWYN BAY, INCLUDING ST GEORGES CHANNEL: WEST 4 OR 5 BACKING SOUTHWEST AND INCREASING 5 OR 6. SCATTERED SHOWERS BECOMING MORE FREQUENT LATER. GOOD DECREASING MODERATE AT TIMES IN SHOWERS. MODERATE BUILDING LOCALLY ROUGH. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 11:06:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08081 for ; Thu, 1 Jul 2004 11:06:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61EsfUL051613; Thu, 1 Jul 2004 07:54:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61EsfJN051612; Thu, 1 Jul 2004 07:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61EseUc051606 for ; Thu, 1 Jul 2004 07:54:40 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1Bg2xO-0006KW-TL for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 09:54:42 -0500 To: "IETF MARID WG" References: <1786510180.20040701210853@brandenburg.com> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 01 Jul 2004 09:54:34 -0500 In-Reply-To: <1786510180.20040701210853@brandenburg.com> (Dave Crocker's message of "Thu, 1 Jul 2004 21:08:53 +0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: SPF, New-SPF, SPF-Classic, SPF-ID, Sender-ID, Marid-core, etc. Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <1786510180.20040701210853@brandenburg.com> Dave Crocker writes: > 1. Which specification are you referring to, for the latter? The > current candidates for names that folks from the SPF camp have been > using are SPF, Unified SPF, SPF Classic and Sender ID. I might have > missed one. In any event, none of those names appear as any working > group document The SPF proposal was submitted quite a while ago, I have no idea where it went to. The Sender-ID proposal is the same as the "marid-core" proposal. I can understand the confuse here. Most of the problem is due to the idea merging of SPF and Caller-ID before a name for the merged spec was thought up. Anyway, here is the run down: SPF/SPF-classic This is the original SPF spec and has been around for quite a while. The spec was supposed to have been submitted (along with DMP, FSV, LMAP and RMX(?)) and wase once found on the MARID charter webpage as input documents. It can be found at http://www.ietf.org/internet-drafts/draft-mengwong-spf-01.txt The "SPF-classic" is a play on the "New Coke"/"Coke Classic" thing, since the merged SPF/C-ID proposal was first tagged with the "New SPF" name. merged SPF and Caller-ID/New-SPF/SPF-ID/Sender-ID/MARID-core This was the spec announced at the interim meeting. See: http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-01.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-rationale-00.txt Unified-SPF This doesn't have an I-D yet and is a fairly new proposal. The idea is outlined/discussed at http://spf.pobox.com/slides/unified%20spf/ Basically, it acknowledges that SPF-classic checks the 2821.FROM and optionally the 2821.HELO and Sender-ID checks the 2822.From:/Sender:/etc. Since proposals based on the SPF syntax and semantics have already been used to cover most of the identities, it is thought that will a few tweaks, the same system can cover basically all the identities so far discussed. Actually, the idea of using SPF records to cover many identities has long been a goal by many of the SPF crowd and gets raised by various people who don't realize that it has been suggested before. The Unified-SPF proposal is really just the natural evolution of SPF. **** Score card of terms for this mailing list **** When reading this mailing list, it appears to be very uniform that references to "SPF-classic" mean the original SPF proposal, as outlined in the I-D mentioned above. Almost all of the references to "SPF" appear to be references to the same thing. References to the term Sender-ID appear to uniformly mean the marid-core/submitter proposal. References to the term Unified-SPF appear to uniformly mean the Unified-SPF proposal. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 11:20:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09278 for ; Thu, 1 Jul 2004 11:20:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61F87e1052884; Thu, 1 Jul 2004 08:08:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61F87Hl052883; Thu, 1 Jul 2004 08:08:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61F86jX052875 for ; Thu, 1 Jul 2004 08:08:07 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Obstacles between us and the finish line MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 1 Jul 2004 10:08:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8F6@srv1.pan-am.ca> Thread-Topic: Obstacles between us and the finish line Thread-Index: AcRfZSD5n0S2ZE5aRKiGtAnJGYmoWAAFrxxg From: "Gordon Fecyk" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i61F87jX052877 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > **** DMP **** > > 1) solid I-D: Yes > > There appears to be a security problem caused by the way a failed MAIL > FROM check may fall back to an EHLO check, allowing > unintended forgery. > Alternatively this is a source of troublesome > interoperability problems > if some servers fall back to EHLO and some don't. Would be eliminated if the EHLO fallback were replaced with checking Resent-From / SUBMITTER. A domain that wants to forward mail should start using these, which is the case with marid-core anyway. That alone wouldn't fix null reverse paths unless EHLO were used exclusively for those, or the extra information in Resent-From / SUBMITTER were provided. > > 5) gratuitous incompatibilities: None. > > Wildcard MX records. Use an identical wildcard DMP record alongside it, such as: $ORIGIN example.com. @ IN MX mailhost1 * IN MX mailhost1 * IN TXT "dmp=" That would at least prevent forgeries of undefined subdomains until you had an actual host you wanted to send mail as (like user@dummy.example.com), at which point you'd create records for it or have the sending server provide records via dynamic DNS update[1]. Doesn't everything tabled so far break when faced with a wildcard MX record anyway? [1] Someone told me providing records dynamically was a problem but never provided an explanation. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 11:39:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11739 for ; Thu, 1 Jul 2004 11:39:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61FK38L053998; Thu, 1 Jul 2004 08:20:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61FK35Z053997; Thu, 1 Jul 2004 08:20:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61FK2au053991 for ; Thu, 1 Jul 2004 08:20:02 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Bg3Lw-0002s7-Qw for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 16:19:56 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Bg3Lu-00068H-1K; Thu, 01 Jul 2004 16:19:54 +0100 Date: Thu, 1 Jul 2004 16:19:54 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Gordon Fecyk cc: IETF MARID WG Subject: DMP, was RE: Obstacles between us and the finish line In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA8F6@srv1.pan-am.ca> Message-ID: References: <700EEF5641B7E247AC1C9B82C05D125DA8F6@srv1.pan-am.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 1 Jul 2004, Gordon Fecyk wrote: > > [problems] Would be eliminated if the EHLO fallback were replaced with > checking Resent-From / SUBMITTER. This is broken for other reasons which I have explained already. > Doesn't everything tabled so far break when faced with a wildcard MX record > anyway? SPF-classic and CSV do not. Tony. -- f.a.n.finch http://dotat.at/ ST DAVIDS HEAD TO COLWYN BAY, INCLUDING ST GEORGES CHANNEL: WEST 4 OR 5 BACKING SOUTHWEST AND INCREASING 5 OR 6. SCATTERED SHOWERS BECOMING MORE FREQUENT LATER. GOOD DECREASING MODERATE AT TIMES IN SHOWERS. MODERATE BUILDING LOCALLY ROUGH. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 12:51:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16712 for ; Thu, 1 Jul 2004 12:51:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Gaq3X058491; Thu, 1 Jul 2004 09:36:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61Gaqt1058490; Thu, 1 Jul 2004 09:36:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61GapSo058483 for ; Thu, 1 Jul 2004 09:36:51 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i61GOfZ5009559; Thu, 1 Jul 2004 09:24:42 -0700 (PDT) In-Reply-To: <20040701131121.28972170CD@mail.nitros9.org> References: <20040701131121.28972170CD@mail.nitros9.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <276631EE-CB7B-11D8-811E-000A95CA7FAE@dbc.mtview.ca.us> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: Marshall Rose Subject: Re: Comparing apples to multiple, hypothetical oranges Date: Thu, 1 Jul 2004 09:24:40 -0700 To: "Alan DeKok" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 01, 2004, at 06:11, Alan DeKok wrote: > If the SPF + CallerId can't submit a document by the IETF meeting > cutoff (July 19, I think), then the chairs should declare all > SPF-related discussions to be out of scope for MARID. here's what i think: 1. the working group should try to focus. 2. the working group doesn't need to tell the co-chairs how to do their jobs. /mtr From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 13:50:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20977 for ; Thu, 1 Jul 2004 13:50:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61HdnB8063619; Thu, 1 Jul 2004 10:39:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61HdnQE063618; Thu, 1 Jul 2004 10:39:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61HdeQR063598 for ; Thu, 1 Jul 2004 10:39:40 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id E5DB016DD6 for ; Thu, 1 Jul 2004 13:46:40 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Comparing apples to multiple, hypothetical oranges In-Reply-To: Your message of "Thu, 01 Jul 2004 09:24:40 PDT." <276631EE-CB7B-11D8-811E-000A95CA7FAE@dbc.mtview.ca.us> Date: Thu, 01 Jul 2004 13:46:40 -0400 Message-Id: <20040701174640.E5DB016DD6@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Marshall Rose wrote: > here's what i think: > > 1. the working group should try to focus. I'm finding it difficult to follow the WG, because half of the discussion involves a proposal which isn't well documented. > 2. the working group doesn't need to tell the co-chairs how to do their > jobs. The co-chairs need to read my comments as having a less hostile intent. My comments weren't orders or demands; they were statements as to my opinion of how the work should proceed. Many working groups have the participants offer suggestions to the chairs as to how the working group should progress, so comments were *not* innapropriate, as your response would seem to suggest. In this case, I agree with Dave. I don't know what people mean by the latest SPF variant, and if there's no documented proposal, I don't see why we're discussing it here. It will take time and effort away from proposals which follow the IETF process. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 15:39:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28448 for ; Thu, 1 Jul 2004 15:39:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61JPhFa076041; Thu, 1 Jul 2004 12:25:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61JPhF3076039; Thu, 1 Jul 2004 12:25:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61JPfgN076030 for ; Thu, 1 Jul 2004 12:25:42 -0700 (PDT) (envelope-from roy+dated+1091301944.31d09b@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i61JPhnd062050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Jul 2004 19:25:44 GMT (envelope-from roy+dated+1091301944.31d09b@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i61JPiAB047142 for ; Thu, 1 Jul 2004 20:25:44 +0100 (BST) (envelope-from roy+dated+1091301944.31d09b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i61JPi1W047141 for ietf-mxcomp@imc.org; Thu, 1 Jul 2004 20:25:44 +0100 (BST) (envelope-from roy+dated+1091301944.31d09b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 01 Jul 2004 20:25:42 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16612.25910.347629.316864@giles.gnomon.org.uk> Date: Thu, 1 Jul 2004 20:25:42 +0100 To: "Hector Santos" Cc: "Dave Crocker" , Subject: CVS Questions/Comments [was Re: Comparing apples to multiple, hypothetical oranges] In-Reply-To: <00e801c45f4d$94020f60$6401a8c0@hdev1> References: <170501979.20040701075828@brandenburg.com> <00e801c45f4d$94020f60$6401a8c0@hdev1> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Hector" == Hector Santos writes: Hector> - if the client domain is a bracketed IP liternal, it must Hector> match the sender IP. Its an obvious spoof. Stricly, that's not true, because the sender might be multi-homed. Incidentally, AIUI, multihomed hosts are the main rationale behind the prohibition in RFC1123 (carried forwards to RFC2821) against rejecting mail because the source IP address doesn't match the HELO. -roy From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 15:55:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29074 for ; Thu, 1 Jul 2004 15:55:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Jewcd077206; Thu, 1 Jul 2004 12:40:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61JewQg077205; Thu, 1 Jul 2004 12:40:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Jevtd077197 for ; Thu, 1 Jul 2004 12:40:58 -0700 (PDT) (envelope-from roy+dated+1091302860.43a12e@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i61Jf0nd082429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Jul 2004 19:41:01 GMT (envelope-from roy+dated+1091302860.43a12e@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i61Jf0BE047242 for ; Thu, 1 Jul 2004 20:41:00 +0100 (BST) (envelope-from roy+dated+1091302860.43a12e@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i61Jf0e2047241 for ietf-mxcomp@imc.org; Thu, 1 Jul 2004 20:41:00 +0100 (BST) (envelope-from roy+dated+1091302860.43a12e@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 01 Jul 2004 20:41:00 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16612.26827.511433.89759@giles.gnomon.org.uk> Date: Thu, 1 Jul 2004 20:40:59 +0100 To: "IETF MARID WG" Subject: Re: The problem with Unified SPF In-Reply-To: References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> <16611.15427.708207.855024@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "wayne" == wayne writes: wayne> 1) domain.com can transition from using ?all to using ~all wayne> or -all wayne> 2) if the scope macro variable is allowed (it was suggested wayne> as part of the Unified-SPF), then you would need to have wayne> something like this: But the problem is artificial in origin. In the example that Meng cites (which he suggests would be the norm) one of the records is only intended for authenticating email address identities (MAIL FROM and PRA) and the other is only intended for authenticating HELO strings. If these records were identifiably different in some way, there'd be no risk of using the record intended only for email addresses to attempt to authenticate a HELO string (or vice versa). I don't see the benefit in writing two records for different purposes, then having to construct workarounds for the fact that the records might not be used for those purposes. Why not just have the records begin with different prefixes? eg v=spf1 if it's intended for PRA/MAIL FROM identities, and v=csv1 if it's intended for HELO identities. Or, to put it another way: leave SPF/Sender ID to authenticate mailboxes, and CSV/CSA to authenticate HELO identities. If you want to unify the syntaxes, then that might not be a bad idea. So use SPF _syntax_ for CSA records, but change the prefix to v=csv1 so as to avoid any ambiguity. Meng's example of mta1.domain.com. TXT "v=spf1 a -all" domain.com. TXT "v=spf1 include:this include:that a mx ?all" then becomes: mta1.domain.com. TXT "v=csv1 a -all" domain.com. TXT "v=spf1 include:this include:that a mx ?all" which is hardly any more complex, and avoids the need for any workarounds. -roy From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 16:48:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01078 for ; Thu, 1 Jul 2004 16:48:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61KXPUb081851; Thu, 1 Jul 2004 13:33:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61KXPgN081850; Thu, 1 Jul 2004 13:33:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61KXONU081844 for ; Thu, 1 Jul 2004 13:33:24 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 66DFB4148A; Thu, 1 Jul 2004 13:33:29 -0700 (PDT) Subject: Re: CSV and alternative authentication techniques From: Douglas Otis To: Tony Finch Cc: Andrew Newton , MARID WG In-Reply-To: References: <1088632784.4998.1710.camel@ddev.mail-abuse.org> <1516519406.20040701212221@brandenburg.com> Content-Type: text/plain Message-Id: <1088714008.7961.23.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 01 Jul 2004 13:33:28 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-01 at 07:10, Tony Finch wrote: > On Thu, 1 Jul 2004, Dave Crocker wrote: > > > > Since Doug raised the issue, but separate from Andrew's question (and, > > hence, the different subject line), the discussion of multiple host > > authentication techniques produced a basic hole, with the possibility > > that the authenticated identity could be different from the one > > asserted in HELO. This is a dangerous hole, indeed. > > > > The resolution is to use whatever domain is associated with the > > authentication, rather than the one in the HELO. > > I think I've already noted that SASL is usually used to authenticate a > user name not a host name, so the potential for confusion and inadvertent > spelunking is high. This is covered in Dave's CSV draft, but as SASL is useful only within a Closed system, perhaps a statement that both authentication and authorization are presumed of a holder of secret information, used to authenticate, where the relevant accreditation namespace is dependent upon the Open method used. This would presume a Closed method would not require accreditation. > This is aside from the problems that it doesn't fulfill the requirement > for avoiding prior arrangement stated in section 2.2 of the CSV doc, and > that its organizational complexity is the square of the number of MTAs. > The cost of TLS with trusted third parties is linear in both dollars and > complexity. DNS-based authentication is free and scales linearly, and is > extremely efficient in conjunction with CSA. > > (The above reasoning is why I think the CSV spec should not be over- > complicated with consideration of multiple authentication methods because > the alternatives are all substantially worse than using the DNS.) > > When the client states its identity multiple times should all of the > statements agree? No. Not as currently defined by RFC3207. REF3207 states: : 4.2 Result of the STARTTLS Command : : Upon completion of the TLS handshake, the SMTP protocol is reset to : the initial state (the state in SMTP after a server issues a 220 : service ready greeting). The server MUST discard any knowledge : obtained from the client, such as the argument to the EHLO command, : which was not obtained from the TLS negotiation itself. The client : MUST discard any knowledge obtained from the server, such as the list : of SMTP service extensions, which was not obtained from the TLS : negotiation itself. The client SHOULD send an EHLO command as the : first command after a successful TLS negotiation. It should be assumed the HELO/EHLO domain may not be indicative of the HELO/EHLO once privacy is established. This may mean that if StartTLS is in progress, not to act upon the HELO until the TLS process completes. There are never two valid HELO domains of which to choose. The specification clearly states to discard previous results. Caveat: If it is felt StartTLS is not useful in this role of authenticating and authorizing with a public server, then requiring the initial HELO/EHLO domain to be valid (or perhaps understood as a site defined pass phrase), then exposures would be reduced as there would be no need to wait for TLS. The TLS session HELO/EHLO domain would be unimportant if the client was validated by a Certificate Authority and thereby recognized. If not, then the TLS session HELO domain should match. > Should the server reject the client if they do not? No. Discard the first as currently defined. > These questions almost go away if TLS and SASL authentication are no > longer considered relevant to CSV. SASL is a closed mechanism, with the exception made by RFC2245, stronger than CSV, except for the exception made by RFC2245. TLS _may_ become an open mechanism, albeit expensive to use. > However there should probably be some comment in the CSA specification > about what the server does when the client says EHLO more than once. I feel this is not needed as it is covered in RFC3207. I would also like to limit the topic of TLS to a single document... Dave's of course. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 18:50:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06947 for ; Thu, 1 Jul 2004 18:50:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Mcm4W090134; Thu, 1 Jul 2004 15:38:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61Mcm1e090133; Thu, 1 Jul 2004 15:38:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Mclx8090121 for ; Thu, 1 Jul 2004 15:38:47 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 0E3DD4149B; Thu, 1 Jul 2004 15:38:42 -0700 (PDT) Subject: Re: The problem with Unified SPF From: Douglas Otis To: Roy Badami Cc: IETF MARID WG In-Reply-To: <16612.26827.511433.89759@giles.gnomon.org.uk> References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> <16611.15427.708207.855024@giles.gnomon.org.uk> <16612.26827.511433.89759@giles.gnomon.org.uk> Content-Type: text/plain Message-Id: <1088721521.7961.121.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 01 Jul 2004 15:38:41 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-01 at 12:40, Roy Badami wrote: > >> "wayne" == wayne writes: > > wayne> 1) domain.com can transition from using ?all to using ~all > wayne> or -all > > wayne> 2) if the scope macro variable is allowed (it was suggested > wayne> as part of the Unified-SPF), then you would need to have > wayne> something like this: > > But the problem is artificial in origin. In the example that Meng > cites (which he suggests would be the norm) one of the records is only > intended for authenticating email address identities (MAIL FROM and > PRA) and the other is only intended for authenticating HELO strings. > > If these records were identifiably different in some way, there'd be > no risk of using the record intended only for email addresses to > attempt to authenticate a HELO string (or vice versa). > > I don't see the benefit in writing two records for different purposes, > then having to construct workarounds for the fact that the records > might not be used for those purposes. > > Why not just have the records begin with different prefixes? eg v=spf1 > if it's intended for PRA/MAIL FROM identities, and v=csv1 if it's > intended for HELO identities. > > Or, to put it another way: leave SPF/Sender ID to authenticate > mailboxes, and CSV/CSA to authenticate HELO identities. If you want > to unify the syntaxes, then that might not be a bad idea. So use SPF > _syntax_ for CSA records, but change the prefix to v=csv1 so as to > avoid any ambiguity. > > Meng's example of > > mta1.domain.com. TXT "v=spf1 a -all" > domain.com. TXT "v=spf1 include:this include:that a mx ?all" > > then becomes: > > mta1.domain.com. TXT "v=csv1 a -all" > domain.com. TXT "v=spf1 include:this include:that a mx ?all" > > which is hardly any more complex, and avoids the need for any workarounds. SPF is of a complex matrix of linked DNS records to list an array of acceptable message mailbox domains. This matrix and array imposes high levels of complexity outstripping current DNS capabilities and thus requiring the proposal of a new linked set of records. SPF is currently being proposed to use the DNS TXT record with yet unknown syntax. (The SPF plate is overflowing.) CSV authorizes and authenticates acceptance of a single host name. This closely matches current DNS capabilities and does not require a new record type to do so. CSV is currently proposed using the SRV record with fully defined syntax. (Next to no syntax actually. Why make a meal out of a mouthful?) Living in its small packet, DNS normally provides specific and concise answers already understood by the libraries in hundreds of programming languages. There is no compelling reason to reject the use of suitable record types. There is no advantage defining duplicate records types using TXT records composed with ad hoc syntax that seem to be solutions searching for a problem. To do so, in this case, would suggest all DNS record types should be defined using a TXT record. Such a departure introduces thousands of lines of new code to replace the use of a few (while forgoing useful automation). -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 19:30:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08398 for ; Thu, 1 Jul 2004 19:30:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61NGPZ1091969; Thu, 1 Jul 2004 16:16:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61NGPBu091968; Thu, 1 Jul 2004 16:16:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61NGOtI091958 for ; Thu, 1 Jul 2004 16:16:24 -0700 (PDT) (envelope-from roy+dated+1091315785.caa5ed@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i61NGPnd009780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Jul 2004 23:16:26 GMT (envelope-from roy+dated+1091315785.caa5ed@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i61NGPhh048322 for ; Fri, 2 Jul 2004 00:16:25 +0100 (BST) (envelope-from roy+dated+1091315785.caa5ed@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i61NGPdj048316 for ietf-mxcomp@imc.org; Fri, 2 Jul 2004 00:16:25 +0100 (BST) (envelope-from roy+dated+1091315785.caa5ed@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 02 Jul 2004 00:16:24 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16612.39751.849912.871904@giles.gnomon.org.uk> Date: Fri, 2 Jul 2004 00:16:23 +0100 To: Douglas Otis Cc: Roy Badami , IETF MARID WG Subject: Re: The problem with Unified SPF In-Reply-To: <1088721521.7961.121.camel@ddev.mail-abuse.org> References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> <16611.15427.708207.855024@giles.gnomon.org.uk> <16612.26827.511433.89759@giles.gnomon.org.uk> <1088721521.7961.121.camel@ddev.mail-abuse.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Douglas" == Douglas Otis writes: Douglas> There is no advantage defining duplicate records Douglas> types using TXT records composed with ad hoc syntax that Douglas> seem to be solutions searching for a problem. To do so, Douglas> in this case, would suggest all DNS record types should Douglas> be defined using a TXT record. I would disagree that SPF is a solution waiting for a problem; I think many people here regard SPF (and its derivatives) as a solution to a problem their very interested in (albeit a slightly different one to the one that CSV/CSA solves). I was simply suggesting that if this WG chooses to advance a proposal based on both the marid-core and marid-csv drafts, there is an argument for using a consistent record syntax for both aspects. But that if we go down that route we should still (IMHO) keep the records separate, contrary to what the Unified SPF folks are proposing. Of course, using SPF syntax for CSA records loses us the additional data processing in the DNS server, so there's still an argument for staying with SRV for CSV and TXT for Sender ID. -roy From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 19:55:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09539 for ; Thu, 1 Jul 2004 19:55:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61NiYSc093185; Thu, 1 Jul 2004 16:44:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61NiY6U093184; Thu, 1 Jul 2004 16:44:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i61NiXQC093177 for ; Thu, 1 Jul 2004 16:44:33 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 19:48:18 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2536346594; Thu, 01 Jul 2004 19:48:17 -0400 Message-ID: <002b01c45fc5$638d7ef0$6401a8c0@hdev1> From: "Hector Santos" To: "Roy Badami" Cc: "Dave Crocker" , References: <170501979.20040701075828@brandenburg.com> <00e801c45f4d$94020f60$6401a8c0@hdev1> <16612.25910.347629.316864@giles.gnomon.org.uk> Subject: Re: CVS Questions/Comments [was Re: Comparing apples to multiple, hypothetical oranges] Date: Thu, 1 Jul 2004 19:44:06 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Roy Badami" To: "Hector Santos" Cc: "Dave Crocker" ; Sent: Thursday, July 01, 2004 3:25 PM Subject: CVS Questions/Comments [was Re: Comparing apples to multiple, hypothetical oranges] > > >>>>> "Hector" == Hector Santos writes: > > Hector> - if the client domain is a bracketed IP liternal, it must > Hector> match the sender IP. Its an obvious spoof. > > Stricly, that's not true, because the sender might be multi-homed. > > Incidentally, AIUI, multihomed hosts are the main rationale behind the > prohibition in RFC1123 (carried forwards to RFC2821) against rejecting > mail because the source IP address doesn't match the HELO. > Good point. Its an option. Doing a quick grep in the logs, I have not come across one yet that is a False Positive. All of them were based on spoofing our IP literal hence no explaining why spammers are not complaining. What do you think about the following? SASL should trump CVS. For maximum capability without lost of functionality, CVS should wait until SASL is established or not, thus implying the CVS logic is initiated before or after the next command. It is the only way I can see implemented it. Users using SMTP AUTH are not expected to be CVS ready. Thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 20:02:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09907 for ; Thu, 1 Jul 2004 20:02:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61NusZK093820; Thu, 1 Jul 2004 16:56:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61NusRj093819; Thu, 1 Jul 2004 16:56:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Nusr7093813 for ; Thu, 1 Jul 2004 16:56:54 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from [202.159.52.250] (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i61Nuil19157; Thu, 1 Jul 2004 16:56:45 -0700 Date: Thu, 1 Jul 2004 22:37:14 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1379082993.20040701223714@brandenburg.com> To: Greg Connor CC: ietf-mxcomp@imc.org Subject: Re: Comparing apples to multiple, hypothetical oranges In-Reply-To: References: <170501979.20040701075828@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Greg, GC> While I agree that "unified SPF" really needs a draft in order to talk GC> details, I don't see anything wrong with talking about it as an "undocumented GC> concept" for a while. When the discussion is in the context of whether to "merge CSV into SPF" then I'm afraid there is quite a lot wrong with comparing a concrete specification to an abstract idea. It also does not help when the abstract idea is used in the form of "Unified SPF can do that", as if everything were entirely settled and no concerns could possibly exist. GC> to say "Stop talking about concepts for which there is no draft". You are right. So it is a good thing, that's not what has been said. What has been said is "stop comparing a hypothetical, undocument concept of an evolved SPF with the concrete, relatively stable specification of CSV." d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 20:04:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10017 for ; Thu, 1 Jul 2004 20:04:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61NtPjF093761; Thu, 1 Jul 2004 16:55:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61NtPfJ093760; Thu, 1 Jul 2004 16:55:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61NtOjq093753 for ; Thu, 1 Jul 2004 16:55:24 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i61NtD57019302; Thu, 1 Jul 2004 16:55:13 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i61NtA0D012930; Thu, 1 Jul 2004 16:55:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <16612.39751.849912.871904@giles.gnomon.org.uk> References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> <16611.15427.708207.855024@giles.gnomon.org.uk> <16612.26827.511433.89759@giles.gnomon.org.uk> <1088721521.7961.121.camel@ddev.mail-abuse.org> <16612.39751.849912.871904@giles.gnomon.org.uk> Date: Thu, 1 Jul 2004 16:55:09 -0700 To: Roy Badami , Douglas Otis From: Ted Hardie Subject: Re: The problem with Unified SPF Cc: Roy Badami , IETF MARID WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:16 AM +0100 7/2/04, Roy Badami wrote: > >I was simply suggesting that if this WG chooses to advance a proposal >based on both the marid-core and marid-csv drafts, there is an >argument for using a consistent record syntax for both aspects. There is an important design question here--the tradeoff between the advantage of reusing a single parser and the disadvantage of lockstep development in what may be two very different axes of extension. The choices need not be quite so binary, of course; they range from "Use ASN.1 for 1 and XML for 2" to "Every feature needed by is shared in a common parser and a protocol MUST". If the working group does decide it would be an advantage to have consistent record syntax, I think there needs to be an explicit statement of what level of consistency is at issue. As an aside, in an earlier message, Meng suggested using the same syntax in several contexts (HELO, PRA, and PTR, if I recall correctly), but with different semantics in each context. Speaking personally, this does not strike me as optimal design, as it could easily result in confusion for both those developing the code and deploying the records. I think that form of reuse would need very careful thought indeed. Again, speaking personally, regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 20:13:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10345 for ; Thu, 1 Jul 2004 20:13:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6206wa7094233; Thu, 1 Jul 2004 17:06:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6206wSG094232; Thu, 1 Jul 2004 17:06:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6206vj3094226 for ; Thu, 1 Jul 2004 17:06:57 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 20:10:49 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2537697032; Thu, 01 Jul 2004 20:10:48 -0400 Message-ID: <003701c45fc8$8886cc90$6401a8c0@hdev1> From: "Hector Santos" To: "Douglas Otis" , "Tony Finch" Cc: "Andrew Newton" , "MARID WG" References: <1088632784.4998.1710.camel@ddev.mail-abuse.org> <1516519406.20040701212221@brandenburg.com> <1088714008.7961.23.camel@ddev.mail-abuse.org> Subject: Re: CSV and alternative authentication techniques Date: Thu, 1 Jul 2004 20:07:12 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: "Tony Finch" Cc: "Andrew Newton" ; "MARID WG" Sent: Thursday, July 01, 2004 4:33 PM Subject: Re: CSV and alternative authentication techniques > This is covered in Dave's CSV draft, but as SASL is useful only within a > Closed system, perhaps a statement that both authentication and > authorization are presumed of a holder of secret information, used to > authenticate, where the relevant accreditation namespace is dependent > upon the Open method used. This would presume a Closed method would not > require accreditation. I believe "closed" is the wrong term to use here as it implies everyone must be authenticated as it usually is in a "closed system." SASL extremely useful for an OPEN system. It offers a system with an User Database a way to authenticate users based on user name/id and password pretty much for the sole purpose of allowing "routing." I mean, what other access priveledge can a SMTP server offer other than final destination vs routing mail? In my opinion, I don't think CSV should stay clear, far away from trying to alter or change the usefulness of SASL. Many operators depend on it and have put many support hours getting they users setup for it - for one reason only - to allow their users to route. Anyway, I see this as an implementation issue, because from what I see, if I were to put this in today, I could only do so after SASL is established or not. If so, CVS is skipped. If not, then the delayed CVS logic is started. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 21:32:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13349 for ; Thu, 1 Jul 2004 21:32:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i621Dwlg098009; Thu, 1 Jul 2004 18:13:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i621Dwtm098008; Thu, 1 Jul 2004 18:13:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i621Dvtc098001 for ; Thu, 1 Jul 2004 18:13:57 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BgCc4-0004Sh-Fd for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 20:13:22 -0500 To: "IETF MARID WG" References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> <16611.15427.708207.855024@giles.gnomon.org.uk> <16612.26827.511433.89759@giles.gnomon.org.uk> <1088721521.7961.121.camel@ddev.mail-abuse.org> <16612.39751.849912.871904@giles.gnomon.org.uk> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 01 Jul 2004 20:13:12 -0500 In-Reply-To: (Ted Hardie's message of "Thu, 1 Jul 2004 16:55:09 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: The problem with Unified SPF Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Ted Hardie writes: > As an aside, in an earlier message, Meng suggested using the same syntax in > several contexts (HELO, PRA, and PTR, if I recall correctly), but with > different semantics in each context. Speaking personally, this does > not strike me as optimal design, as it could easily result in confusion > for both those developing the code and deploying the records. I think > that form of reuse would need very careful thought indeed. I guess I'm somewhat amused by the concerns of using SPF-classic to cover the HELO domain and thus be an alternative to CSV. SPF-classic has *always* covered the HELO domain. There *is* no change in semantics of the SPF records for the HELO domain or the 2821.FROM. SPF-classic is not some vague, new concept, it was one of the input documents to this working group. The change in semantics of the SPF record in this working group occurred when people decided that SPF records could/should cover the 2822.From:/Sender:/etc. headers in the Sender-ID proposal. I can't remember anyone other than Margaret and me expressing any concerns about this change in semantics. What Unified-SPF does is add a scope macro variable to make the slightly different contexts work better in some cases. It allows the use of the SPF records, syntax, and semantics to be *optionally* used in several identities/scopes. This is in contrast to SPF-classic that *only* covers 2821.HELO/2821.FROM, and Sender-ID that *only* covers 2822.From:/Sender:/etc. Unified-SPF also says you can do either, or both, or you can even optionally cover the in-addr scope, similar to MTAmark. In <16612.26827.511433.89759@giles.gnomon.org.uk> Roy Badami writes: >>>>>> "wayne" == wayne writes: > > wayne> 1) [...] transition from using ?all to using ~all or -all > wayne> 2) if the scope macro variable [...] > > But the problem is artificial in origin. In the example that Meng > cites (which he suggests would be the norm) one of the records is only > intended for authenticating email address identities (MAIL FROM and > PRA) and the other is only intended for authenticating HELO strings. No, both records can be used in all scopes under the Unified-SPF proposal. Both records been recommended as part of SPF-classic since before this working group was started. > I don't see the benefit in writing two records for different purposes, > then having to construct workarounds for the fact that the records > might not be used for those purposes. The two records are needed because you generally want to cover the different domain names (the email domain and the mta domain) differently. > Why not just have the records begin with different prefixes? eg v=spf1 > if it's intended for PRA/MAIL FROM identities, and v=csv1 if it's > intended for HELO identities. Uh, in the very message you replied to, I said: : Actually, there has also been a third suggested way for Unified-SPF to : fix this. Use a different version tag, such as: : : domain.com. TXT "v=spf1 include:this include:that a mx ?all" : domain.com. TXT "v=spf1-helo -all" Now, whether the new tag is v=spf1-helo or v=csv1, or v= doesn't make much difference. I think the macro variable for a scope is a slightly cleaner solution than a different magic number. If all you want to do is to cover the HELO domain, then CSV is a cleaner solution than SPF-classic. For people who want to cover one of the 2821.FROM/2822.From: identities, using the long-standing SPF-classic semantics to cover the HELO domain is a cleaner solution than CSV. I really don't care one way or the other as to whether this working group advances CSV to being an RFC. I do care about all the FUD being spread, much of it apparently caused by people not reading or understanding the proposals. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 21:53:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14837 for ; Thu, 1 Jul 2004 21:53:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i621kYHn099568; Thu, 1 Jul 2004 18:46:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i621kYb0099567; Thu, 1 Jul 2004 18:46:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i621kX9K099561 for ; Thu, 1 Jul 2004 18:46:33 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: Thoroughly Confused Sysadmins: Raise your hands MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 1 Jul 2004 20:46:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8F9@srv1.pan-am.ca> Thread-Topic: Thoroughly Confused Sysadmins: Raise your hands Thread-Index: AcRf1noMZ1/MOy6XTh+lpBwQiVzhEw== From: "Gordon Fecyk" To: "IETF MXCOMP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i621kX9K099562 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit OK, admittedly I've given up on following every single thread in this list because the arguments have gone way over my head. And before you even suggest that I shouldn't be here because of that, understand this: I HAVE TO IMPLEMENT THIS GARBAGE. I have to install it and support it in the field. I have to explain to clients why it's not working and they're still getting complaints from people about mail that didn't really come from their network. I have to understand, if not how or why it works, the reason for it to work and how to troubleshoot it when it doesn't work. Which brings me to the point of this rant. Exactly what are you trying to accomplish here? All of it. Because it's gone far beyond simply verifying a sender's address or a forwarder's address and into theological - not even technical but religious! - arguments about DNS overloading, SMTP overloading, breaking existing semantics of each, building new semantics that don't even fit in the existing rules (ie: DNS packet sizes), a servere unwillingness to abandon consistently abused things. And that doesn't include all of the political infighting, harsh business accumen, introductions of proprietary / patented crap in doomed efforts to sell said crap, obscene stubbornness and ignorance of hard data, and I don't know what else anymore. If you're as confused as I am, speak up. The 60th IETF is four weeks away and this motley crew's supposed to come up with passable documents by then. If something's not clear make sure you bring it up or it won't be addressed until too late. I'm beginning to appreciate what Steve Atkins, another tired old sysadmin, first asked me a year ago: "Why would I want to do this? What benefit is it to me? What's the cost?" One of the reasons wayne said DMP-02 is a "solid i-d" is that I tried really hard to answer Steve's questions. And those answers came at the cost of much rewriting. Since Meng, Harry, Bob and others in their camp were charged with drafting this stuff and you've now had a chance to be thoroughly nitpicked, please you three - explain what you're doing so a tired and confused network administrator can understand it. And tell me what I have to do to implement it, even if I have to write it from scratch in C or Perl or (Gaia forbid) VB or Python or whatever. I'm not looking for source code, I'm not looking for examples and it doesn't have to be a multi-page essay written so a five-year-old can read it. Just answer the fundamental questions tersely: Who, What, Where, When, Why and if you wish, How. Gentlemen who wrote these drafts: Ignore the nitpicking diatribes of your fellows, just for a moment, and try to answer these questions. This, to me the tired old sysadmin, is the acid test. I will not be the only tired old sysadmin who has to implement what you write. IPSec is now my favorite example of how to confuse the hell out of a tired old sysadmin. It's supposed to be the wonder drug for inter-site connectivity, yet it's confusing as all Hell, requires cooperation between differing entities in the case of third-party vendors providing services (ie: computerized reservation systems for travel agencies) which never exists, different implementors using different language, and, ugh, doesn't even work half of the time between differeing hardware even when you do follow the cookbooks to the letter. And my security-freak friends wonder why I stick with PPTP when IPSec is So Much More Secure. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 22:46:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17385 for ; Thu, 1 Jul 2004 22:46:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i622Z4aa002388; Thu, 1 Jul 2004 19:35:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i622Z48V002387; Thu, 1 Jul 2004 19:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i622Z3Pe002379 for ; Thu, 1 Jul 2004 19:35:03 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 01 Jul 2004 22:38:57 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2546584750; Thu, 01 Jul 2004 22:38:56 -0400 Message-ID: <00c801c45fdd$3a54bea0$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "Douglas Otis" Cc: "Andrew Newton" , "MARID WG" References: <1088632784.4998.1710.camel@ddev.mail-abuse.org> <1516519406.20040701212221@brandenburg.com> Subject: Re: CSV and alternative authentication techniques Date: Thu, 1 Jul 2004 22:35:16 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave, I am honestly trying to keep focus with addressing CVS to see how we can make it work for our package. If it was something we can test today, it would be done. Feedback is the only way I can see if I understand it all. 1) I don't see how TLS applies. I don't think it is even relevant. TLS protects (addressed) secured transmission. I believe you documented TLS is not useful or reliable. Here. 2) I do see a conflict with SASL (ESMTP AUTH). I think for maximum compatibility CVS *may* best apply until SASL is known (established or not) by the client. 3) How do I best merge or not, a bad reputation status against a CVS certified status? Please confirm, correct me or fill me on the about. #2 and #3 are related. Here's how: I have 20,000 user accounts. To route mail, they have to use SASL. We have not received any complaints of any of our users abusing others (and don't expect it from the professional group), but if we did, what does that mean? Can CVS help? I add a CVS record and I registered with MAPS new CVS compliant "Accreditation" service. This will not stop the abuse of any specific individual user. Am I to believe that I need to make sure all our users are CVS ready too? Even so, it seems to me that I am still stuck of directly addressing user abuse issues on a personal basis. Also, another system may be using RBL and quite maybe CVS. They see we have abusive users and even with our CVS certification, they decided to use RBL to block us. Or, is this now a administrative policy issue where a complaint is sent to accreditation agent to get my status remove or suspended? These are real possible issues and scenarios. thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Thu Jul 1 22:52:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17626 for ; Thu, 1 Jul 2004 22:52:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i622ZUjo002411; Thu, 1 Jul 2004 19:35:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i622ZU1d002410; Thu, 1 Jul 2004 19:35:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i622ZT6s002399 for ; Thu, 1 Jul 2004 19:35:29 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7C73EE0654; Thu, 1 Jul 2004 22:35:32 -0400 (EDT) Date: Thu, 1 Jul 2004 22:35:32 -0400 From: John Leslie To: Andrew Newton Cc: MARID WG Subject: Re: CSV and STARTTLS Message-ID: <20040702023532.GC72134@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton wrote: > From section B.4.1 of draft-marid-csv-intro: > >> B.4.1 StartTLS >> >> A common certificate method as used with StartTLS [RFC3207] can >> authenticate an unknown server after an investment in signed periodic >> digital certificates, encryption capabilities, and services of a >> Certificate Authority. This investment creates a barrier for >> large-scale use over the open Internet. Reliance on the certificate >> signature also adds a need to vet Certificate Authorities in addition >> to the confirmed domains. This (IMHO) intends to say that StartTLS can offer strong authentication, but it comes at the expense of a lot of certificate-related baggage. >> Spontaneous communications are at the core of Internet design and >> operation. So omission of a Certificate Authority is typically >> allowed of clients. When this is allowed, StartTLS loses any ability >> to authenticate the relationship of the client to its claimed domain >> name This intends to say that, in order to allow communication between MTAs lacking any prior relationship, StartTLS is implemented with a critical piece of that baggage removed. It goes on to warn that, with this critical piece of baggage removed, StartTLS is no longer able to authenticate the relationship claimed to the EHLO name. > Does this imply that the strong authentication provided by certificate > validation of TLS is to be subjugated by CSV, which is most likely to > be weaker authentication? That certainly was not intended. StartTLS, even in its weakend form, is still useful for its intended purpose: it's just not useful as a means of authenticating the EHLO name. > Also, I think many security-minded folks may disagree with the > characterization in the first paragraph. Opportunistic encryption with > peer authentication using TLS happens every day on the Internet. You've lost me, Andy. I can only guess that you interpreted "creates a barrier" to mean that the expense of the investment "creates" an "insurmountable barrier", which strikes me as an unlikely parsing, even with the following paragraph amputated. Given the paragraph which follows, it seems clear to me that "omission of a Certificate Authority" is a common method of surmounting the barrier. Or did you mean something else? -- John Leslie From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 02:13:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07632 for ; Fri, 2 Jul 2004 02:13:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6262F4R042158; Thu, 1 Jul 2004 23:02:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6262FXB042157; Thu, 1 Jul 2004 23:02:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6262EjJ042135 for ; Thu, 1 Jul 2004 23:02:14 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from [202.159.52.236] (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6262Hl11396 for ; Thu, 1 Jul 2004 23:02:18 -0700 Date: Fri, 2 Jul 2004 10:42:54 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <163427162.20040702104254@brandenburg.com> To: ietf-mxcomp@imc.org Subject: apology to matthew 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 Folks, I completely overreacted to Matthew's reference to Doug's MAPS background, and thereby misinterpreted it. Only after posting my response did I re-read his note more carefully and realize that he was highlighting a perspective for analyzing CSV, rather than in any way calling Doug's position into question. Indeed, CSV is very much intended to flow from existing blacklist/whitelist practise among providers. So Matthews' observation was both natural and appropriate. I won't blame my note on my limited Internet access, or on the effects of the sun, surf or arak, the potent, distilled rice-wine they have over here. I was simply too defensive. Apologies to Matthew and to the list. d/ ----- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA ; From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 02:14:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07734 for ; Fri, 2 Jul 2004 02:14:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6262dmU042323; Thu, 1 Jul 2004 23:02:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6262dng042322; Thu, 1 Jul 2004 23:02:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6262dTQ042315 for ; Thu, 1 Jul 2004 23:02:39 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from [202.159.52.236] (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6262Yl11424; Thu, 1 Jul 2004 23:02:37 -0700 Date: Fri, 2 Jul 2004 12:38:37 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <603278271.20040702123837@brandenburg.com> To: Greg Connor CC: IETF MARID WG Subject: Re: Differences between CSV and Sender-ID In-Reply-To: <6100752.1088590509@Ryoga.corp.sgi.com> References: <6100752.1088590509@Ryoga.corp.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Greg, GC> A HELO check can catch some really obvious bad cases (like spam or viruses GC> using the receiver's own name) and some obvious good cases (like people we GC> want to whitelist). With respect to CSV, I think this needs to be phrased quite differently, even though the semantics will probably seem similar, or at least not contradictory. The reason for this need is that I think it leads to a very different perspective on the implications of a CSV mechanism versus an SPF-like mechanism. HELO makes an assertion about the operation and accountability of the MTA. There is quite a bit of history and current use of services that vet sending SMTP clients and their network operators. A HELO mechanism check can be used to produce a domain-name based codification of such checking, rather than requiring that white/black lists be maintained in terms of IP Addresses. The benefit of having a domain name base involves all of the reasons we all like domain names better than IP Addresses, for use by humans. GC> CSV also uses HELO to tie a reputation to the sending MTA. The concern about accreditation (of which "reputation" is a subset) is rather interesting, here. What folks seem to be missing is that ALL mechanisms that involve acceptance or rejection based on a name or address has an accreditation component. Accreditation is, in fact, the acceptance or rejection policy engine. CSV merely specifies two external standards for such a mechanism. So, yes, a mechanism that only seeks to detect forgeries does not have an accreditation mechanism. But forgive me if I am wrong: I thought folks were interested in detecting and preventing spam, and spam is very, very much about accreditation, not forgery. Forgery is a current symptom, rather than a core aspect of spam and virus sending. Eliminate forgery and there will still be masses of spam and virus sending. I had rather hoped we were trying to get at core issues nof fighting spam, what with the scale of the problem and the cost and delay inherent in any standards effort. GC> This seems to GC> be based on the assumption that good mail comes from good MTAs, and bad GC> mail comes from bad MTAs, which some have suggested is not well-supported. "Some have suggested" is language that applies to any interesting topic, for every possible point of view on the topic. Hence, it does not carry any useful information. (Yeah, I am saying that a bit sharply. It is a pet-peeve of mine about so-called news reporting and I really hope the content-free utterance does not seep into serious technical discussions.) To move this particular point into something that might be productive, please refer to the thread "who are we accrediting?" and note John Levine's posting. I'll post a response to it. GC> I think checking the HELO *alone* is not an adequate solution to the GC> problem set. I agree. RFC2822 author/sender based accreditation is also going to be needed. The nature and form of that accreditation is a different question. GC> If the main thing we want out of MARID is to stop people forging mail I do not have access to the working group charter as I write this, but I sure hope that forgery is not the primary concern of the working group. Otherwise, there is a rather large community of email users and providers who are going to rather upset that we spent all this time and did nothing that is intended to reduce spam. On the other hand, I could see how "DNS-based MTA authentication" could cause one to think that forgery is the focus. GC> apparently-from and bouncing-to our own domains, a MAILFROM/PRA check is GC> going to be required. Some sort of rfc2822 author/sender accredition is going to be required... in some cases. GC> Mechanically, CSV and SPF are both capable of checking HELO. Mechanically, CSV and SPF are both fruit. But let me tell you, you do not want to think about or use durian the same way you think about and use oranges. However, your statement highlights a deeper problem in most of the efforts to discuss CSV and SPF differences: Such efforts are almost entirely tied to mechanical and syntactic issues and do not focus on underlying concepts. CSV and SPF are fundamentally different pardigms. CSV vets an MTA's traffic. SPF vets an RFC2822 author/sender's message. They are orthogonal informational-theoretic areas of consideration. Where the confusion comes in, of course, is that SPF involves the MTA, albeit through an indirection. Let's try for some concise descriptions of the two paradigms: SPF: Per-message MTA path validation, based on Author/Sender authorization and accreditations. CSV: MTA traffic validation, based on MTA operator authorization and accreditation. SPF vets an MTA's sending a single message. It accredits the MTA based on the RFC2822 author/sender. While introducing a path-dependency into the mechanism, it simply defers the hard question, namely accrediting the author/sender. CSV vets an entire MTA session. It accredits the MTA based on the operator of that MTA. Current whitelist and blacklist services focus on the MTA network, ie, the operator of the MTA. So CSV provides a standardizing mechanism for existing practise. The limitations of that practise are demonstrated every day, but so are the benefits. GC> - If the MTA name is also used as a HELO name for one of the MTAs I do not understand what that means. What is an "MTA name", other than the string it puts into the HELO parameter? GC> - In most cases the existing SPF record should be sufficient, since GC> it probably includes that MTA. My guess is that you are talking about the narrow case in which the RFC2822 author/sender has the same domain name as the MTA HELO. While a popular scenario, it is a long way from being the ONLY popular scenario. And that's the problem. SPF is problematic for a number of other such popular scenarios. GC> Semantically, there is some difference in the understanding between what GC> the CSV check means, and what the SPF+HELO check means. It is rather more than "some". GC> It would be better to use ?include:comcast.net or ?ptr:comcast.net. That GC> way the mail from those domains is still allowed, but not "guaranteed" to GC> be from you. This begs for an obvious question: What is the benefit to the anti-spam world of something which offers no guarantees? Is that not the same as saying "I enforce no anti-spam policies, since anyone can claim to be part of my domain"? No accountability is a rather serious deficiency. GC> If the result comes back unknown, you can't attach reputation GC> or whitelisting to that transaction, you just have to proceed in "legacy" GC> mode. And the value-add of SPF, in this scenario is what, exactly? What does the administrator of the domain and/or the operator of the receiving SMTP client get for their effort? GC> If people are really worried about others forging their name in HELO CSV's anti-forgery component is not it's focus. Its focus is upon accrediting MTAs. Authentication is merely a necessary step along the path to assess accreditation. >>Is it clear to you that CSV has definite security advantages >> over SPF/Sender-ID? GC> There is general agreement that the smaller problem GC> of HELO checking "smaller problem"? I hope you do not mean that identifying spam spigots is a small problem or that doing it will be a small benefit. That is one of the things CSV is useful for, that SPF is not. Entire networks of compromised machines can be blocked with a single accreditation entry, no matter what the domain names they use for their rfc2822 author/sender. GC> CSV may have a better security story, but I believe this is a direct result GC> of deciding to include fewer features and less flexibility. Methinks there is a lesson in protocol design, here. GC> Regarding DDOS concerns, I think they can be solved by placing some limits GC> on the amount of recursion possible and the total number of queries needed GC> per mail message, and that should satisfy most concerns. Offhand, I am not sure what you mean and I am certain I do not understand how it pertains to protection against DDOS attacks. GC> I think there is enough consensus in the group that we need to protect PRA GC> and/or MAIL FROM, There is agreement that we need a mechanism that identifies and accredits rfc2822 author/sender IN SOME CASES. GC> and that HELO is of secondary importance. I'm not sure whether you noticed, but there is a rather different tone in the comments about HELO checking now than there was a month or so ago. GC> Not everyone GC> agrees with this, but I think a majority of folks think that HELO checking I am confused. Were the chairs asking each of us to perform a rough consensus assessment of the working group? GC> So, if we are going forward with PRA/SenderID or GC> something like it, it should be easy enough to adapt it to HELO checking as GC> well. I'm sure we all look forward to the specification that satisfies your expectation. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 03:08:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11689 for ; Fri, 2 Jul 2004 03:08:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i626vF3B064605; Thu, 1 Jul 2004 23:57:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i626vFb4064603; Thu, 1 Jul 2004 23:57:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i626vE5J064570 for ; Thu, 1 Jul 2004 23:57:14 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 607DA1D651; Thu, 1 Jul 2004 23:57:12 -0700 (PDT) Date: Thu, 01 Jul 2004 23:57:15 -0700 From: Greg Connor To: Gordon Fecyk , "IETF MXCOMP (E-mail)" Subject: Re: Thoroughly Confused Sysadmins: Raise your hands Message-ID: <16013396.1088726235@[10.12.1.26]> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA8F9@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA8F9@srv1.pan-am.ca> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Gordon Fecyk wrote: > > OK, admittedly I've given up on following every single thread in this list > because the arguments have gone way over my head. And before you even > suggest that I shouldn't be here because of that, understand this: > > I HAVE TO IMPLEMENT THIS GARBAGE. I am right there with you... I am a sysadmin too. > Which brings me to the point of this rant. Exactly what are you trying to > accomplish here? All of it. > > Because it's gone far beyond simply verifying a sender's address or a > forwarder's address and into theological - not even technical but > religious! - arguments about DNS overloading, SMTP overloading, breaking > existing semantics of each, building new semantics that don't even fit in > the existing rules (ie: DNS packet sizes), a servere unwillingness to > abandon consistently abused things. And that doesn't include all of the > political infighting, harsh business accumen, introductions of > proprietary / patented crap in doomed efforts to sell said crap, obscene > stubbornness and ignorance of hard data, and I don't know what else > anymore. Here's my 2 cents. I am a supporter of SPF and I was put off by CallerID, and at first I thought any compromise with MS would be impossible. But, around the time of the MARID Interim meeting, something strange began to happen. SPF supporters and MS supporters decided to set aside some strong differences and get to work on a merged proposal. This was based on a lot of work MARID had done in going over identities, and way back when we were talking about identities to check, I think we reached a loose consensus that we wanted to check 2821 and 2822 identities, each for their very own good reasons. Despite some strong religious differences, a merged proposal came out of it. I was only there for the tail end of it, but it was heady stuff. The idea that you could use the same mechanism to check MAIL FROM +SRS and PRA using the same tool was a good one. The idea that the religious differences like 2821/2822 and SPF/XML didn't matter as much as the underlying features was a better one. CSV supporters are faced with similar issues now. Checking HELO is something a few people wanted (and was a good fallback in case of MAIL FROM: <>) so SPF had that built in from the start. If you were to design a tool that only does HELO checking, and nothing else, would you have a much simpler tool? Of course. Is SPF sufficient to check HELO by itself, if overpowered for that? Probably. But to even discuss such a merger is quite beyond CSV's most vocal supporters for what I think are "religious" reasons. [*] I guess I would be more stressed about this if CSV had more than a handful of supporters. I think most folks in the WG believe as I do, that either SPF or SenderID gets us one step closer to stopping forgery, and CSV represents a step sideways -- neither necessary nor sufficient. Unified SPF, I think, is really an attempt to say, if you want to check these other identities, here's a way to do it. Now all that is missing is the value of checking in each context, the semantics of what it means, and some recommendations on why you would want to check ID-du-jour and what you might want to do with the results. CSV has done a lot of this "semantic" work in terms of HELO, so some of that might be compatible, if it could be pried away from its "One True Implementation" dogma of SRV records. HELO checking has some value -- that is why SPF has had it there for quite some time (mostly for bounces which have blank MAIL FROM) But... I have decided to stop trying to coax CSV supporters into an agreement, since I don't care enough about HELO checking anyway. [*] In this context a "technical" argument is one that says "What you want to do is impossible or infeasible because X". A "religious" argument is one taken on faith such as "Nobody will want to use X records" or "X is the correct way to do this". Also, taking a scale which defines a wide range of correct choices and leaning hard to one side is a form of religious argument. > Since Meng, Harry, Bob and others in their camp were charged with drafting > this stuff and you've now had a chance to be thoroughly nitpicked, please > you three - explain what you're doing so a tired and confused network > administrator can understand it. And tell me what I have to do to > implement it, even if I have to write it from scratch in C or Perl or > (Gaia forbid) VB or Python or whatever. I'm not looking for source code, > I'm not looking for examples and it doesn't have to be a multi-page essay > written so a five-year-old can read it. Just answer the fundamental > questions tersely: Who, What, Where, When, Why and if you wish, How. I wasn't technically a party to the merged Sender ID proposal being decided, but I was one of the first to hear about the main points of it. I think the combined proposal serves most of the same purposes CallerID and SPF were trying to solve separately and has more value than either of them taken alone. So, here is my quick attempt to answer based on my understanding of Sender ID. WHO: domain owners who wish to protect misuse of their domains, and receivers who want to honor their intentions and bounce unauthorized mail. WHAT: domain owners: publish your IPs in DNS using simple mechanisms like "a mx ptr" that refer to other stuff in DNS that receivers usually look up anyway. receivers: bounce mail on Fail, treat with normal policy (filtering or IP DNSBL) on Pass or Unknown, use Pass to whitelist by name. WHERE: DNS TXT records and your MTA. More specifically... PRA: something that is easy for forwarders to add (unlike SRS) and some MTAs like Postfix have it in there already. WHEN: NOW: publish SPF records. SOON: start checking inbound mail, and whitelist known forwarders (e.g. using trusted-forwarder.org whitelist). Forwarders get busy on adding some headers. Careful admins will want to log results only and switch to -all publishing and FAIL-Bounce receiving after showing FP rate is low enough. WHEN: LATER: Other cool stuff becomes possible such as showing the PRA in MUA with a verification icon next to it. Mail sent directly with no forwarding immediately gets a "verified" icon. In the future, if PRA is the receiver's own forwarding address, some MUAs may choose to trust Received: lines added by PRA agent and also show the "previous PRA" as well (similar to the SPF checks on Received: lines that SpamAssassin does). WHY: eventually force spammers to get their own names at increasing cost. In the shorter term, spammers will abuse names that are not SPF-protected disproportionately, creating a good incentive to publish with -all. There will be additional pressure on registrars to check mailing address (or at least credit card billing address) on all domains, or for inclusion into a voluntary whitelist as an extra paid service. Third parties may also provide this mailing address verification service for a small fee, with the caveat that domains terminated for spamming will cause other domains at the same street address to be delisted as well. OK that's enough for now. Above all, Don't Panic. We will get through this! -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 03:17:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11951 for ; Fri, 2 Jul 2004 03:17:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6262Quw042240; Thu, 1 Jul 2004 23:02:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6262QPA042239; Thu, 1 Jul 2004 23:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6262QLs042231 for ; Thu, 1 Jul 2004 23:02:26 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from [202.159.52.236] (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6262Ml11415; Thu, 1 Jul 2004 23:02:23 -0700 Date: Fri, 2 Jul 2004 12:19:50 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <653933787.20040702121950@brandenburg.com> To: John Levine CC: ietf-mxcomp@imc.org, gconnor@nekodojo.org Subject: Re: Who are we accrediting? In-Reply-To: <20040701015906.14011.qmail@xuxa.iecc.com> References: <20040701015906.14011.qmail@xuxa.iecc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John, >>I think checking the HELO *alone* is not an adequate solution to the >>problem set. I don't think CSV alone is enough to be effective >>against spam coming from big ISPs, where good and bad mail may flow >>from the same MTA. JL> With any MTA of any size, you're going to get a mix of good and bad JL> mail. JL> A fairly fundamental question is whether we consider that to be a fact JL> of life that MTA operators can't control, or we consider MTA operators JL> to be responsible for the mail that they send, and evalute them in JL> view of their entire mail stream. To re-use some text from a parallel posting of mine: DC> CSV vets an entire MTA session. It accredits the MTA based on the DC> operator of that MTA. DC> DC> Current whitelist and blacklist services focus on the MTA network, ie, DC> the operator of the MTA. So CSV provides a standardizing mechanism DC> for existing practise. DC> DC> The limitations of that practise are demonstrated every day, but so DC> are the benefits. In other words, whatever its limitations, it is already viewed as having field-tested utility. JL> I realize that opinions differ, but I would like to see a scheme like JL> CSV that uses an IP address to identify an MTA, It recently occurred to me that we should add support for direct IP Address accredition, if only as a transitional mechanism to facilitate adoption by those already using IP Addresses based accreditation. I've already started discussion with my co-authors. I believe domain-name based accreditation has better economies of scale and better stability, but it's clear where the current installed base for this model is... d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 03:34:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12485 for ; Fri, 2 Jul 2004 03:34:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i627LlI9073464; Fri, 2 Jul 2004 00:21:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i627LlCp073463; Fri, 2 Jul 2004 00:21:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i627Lk4M073448 for ; Fri, 2 Jul 2004 00:21:46 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 02 Jul 2004 03:25:35 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2563782891; Fri, 02 Jul 2004 03:25:34 -0400 Message-ID: <012601c46005$45d163f0$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "Greg Connor" Cc: "IETF MARID WG" References: <6100752.1088590509@Ryoga.corp.sgi.com> <603278271.20040702123837@brandenburg.com> Subject: Re: Differences between CSV and Sender-ID Date: Fri, 2 Jul 2004 03:20:52 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" To: "Greg Connor" Cc: "IETF MARID WG" Sent: Friday, July 02, 2004 12:38 AM Subject: Re: Differences between CSV and Sender-ID > GC> and that HELO is of secondary importance. > > I'm not sure whether you noticed, but there is a rather different tone > in the comments about HELO checking now than there was a month or so > ago. Actually, what I notice is a difference in your own tone. First, last year, you "pulled a fast one" by having everyone, including the ASRG, focused on SMTP compatibility. http://www.brandenburg.com/specifications/draft-crocker-spam-techconsider-02.txt To paraphrase: "Remember Compatibility, Incremental changes is the key folks." Many, including myself were talking about the necessary for changed, including the key interest to focus of SMTP compliancy, including HELO for over a year now. But ever since SPF has forced the issue with MARID, you have been every active and provided new work focusing on what many already knew. Now you want us to change our servers in drastic ways! I'm sorry for own tone (blame it a few jacks, ok four), but I don't appreciate the lack of common courtesy to respond to my atleast 1 of my inputs or comments to your CVS specification. I listened to your concerns about the WG tangents. I spent quality time reviewing all the 3 docs (39 pages) and serious considering for implementation. Not one response from you. NADA! If my comments "do not apply" or "bother you," I would only know with FEEDBACK and then I won't have to be wasting more time. Oh well, you are going to ignore this also anyway, so never mind. Thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 04:01:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13732 for ; Fri, 2 Jul 2004 04:01:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i627oOLO083528; Fri, 2 Jul 2004 00:50:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i627oOKw083527; Fri, 2 Jul 2004 00:50:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i627oOW7083508 for ; Fri, 2 Jul 2004 00:50:24 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i627oMm9032161 for ; Fri, 2 Jul 2004 00:50:22 -0700 Subject: Scripts breaking the DNS selector to ratio barrier or just breaking DNS? From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1088754622.2737.14.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 02 Jul 2004 00:50:22 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit DNS uses selectors (names composed of labels) to return elements (records). With a low number of elements per selector, DNS is able to return an immediate answer, often in no more than 10 seconds. The number of these elements within an answer can often be counted on your fingers. This works well for resolving names to addresses, the principle use for DNS. SPF, and its temporal incarnation Sender-ID, used textual scripts to extend this answer using techniques such as CIDR notation, for network segments rather than addresses, and links to other textual records as a means to continue the answer. Normally a host name such as my-mail-server.my-domain.com resolves to a few addresses. DNS works well if you know the name of the machine. SPF et al however could not endure such limited results, as the name was not for a machine. SPF wished to use the domain of a return mailbox to resolve addresses for ALL servers that may issue a such a message. For a large organization, they may directly control dozens of outbound mail machines where each may have several addresses. So for SPF, this is not a usual answer found in a single DNS response. But through the use of scripts and CIDR notation, this answer could fit. This was not enough however. Mail may originate in or traverse other domains. The use of script does not help much to reduce the size of linked mailbox domains. This calls for an answer that may simply need many answers linked to the initial selector. The script wizards needed to extend this response to include these other domains as a means to delegate. So names are added to the CIDR notation pointing to yet more acceptable mailbox domains. Where does this end? Hard to know, as these script wizards can't decide. This process can take forever. Do they limit the time, recursion depth, number of branches, number of segments, or number of mailbox domains? Again, they can't decide. What happens if forced to quit? What does this do to mail delivery? A company may wish to point to other domains that may handle their advertising, product support, corporate offices, and factory outlets, all using the common mailbox domain that often serves as part of the company trademark. With ten outlets using 4 different network providers, this company already has a need to cross-reference 7 other domains. The advertising company uses a complex network of subcontractors, where, so far, list 50 domains within their records. Each of these large ISPs have several records for their outbound mail services. Now the scripted answer, discovered through the linking of text records, includes many domains and network segments. Perhaps this can fit in a few dozen text records, but these are discovered using a series of sequential queries. A series of queries is always bad, especially if this must be done for each message seen within a mail stream. This was primarily to prevent rogue systems from originating mail from machines not included within the array of network segments, defined within the matrix of records, linked to the original selector. These lists may not be comprehensive. After all, it is not often the complete path of a message is known before hand. It may well be, there are those wishing to retain the freedom of using any mail access to send a message and, for them, these lists may be defined as "open." The end of the exhaustive search through dozens of records reveals that the message should be marked "unknown" with no other changes to its handling. (At least thats what it should mean.) Does this lower the amount of undesirable mail. No. Does this stop the spoofing of return addresses, absolutely not. One bug-a-boo comes from a technique spoofing the return path as a means to deliver mail addressed to a bogus mailbox. This could be prevented if the recipient could discover valid users before accepting mail, but that information could lead to more trouble. Making 20 queries of DNS text records seemed like a better solution than bouncing the message? SPF will not prevent spoofing, but will likely mean those able to defeat the SPF checks will have an easier time duping their targets. 70% of the ISPs don't even bother to authenticate the mail sent on their networks. What value is there thinking the domain of a message is confirmed traveling within the what-me-worry.com network? Who did what? SPF can't resolve that question nor can it determine the domain of the last SMTP server that offered the message. There is talk about using the mailbox domain lists to check against the HELO/EHLO domain. What do these two domains have in common? Nothing. There is a significant difference between authorizing and authenticating a host and network segments for an array of mailbox domains. The matrix of records, composing the array of network segments, attempts to resolve whether a mailbox domain is acceptable for traversal. CSV uses a single SRV record as a means to both Authorize and Authenticate the host name to ascertain access accountability. SPF is not concerned about this issue. The host name in the HELO/EHLO announcement offers the natural DNS ratio of selector to elements. This also means wildcards are not need. Linked files are not needed. CIDR segment notation is not needed. In fact, CIDR notation is detrimental. A script based record will not improve the resilience to a DDoS attack. In fact, a script based record will not find native support in hundreds of programming languages as will a SRV record. Does SPF aid enforcement or allow accreditation of suitable policies that secure access to the mail channel? No. So why are the script wizards looking to mold CSV into yet another script? To justify the need for a DNS script parser? To allow an endless stream of new script based DNS record types? Because they like inventing script languages, even if they can't decide what is a good script? Your guess is as good as mine. These script wizards are wrong about a need to make these records for SPF and CSV "look" the same to sell SPF. In fact, this will likely lead to confusion about what should be in the CSV record. Back to the old saw. The E in IETF stands for Marketing. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 06:46:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27199 for ; Fri, 2 Jul 2004 06:45:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62AW9lG039849; Fri, 2 Jul 2004 03:32:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62AW9nA039848; Fri, 2 Jul 2004 03:32:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62AW8HR039840 for ; Fri, 2 Jul 2004 03:32:08 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35180) by ppsw-9.csi.cam.ac.uk (old-ppsw.cam.ac.uk [131.111.8.3]:25) with esmtp (Exim 4.34) id 1BgLKq-0006ph-RO for ietf-mxcomp@imc.org; Fri, 02 Jul 2004 11:32:00 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BgLKq-0005s2-8c; Fri, 02 Jul 2004 11:32:00 +0100 Date: Fri, 2 Jul 2004 11:32:00 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Douglas Otis cc: Tony Finch , Andrew Newton , MARID WG Subject: Re: CSV and alternative authentication techniques In-Reply-To: <1088714008.7961.23.camel@ddev.mail-abuse.org> Message-ID: References: <1088632784.4998.1710.camel@ddev.mail-abuse.org> <1516519406.20040701212221@brandenburg.com> <1088714008.7961.23.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 1 Jul 2004, Douglas Otis wrote: > > There are never two valid HELO domains of which to choose. The > specification [RFC 3207] clearly states to discard previous results. OK. > The TLS session HELO/EHLO domain would be unimportant if > the client was validated by a Certificate Authority and thereby > recognized. If not, then the TLS session HELO domain should match. This isn't covered by RFC 3207 so needs to be explained by HNA. > > However there should probably be some comment in the CSA specification > > about what the server does when the client says EHLO more than once. > > I feel this is not needed as it is covered in RFC3207. I would also > like to limit the topic of TLS to a single document... Dave's of course. > : ) Note that a client can say EHLO more than once in a non-TLS SMTP session. Should the server only use the most recent one for CSV, or the first one? (Using the first one is probably contrary to RFC 2821.) Do they have to be all the same? Tony. -- f.a.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 3 OR 4, OCCASIONALLY 5 LATER. THUNDERY SHOWERS. MODERATE OR GOOD. From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 06:46:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27217 for ; Fri, 2 Jul 2004 06:46:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62AZaEf040137; Fri, 2 Jul 2004 03:35:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62AZa8p040136; Fri, 2 Jul 2004 03:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62AZZJ3040129 for ; Fri, 2 Jul 2004 03:35:35 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 999C81D651; Fri, 2 Jul 2004 03:35:36 -0700 (PDT) Date: Fri, 02 Jul 2004 03:35:40 -0700 From: Greg Connor To: Dave Crocker Cc: IETF MARID WG Subject: Re: Differences between CSV and Sender-ID Message-ID: <29117638.1088739340@[10.12.1.26]> In-Reply-To: <603278271.20040702123837@brandenburg.com> References: <603278271.20040702123837@brandenburg.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Dave, I'm not exactly pleased to see my post carved up, with a number of 1-3 line responses added for every 1-3 lines I wrote. I feel it is a style that encourages fighting, bickering, and disagreement rather than mutual understanding and consensus-building. However, I don't believe at all that you meant to be rude or anything. Perhaps you interpreted my message as an attack against CSV and reacted defensively? Anyway, you raise some good points here, so I will attempt to reply as concisely as I can. It's going to appear disjointed but I will try not to break things up too much further than they already are. --Dave Crocker wrote: > > Greg, > > > GC> A HELO check can catch some really obvious bad cases (like spam or > viruses GC> using the receiver's own name) and some obvious good cases > (like people we GC> want to whitelist). > > With respect to CSV, I think this needs to be phrased quite > differently, even though the semantics will probably seem similar, or > at least not contradictory. The reason for this need is that I think it > leads to a very different perspective on the implications of a CSV > mechanism versus an SPF-like mechanism. > > HELO makes an assertion about the operation and accountability of the > MTA. There is quite a bit of history and current use of services that > vet sending SMTP clients and their network operators. > > A HELO mechanism check can be used to produce a domain-name based > codification of such checking, rather than requiring that white/black > lists be maintained in terms of IP Addresses. The benefit of having a > domain name base involves all of the reasons we all like domain names > better than IP Addresses, for use by humans. Without commenting on mechanisms, I totally agree with your explanation of HELO and its significance. I was attempting to keep it a bit simple for the readers. The two paragraphs above are a good explanation as to why HELO is significant, and why checking it (by whatever mechanism) is desirable. All is well. > GC> CSV also uses HELO to tie a reputation to the sending MTA. > > The concern about accreditation (of which "reputation" is a subset) is > rather interesting, here. What folks seem to be missing is that ALL > mechanisms that involve acceptance or rejection based on a name or > address has an accreditation component. Accreditation is, in fact, the > acceptance or rejection policy engine. > > CSV merely specifies two external standards for such a mechanism. > > So, yes, a mechanism that only seeks to detect forgeries does not have > an accreditation mechanism. But forgive me if I am wrong: I thought > folks were interested in detecting and preventing spam, and spam is > very, very much about accreditation, not forgery. > > Forgery is a current symptom, rather than a core aspect of spam and > virus sending. Eliminate forgery and there will still be masses of > spam and virus sending. > > I had rather hoped we were trying to get at core issues nof fighting > spam, what with the scale of the problem and the cost and delay > inherent in any standards effort. My statement wasn't meant as a negative. I actually agree with what you said here. CSV hangs reputation/accreditation on HELO, SPF chooses to hang it on another identity. I certainly didn't mean to imply that accreditation is not important. > GC> This seems to > GC> be based on the assumption that good mail comes from good MTAs, and > bad GC> mail comes from bad MTAs, which some have suggested is not > well-supported. > > "Some have suggested" is language that applies to any interesting > topic, for every possible point of view on the topic. Hence, it does > not carry any useful information. (Yeah, I am saying that a bit > sharply. It is a pet-peeve of mine about so-called news reporting and > I really hope the content-free utterance does not seep into serious > technical discussions.) > > To move this particular point into something that might be productive, > please refer to the thread "who are we accrediting?" and note John > Levine's posting. I'll post a response to it. In the part you quoted, I was trying to point out one area of disagreement, without actually taking sides (I explained my own opinion after the "My opinion" tag), so my apologies for the vagueness. So, to be clear, I am suggesting that this assumption is not valid or useful. I think the reputation of the MTA is often interesting, but certainly not enough in itself to judge the quality of the mail. But, after reading your message I am starting to think that you don't believe this assumption either, that there are only "good" and "bad" MTAs. In that case, this disagreement is not directed at you, but at other CSV supporters (Matthew and Doug) who have been suggesting that checking HELO against a reputation is pretty much all you need and other proposals that check other identities are worthless, doomed to failure, or both. > GC> I think checking the HELO *alone* is not an adequate solution to the > GC> problem set. > > I agree. RFC2822 author/sender based accreditation is also going to > be needed. The nature and form of that accreditation is a different > question. Right... that's what I was trying to say too :) > GC> If the main thing we want out of MARID is to stop people forging mail > > I do not have access to the working group charter as I write this, but > I sure hope that forgery is not the primary concern of the working > group. > > Otherwise, there is a rather large community of email users and > providers who are going to rather upset that we spent all this time > and did nothing that is intended to reduce spam. > > On the other hand, I could see how "DNS-based MTA authentication" could > cause one to think that forgery is the focus. Wow, we're interrupting mid-sentence now, I see :) I won't spend much time on this one other than to say: 1. I want to stop spam too, and I think stopping forgery is a necessary but sufficient step.. 2. I honestly believed that stopping forgery was the point of the WG and that stuff that stops spam by other means than stopping forgery would be ruled out of scope, and 3. It looks like you agreed with the important part of my sentence anyway :) > GC> apparently-from and bouncing-to our own domains, a MAILFROM/PRA check > is GC> going to be required. > > Some sort of rfc2822 author/sender accredition is going to be > required... in some cases. Agreed :) > GC> Mechanically, CSV and SPF are both capable of checking HELO. > > Mechanically, CSV and SPF are both fruit. But let me tell you, you do > not want to think about or use durian the same way you think about and > use oranges. > > However, your statement highlights a deeper problem in most of the > efforts to discuss CSV and SPF differences: Such efforts are almost > entirely tied to mechanical and syntactic issues and do not focus on > underlying concepts. Right... That actuall IS what I mean here -- I mean to separate the mechanics of each proposal from the underlying concepts. The assertion I was trying to test is whether the mechanism SPF uses to test PRA, MAIL FROM and HELO is capable of doing the same things the CSV mechanism does. If it cannot for strictly *mechanical* reasons, I would like to understand what they are. So far the answer whenever I ask this is "Well, you COULD use SPF TXT records instead of SRV records, but why would you want to?" If it's possible to present an end user with one tool that has two applications, that might be a worthwhile goal. Speaking only of the *mechanism* I don't see that SRV records have an inherent advantage over TXT records, or that the underlying concepts of CSV depend on SRV records. > CSV and SPF are fundamentally different pardigms. > > CSV vets an MTA's traffic. > > SPF vets an RFC2822 author/sender's message. > > They are orthogonal informational-theoretic areas of consideration. > > Where the confusion comes in, of course, is that SPF involves the MTA, > albeit through an indirection. > > Let's try for some concise descriptions of the two paradigms: > > > SPF: > > Per-message MTA path validation, based on Author/Sender > authorization and accreditations. > > CSV: > > MTA traffic validation, based on MTA operator authorization and > accreditation. > > > SPF vets an MTA's sending a single message. It accredits the MTA > based on the RFC2822 author/sender. While introducing a > path-dependency into the mechanism, it simply defers the hard > question, namely accrediting the author/sender. > > CSV vets an entire MTA session. It accredits the MTA based on the > operator of that MTA. I don't really agree that CSV and SPF are fundamentally different paradigms. They are different, but I don't think fundamentally so, and I don't think either of them represents a "paradigm" really. I think of SPF not as a great idea, but as a collection of great ideas. Some of these are: - A mechanism that maps (domain name, IP) onto (pass, fail, unknown) - Application of this mechanism to MAIL FROM, to vet a message path (or partial path, when forwarders use SRS) - Application of this mechanism to PRA, to vet a message path (or partial path, when forwarders use recommended headers) - Accreditation can be applied to the domain of any ID that returns pass result. - An ID that returns fail result should be treated as highly suspect and probably rejects. An ID that returns unknown result should not be used to judge a mail as good or bad and the receiver should fall back to other methods. CSV is also made of multiple great ideas, such as: - A mechanism that maps (domain name, IP) onto (allowed, disallowed, no_info) - Application of this mechanism to HELO, to vet an MTA - Accreditation can be applied to the MTA based on its name, if result is allowed. - An IP address specifically disallowed from using the name claimed in HELO should be treated as MTA-not-grata - An MTA that has no info CSV may check should be rated on other means (e.g. IP) or not at all. The point of this exercise is to separate the "mechanism" carrying the message from the content and meaning of the message itself. The SRV record mechanism is clever, but I got the feeling from reading CSV documents and speaking to you and other CSV supporters that it is not the main important thing that CSV does. By suggesting that the mechanisms *could be* compatible, I don't mean to imply that the two types of checks already mean the same thing. They don't. SPF has a couple of modes where it checks HELO, but it lacks an explanation as to why one might want to do that, what the information means, and how to interpret it and act on it. Why am I so keen to show that one mechanism could be used for both checks? Well, one of the first things that this WG worked on was deciding which identities to check. My understand was, at the time, that there was a pretty strong consensus that we should work on both 2821 and 2822 identities, and I *thought* we had also decided that if we tackle one identity first, we would do so in such a way that the other identities could be checked with the same or similar mechanism. > Current whitelist and blacklist services focus on the MTA network, ie, > the operator of the MTA. So CSV provides a standardizing mechanism > for existing practise. > > The limitations of that practise are demonstrated every day, but so > are the benefits. That is an excellent point, and I agree. > GC> - If the MTA name is also used as a HELO name for one of the MTAs > GC> - In most cases the existing SPF record should be sufficient, > since GC> it probably includes that MTA. > > My guess is that you are talking about the narrow case in which the > RFC2822 author/sender has the same domain name as the MTA HELO. While > a popular scenario, it is a long way from being the ONLY popular > scenario. And that's the problem. SPF is problematic for a number of > other such popular scenarios. You are correct, that should have been "sender domain name" not MTA name. I agree, this is definitely not the majority case. I mention it here because it is really the only case where the SAME name may be used by both email addresses and HELO. If the same name might be used by an MTA and by the RHS of an email address, I think chances are very good that the allowed IPs for both cases will be the same. Again, this hearkens back to the discussion of which identities we want to be able to validate. At the time, we identified HELO, MAIL FROM and From:/Sender:, and along with the idea that perhaps all three merit checking, we brought up the cases where the same domain name might be used in different contexts. Each context might have wildly different meaning and usage, but where the NAME is exactly the same, the set of authorized IPs would usually be the same or a blend of the two usage sets would be suitable. If I remember correctly, not everyone was convinced at the time that a single set of IPs would always work, so there was some discussion of a "scope tag" of sorts, but I think most of the group agreed at the time that the need for this would be rare. > GC> Semantically, there is some difference in the understanding between > what GC> the CSV check means, and what the SPF+HELO check means. > > It is rather more than "some". Agreed. But if the implication is that they are different enough to *require* different mechanisms, I would not agree with that. Let me say this again because I think it is important: THE IDEA OF USING ONE MECHANISM TO VALIDATE DIFFERENT IDENTITIES IS NOT NEW. As I continue to suggest that CSV *could* be implemented using SPF TXT records, people continue to look at me as if I'm speaking heresy. All I can say is, please review the archives. This same WG agreed that multiple identities are worthy of checking, and if possible they should be checked in the same or similar ways. Did I misunderstand, or have we changed directions on this, or has everyone just forgotten what we talked about for the first month or more? > GC> It would be better to use ?include:comcast.net or ?ptr:comcast.net. > That GC> way the mail from those domains is still allowed, but not > "guaranteed" to GC> be from you. > > This begs for an obvious question: What is the benefit to the > anti-spam world of something which offers no guarantees? Is that not > the same as saying "I enforce no anti-spam policies, since anyone can > claim to be part of my domain"? No accountability is a rather serious > deficiency. To quote Douglas Adams, "We demand rigidly defined areas of doubt and uncertainty!" :) Seriously though, the "unknown" state was put in there for a reason. In an ideal world, all my users would phone home and submit with SMTP AUTH and all our mail would go out the pre-defined block of IPs. But, some domain owners might want partial coverage, and might need some usage cases to be supported in "legacy mode" for a while. If a domain owner is not 100% sure he has rounded up all the roaming users, he may choose to write ?all at the end - in which case forgeries would not be stopped, but the +entries in the list can still be used to invoke reputation and whitelisting. If all the roaming users happen to be on comcast.net, a record with ?ptr:comcast.net -all is much better than ?all -- possibly enough to make spammers/forgers move on to the next target. In other words, the "unknown" state is a feature, not a bug. If you don't agree, fine, don't use the feature. Your characterization of this mode as a "deficiency" is uncharitable and seems to contain a high FUD to fact ratio. If you had not taken the sentence out of context, my original intent would be a bit clearer -- I was actually responding to some other FUD based on a wrong understanding of SPF (or intentional misreading or other straw man). The example given by Doug and Matt both was "Well what about a domain that publishes include:comcast.net? That means anyone on comcast.net could HELO as my own name!" Yes, and this would be a mistake on the part of the domain owner; they are in effect saying "We trust comcast.net to not forge mail from us or otherwise use our name improperly." > GC> If the result comes back unknown, you can't attach reputation > GC> or whitelisting to that transaction, you just have to proceed in > "legacy" GC> mode. > > And the value-add of SPF, in this scenario is what, exactly? > > What does the administrator of the domain and/or the operator of the > receiving SMTP client get for their effort? See above regarding FUD. I will note also that despite disparagement pointed at the "unknown" mode of SPF, CSV also has a de-facto "unknown" mode - you can just choose not to publish any records at all for that particular name. I would assume that reputation would not attach in this case either. >>> Is it clear to you that CSV has definite security advantages >>> over SPF/Sender-ID? > > > GC> There is general agreement that the smaller problem > GC> of HELO checking > > "smaller problem"? > > I hope you do not mean that identifying spam spigots is a small > problem or that doing it will be a small benefit. > > That is one of the things CSV is useful for, that SPF is not. Entire > networks of compromised machines can be blocked with a single > accreditation entry, no matter what the domain names they use for their > rfc2822 author/sender. Actually I was not referring to my own opinion as "general agreement" -- I was referring to the decisions of this WG as to which identities should be checked. I believe it was agreed that 2821.MAIL FROM was most important, followed by 2822.From/Sender, and 2821.HELO was the least important of the three. I DO agree though; identifying spam spigots is a big problem, and doing it is a big benefit. You have made a good case for HELO checking. I'm not suggesting that HELO checking shouldn't be done, and you're not suggesting that it's a total solution in itself that trumps others. We may not be on the same page but I think it's in the same book :) > GC> CSV may have a better security story, but I believe this is a direct > result GC> of deciding to include fewer features and less flexibility. > > Methinks there is a lesson in protocol design, here. > > > GC> Regarding DDOS concerns, I think they can be solved by placing some > limits GC> on the amount of recursion possible and the total number of > queries needed GC> per mail message, and that should satisfy most > concerns. > > Offhand, I am not sure what you mean and I am certain I do not > understand how it pertains to protection against DDOS attacks. Sorry, I didn't mean "[all] DDOS attacks" -- this was a specific reply to a specific concern in SPF. I don't know why Matt and Doug chose to say over and over again how nasty and yucky and vulnerable SPF is, citing this as a reason why CSV is cool and wanted and necessary. I don't think SPF and CSV are mutually exclusive and I don't think the "air of competition" serves any of us well. I think CSV contains great ideas and so does SenderID. > GC> I think there is enough consensus in the group that we need to > protect PRA GC> and/or MAIL FROM, > > There is agreement that we need a mechanism that identifies and > accredits rfc2822 author/sender IN SOME CASES. No comment at this time, Senator. :) > GC> and that HELO is of secondary importance. > > I'm not sure whether you noticed, but there is a rather different tone > in the comments about HELO checking now than there was a month or so > ago. I noticed. CSV has done a lot to bring HELO into the spotlight. This is a good thing. As long as CSV isn't trying to elbow other proposals out of the way, I don't have a problem with it. In fact, Unified SPF is based pretty strongly on my efforts to get HELO placed more prominently on SPF's radar screen. I have gone from not taking HELO seriously to actively preaching the gospel of HELO to spf-discuss and #spf on IRC. I don't think HELO has eclipsed PRA/MAIL FROM/SUBMITTER in importance or utility. > GC> Not everyone > GC> agrees with this, but I think a majority of folks think that HELO > checking > > I am confused. Were the chairs asking each of us to perform a rough > consensus assessment of the working group? I was referring again to the rough consensus reached at our first-phase milestone. I believe it was agreed that 2821.MAIL FROM was most important, followed by 2822.From/Sender, and 2821.HELO was the least important of the three. Perhaps I misremember, but that's what I thought we said. > GC> So, if we are going forward with PRA/SenderID or > GC> something like it, it should be easy enough to adapt it to HELO > checking as GC> well. > > I'm sure we all look forward to the specification that satisfies your > expectation. Being worked on. I think you will be pleased. As I said before, if Unified SPF borrows some ideas from CSV, please consider that a form of flattery :) -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 06:49:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27415 for ; Fri, 2 Jul 2004 06:49:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Aefq1040446; Fri, 2 Jul 2004 03:40:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62Aeft2040445; Fri, 2 Jul 2004 03:40:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62AefQU040437 for ; Fri, 2 Jul 2004 03:40:41 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 02 Jul 2004 06:40:40 -0400 id 0005C574.40E53BA8.0000489D In-Reply-To: <20040702023532.GC72134@verdi> References: <20040702023532.GC72134@verdi> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <40FA7C4A-CC14-11D8-BF80-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: MARID WG From: Andrew Newton Subject: Re: CSV and STARTTLS Date: Fri, 2 Jul 2004 06:40:36 -0400 To: John Leslie X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 1, 2004, at 10:35 PM, John Leslie wrote: > This intends to say that, in order to allow communication between > MTAs lacking any prior relationship, StartTLS is implemented with a > critical piece of that baggage removed. It goes on to warn that, with > this critical piece of baggage removed, StartTLS is no longer able to > authenticate the relationship claimed to the EHLO name. > >> Does this imply that the strong authentication provided by certificate >> validation of TLS is to be subjugated by CSV, which is most likely to >> be weaker authentication? > > That certainly was not intended. StartTLS, even in its weakend form, > is still useful for its intended purpose: it's just not useful as a > means of authenticating the EHLO name. Ah. This makes sense to be now. Thanks. -andy From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 09:32:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05400 for ; Fri, 2 Jul 2004 09:32:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62DNI44054972; Fri, 2 Jul 2004 06:23:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62DNI7B054971; Fri, 2 Jul 2004 06:23:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62DNHuU054963 for ; Fri, 2 Jul 2004 06:23:17 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BgO0Y-0005oh-DW for ietf-mxcomp@imc.org; Fri, 02 Jul 2004 14:23:14 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BgO0X-0006gX-EN; Fri, 02 Jul 2004 14:23:13 +0100 Date: Fri, 2 Jul 2004 14:23:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Douglas Otis cc: Roy Badami , IETF MARID WG Subject: Re: The problem with Unified SPF In-Reply-To: <1088721521.7961.121.camel@ddev.mail-abuse.org> Message-ID: References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> <16611.15427.708207.855024@giles.gnomon.org.uk> <16612.26827.511433.89759@giles.gnomon.org.uk> <1088721521.7961.121.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 1 Jul 2004, Douglas Otis wrote: > > SPF is of a complex matrix of linked DNS records to list an array of > acceptable message mailbox domains. This matrix and array imposes high > levels of complexity outstripping current DNS capabilities and thus > requiring the proposal of a new linked set of records. SPF is currently > being proposed to use the DNS TXT record with yet unknown syntax. (The > SPF plate is overflowing.) Should the syntax for SPF be DDDS? Tony. -- f.a.n.finch http://dotat.at/ . From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 10:02:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06448 for ; Fri, 2 Jul 2004 10:02:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Drgkb057278; Fri, 2 Jul 2004 06:53:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62DrgOD057277; Fri, 2 Jul 2004 06:53:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62DrfIV057271 for ; Fri, 2 Jul 2004 06:53:41 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i62Dral14891; Fri, 2 Jul 2004 06:53:39 -0700 Date: Fri, 2 Jul 2004 15:08:26 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1159464534.20040702150826@brandenburg.com> To: Meng Weng Wong CC: ietf-mxcomp@imc.org Subject: Re: DDOS attacks In-Reply-To: <20040629225257.GJ16052@dumbo.pobox.com> References: <20040629142750.GU3747@verdi> <20040629144923.GS13225@dumbo.pobox.com> <40E1ED34.1020501@elvey.com> <20040629225257.GJ16052@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng, MWW> It seems to me the DDOS attacks we have reviewed so far MWW> pretty much boil down to: I believe that you have completely misunderstood the problem and, therefore, entirely missed the nature of at least one approach to solving it. The problem is not just with malicious attacks designed to create a service interruption. Current methods of spam transmission are architecturally identical to a DDOS attack. The only difference is that they target a large number of recipients, rather than just one. Hence, it is the act of mass coercion and mass transmission that is the issue. It pertains, of course, to true attacks, but it also pertains to the sending of spam. It can involve thousands of user machines, and any number of user domain names, all going through the same ISP.; A mechanism which can identify an aggregate source of such traffic permits a high degree of efficiency at limiting its damage. That is what CSV permits. As I understand its intent and design, that is not something that SPF does do at all. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 10:04:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06649 for ; Fri, 2 Jul 2004 10:04:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62DrWaZ057265; Fri, 2 Jul 2004 06:53:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62DrWkL057264; Fri, 2 Jul 2004 06:53:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62DrWRO057258 for ; Fri, 2 Jul 2004 06:53:32 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i62DrSl14869; Fri, 2 Jul 2004 06:53:29 -0700 Date: Fri, 2 Jul 2004 14:55:19 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <98447468.20040702145519@brandenburg.com> To: Meng Weng Wong CC: ietf-mxcomp@imc.org Subject: Re: The problem with Unified SPF In-Reply-To: <20040630220353.GX13225@dumbo.pobox.com> References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng, MWW> HELO domain.com MWW> MAIL FROM: MWW> In this situation, an SPF record could easily become MWW> unnecessarily complex for HELO purposes. MWW> domain.com. TXT "v=spf1 include:this include:that a mx ?all" MWW> If the domain admin changes the HELO string to be: MWW> HELO mta1.domain.com MWW> MAIL FROM: Actually, this is a remarkably concise demonstration of the problem inherent with trying to multiplex two, entirely separate semantics into the same record. The way to solve it is not to dictate to users how they administer their namespace, such as telling them what kinds of names to use in HELO strings. Rather, it is to separate the mechanisms that have different semantics. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 10:28:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08689 for ; Fri, 2 Jul 2004 10:28:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62EDOFi058140; Fri, 2 Jul 2004 07:13:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62EDO05058139; Fri, 2 Jul 2004 07:13:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62EDNvf058133 for ; Fri, 2 Jul 2004 07:13:24 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 799CAE071B; Fri, 2 Jul 2004 10:13:24 -0400 (EDT) Date: Fri, 2 Jul 2004 10:13:24 -0400 From: John Leslie To: Hector Santos Cc: ietf-mxcomp@imc.org Subject: Re: CVS Questions/Comments [was Re: Comparing apples to multiple, hypothetical oranges] Message-ID: <20040702141324.GF72134@verdi> References: <170501979.20040701075828@brandenburg.com> <00e801c45f4d$94020f60$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e801c45f4d$94020f60$6401a8c0@hdev1> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector Santos wrote: > > 1) Are there any CVS test sites to test/compare results? I wouldn't quite call it a "test site", but I have placed CSV records for JLC.net. Most of our mail goes out through "mailhost.jlc.net"; thus there are DNS records (in bind format): " " mailhost IN A 199.201.159.9 " IN PTR _vouch._smtp.csv_vouch " _client._smtp.mailhost SRV 1 2 0 mailhost - saying that mailhost.jlc.net is authorized as an SMTP client, and that the list of IP addresses is not empty; and - saying that the csv_vouch.jlc.net reputation service will vouch for it. (Not surprisingly, csv_vouch.jlc.net reports an "excellent" rating.) > 2) Are there any DNA sites to test/compare results? CSV_vouch is a separate zone: " " $TTL 7200 " @ IN SOA jlc.net. tech.jlc.net. ( " 1 " 7200 ; " 900 ; " 86400 ; " 7200 ) " IN NS ns1.jlc.net. " IN NS ns2.jlc.net. " mailhost.jlc.net TXT "MARID,1,A" > 3) Do you have a list of CVS ready domains I can use for testing logic? No. (Perhaps I'll get a round tuit...) > 4) Is Acceditation required for CVS to be useful? In other words, is it > useless without it? "Accreditation is in the eye of the beholder." CSV certainly is not "useless" without formal accreditation services. Without any accreditation service at all, it can report, "This domain operates no mail-servers" based upon a "SRV 1 1 0" record. Without a real-time accreditation check, you're at risk trusting a CSV report of "authorized"; but until spammers adjust, it would be relatively safe to let this override an IP-based blacklist. And surely the authorization info, recorded in a Received header, should prove helpful in directing spam reports. -- John Leslie > From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 13:16:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20988 for ; Fri, 2 Jul 2004 13:16:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62H5PCb070659; Fri, 2 Jul 2004 10:05:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62H5Pei070658; Fri, 2 Jul 2004 10:05:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62H5OZ2070648 for ; Fri, 2 Jul 2004 10:05:24 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 376DD4148F; Fri, 2 Jul 2004 10:05:23 -0700 (PDT) Subject: Re: CSV and alternative authentication techniques From: Douglas Otis To: Tony Finch Cc: Andrew Newton , MARID WG In-Reply-To: References: <1088632784.4998.1710.camel@ddev.mail-abuse.org> <1516519406.20040701212221@brandenburg.com> <1088714008.7961.23.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1088787922.7961.211.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 02 Jul 2004 10:05:22 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-07-02 at 03:32, Tony Finch wrote: > On Thu, 1 Jul 2004, Douglas Otis wrote: > > > > There are never two valid HELO domains of which to choose. The > > specification [RFC 3207] clearly states to discard previous results. > > OK. > > > The TLS session HELO/EHLO domain would be unimportant if > > the client was validated by a Certificate Authority and thereby > > recognized. If not, then the TLS session HELO domain should match. > > This isn't covered by RFC 3207 so needs to be explained by HNA. > > > > However there should probably be some comment in the CSA specification > > > about what the server does when the client says EHLO more than once. > > > > I feel this is not needed as it is covered in RFC3207. I would also > > like to limit the topic of TLS to a single document... Dave's of course. > > : ) > > Note that a client can say EHLO more than once in a non-TLS SMTP session. > Should the server only use the most recent one for CSV, or the first one? > (Using the first one is probably contrary to RFC 2821.) Do they have to be > all the same? You ask good questions. There could be the fall-back of EHLO to HELO and the use of EHLO to act as RSET. As the intent of this domain in each case (separate from the TSL issue) is to identify the client's host name, I would not expect this to change. However, there could be a valid reason it may change. To credit a portion of the mail stream to "client-xxx.big-provider.com." This may allow the receiver to accredit different entities for the mail stream without requiring a new connection. Using EHLO would be expensive and is why RSET is used to avoid this overhead. Perhaps there should be a mention that if the HELO/EHLO domain changes during a session, it should be re-evaluated. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 13:46:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22768 for ; Fri, 2 Jul 2004 13:46:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62HbriG073539; Fri, 2 Jul 2004 10:37:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62HbrRa073538; Fri, 2 Jul 2004 10:37:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62HbqF8073519 for ; Fri, 2 Jul 2004 10:37:53 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 8A15141491 for ; Fri, 2 Jul 2004 10:37:51 -0700 (PDT) Subject: CSV stake in the ground From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1088789795.8770.0.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 02 Jul 2004 10:37:51 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Rough consensus and working code... I would like to put additional resources into CSV. Should I be confident these documents will not dramatically change? It will become a much prolonged time line (and wasted effort) if this devolves into a debate how an SRV DNS record could be defined using a TXT record. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 14:38:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27484 for ; Fri, 2 Jul 2004 14:38:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62IMQ5q076768; Fri, 2 Jul 2004 11:22:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62IMQ7V076767; Fri, 2 Jul 2004 11:22:26 -0700 (PDT) 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 i62IMPWb076760 for ; Fri, 2 Jul 2004 11:22:25 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 02 Jul 2004 14:26:19 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2603427016; Fri, 02 Jul 2004 14:26:18 -0400 Message-ID: <004901c46061$94f47740$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "MARID" , "Douglas Otis" References: <1088789795.8770.0.camel@ddev.mail-abuse.org> Subject: Re: CSV stake in the ground Date: Fri, 2 Jul 2004 14:22:43 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit For what its worth, as CSV stands today, it is difficult to endorse it or warrant any further for product consideration or implementation for the following five (5) simple reasons: - Potentially high (unnecessary) SMTP redesign issues, - Has higher than required SMTP compatibility conflicts, - Potential customer acceptance (PR) issue regarding fee-based service bureaus, - Overall, the change vs. benefits offer no advantage over what SPF can not offer. and - You, nor Dave have never answered my comments/questions. I don't care about SRV vs. TXT, that's a DNS admin thing. But either way, I will be looking to optimize or minimize the total number of lookups. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Douglas Otis" To: "MARID" Sent: Friday, July 02, 2004 1:37 PM Subject: CSV stake in the ground > > Rough consensus and working code... > > I would like to put additional resources into CSV. Should I be > confident these documents will not dramatically change? It will become > a much prolonged time line (and wasted effort) if this devolves into a > debate how an SRV DNS record could be defined using a TXT record. > > -Doug > > > From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 14:38:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27538 for ; Fri, 2 Jul 2004 14:38:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62IVLMJ077919; Fri, 2 Jul 2004 11:31:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62IVLHA077918; Fri, 2 Jul 2004 11:31:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62IVLuN077910 for ; Fri, 2 Jul 2004 11:31:21 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 02 Jul 2004 14:31:23 -0400 id 0005C566.40E5A9FB.00007550 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <0417BB1A-CC56-11D8-BE33-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: MARID WG From: Andrew Newton Subject: consensus statement on CSV Date: Fri, 2 Jul 2004 14:31:21 -0400 X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Regarding the CSV proposal: 1) The co-chairs feel that most participants of the MARID working group understand that there are semantic and operational differences between the CSV proposal and the Sender-ID proposal. 2) The co-chairs observe that there is no working group consensus to incorporate CSV semantics into the Sender-ID proposal. 3) The co-chairs find that there is working group consensus to continue the work on CSV and it is their judgment that CSV work be addressed once Sender-ID is in working group last call. -andy From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 15:56:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03545 for ; Fri, 2 Jul 2004 15:56:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Jm0uh083423; Fri, 2 Jul 2004 12:48:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62Jm03l083422; Fri, 2 Jul 2004 12:48:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62JlxDM083416 for ; Fri, 2 Jul 2004 12:47:59 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 3A48641493; Fri, 2 Jul 2004 12:47:59 -0700 (PDT) Subject: Re: CSV stake in the ground From: Douglas Otis To: Hector Santos Cc: Dave Crocker , MARID In-Reply-To: <004901c46061$94f47740$6401a8c0@hdev1> References: <1088789795.8770.0.camel@ddev.mail-abuse.org> <004901c46061$94f47740$6401a8c0@hdev1> Content-Type: text/plain Message-Id: <1088797678.8871.82.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 02 Jul 2004 12:47:58 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-07-02 at 11:22, Hector Santos wrote: > For what its worth, as CSV stands today, it is difficult to endorse it or > warrant any further for product consideration or implementation for the > following five (5) simple reasons: > > - Potentially high (unnecessary) SMTP redesign issues, CSV is proximal to the current use of RBL. I do not envision serious design issues. The concerns raised are being addressed by Dave Crocker and John Leslie. You are right in that StartTLS, as used today, is not relevant, but to simply cover the topic of public or open authentication and authorization techniques, these methods were mentioned. You are right, more information is needed, and it will be forth coming. > - Has higher than required SMTP compatibility conflicts, CSV virtually leaves SMTP unchanged. CSV requires only careful placement in the SMTP session process of where the CSV checks are applied. CSV makes the least change to SMTP compared to other proposals. It does require the host name be valid, but I would not describe that as a major change. The intent of CSV is to remove reasons permitting this lapse in host name validation. SMTP requires the check, it just currently forgives an unsuccessful result. > - Potential customer acceptance (PR) issue regarding fee-based service > bureaus, Accreditation bureaus exist today and are responsible for preventing many more times that not seen than the amount that is seen. The cost of these services is highly dependent upon efforts needed to vet these accreditations. In addition, use of names is a positive alternative that will help those currently hampered using dynamically assigned addresses. That which remains is difficult to deal with on a per mailbox basis, but having an authorized and authenticated domain that provided access for such user may become a powerful tool for enforcement of criminal activity. Controlling access is the only means the mail system will improve. SPF does not impact that aspect of the problem at all. In fact, SPF can not assess the source of abuse, or accredit any provider for failing to ensure security. Only through accurate accreditation is this possible. If you do not use any accreditation service, you still benefit. Through third party assessment, providers learn of abuse and where security has been violated. Again, SPF offers little or no help in this area. Do not expect spammers to take very long to adapt to any SPF deterrent and likely find the means to totally defeat any SPF limitation that you wish to see imposed. > - Overall, the change vs. benefits offer no advantage over what SPF can not > offer. and SPF will always allow spammers to leverage any domain that publishes an "open" list, including their own domain. Those that publish such a list may find their addresses spoofed heavily and their DNS servers overwhelmed. Their reaction to this problem would be to either "close" the list or remove the SPF record entirely. Those that "close" their list may find their mail lost in transit, if it takes a path not published, perhaps through no fault of theirs. As SPF never holds a service provider accountable for their exercise of policy regarding security, SPF can not ensure even those that publish a "closed" list will stop seeing their mailbox spoofed. As SPF is very susceptible to DDoS, it may well be disabled, leaving victims a false impression based upon these defeated SPF assurances. Unlike CSV, SPF _DOES_ require extensive SMTP design changes. > - You, nor Dave have never answered my comments/questions. Remember, Dave is on vacation and much of your concerns addressed his document which he promised to update. Perhaps you could factor that in to your concerns. You have been prolific addressing your concerns and my understanding is that Dave has difficulty finding reasonable bandwidth to permit direct access to these lists. Give him a chance to respond via the update at least. > I don't care about SRV vs. TXT, that's a DNS admin thing. But either way, I > will be looking to optimize or minimize the total number of lookups. The TXT record examples often assumed additional lookups would be required by simply placing a free standing a in the TXT record. On the face of it, this may appear to be similar to the function of the SRV record, it is not however. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 18:50:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12796 for ; Fri, 2 Jul 2004 18:50:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62MaSnq099824; Fri, 2 Jul 2004 15:36:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62MaSA8099823; Fri, 2 Jul 2004 15:36:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62MaS9M099815 for ; Fri, 2 Jul 2004 15:36:28 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 02 Jul 2004 18:36:31 -0400 id 00058061.40E5E36F.00000B6D Mime-Version: 1.0 (Apple Message framework v618) Message-Id: <41F85406-CC78-11D8-BE33-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: MARID WG From: Andrew Newton Subject: Fwd: MARID use of reverse-DNS Date: Fri, 2 Jul 2004 18:36:28 -0400 X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i62MaS9M099818 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Paul Wilson and George Michaelson of APNIC sent us this note regarding the use of Reverse DNS for any MARID proposals. APNIC is one of the four Regional Internet Registries (RIR), the entities responsible for the management of IP address allocation and delegation and management of the Reverse DNS space. -andy Begin forwarded message: > From: Paul Wilson > Date: July 2, 2004 2:00:28 AM EDT > To: "Marshall T. Rose" , Andrew > Newton > Cc: George Michaelson > Subject: MARID use of reverse-DNS > > Marshall, Andy, > > We're emailing you as co-chairs of MARID to register the interest of > RIRs in any outcome from MARID which defines a role for reverse-DNS > records. > > As you will know, administrative management of reverse DNS delegations > vests in the RIRs, as a function of our overall role. We are both a > registration/maintenance entry point, and a provider of the operational > reverse DNS services related to address space under our management. > > We are aware of issues in the depth of coverage in reverse-DNS, in two > ways: > > Firstly, there is an ongoing 'lame' state for delegated address ranges > (of the order 20%) which we are now actively managing through a > (recently developed) lame DNS detection, reporting and cleanup process. > > Secondly, the participation rate in reverse-DNS is less than 100%, > varying by country, age of network, and maturity of regional/local > Internet/ISP coordination. > > These issues need to be considered within any MARID deployment > strategy, > and in your analysis of the deployment outcomes for SMTP or other email > delivery methods using reverse-DNS. > > The RIRs do have an interest in two or more domains of concern: > > 1) Operational Impacts > > If MARID relies on reverse-DNS, this will have implications for our > management of service, and the services we provide to our > members/customers to support their own use of the service. There will > be additional overheads for RIRs in terms of data management, and some > software development will certainly be required. > > In terms of the operational DNS service provision, our current platform > has been scaled progressively with growth in the absolute number of DNS > lookups, and the scaling function to date has been essentially linear. > > Should MARID require each SMTP transaction to perform a reverse-DNS > lookup, we would face an increased growth in traffic, in proportion to > the rate of in both packets and bytes/sec served, and probably need to > investigate changes to our deployment methodology in line with the root > servers, such as use of anycast DNS, and improvements in DNS zone > management to scale with the increased rate of change as the > non-delegated reverse spaces (and lame reverse spaces) scramble to > comply with SMTP delivery obligations. > > 2) Policy Impacts > > RIRs do not have an 'enforcement' role with respect to reverse-DNS, in > terms of “completeness” of records; however we do take an active role > (as mentioned above) to detect and correct certain specific cases of > correctness of the records. The specific extent of our authority may > need to be borne in mind in this standards development process. > > That said, the RIRs’ specific responsibilities and activities are the > result of community consideration and consensus. Any proposal to > substantially revise any responsibility or activity is normally taken > through an open policy process which can certainly accept such > initiatives, but which may take 3-12 months to complete. > > Therefore we suggest that you consider providing advance notice to RIR > communities of any future proposal, through informational presentations > at future meetings. In the case of APNIC, our next meeting will take > place in Fiji between 31 August and 4 September 2004, and you would be > welcome to take this opportunity to make such a presentation. > > George will be in San Diego for IETF-60, and interested to hear an > update on this. > > > Thanks. > > Paul Wilson > George Michaelson > APNIC > > > _______________________________________________________________________ > _ > Paul Wilson, Director-General, APNIC > > http://www.apnic.net ph/fx +61 7 3858 > 3100/99 > ----------------------------------------------------------------------- > - > See you at APNIC-18! Nadi, Fiji, 31 Aug - 3 Sep > 2004 From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 19:38:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14744 for ; Fri, 2 Jul 2004 19:38:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62NR9Nl004017; Fri, 2 Jul 2004 16:27:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62NR9pn004016; Fri, 2 Jul 2004 16:27:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62NR87l004007 for ; Fri, 2 Jul 2004 16:27:09 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BgXR1-00086I-Gq for ietf-mxcomp@imc.org; Sat, 03 Jul 2004 00:27:11 +0100 In-Reply-To: <41F85406-CC78-11D8-BE33-000A95B3BA44@hxr.us> Subject: Re: Fwd: MARID use of reverse-DNS To: ietf-mxcomp@imc.org From: "Jon Kyme" X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 68.120.225.168 Message-Id: Date: Sat, 03 Jul 2004 00:27:11 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Paul Wilson and George Michaelson of APNIC sent us this note regarding > the use of Reverse DNS for any MARID proposals. > Interesting perspective... Are the co-chairs canvassing the other RIRs ? From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 19:45:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15149 for ; Fri, 2 Jul 2004 19:45:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62NcW5Z004677; Fri, 2 Jul 2004 16:38:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62NcWo5004676; Fri, 2 Jul 2004 16:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62NcWLK004670 for ; Fri, 2 Jul 2004 16:38:32 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i62NcSl05835; Fri, 2 Jul 2004 16:38:29 -0700 Date: Fri, 2 Jul 2004 22:45:50 +0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1278665427.20040702224550@brandenburg.com> To: Greg Connor CC: IETF MARID WG Subject: Re: Differences between CSV and Sender-ID In-Reply-To: <29117638.1088739340@[10\.12\.1\.26]> References: <603278271.20040702123837@brandenburg.com> <29117638.1088739340@[10.12.1.26]> 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 Greg, GC> I'm not exactly pleased to see my post carved up, with a number of 1-3 line GC> responses added for every 1-3 lines I wrote. I feel it is a style that GC> encourages fighting, bickering, and disagreement rather than mutual GC> understanding and consensus-building. It is a well-established style, designed to cite precisely the text being responded to, in the style of a dialogue, and without carrying unnecessary baggage from the quoted message. It presumes that folks have access to the original, so it need not worry about the 'flow' of the message. In this case, I felt that responding to the details of your note was appropriate. GC> So, to be clear, I am suggesting that this assumption is not valid or GC> useful. I think the reputation of the MTA is often interesting, but GC> certainly not enough in itself to judge the quality of the mail. You might want to discuss that view with the substantial fraction of the anti-spam listing services that do not share your view. GC> But, GC> after reading your message I am starting to think that you don't believe GC> this assumption either, that there are only "good" and "bad" MTAs. Discussion will probably be more productive if we refrain from guessing each other's beliefs. GC> In that GC> case, this disagreement is not directed at you, but at other CSV supporters GC> (Matthew and Doug) who have been suggesting that checking HELO against a GC> reputation is pretty much all you need None of the CSV folk have made any statement like that. GC> and other proposals that check other GC> identities are worthless, doomed to failure, or both. None of the CSV folks have made any statement like that. GC> 1. I want to stop spam too, and I think stopping forgery is a necessary GC> but sufficient step. That has not been the typical view of SPF proponents. Nor does it have any objective, analytical basis. Spam does not require forging. Forging is simply a convenient hack, so it is used... for now. Spammers have shown an impressive degree of adaptability. Take away one convenient hack and they find others. >> GC> apparently-from and bouncing-to our own domains, a MAILFROM/PRA check >> is GC> going to be required. >> Some sort of rfc2822 author/sender accredition is going to be >> required... in some cases. GC> Agreed :) I hope you, and everyone else, understand that I said something significantly different from what you said. >> GC> Mechanically, CSV and SPF are both capable of checking HELO. >> >> Mechanically, CSV and SPF are both fruit. But let me tell you, you do >> not want to think about or use durian the same way you think about and >> use oranges. >> >> However, your statement highlights a deeper problem in most of the >> efforts to discuss CSV and SPF differences: Such efforts are almost >> entirely tied to mechanical and syntactic issues and do not focus on >> underlying concepts. GC> Right... That actuall IS what I mean here -- I mean to separate the GC> mechanics of each proposal from the underlying concepts. The assertion I GC> was trying to test is whether the mechanism SPF uses to test PRA, MAIL FROM GC> and HELO is capable of doing the same things the CSV mechanism does. Marshall Rose recently published an article about helicopers and submarines in an ACM periodical. If there is an online citation to it, I suggest you take a look at the point it makes. GC> Speaking only of the GC> *mechanism* I don't see that SRV records have an inherent advantage over GC> TXT records, or that the underlying concepts of CSV depend on SRV records. I think Douglas has been doing quite a good job of speaking to that point. A careful review of his postings on that matter might be helpful. >> CSV and SPF are fundamentally different pardigms. >> CSV vets an MTA's traffic. >> SPF vets an RFC2822 author/sender's message. >> >> SPF: >> Per-message MTA path validation, based on Author/Sender >> authorization and accreditations. >> CSV: >> MTA traffic validation, based on MTA operator authorization and >> accreditation. >> SPF vets an MTA's sending a single message. It accredits the MTA >> based on the RFC2822 author/sender. While introducing a >> path-dependency into the mechanism, it simply defers the hard >> question, namely accrediting the author/sender. >> CSV vets an entire MTA session. It accredits the MTA based on the >> operator of that MTA. GC> I don't really agree that CSV and SPF are fundamentally different GC> paradigms. Do you disagree with any of the summaries about the two that I list, above? If you do, then please explain. GC> I think of SPF not as a great idea, but as a collection of great ideas. Actually, what you then proceeded to describe was a bunch of mechanisms. What I am rather pointedly trying to do is conduct a discussion based on the concepts and information-theorectic aspects of the two services. GC> The point of this exercise is to separate the "mechanism" carrying the GC> message from the content and meaning of the message itself. That might be *your* goal, but *mine* is to make sure we all are in synch about the differences in the NATURE of the two services, before haggling over the details of the mechanisms. GC> I will note also that despite disparagement pointed at the "unknown" mode GC> of SPF, CSV also has a de-facto "unknown" mode - you can just choose not to GC> publish any records at all for that particular name. There is a significant difference in cost between doing no work, versus doing a bunch of administrative configuration and networking querying and analysis of the responses, only to produce an unknown. GC> I don't know why Matt and Doug chose to say over and over again how nasty GC> and yucky and vulnerable SPF is, Perhaps because they have some relevant operations experience with complex configurations and the deliterious effects of functional interactions for complex mechanisms. GC> citing this as a reason why CSV is cool GC> and wanted and necessary. Actually, I read their notes as saying two separate things. One is about the spiffiness of CSV. The other is criticism of SPF. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 20:07:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15719 for ; Fri, 2 Jul 2004 20:07:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62NqP3c005389; Fri, 2 Jul 2004 16:52:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62NqPWS005388; Fri, 2 Jul 2004 16:52:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62NqPpE005382 for ; Fri, 2 Jul 2004 16:52:25 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i62NqPl06790; Fri, 2 Jul 2004 16:52:26 -0700 Date: Sat, 3 Jul 2004 07:52:17 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <353504412.20040703075217@brandenburg.com> To: Andrew Newton CC: MARID WG Subject: Re: consensus statement on CSV In-Reply-To: <0417BB1A-CC56-11D8-BE33-000A95B3BA44@hxr.us> References: <0417BB1A-CC56-11D8-BE33-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew, AN> Regarding the CSV proposal: thanks! d/ ps. procedural question: are the chair comfortable with the CSV team's continuing to issue updates, in spite of CSV working group focus being deferred until marid-core is last-called? I ask this due the high likelihood that new versions will generate mailing list traffic. -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 20:16:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16039 for ; Fri, 2 Jul 2004 20:16:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6302ffG005892; Fri, 2 Jul 2004 17:02:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6302f8N005891; Fri, 2 Jul 2004 17:02:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6302exO005885 for ; Fri, 2 Jul 2004 17:02:40 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i6304dEs030154; Fri, 2 Jul 2004 17:04:39 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i6304d2e030151; Fri, 2 Jul 2004 17:04:39 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 2 Jul 2004 17:04:39 -0700 (PDT) From: "william(at)elan.net" To: Mark Lentczner cc: IETF MARID WG Subject: Re: Unified SPF IDs? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 2 Jul 2004, Mark Lentczner wrote: > There seems to be enough interest in exploring the Unified SPF concept > further that perhaps a formal ID is now warranted. Meng and I can > write this up if the working group would find it useful. > > In particular, this would be a re-factoring of the SPF syntax and > testing framework to embrace the various kinds of checks that have been > discussed on MARID (PTR, HELO, MAIL-FROM and PRA), in a way that is > compatible with the existing SPF classic deployment and consensus ideas > from this working group on Sender-ID. > > Thoughts? Do folks think it is time for Meng and I to do this work? Yes. (I doubt you'd be done in one weekend though, so I'd wish you happy holidays instead) -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 20:17:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16061 for ; Fri, 2 Jul 2004 20:17:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Nr3YG005418; Fri, 2 Jul 2004 16:53:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62Nr3Kh005417; Fri, 2 Jul 2004 16:53:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Nr2Cs005403 for ; Fri, 2 Jul 2004 16:53:02 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [66.80.0.5] (dhcp-5.danastreet.live.com [66.80.0.5]) by mail.glyphic.com (Postfix) with ESMTP id 6A55540D8 for ; Fri, 2 Jul 2004 16:53:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Mark Lentczner Subject: Unified SPF IDs? Date: Fri, 2 Jul 2004 16:53:00 -0700 X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit There seems to be enough interest in exploring the Unified SPF concept further that perhaps a formal ID is now warranted. Meng and I can write this up if the working group would find it useful. In particular, this would be a re-factoring of the SPF syntax and testing framework to embrace the various kinds of checks that have been discussed on MARID (PTR, HELO, MAIL-FROM and PRA), in a way that is compatible with the existing SPF classic deployment and consensus ideas from this working group on Sender-ID. Thoughts? Do folks think it is time for Meng and I to do this work? Long weekend coming up.... - Mark From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 20:18:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16096 for ; Fri, 2 Jul 2004 20:18:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Nwjkd005713; Fri, 2 Jul 2004 16:58:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62NwjGe005712; Fri, 2 Jul 2004 16:58:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62NwiSv005705 for ; Fri, 2 Jul 2004 16:58:44 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i6300hfY029603; Fri, 2 Jul 2004 17:00:43 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i6300h1g029600; Fri, 2 Jul 2004 17:00:43 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 2 Jul 2004 17:00:43 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: MARID WG Subject: Re: Fwd: MARID use of reverse-DNS In-Reply-To: <41F85406-CC78-11D8-BE33-000A95B3BA44@hxr.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've already commented that if RIRs consider it to much of an issue with adding new record into INADDR tree, we have an easy way out by checking some type of MARID record for corresponding PTR dns name. Currently major ISPs (like AOL) already require valid PTR record for connecting hosts and handling of PTR deligations is fairly well understood and documented by several RFCs. I've talked about this with Meng and he included the info into unified SPF framework/proposal (please write that one up that proposal in more clear text then just online presentation). The only issue I had is that unified SPF did not provide syntax to delimiter PTR-only authorization records from some other type of SPF record, which required identity scope modifier and I think that was proposed as type of macro (although that would only be of use for redirects, right?). I do additionally note on the identity scope issue that nunber of identies is likely to remain rather small. If you consider something other then macro and at the same time want to keep spf syntax small, then one modifier prefix symbol + one identify letter (i.e. two symbols) should be be enough to add this info and not require multiple dns lookups. For example, lets say $ is a prefix symbol and identity symbols are: m = envelope mail from, e = ehlo, p = ptr, s = submitter (rfc822 from) Then spf syntax to use them might be: v=spf2 $sm?a/24 $p+ip4:192.168.0.0/16 $e+ptr $p~all -all (note $sm means it applies to both submitter and mail from) Additionally I think scoping in general, might be usefull. Could use "<" and ">" for that (maybe something else...), so here is another example: v=spf2 $sm $p $e+ptr -all --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 20:35:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16849 for ; Fri, 2 Jul 2004 20:35:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i630PXX2006679; Fri, 2 Jul 2004 17:25:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i630PXMx006678; Fri, 2 Jul 2004 17:25:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i630PXRj006672 for ; Fri, 2 Jul 2004 17:25:33 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i630JpZ5006045; Fri, 2 Jul 2004 17:19:51 -0700 (PDT) In-Reply-To: <353504412.20040703075217@brandenburg.com> References: <0417BB1A-CC56-11D8-BE33-000A95B3BA44@hxr.us> <353504412.20040703075217@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Andrew Newton , MARID WG From: Marshall Rose Subject: Re: consensus statement on CSV Date: Fri, 2 Jul 2004 17:19:51 -0700 To: Dave Crocker X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 02, 2004, at 16:52, Dave Crocker wrote: > ps. procedural question: are the chair comfortable with the CSV > team's continuing to issue updates, in spite of CSV working group > focus being deferred until marid-core is last-called? I ask this due > the high likelihood that new versions will generate mailing list > traffic. i think it would be fine for the csv design team to continue to refine their specifications; however, in order to help the working group -- as a whole focus -- the co-chairs ask that csv-related emails be minimal on the mailing list for a few weeks. thanks! /mtr From owner-ietf-mxcomp@mail.imc.org Fri Jul 2 22:15:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20883 for ; Fri, 2 Jul 2004 22:15:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i631t9RD023130; Fri, 2 Jul 2004 18:55:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i631t9Lu023129; Fri, 2 Jul 2004 18:55:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i631t8nm023105 for ; Fri, 2 Jul 2004 18:55:08 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 02 Jul 2004 21:58:59 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2630587391; Fri, 02 Jul 2004 21:58:58 -0400 Message-ID: <001601c460a0$d2c13dd0$6401a8c0@hdev1> From: "Hector Santos" To: "Douglas Otis" Cc: "Dave Crocker" , "MARID" References: <1088789795.8770.0.camel@ddev.mail-abuse.org> <004901c46061$94f47740$6401a8c0@hdev1> <1088797678.8871.82.camel@ddev.mail-abuse.org> Subject: Re: CSV stake in the ground Date: Fri, 2 Jul 2004 21:55:29 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Doug, Dave, Your message is greatly appreciated. I would like to apologize to all, especially to Dave, for any impatience behavior exhibited by me. Just one clarification and one report of a very important news event that has occurred today directly related to CSV, and a follow up question related to the report. It may change or reinforce some decisions. Clarification: I am not against DNA. I'm a capitalistic vendor too. :-) I did understand your intent to allow this part of the process to be flexible and a "plug and play" concept including with RBL.. I was simply noting the major consideration as to how it is introduced into a commercial product line. One of many example issues related to customers will be marketing: "Great new ANTI-SPAM feature" with an asterisk footnote that says "Required batteries (DNA service) not included" etc. Report: I have a private address home DSL account with bellsouth.net, a large ISP, I would say. They used the current connection machine IP address to authorize "anonymous sender" (I can use any MAIL FROM: address) relay/route access. SMTP AUTH was not supported hurting legitimate roaming users. Their reason: It allowed users to share ID/passwords with friends or to spam from any machine. However, this didn't jive with the idea that the same account info is required for POP3 which can be used from any machine. (I know of no POP3 server that uses only an IP for access, do you?) As of July 13, Bellsouth.net will require all users to use SMTP AUTH to connect to their servers. . Part of their announcement is below. My question to you is this: I need to check this out more, i.e, are they still locking the IP and requiring SMTP AUTH as well, but assuming CSV was available today and it was a technology that Bellsouth.net was expose to and could implement, how would they use CVS in lieu of SMTP AUTH? Announcement from Bellsouth.Net: .... This spam fighting upgrade to the BellSouth e-mail service requires you to make a small change to your e-mail client by July 13, 2004. This change must be made to each account that uses your e-mail client program. These accounts include any account you have that ends in @bellsouth.net as well as accounts from other ISPs, such as yahoo.com, msn.com, etc. The change is: a.. Add additional validation to your existing e-mail account. Your e-mail service will also now require additional validation to promptly send your messages from the BellSouth network. We ask you to check the box in your e-mail properties that specifies ‘My server requires authentication’ and enter your e-mail account password in the appropriate field. ... This change applies to all customers who send their e-mail with an e-mail client through the BellSouth e-mail servers at mail.bellsouth.net. ... If you do not ensure this change by July 13, 2004, after that date, you will be asked to enter the account password each time you send an e-mail. These changes will be required in order to send e-mail with our enhanced protection. Thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Douglas Otis" To: "Hector Santos" Cc: "Dave Crocker" ; "MARID" Sent: Friday, July 02, 2004 3:47 PM Subject: Re: CSV stake in the ground > On Fri, 2004-07-02 at 11:22, Hector Santos wrote: > > For what its worth, as CSV stands today, it is difficult to endorse it or > > warrant any further for product consideration or implementation for the > > following five (5) simple reasons: > > > > - Potentially high (unnecessary) SMTP redesign issues, > > CSV is proximal to the current use of RBL. I do not envision serious > design issues. The concerns raised are being addressed by Dave Crocker > and John Leslie. You are right in that StartTLS, as used today, is not > relevant, but to simply cover the topic of public or open authentication > and authorization techniques, these methods were mentioned. You are > right, more information is needed, and it will be forth coming. > > > - Has higher than required SMTP compatibility conflicts, > > CSV virtually leaves SMTP unchanged. CSV requires only careful > placement in the SMTP session process of where the CSV checks are > applied. CSV makes the least change to SMTP compared to other > proposals. It does require the host name be valid, but I would not > describe that as a major change. The intent of CSV is to remove reasons > permitting this lapse in host name validation. SMTP requires the check, > it just currently forgives an unsuccessful result. > > > - Potential customer acceptance (PR) issue regarding fee-based service > > bureaus, > > Accreditation bureaus exist today and are responsible for preventing > many more times that not seen than the amount that is seen. The cost of > these services is highly dependent upon efforts needed to vet these > accreditations. In addition, use of names is a positive alternative > that will help those currently hampered using dynamically assigned > addresses. That which remains is difficult to deal with on a per > mailbox basis, but having an authorized and authenticated domain that > provided access for such user may become a powerful tool for enforcement > of criminal activity. Controlling access is the only means the mail > system will improve. SPF does not impact that aspect of the problem at > all. In fact, SPF can not assess the source of abuse, or accredit any > provider for failing to ensure security. Only through accurate > accreditation is this possible. > > If you do not use any accreditation service, you still benefit. Through > third party assessment, providers learn of abuse and where security has > been violated. Again, SPF offers little or no help in this area. Do > not expect spammers to take very long to adapt to any SPF deterrent and > likely find the means to totally defeat any SPF limitation that you wish > to see imposed. > > > - Overall, the change vs. benefits offer no advantage over what SPF can not > > offer. and > > SPF will always allow spammers to leverage any domain that publishes an > "open" list, including their own domain. Those that publish such a list > may find their addresses spoofed heavily and their DNS servers > overwhelmed. Their reaction to this problem would be to either "close" > the list or remove the SPF record entirely. Those that "close" their > list may find their mail lost in transit, if it takes a path not > published, perhaps through no fault of theirs. As SPF never holds a > service provider accountable for their exercise of policy regarding > security, SPF can not ensure even those that publish a "closed" list > will stop seeing their mailbox spoofed. As SPF is very susceptible to > DDoS, it may well be disabled, leaving victims a false impression based > upon these defeated SPF assurances. Unlike CSV, SPF _DOES_ require > extensive SMTP design changes. > > > - You, nor Dave have never answered my comments/questions. > > Remember, Dave is on vacation and much of your concerns addressed his > document which he promised to update. Perhaps you could factor that in > to your concerns. You have been prolific addressing your concerns and > my understanding is that Dave has difficulty finding reasonable > bandwidth to permit direct access to these lists. Give him a chance to > respond via the update at least. > > > I don't care about SRV vs. TXT, that's a DNS admin thing. But either way, I > > will be looking to optimize or minimize the total number of lookups. > > The TXT record examples often assumed additional lookups would be > required by simply placing a free standing a in the TXT record. On the > face of it, this may appear to be similar to the function of the SRV > record, it is not however. > > -Doug > > > > > From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 00:55:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27886 for ; Sat, 3 Jul 2004 00:55:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i634go77057891; Fri, 2 Jul 2004 21:42:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i634go8J057890; Fri, 2 Jul 2004 21:42:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i634gn8w057881 for ; Fri, 2 Jul 2004 21:42:49 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BgcMT-0003Cc-8c for ietf-mxcomp@imc.org; Fri, 02 Jul 2004 23:42:56 -0500 To: "IETF MARID WG" References: <6100752.1088590509@Ryoga.corp.sgi.com> <603278271.20040702123837@brandenburg.com> From: wayne Reply-To: "IETF MARID WG" Date: Fri, 02 Jul 2004 23:42:49 -0500 In-Reply-To: <603278271.20040702123837@brandenburg.com> (Dave Crocker's message of "Fri, 2 Jul 2004 12:38:37 +0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Differences between CSV and Sender-ID Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <603278271.20040702123837@brandenburg.com> Dave Crocker writes: > GC> Mechanically, CSV and SPF are both capable of checking HELO. > > Mechanically, CSV and SPF are both fruit. But let me tell you, you do > not want to think about or use durian the same way you think about and > use oranges. > > However, your statement highlights a deeper problem in most of the > efforts to discuss CSV and SPF differences: Such efforts are almost > entirely tied to mechanical and syntactic issues and do not focus on > underlying concepts. > > CSV and SPF are fundamentally different pardigms. > > CSV vets an MTA's traffic. > > SPF vets an RFC2822 author/sender's message. Dave: You appear to be confusing SPF with Sender-ID. SPF vets the 2821.FROM and the 2821.HELO. Sender-ID and Caller-ID vet the 2822.From:/Sender:/etc. I posted the following messages as a direct reply to address your confusion: http://www.imc.org/ietf-mxcomp/mail-archive/msg02494.html Your continued confusing of Sender-ID with SPF is as bad as if people confused your earlier proposals of DSAR/HNAA with CSV. Worse, it appears that your confusing is creating problems for others. Now, since SPF-classic (see link above) doesn't have anything to do with the 2822 information and *does* validate the HELO domain, most of your message is, at best, irrelevant. Granted, SPF-classic's validation of the HELO domain has not been cited as a key feature of SPF, so this confusion is a little more understandable. I did address it in this recent message: http://www.imc.org/ietf-mxcomp/mail-archive/msg02508.html -wayne From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 03:26:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18123 for ; Sat, 3 Jul 2004 03:26:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i637FXf8032771; Sat, 3 Jul 2004 00:15:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i637FXbr032770; Sat, 3 Jul 2004 00:15:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i637FWLZ032756 for ; Sat, 3 Jul 2004 00:15:32 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Sat, 03 Jul 2004 03:19:22 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2649809688; Sat, 03 Jul 2004 03:19:20 -0400 Message-ID: <003301c460cd$94d1b4f0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MARID WG" References: <6100752.1088590509@Ryoga.corp.sgi.com> <603278271.20040702123837@brandenburg.com> Subject: Re: Differences between CSV and Sender-ID Date: Sat, 3 Jul 2004 03:15:53 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "wayne" To: "IETF MARID WG" Sent: Saturday, July 03, 2004 12:42 AM Subject: Re: Differences between CSV and Sender-ID > Now, since SPF-classic (see link above) doesn't have anything to do > with the 2822 information and *does* validate the HELO domain, most of > your message is, at best, irrelevant. > > Granted, SPF-classic's validation of the HELO domain has not been > cited as a key feature of SPF, so this confusion is a little more > understandable. I did address it in this recent message: > http://www.imc.org/ietf-mxcomp/mail-archive/msg02508.html > I think you might be underestimating what SPF can do here to match the basic concept in CVS with one simple change. :-) It starts with this assertion: SPF HELO lookups results can only result in NONE, PASS or FAIL. It is not logical to have a SOFTFAIL or NEUTRAL. without breaking the "chain of trust" concept. Add this and you have the key fundamental premise of CSV - persistent domains. If you need me to explain this, I will. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 06:52:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24950 for ; Sat, 3 Jul 2004 06:52:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63ASAC6099273; Sat, 3 Jul 2004 03:28:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i63ASAnr099272; Sat, 3 Jul 2004 03:28:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63ASA5a099266 for ; Sat, 3 Jul 2004 03:28:10 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i63ASBK8014461 for ; Sat, 3 Jul 2004 03:28:11 -0700 Subject: Re: Differences between CSV and Sender-ID From: Douglas Otis To: IETF MARID WG In-Reply-To: References: <6100752.1088590509@Ryoga.corp.sgi.com> <603278271.20040702123837@brandenburg.com> Content-Type: text/plain Message-Id: <1088850491.2786.49.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 03 Jul 2004 03:28:11 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-07-02 at 21:42, wayne wrote: > In <603278271.20040702123837@brandenburg.com> Dave Crocker writes: > > > GC> Mechanically, CSV and SPF are both capable of checking HELO. > > > > Mechanically, CSV and SPF are both fruit. But let me tell you, you do > > not want to think about or use durian the same way you think about and > > use oranges. > > > > However, your statement highlights a deeper problem in most of the > > efforts to discuss CSV and SPF differences: Such efforts are almost > > entirely tied to mechanical and syntactic issues and do not focus on > > underlying concepts. > > > > CSV and SPF are fundamentally different pardigms. > > > > CSV vets an MTA's traffic. > > > > SPF vets an RFC2822 author/sender's message. > Dave: > > You appear to be confusing SPF with Sender-ID. SPF vets the 2821.FROM > and the 2821.HELO. Sender-ID and Caller-ID vet the > 2822.From:/Sender:/etc. > > I posted the following messages as a direct reply to address your > confusion: > http://www.imc.org/ietf-mxcomp/mail-archive/msg02494.html > > Your continued confusing of Sender-ID with SPF is as bad as if people > confused your earlier proposals of DSAR/HNAA with CSV. Worse, it > appears that your confusing is creating problems for others. I think much of this confusion comes from continuing reference to SPF+ which has yet to be defined. As such, there is no clear definition yet as to what SPF _currently_ checks, so your distinctions are only somewhat accurate, if at all. I agree that looking at the historical documents of what SPF _had_ been checking and what Sender-ID _is_ checking is different, but as Sender-ID _is_ the current incarnation of SPF, why are you making this distinction? Are you suggesting a desire to abandon Sender-ID? This is confusing. > Now, since SPF-classic (see link above) doesn't have anything to do > with the 2822 information and *does* validate the HELO domain, most of > your message is, at best, irrelevant. Here you are confused. The checking of the HELO domain by SPF-Classic does not provide the same results as obtained by CSV. Looking at the inputs and outputs alone fails to consider the _completely_ different dataset involved. There was wisdom in Sender-ID dropping this meaningless HELO check made by SPF-Classic. This continues to confuse many others as well. > Granted, SPF-classic's validation of the HELO domain has not been > cited as a key feature of SPF, so this confusion is a little more > understandable. I did address it in this recent message: > http://www.imc.org/ietf-mxcomp/mail-archive/msg02508.html The goal of CSV is to establish a _single_ accountable entity for the mail stream. the SPF-classic occasional validation of the HELO domain was only to see if _any_ entity was accountable. Even if this check is made every time, it still remains an entirely different (and meaningless) check. The goal of SPF/Sender-ID was to flag some concept of "from" as having been confirmed. The HELO domain provides a very nebulous reference for such confirmation, and thus the wisdom excluding this check. Reinstating this check would only continue this original muddle. CSV is, was, and remains entirely orthogonal to SPF/Sender-ID. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 09:13:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29980 for ; Sat, 3 Jul 2004 09:13:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63D5Lta010781; Sat, 3 Jul 2004 06:05:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i63D5LYe010780; Sat, 3 Jul 2004 06:05:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63D5ELa010771 for ; Sat, 3 Jul 2004 06:05:16 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3AFF617107 for ; Sat, 3 Jul 2004 09:12:11 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Fri, 02 Jul 2004 22:45:50 +0800." <1278665427.20040702224550@brandenburg.com> Date: Sat, 03 Jul 2004 09:12:11 -0400 Message-Id: <20040703131211.3AFF617107@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > Spam does not require forging. Forging is simply a convenient hack, > so it is used... for now. FYI, I have been in discussions with large financial 1institutions, who see forgery as a serious problem. Tracking down and/or stopping forged spam is a high priority for them, and will save them large amounts of money. They don't see forgery as a "convenient hack" for spammers, they see it as a direct and purposeful attack on their business. > Spammers have shown an impressive degree of adaptability. Take > away one convenient hack and they find others. The locks on my doors stop certain kinds of criminals. I know that they don't stop determined criminals, but I still use the locks. The locks stop the casual thieves, and more than pay for themselves. I know that there will probably always be spam, and that it's impossible to get rid of *all* of it. But calling a direct attack on someones name a "convenient hack" belittles other peoples problems and their attempts to deal with those problems. Spammers forge peoples names to gain false association with an established positive reputation, or to move the negative side-effects of spam onto third parties. Stopping forgery will have a direct positive effect on the reputation and administration costs of innocent bystanders. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 09:55:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01072 for ; Sat, 3 Jul 2004 09:55:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63Dm2Jh013415; Sat, 3 Jul 2004 06:48:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i63Dm2ZJ013414; Sat, 3 Jul 2004 06:48:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63Dm1YX013408 for ; Sat, 3 Jul 2004 06:48:01 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1Bgkrz-0007RG-D7 for ietf-mxcomp@imc.org; Sat, 03 Jul 2004 08:48:03 -0500 To: "IETF MARID WG" References: <6100752.1088590509@Ryoga.corp.sgi.com> <603278271.20040702123837@brandenburg.com> <1088850491.2786.49.camel@bash.adsl-64-142-13-68.sonic.net> From: wayne Reply-To: "IETF MARID WG" Date: Sat, 03 Jul 2004 08:47:55 -0500 In-Reply-To: <1088850491.2786.49.camel@bash.adsl-64-142-13-68.sonic.net> (Douglas Otis's message of "Sat, 03 Jul 2004 03:28:11 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Differences between CSV and Sender-ID Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <1088850491.2786.49.camel@bash.adsl-64-142-13-68.sonic.net> Douglas Otis writes: > On Fri, 2004-07-02 at 21:42, wayne wrote: > >> You appear to be confusing SPF with Sender-ID. SPF vets the 2821.FROM >> and the 2821.HELO. Sender-ID and Caller-ID vet the >> 2822.From:/Sender:/etc. >> >> I posted the following messages as a direct reply to address your >> confusion: >> http://www.imc.org/ietf-mxcomp/mail-archive/msg02494.html > > I think much of this confusion comes from continuing reference to SPF+ > which has yet to be defined. Your message is the only reference to "SPF+" I can find on this mailing list. Since you have apparently created the term "SPF+", please go ahead and define it. > As such, there is no clear definition yet > as to what SPF _currently_ checks, so your distinctions are only > somewhat accurate, if at all. I agree that looking at the historical > documents of what SPF _had_ been checking and what Sender-ID _is_ > checking is different, but as Sender-ID _is_ the current incarnation of > SPF, why are you making this distinction? Sender-ID is not SPF. That is why Sender-ID has a different name than SPF. There are no protocal police. There is nothing anyone can do to force people to use or not use either SPF or Sender-ID. There is certainly a large and growing number of people who continue to use SPF. There are also people who almost certainly start using Sender-ID once stable specs published (e.g. ones without XML requirements, etc.) As such, your reference to SPF in the past tense has no basis in reality. Similarly, your reference to people using Sender-ID in the present tense has no basis in reality. > Are you suggesting a desire > to abandon Sender-ID? This is confusing. I have made no such suggestion that I want to abandon Sender-ID. If the PRA algorithm works as well as claimed, I will add it to my SPF library and have it support both SPF and Sender-ID. >> Now, since SPF-classic (see link above) doesn't have anything to do >> with the 2822 information and *does* validate the HELO domain, most of >> your message is, at best, irrelevant. > > Here you are confused. [discussion of CSV vs SPF snipped] I have more to comment on this, but I'm afraid I'm already 5 minutes late leaving to pick up my kids, so I'll have to post it tonight. -wayne From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 10:36:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02390 for ; Sat, 3 Jul 2004 10:36:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63ERP6J014915; Sat, 3 Jul 2004 07:27:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i63ERPXn014914; Sat, 3 Jul 2004 07:27:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63ERMuZ014904 for ; Sat, 3 Jul 2004 07:27:24 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: MARID use of reverse-DNS MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Date: Sat, 3 Jul 2004 09:27:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA900@srv1.pan-am.ca> Thread-Topic: MARID use of reverse-DNS Thread-Index: AcRgh2Ux/ctRuF2OQdS2xkRjnha8kgAgcSxQ From: "Gordon Fecyk" To: "MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i63ERPuZ014908 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > 1) Operational Impacts > > > > If MARID relies on reverse-DNS, this will have implications for our > > management of service, and the services we provide to our > > members/customers to support their own use of the service. > > 2) Policy Impacts > > > > RIRs do not have an 'enforcement' role with respect to > > reverse-DNS, in terms of “completeness” of records; Sounds like APNIC would rather not bear the burden of our work. I seem to recall stating this rather bluntly back at IETF-59. Even so I get the impression that we've avoided (ab)using .arpa entirely in the current drafts. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 13:53:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08666 for ; Sat, 3 Jul 2004 13:53:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63HeaqF028070; Sat, 3 Jul 2004 10:40:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i63Hea5o028069; Sat, 3 Jul 2004 10:40:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63HeZ5j027993 for ; Sat, 3 Jul 2004 10:40:35 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id EEF301D651 for ; Sat, 3 Jul 2004 10:40:36 -0700 (PDT) Date: Sat, 03 Jul 2004 10:40:41 -0700 From: Greg Connor To: MARID WG Subject: Re: Fwd: MARID use of reverse-DNS Message-ID: <1503872.1088851241@[10.12.1.26]> In-Reply-To: <41F85406-CC78-11D8-BE33-000A95B3BA44@hxr.us> References: <41F85406-CC78-11D8-BE33-000A95B3BA44@hxr.us> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Andrew, thanks for posting that. >> From: Paul Wilson >> Subject: MARID use of reverse-DNS >> We are aware of issues in the depth of coverage in reverse-DNS, in two >> ways: >> >> Firstly, there is an ongoing 'lame' state for delegated address ranges >> (of the order 20%) which we are now actively managing through a >> (recently developed) lame DNS detection, reporting and cleanup process. >> >> Secondly, the participation rate in reverse-DNS is less than 100%, >> varying by country, age of network, and maturity of regional/local >> Internet/ISP coordination. I am really glad someone is aware of this and working on it. I don't think use of PTR will be core to MARID but lack of proper rDNS has plagued anti-spam efforts for quite some time >> 1) Operational Impacts ... >> Should MARID require each SMTP transaction to perform a reverse-DNS >> lookup, we would face an increased growth in traffic, in proportion to >> the rate of in both packets and bytes/sec served, and probably need to >> investigate changes to our deployment methodology in line with the root >> servers, such as use of anycast DNS, and improvements in DNS zone >> management to scale with the increased rate of change as the >> non-delegated reverse spaces (and lame reverse spaces) scramble to >> comply with SMTP delivery obligations. This concern kind of ignores that most MTAs already do a PTR lookup - Sendmail has had this in place for a long time. We probably won't make PTR a key component (at least I don't think it is a key component in any of the input proposals). Most of us are already aware of the poor support that many ISPs offer in terms of reverse lookups. SPF has a ptr: mechanism, so those who have proper PTR records set up might choose to use them instead of listing all their ranges. Speaking of scrambling to comply though, there is already pressure from other large ISPs on users with no PTR (or non-existent name in a PTR) to go cry to their ISP -- for example AOL has a published policy that they "may" deny service if your mailer has no PTR. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 19:30:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28213 for ; Sat, 3 Jul 2004 19:30:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63NGWmh043916; Sat, 3 Jul 2004 16:16:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i63NGWeu043915; Sat, 3 Jul 2004 16:16:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63NGWp2043909 for ; Sat, 3 Jul 2004 16:16:32 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i63NGKl13535; Sat, 3 Jul 2004 16:16:21 -0700 Date: Sun, 4 Jul 2004 07:16:08 +0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <191821464.20040704071608@brandenburg.com> To: Marshall Rose CC: Andrew Newton , MARID WG Subject: Re: consensus statement on CSV In-Reply-To: References: <0417BB1A-CC56-11D8-BE33-000A95B3BA44@hxr.us> <353504412.20040703075217@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Marshall, R> i think it would be fine for the csv design team to continue to refine MR> their specifications; however, in order to help the working group -- as MR> a whole focus -- the co-chairs ask that csv-related emails be minimal MR> on the mailing list for a few weeks. OK. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 19:30:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28242 for ; Sat, 3 Jul 2004 19:30:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63NFBG1043868; Sat, 3 Jul 2004 16:15:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i63NFBhx043867; Sat, 3 Jul 2004 16:15:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63NFA7M043861 for ; Sat, 3 Jul 2004 16:15:10 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i63NEgl13444; Sat, 3 Jul 2004 16:14:43 -0700 Date: Sat, 3 Jul 2004 11:46:35 +0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1511446799.20040703114635@brandenburg.com> To: "Hector Santos" CC: "MARID" Subject: Re: CSV stake in the ground In-Reply-To: <004901c46061$94f47740$6401a8c0@hdev1> References: <1088789795.8770.0.camel@ddev.mail-abuse.org> <004901c46061$94f47740$6401a8c0@hdev1> 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 Hector, HS> For what its worth, as CSV stands today, it is difficult to endorse it or HS> warrant any further for product consideration or implementation for the HS> following five (5) simple reasons: HS> - Potentially high (unnecessary) SMTP redesign issues, CSV does not require any redesign of SMTP. None. HS> - Has higher than required SMTP compatibility conflicts, CSV has no compatibility issues with SMTP. None. HS> - Potential customer acceptance (PR) issue regarding fee-based service HS> bureaus, I cannot seriously guess what you are talking about. It seems to have something to do with business models, but there is nothing about CSV that prefers or limits choice of business models. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 19:33:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28304 for ; Sat, 3 Jul 2004 19:33:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63NEuQp043849; Sat, 3 Jul 2004 16:14:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i63NEuhL043848; Sat, 3 Jul 2004 16:14:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63NEtsM043842 for ; Sat, 3 Jul 2004 16:14:55 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i63NEvl13452; Sat, 3 Jul 2004 16:14:58 -0700 Date: Sat, 3 Jul 2004 11:58:05 +0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1108666263.20040703115805@brandenburg.com> To: Douglas Otis CC: MARID WG Subject: Re: CSV and alternative authentication techniques In-Reply-To: <1088787922.7961.211.camel@ddev.mail-abuse.org> References: <1088632784.4998.1710.camel@ddev.mail-abuse.org> <1516519406.20040701212221@brandenburg.com> <1088714008.7961.23.camel@ddev.mail-abuse.org> <1088787922.7961.211.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas, My feeling is that CSV should simply say what to do with a HELO/EHLO but not say anything about larger, SMTP state transitions. That is: When the HELO contains a name, do CSV and apply the results to the session. (I'd rather not explicitly say to do it again if there is another HELO, since then we have to worry about interpretations of the SMTP state machine. If the rule just says what I wrote, above, then it is simple and rigorous and entirely covers the case of repeated HELO.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 19:44:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28792 for ; Sat, 3 Jul 2004 19:44:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63Nb112044531; Sat, 3 Jul 2004 16:37:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i63Nb1KD044530; Sat, 3 Jul 2004 16:37:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp105.mail.sc5.yahoo.com (smtp105.mail.sc5.yahoo.com [66.163.169.225]) by above.proper.com (8.12.11/8.12.9) with SMTP id i63Nb0CT044524 for ; Sat, 3 Jul 2004 16:37:01 -0700 (PDT) (envelope-from fletcherdunn@yahoo.com) Received: from unknown (HELO AME) (fletcherdunn@65.65.223.33 with login) by smtp105.mail.sc5.yahoo.com with SMTP; 3 Jul 2004 23:37:01 -0000 From: "Fletcher Dunn" To: Subject: Why DNS? Date: Sat, 3 Jul 2004 18:42:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Forgive me if this question is misplaced. I have been a student of spam and email for years, but I have never officially been involved in the dicsussion until now. Basically I am wondering why the "D" in MARID. To authenticate the sender, a recipient needs to obtain an official copy of the sender policy. One way to disseminate this information is through DNS. But using DNS is a significant complication in implemtation. (Does everybody implement TXT records properly? Isn't it sort of a kludge to paste together multiple TXT records to hold lengthy sender policies?). It's a factor delaying the adoption of a standard for sender authentication. If the sender policy basically boils down to an XML document, wouldn't wouldn't a simpler solution be for the sender to deliver the sender policy itself? Obviously I don't mean that the sender would deliver it along with the message - that certainly isn't secure, or optimal. The recipient would look up "responsible domain"'s MX record (again, depending on exactly what you want "responsible domain" to mean), and requests the sender policy from the domain's SMTP server, perhaps using a simple SMTP extension like SPOLICY This places no additional role or burden on DNS. It also more fairly distributes the extra communications load requires to maintain this information on those sending the most messages. All changes required to implement sender authentication are in one piece of software: the MTA. Again, forgive me if this idea is one that was considered and rejected long ago, I scanned the archives and didn't see the idea mentioned. - Fletcher Dunn From owner-ietf-mxcomp@mail.imc.org Sat Jul 3 23:23:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06714 for ; Sat, 3 Jul 2004 23:23:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i643B6C6054785; Sat, 3 Jul 2004 20:11:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i643B6M5054784; Sat, 3 Jul 2004 20:11:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nic.af ([65.162.19.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i643AqnG054740 for ; Sat, 3 Jul 2004 20:10:56 -0700 (PDT) (envelope-from stephane@laperouse.internatif.org) Received: by mail.nic.af (Postfix, from userid 10) id E2916FE113; Sun, 4 Jul 2004 07:40:43 +0430 (AFT) Received: by laperouse.internatif.org (Postfix, from userid 1000) id 89276DC82; Sat, 3 Jul 2004 22:23:26 +0430 (AFT) Date: Sat, 3 Jul 2004 22:23:25 +0430 From: Stephane Bortzmeyer To: ietf-mxcomp@imc.org Subject: Pejorative wording in draft-ietf-marid-rationale-00 Message-ID: <20040703175325.GA6273@laperouse.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Behind the curtains: an apology for Sender ID" mentions several times people who manage their own email server by calling them "hobbyists". This seems to imply that people who dare to send email themselves instead of relaying through their IAP server are not professionnals, probably bearded, penguin-lovers (Linux is mentioned, as if they were no MTA on FreeBSD or MS-Windows), and generally not really worthy of MARID's attention. The world of people who send email directly is much larger than the few students trying to learn Postfix. Many small organizations prefer to run a MTA, to avoid the performance penalty, and lack of accounting that comes from trusting the IAP mail server. I know that some IAP claim that no one in the future will send email directly (and some do forbid it, for instance by transparent proxies on port 25), but I hope MARID does not endorse that view. If so, I suggest to replace "hobbyists" by "managers of their own MTA". From owner-ietf-mxcomp@mail.imc.org Sun Jul 4 01:50:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11752 for ; Sun, 4 Jul 2004 01:50:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i645coZX074681; Sat, 3 Jul 2004 22:38:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i645coG3074680; Sat, 3 Jul 2004 22:38:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i645cniV074635 for ; Sat, 3 Jul 2004 22:38:49 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 8BF92132CF9; Sun, 4 Jul 2004 01:38:51 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 35773672; Sun, 4 Jul 2004 01:38:51 -0400 (EDT) Date: Sun, 4 Jul 2004 01:38:51 -0400 From: Meng Weng Wong To: Stephane Bortzmeyer Cc: ietf-mxcomp@imc.org Subject: Re: Pejorative wording in draft-ietf-marid-rationale-00 Message-ID: <20040704053851.GA16317@dumbo.pobox.com> References: <20040703175325.GA6273@laperouse.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040703175325.GA6273@laperouse.sources.org> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jul 03, 2004 at 10:23:25PM +0430, Stephane Bortzmeyer wrote: | | If so, I suggest to replace "hobbyists" by "managers of their own | MTA". | thank you for the comments, this has been done and will be shown in the next release of the rationale document. From owner-ietf-mxcomp@mail.imc.org Sun Jul 4 02:36:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26832 for ; Sun, 4 Jul 2004 02:36:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i646E5qB092570; Sat, 3 Jul 2004 23:14:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i646E5Ao092569; Sat, 3 Jul 2004 23:14:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i646E4cB092547 for ; Sat, 3 Jul 2004 23:14:04 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1Bh0GJ-0008U7-TH for ietf-mxcomp@imc.org; Sun, 04 Jul 2004 01:14:09 -0500 To: "IETF MARID WG" References: <6100752.1088590509@Ryoga.corp.sgi.com> <603278271.20040702123837@brandenburg.com> <1088850491.2786.49.camel@bash.adsl-64-142-13-68.sonic.net> From: wayne Reply-To: "IETF MARID WG" Date: Sun, 04 Jul 2004 01:14:03 -0500 In-Reply-To: (wayne@midwestcs.com's message of "Sat, 03 Jul 2004 08:47:55 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Differences between CSV and Sender-ID Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In wayne writes: >>> Now, since SPF-classic (see link above) doesn't have anything to do >>> with the 2822 information and *does* validate the HELO domain, most of >>> your message is, at best, irrelevant. >> >> Here you are confused. [discussion of CSV vs SPF snipped] > > I have more to comment on this, but I'm afraid I'm already 5 minutes > late leaving to pick up my kids, so I'll have to post it tonight. fyi; I wrote to Doug offlist because I realized that Andy and Marshall have requested that CSV discussions on the MARID list should be minimized. If anyone is interested in my reply, contact Doug or me. I don't consider the email private, just not in-scope for this list. -wayne From owner-ietf-mxcomp@mail.imc.org Sun Jul 4 03:33:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28564 for ; Sun, 4 Jul 2004 03:33:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i647GX0J014094; Sun, 4 Jul 2004 00:16:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i647GX2E014093; Sun, 4 Jul 2004 00:16:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i647GXE2014086 for ; Sun, 4 Jul 2004 00:16:33 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i647GOl13744; Sun, 4 Jul 2004 00:16:25 -0700 Date: Sun, 4 Jul 2004 14:15:57 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1313037133.20040704141557@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <20040703131211.3AFF617107@mail.nitros9.org> References: Your message of "Fri, 02 Jul 2004 22:45:50 +0800." <1278665427.20040702224550@brandenburg.com> <20040703131211.3AFF617107@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan, >> Spam does not require forging. Forging is simply a convenient hack, >> so it is used... for now. AD> FYI, I have been in discussions with large financial 1institutions, AD> who see forgery as a serious problem. I did not say that forgery is not a problem. I said that it is not essential to spamming. Get rid of forging and you will not reduce spamming at all. In any event, the forgery protection that financial institutions require is considerably stronger than the anti-spam forgery protection schemes being considered in this working group. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Sun Jul 4 04:19:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28589 for ; Sun, 4 Jul 2004 03:33:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i647HA8v014320; Sun, 4 Jul 2004 00:17:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i647HAnT014319; Sun, 4 Jul 2004 00:17:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i647H9oB014311 for ; Sun, 4 Jul 2004 00:17:09 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i647H6l13790; Sun, 4 Jul 2004 00:17:06 -0700 Date: Sun, 4 Jul 2004 14:11:47 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <983183059.20040704141147@brandenburg.com> To: Douglas Otis CC: IETF MARID WG Subject: Re: Differences between CSV and Sender-ID In-Reply-To: <1088850491.2786.49.camel@bash.adsl-64-142-13-68.sonic.net> References: <6100752.1088590509@Ryoga.corp.sgi.com> <603278271.20040702123837@brandenburg.com> <1088850491.2786.49.camel@bash.adsl-64-142-13-68.sonic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, (what follows does distinguish between Doug's comments and the ones he was responding to, just in case anyone wonders...) >> > SPF vets an RFC2822 author/sender's message. >> You appear to be confusing SPF with Sender-ID. SPF vets the 2821.FROM >> and the 2821.HELO. Sender-ID and Caller-ID vet the >> 2822.From:/Sender:/etc. >> >> I posted the following messages as a direct reply to address your >> confusion: >> http://www.imc.org/ietf-mxcomp/mail-archive/msg02494.html >> DO> I think much of this confusion comes from continuing reference to SPF+ DO> which has yet to be defined. My assessment was based on draft-ietf-marid-core. I don't care what acronym is used. I was fairly careful in the statement that is quoted at the beginning of this message, because it applies to all of the *SPF* and *-id proposals as they have been described. >> Now, since SPF-classic (see link above) doesn't have anything to do >> with the 2822 information and *does* validate the HELO domain, most of >> your message is, at best, irrelevant. SPF Classic has/had everything in the world to do with RFC2822 information, because it is the RFC2822.Sender that sets the RFC2821.MailFrom header. DO> The checking of the HELO domain by SPF-Classic DO> does not provide the same results as obtained by CSV. Looking at the DO> inputs and outputs alone fails to consider the _completely_ different DO> dataset involved. right. DO> The goal of CSV is to establish a _single_ accountable entity for the DO> mail stream. the SPF-classic occasional validation of the HELO domain DO> was only to see if _any_ entity was accountable. this is a rather interesting point that I had not previously appreciated. thanks! d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Sun Jul 4 06:21:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04420 for ; Sun, 4 Jul 2004 06:21:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i649ur16069637; Sun, 4 Jul 2004 02:56:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i649urP8069636; Sun, 4 Jul 2004 02:56:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i649uq55069622 for ; Sun, 4 Jul 2004 02:56:53 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Sun, 04 Jul 2004 06:00:45 -0400 Received: from ([65.2.60.5]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2745893313; Sun, 04 Jul 2004 06:00:44 -0400 Message-ID: <002b01c461ad$3d573b60$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" Cc: "MARID" References: <1088789795.8770.0.camel@ddev.mail-abuse.org> <004901c46061$94f47740$6401a8c0@hdev1> <1511446799.20040703114635@brandenburg.com> Subject: Re: CSV stake in the ground Date: Sun, 4 Jul 2004 05:56:53 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" To: "Hector Santos" Cc: "MARID" Sent: Friday, July 02, 2004 11:46 PM Subject: Re: CSV stake in the ground > HS> - Has higher than required SMTP compatibility conflicts, > HS> - Potentially high (unnecessary) SMTP redesign issues, > > CSV does not require any redesign of SMTP. None. > CSV has no compatibility issues with SMTP. None. Dave, I believe it all depends on what your team (and yourself) finally conclude on how CSV is going to behave. As it is stated now, you have many issues that make it problematic to implement. Do I need to outline them? > HS> - Potential customer acceptance (PR) issue regarding fee-based service > HS> bureaus, > > I cannot seriously guess what you are talking about. > It seems to have something to do with business models, but there is > nothing about CSV that prefers or limits choice of business models. Dave, I clarified I have no problem with this. But I am surprise to read you don't see the implications this has for commercial mail server product vendors, and quite probably, even more with non-commercial developers. This might all depend on the availability and type DNA services available. If its only going to be MAPS, we might want to get an arrangement with them to help promote it. But I would like to see more DNA services available before committing time, money and resources to CSV development. That would be just the few of the many other issues that will crop up. In short, CSV is not just a basic plug and play technical solution. Thanks for writing. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sun Jul 4 09:11:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11162 for ; Sun, 4 Jul 2004 09:11:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i64CrjKE086740; Sun, 4 Jul 2004 05:53:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i64CrjWO086739; Sun, 4 Jul 2004 05:53:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i64CrjOv086733 for ; Sun, 4 Jul 2004 05:53:45 -0700 (PDT) (envelope-from dhc2@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i64CrXl09501; Sun, 4 Jul 2004 05:53:34 -0700 Date: Sun, 4 Jul 2004 19:53:24 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <129796493.20040704195324@brandenburg.com> To: "Hector Santos" CC: "MARID" Subject: Re: CSV stake in the ground In-Reply-To: <002b01c461ad$3d573b60$6401a8c0@hdev1> References: <1088789795.8770.0.camel@ddev.mail-abuse.org> <004901c46061$94f47740$6401a8c0@hdev1> <1511446799.20040703114635@brandenburg.com> <002b01c461ad$3d573b60$6401a8c0@hdev1> 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 Hector, HS> As it is stated now, you have many HS> issues that make it problematic to implement. Do I need to outline them? yes. but not for several weeks, since the chairs have asked that CSV not be discussed right now. HS> n But I am surprise to read HS> you don't see the implications this has for commercial mail server product HS> vendors, I see the implications quite well. What I said was that CSV does not constrain the busines model choices. HS> But I would like to see more DNA services available before HS> committing time, money and resources to CSV development. One of the business decisions available is to wait for others to lead the market. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Sun Jul 4 19:39:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08023 for ; Sun, 4 Jul 2004 19:39:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i64NMLHq012068; Sun, 4 Jul 2004 16:22:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i64NMLeP012067; Sun, 4 Jul 2004 16:22:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i64NMLhA012061 for ; Sun, 4 Jul 2004 16:22:21 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i64NMOl24945 for ; Sun, 4 Jul 2004 16:22:24 -0700 Date: Mon, 5 Jul 2004 06:22:10 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1472853713.20040705062210@brandenburg.com> To: ietf-mxcomp@imc.org Subject: Comments on marid-submitter-01 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 Eric and Harry, The next version of mail-crocker-email-architecture includes the submitter construct. The sequence that led to your spec convinced me that there is a core construct we need to have be explicit in the email architecture. Comments on your draft's details: > Abstract > > The responsible submitter is the e- > mail address of the entity most recently responsible for introducing > a message into the transport stream. I find this to be a clear, concise definition and matches what I think it should cite. However, I think it worth asking whether anybody has any discomfort with it at all and if so, why? My reason for asking is that the definition needs to be bullet-proof against any sort of "reasonable" misinterpretation. > 1. Introduction > > The practice of falsifying the identity of the sender of an e-mail > message, commonly called "spoofing", is a prevalent tactic used by > senders of unsolicited commercial e-mail or "spam". A number of > proposals have been put forward to address the spoofing problem. > Notable among them are [RMX], [SPF], [LMAP] and [CALLERID]. This line of discussion invites useless debate, because those proposals generally are about RFC2821.MailFrom rather than RFC2822.Sender or its relations and they are about spam control rather than improving the ability of an SMTP session to have access to the purported sender information. Because this is intended as a very narrow specification, rather than either a pedagogical treatise or a broader effort to reduce spam, etc., that you have a simpler introduction that goes quickly to the requirement you want Submitter to satisfy. In general, a specification that compares itself with other specifications is inviting debate about reportorial accuracy, and other distractions to the technical focus. You do not have to have the comparisons, so I strongly suggest leaving them out. Rather, how about something roughly along the lines of: Email abuse has highlighted the need to improve identification of the "submitter", the entity responsible for injecting a message into the email transport stream. The email message object current uses an array of different headers for this identification. The current specification codifies rules for correctly determining the submitter and encoding that identification into an email transport session-time field. This will permit... In contrast, the following text: > Deriving the purported responsible domain from RFC 2821 data has the ... > Deriving the purported responsible domain from RFC 2822 headers has is evaluating technical options that feed directly into the design of this spec, so keeping the text IS useful to*directly* understanding the thinking behind this specification. > 4.1 Setting the SUBMITTER Parameter Value > > The purpose of the SUBMITTER parameter is to allow the SMTP client to > indicate to the server the purported responsible address of the > message directly in the RFC 2821 protocol. > > Therefore, SMTP clients that support the Responsible Submitter > extension SHOULD include the SUMBITTER parameter on all messages > where the purported responsible address, as defined in section 4 of > [SENDER-ID] differs from the MAIL FROM address. A matter of my own ietf style preference: The specification for determining Responsible Submitter strikes me as having much broader utility than just the marid-core specification. Although this might seem like nit-picking, I suggest you break it out into a separate document, so that it receives independent focus and so that it does not have to fate-share with other documents. Further, that then means there is not need for THIS specification to fate-share with marid-core. > > At some future time, it is likely that use of the SUBMITTER parameter > will be made MANDATORY whenever the purported responsible address > differs from the MAIL FROM address. In my opinion, this is a very bad bit of text to have. Specifications quite simply should not refer to the requirements of the future, because they are typically wrong, especially when they refer to social requirements rather than technical ones. Whether this is made mandatory depends upon the social aspects of its adoption, not on the technical aspects of its operation. You do not have to have this text in here, for the specification to be whole and useful, so take it out. > A common model will be for the Mail User Agent (MUA) to transmit a will -> could (submit is not yet in sufficient use to make the "will" certain, no matter how much we all might wish otherwise.) > 4.2 Processing the SUBMITTER Parameter I think this entire section is is the wrong document, so I suggest removing it. It makes this specification be a customer of the marid-core specification, rather than the reverse. This can (and I believe should) be a neat, clean, simple, direct specification for adding a bit of information into the SMTP control flow. Broader, bigger systems USES of this information ought to go into broader, bigger specifications that cite this specification, rather than having this specification cite them. Again, this is about setting up specification dependencies in a way that minimizes risk both of timing and distraction... > 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server > > When an MTA receives a message with a SUBMITTER parameter and must > forward it to another MTA that does not support the SUBMITTER > extension, the forwarding MTA MUST transmit the message without the > SUBMITTER parameter. This is a very big decision. I don't know whether I think it is right or wrong, so I'm flagging it, hoping the working group discusses it. It makes it easier to adopt, but greatly weakens its import. > 6. Security Considerations > > The purpose of this extension is to help deter the practice of > forging or "spoofing" the address of the sender of an e-mail message. Actually, the purpose of this extension is to move RFC2822 Sender-related identification into the email transfer control stream, to improve its use during transfers. All the rest is part of the broader, grander specification, elsewhere. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Sun Jul 4 22:51:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15343 for ; Sun, 4 Jul 2004 22:51:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i652Of9T047340; Sun, 4 Jul 2004 19:24:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i652OfDk047338; Sun, 4 Jul 2004 19:24:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i652OevJ047323; Sun, 4 Jul 2004 19:24:40 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i652Ogl04552; Sun, 4 Jul 2004 19:24:43 -0700 Date: Mon, 5 Jul 2004 09:24:29 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <202378805.20040705092429@brandenburg.com> To: ietf-smtp Subject: Revised draft-crocker-mail-arch 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 Folks, (ietf-mxcomp bcc'd, but discussion should be pursued on ietf-smtp mailing list.) I have submitted a new version of the Internet Mail Architecture I-D. You can access a version at: It has significant changes, notably including: > Actors: > Addition of the User/Relay/Provider construct of actors. Labeling of > these roles has also been added to the tables showing architectural > function. The distinction of Actors, versus architectural system > components, is not typical for discussions of email. Therefore it is > likely that the construct needs refinement. In particular, please > review the table assignments. > MDA/MS/MUA: > The construct of the Message Store has been added. This change is > intended to reflect the consensus view from online discussion, > rather than being the editor's view, which has in any event > changed... However it is likely that it will need significant > revision or replacement. Please review it carefully! > Message Identifiers: > Discussion of message identifiers has been added to the section on > Email Identities. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 01:35:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22837 for ; Mon, 5 Jul 2004 01:35:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6557t5V082992; Sun, 4 Jul 2004 22:07:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6557sVE082991; Sun, 4 Jul 2004 22:07:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nic.af ([65.162.19.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6557pid082912 for ; Sun, 4 Jul 2004 22:07:53 -0700 (PDT) (envelope-from stephane@laperouse.internatif.org) Received: by mail.nic.af (Postfix, from userid 10) id 02DC4FE11B; Mon, 5 Jul 2004 09:37:47 +0430 (AFT) Received: by laperouse.internatif.org (Postfix, from userid 1000) id 52815DC82; Mon, 5 Jul 2004 09:12:43 +0430 (AFT) Date: Mon, 5 Jul 2004 09:12:42 +0430 From: Stephane Bortzmeyer To: Fletcher Dunn Cc: ietf-mxcomp@imc.org Subject: Re: Why DNS? Message-ID: <20040705044242.GB13392@laperouse.sources.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jul 03, 2004 at 06:42:02PM -0500, Fletcher Dunn wrote a message of 33 lines which said: > and requests the sender policy from the domain's SMTP server, > perhaps using a simple SMTP extension like > > SPOLICY What if the sender is behind a relay (a sender with no permanent connectivity or a sender using UUCP or X400)? Remember that email does not require a end-to-end link with SMTP and this is one of its great strengths. Surely, the relay managers would not like to have to relay policies for their customers. From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 05:26:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16251 for ; Mon, 5 Jul 2004 05:26:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6592Ylk086496; Mon, 5 Jul 2004 02:02:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6592Ya4086495; Mon, 5 Jul 2004 02:02:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from brown.csi.cam.ac.uk (brown.csi.cam.ac.uk [131.111.8.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6592XJp086478 for ; Mon, 5 Jul 2004 02:02:34 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by brown.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BhPMX-0001CV-N2 for ietf-mxcomp@imc.org; Mon, 05 Jul 2004 10:02:09 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BhPMR-0006lu-Rf; Mon, 05 Jul 2004 10:02:03 +0100 Date: Mon, 5 Jul 2004 10:02:03 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Crocker cc: ietf-mxcomp@imc.org Subject: Re: Comments on marid-submitter-01 In-Reply-To: <1472853713.20040705062210@brandenburg.com> Message-ID: References: <1472853713.20040705062210@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 5 Jul 2004, Dave Crocker wrote: > > > 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server > > > > When an MTA receives a message with a SUBMITTER parameter and must > > forward it to another MTA that does not support the SUBMITTER > > extension, the forwarding MTA MUST transmit the message without the > > SUBMITTER parameter. > > This is a very big decision. I don't know whether I think it is right > or wrong, so I'm flagging it, hoping the working group discusses it. > It makes it easier to adopt, but greatly weakens its import. What are the alternatives? I note that as SUBMITTER is currently specified it is an optimisation to bring some post-DATA information into the pre-DATA envelope so that liars can be detected sooner. If a message passes through an MTA that doesn't support SUBMITTER the information can be recovered. (I wonder if SUBMITTER will be of any use in practice. Why should we expect a criminal to co-operate with optimizing our anti-forgery protocols?) I agree with Dave's other comments. Tony. -- f.a.n.finch http://dotat.at/ BERWICK ON TWEED TO WHITBY: NORTH OR NORTHWEST 3, BECOMES SOUTHEAST FOR A WHILE, THEN WEST OR NORTHWEST 3 OR 4 OVERNIGHT. SCATTERED SHOWERS. GOOD. SLIGHT. From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 07:56:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22281 for ; Mon, 5 Jul 2004 07:56:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65BY9NU017486; Mon, 5 Jul 2004 04:34:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i65BY9EI017485; Mon, 5 Jul 2004 04:34:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (news.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i65BY8ae017477 for ; Mon, 5 Jul 2004 04:34:09 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Mon, 05 Jul 2004 07:37:58 -0400 Received: from ([65.10.108.18]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2838125375; Mon, 05 Jul 2004 07:37:56 -0400 Message-ID: <006001c46283$fe6a8c90$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" Subject: Is MARID-SUBMITTER is really necessary? SPF can be used to solve this problem. Date: Mon, 5 Jul 2004 07:34:09 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I hope my input is considered 'reasonable' I just don't see the true usefulness of the submitter extension yet. SPF can solve all the three examples provided in the SUBMITTER proposal using a simple modification to the SPF lookup provisions by adding the "chain of trust" concept to it: Lets go thru each example which attempt to illustrate real basic mail forwarding problems that "SPF classic" currently suffers with. I hope to show that SUBMITTER offers no value or benefit against the major change requirements and show how a SPF can accomplish the same functionality SUBMITTER attempts to address. 5.2 Mail Forwarding: This problem has two separate MARID authentication concepts: Example: S: 220 alumni.almamater.edu ESMTP server ready C: HELO example.com S: 250 alumni.almamater.edu C: MAIL FROM: S: 250 sender ok C: RCPT TO: Using SPF: SPF(MAILFROM,IP) --> PASS This must be true in order to accept the final destination message, including to allowing the final result to be true as well. In this example, the final destination has a user defined mail forwarding address which the MDA turns around and sents it out: S: 220 woodgrove.example.com ESMTP server ready C: HELO alumni.almamater.edu S: 250 woodgrove.example.com C: MAIL FROM: S: 250 sender ok C: RCPT TO: S: 250 recipient ok The classic SPF issue result will be:: SPF(MAILFROM, IP) ---> FAIL or some non-pass SPF result because the IP no longer matches. However, this is solved using a SPF/MARID HELO provision to validate the the MARID compliant alumni.almamater.edu domain. Using SPF: SPF(MAILFROM, IP) => FAIL SPF(HELO, IP) => PASS This concept is fundamental to the chain of trust concept. It is impossible to have a valid overall SPF result with a failured SPF HELO result. It implies that the original receiver is NOT SPF compliant! 5.3 Mobil User The same issue applies here with this mobil user as well. Using a SPF/MARID HELO provision to validate the the MARID compliant consolidatedmessenger.net domain is all that is required. Example: IP address of consolidatedmessenger.net MTA S: 220 alumni.almamater.edu ESMTP server ready C: HELO consolidatedmessenger.net C: MAIL FROM: S: 250 sender ok C: RCPT TO: S: 250 recipient ok Using SPF: SPF(MAILFROM, IP) => FAIL SPF(HELO, IP) => PASS Again, this concept is fundamental to the chain of trust concept. It is impossible to have a valid overall SPF result with a failured SPF HELO result. 5.4 Guest E-mail Service Finally, the same applies here as well. Example: IP address of email.exemplarhotel.com MTA S: 220 alumni.almamater.edu ESMTP server ready C: HELO email.exemplarhotel.com S: 250 alumni.almamater.edu C: MAIL FROM: S: 250 sender ok C: RCPT TO: S: 250 recipient ok Using SPF: SPF(MAILFROM, IP) => FAIL SPF(HELO, IP) => PASS Again, this concept is fundamental to the chain of trust concept. It is impossible to have a valid overall SPF result with a failured SPF HELO result. In summary, I see no benefit to SUBMITTER. It has a high degree of SMTP change requires with no add-valued over what a simple modification to the SPF functional provisions on HELO lookup logic by including the concept of chain of trust. It provides the same result at the 2821 level with maximum capability (no SMTP change). I hope to be proven wrong with this because implementing submitter is going to be a major redesign cost with little guarantee of effectiveness and usefulness. Thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 08:01:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22446 for ; Mon, 5 Jul 2004 08:01:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65BpB7S018523; Mon, 5 Jul 2004 04:51:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i65BpBwa018522; Mon, 5 Jul 2004 04:51:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i65BpAnx018515 for ; Mon, 5 Jul 2004 04:51:10 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Mon, 05 Jul 2004 07:55:06 -0400 Received: from ([65.10.108.18]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2839153579; Mon, 05 Jul 2004 07:55:04 -0400 Message-ID: <007c01c46286$634fcb50$6401a8c0@hdev1> From: "Hector Santos" To: References: <1472853713.20040705062210@brandenburg.com> Subject: Re: Comments on marid-submitter-01 Date: Mon, 5 Jul 2004 07:49:21 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" To: Sent: Sunday, July 04, 2004 7:22 PM Subject: Comments on marid-submitter-01 > > 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server > > > > When an MTA receives a message with a SUBMITTER parameter and must > > forward it to another MTA that does not support the SUBMITTER > > extension, the forwarding MTA MUST transmit the message without the > > SUBMITTER parameter. > > This is a very big decision. I don't know whether I think it is right > or wrong, so I'm flagging it, hoping the working group discusses it. > It makes it easier to adopt, but greatly weakens its import. Well, the non-compliant SUBMITTER receiver will probably use CSV on the sender then :-) or use SPF with a simple HELO modification. So even if: SPF(sender-MAILFROM , ip) --> FAIL the HELO Lookup: SPF(sender-HELO, ip) --> PASS must be true if the sender is a compliant SPF/SUBMITTER client. After all, it has made extensive changes to SMTP in order to comform to it in the first place. The client domain used must be MARID ready if you want to keep the chain of trust unbroken. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 14:38:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10496 for ; Mon, 5 Jul 2004 14:38:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65IHNVe048009; Mon, 5 Jul 2004 11:17:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i65IHNF8048008; Mon, 5 Jul 2004 11:17:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65IHKlP047997 for ; Mon, 5 Jul 2004 11:17:23 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Is MARID-SUBMITTER is really necessary? Date: Mon, 5 Jul 2004 13:17:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA906@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Is MARID-SUBMITTER is really necessary? SPF can be used to solve this problem. Thread-Index: AcRih5f1T9xDIWKxTTOCE5usCD5xbgAM6/KA From: "Gordon Fecyk" To: "IETF-MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i65IHNlP048003 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > SPF(MAILFROM, IP) => FAIL > SPF(HELO, IP) => PASS This causes multiple lookups, adding to an already considerable overhead on DNS. DMP did this too, but I'd gladly not do that if the information in SUBMITTER is available. CSV avoids this completely by ignoring the mailfrom information and sticking with HELO, but it too requires a second lookup to a reputation providership. I also argue that a CSV-using mail server could set itself up as a reputation provider, much like a secure site can use a private CA certificate or a self-signed certificate. I believe in the interest of keeping total overhead down, especially DNS overhead, SUBMITTER is very important, and Resent-From: could be used in lieu if SUBMITTER (ie: on a non-ESMTP server). And the arguments against Resent-From don't wash with me either - if you're really worried about exact RFC2822 semantics, make it an x-header (such as X-MARID-Resent-From:). -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 14:50:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11088 for ; Mon, 5 Jul 2004 14:50:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65IYNFC049775; Mon, 5 Jul 2004 11:34:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i65IYN8F049774; Mon, 5 Jul 2004 11:34:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65IYKsF049768 for ; Mon, 5 Jul 2004 11:34:23 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3269517109 for ; Mon, 5 Jul 2004 14:41:19 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Sun, 04 Jul 2004 14:15:57 +0700." <1313037133.20040704141557@brandenburg.com> Date: Mon, 05 Jul 2004 14:41:19 -0400 Message-Id: <20040705184119.3269517109@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > I did not say that forgery is not a problem. > > I said that it is not essential to spamming. It is essential to a particular class of spam, as I mentioned in my previous message. I was trying to explain why broad statements about forgery and spam could be construed as belittling something that, for many, is a serious problem. > Get rid of forging and you will not reduce spamming at all. I've been saying that on ASRG for about a year. This isn't news. Prevention of forgeries will, however, reduce the impact of spam on innocent third parties. RBL's stop spam from one IP, but the spammer can just move, and spam again. Does this mean that RBL's are useless? Of course not. Similarly, MARID won't stop spam, but that doesn't mean it's addressing a trivial problem. I don't see weekly statements on anti-spam lists saying "RBL's won't stop spam", but I do see such statements about MARID. I don't know why, and I just don't get it. > In any event, the forgery protection that financial institutions > require is considerably stronger than the anti-spam forgery protection > schemes being considered in this working group. As I've been saying, MARID is a start, but not the end solution to spam. My comments were not intended to re-hash old issues. Rather, they were intended to point out that what for you seems like a "convenient hack" is for others, including myself, a direct and personal attack on our systems and reputation. I'm not trying to belittle your position. Rather, I'm trying to ensure that you don't belittle mine. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 18:59:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22157 for ; Mon, 5 Jul 2004 18:59:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65MThk8067434; Mon, 5 Jul 2004 15:29:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i65MTh9t067433; Mon, 5 Jul 2004 15:29:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by above.proper.com (8.12.11/8.12.9) with SMTP id i65MThlY067426 for ; Mon, 5 Jul 2004 15:29:43 -0700 (PDT) (envelope-from fletcherdunn@yahoo.com) Received: from unknown (HELO AME) (fletcherdunn@65.65.223.33 with login) by smtp018.mail.yahoo.com with SMTP; 5 Jul 2004 22:29:20 -0000 From: "Fletcher Dunn" To: "Stephane Bortzmeyer" Cc: Subject: RE: Why DNS? Date: Mon, 5 Jul 2004 17:34:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040705044242.GB13392@laperouse.sources.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >What if the sender is behind a relay (a sender with no permanent >connectivity or a sender using UUCP or X400)? Remember that email does >not require a end-to-end link with SMTP and this is one of its great >strengths. How does such a person *receive* email? Obviously, they must have *some* sort of permanent connection. So the answer to the above scenario is this: The sender policy for domain X is available at the server(s) where domain X receives email, i.e. the server(s) pointed to by the MX record for that domain. This is my suggestion in a nutshell. Since my original email was brief (and contained numerous typos! doh!), please let me state my case once more, in a bit more detail. Before I begin with the "why," let me include a simple example of how it would work, in case it isn't obvious: 1.) smtp.recipient.com receives an incoming mail and determines that the "responsible domain" is sender.com. 2.) smtp.recipient.com checks for a locally cached policy from sender.com and finds none. 3.) smtp.recipient.com looks up sender.com's MX record, and contacts sender.com at the SMTP port exactly as if he were going to send an email to sender.com. 4.) Using a new SMTP extension, smtp.recipient.com requests the sender policy for sender.com. ("SPOLICY sender.com" ??) 5.) sender.com's mail server replies with the sender policy. (Basically an XML document?) 6.) smtp.recipient.com consults the sender policy to take appropriate action regarding the incoming email. You'll notice that my suggestion only differs from current proposals in steps 2..5. Steps 1 and 6 are (tricky) steps that aren't unique to my suggestion. I'm not sure if there ever was a discussion of "MAR" outside the context "ID," or if was always assumed that DNS was the best way? Clearly, to authenticate the MTA, DNS will have an important role in the transaction between two unrelated parties - it serves as a mutually-trusted third party. But that doesn't mean it needs to actually *deliver* the authentication records, it only needs to authenticate them. Using DNS to deliver the policy is a hurdle toward widespread acceptance. Here are some advantages of storing the sender policy at the sender's mail server: 1.) It only requires changing one piece of software: the MTA. Assume for a moment that we use DNS TXT records to deliver the policy, and by a fortunate blessing all the DNS servers on the Internet implement the feature properly, even though it is a relatively obscure feature. Even if we assume this, it is still highly likely that there will be changes necessary for performance reasons. 2.) More importantly, using DNS requires the entire Internet to participate. By this I don't mean that all the mail servers must participate or that everybody must publish a sender policy - that's not the case with any sender authentication mechanism. I also don't mean that it couldn't function *at all* without everybody's participation - trial implementations already exist. What I mean is that the DNS of the entire Internet must work properly with these new features being proposed, if we're going to use DNS to distribute the policy *reliably* and *efficiently* with widespread use. This is a big hurdle. 3.) We've just increased our "minimum system requiremenets" for a DNS server on the Internet. Will current DNS servers require hardware upgrades to be able to store the extra information? (In addition to the software upgrades that will probably be necessary.) Are we suddenly going to require more DNS servers to be added to the infrastructure? In summary, if we use DNS to distribute MTA authentication records, it is likely that widespread use will create a need for significant software and/or hardware upgrades to be made to a large percentage (majority?) of the DNS servers on the Internet. Until these upgrades are made, any MARID system will malfunction in the worst case and function inefficiently in the best case. There are also philosophical problems with using DNS: 1.) Currently, DNS's primary role is to locate things. It's the map of the Internet, matching up names and IP's. Should we now task DNS with delivering a document related to a particular Internet application (mail)? Should we distribute an FTP server's list of mirror sites or policy for anonymous logins, or an HTTP server's policy for caching documents? Of course, those examples seem ludicrous - if we want to know that information, we get it directly from the server. The same applies to email - it's more appropriate for mail policy information to be distributed via the mail system. 2.) Any sender authentication mechanism will require some additional communications overhead for the recipient to obtain the sender policy. If we obtain the policy directly from the sender, then this extra burden is more "fairly" distributed. That is, it is more directly proportionately borne by those sending (and receiving) the most email - there is no extra overhead for those not involved in the transaction. Any sender authentication system will increase the "cost" of mail slightly, but my proposal increases the cost of *sending* a mail specifically. In contrast, using DNS to store the policy increases the burden on recipients more than it does on senders! (This is particularly interesting considering the anti-spam proposals suggesting that we all agree to *purposefuly* increase the cost of email - for example by requiring the sender to perform some unnecessay but time-consuming computation, or perhaps if we waited 10 seconds from the time we receive a mail connection until the time we process that mail connection. These proposals make an interesting contrast to discussions regarding how to avoid extra DNS checks in order to reduce the delay in processing a message.) 3.) DNS is a distributed database. For its current role as "map of the Internet", this distributed nature is necessary for reliability and performance. But for the role of delivering a sender policy, I don't see a distributed database as having any advantage over a non-distributed one. I don't need to broadcast my sender policy to everybody - the only people who need know my sender policy are those to whom I'm sending mail. It's not a matter of privacy, of course, just of simplicity and efficiency. Why spend the resources distributing and storing the information when most people aren't going to need it? When it comes to the information currently held in DNS, the answer to this question is, "We don't know in advance who will need what information, so we send everything to everybody (at the top level, at least)." But for the sender policy, this is not the case - we know exactly who will need the information, so there's no need for anybody else to burden themselves with this information when they don't need it. I realize that we aren't actually "broadcasting" our policy, with every server in the world storing the policy for every domain in the Internet. However, the general point remains that unrelated 3rd parties are unnecessarily involved in the distribution and storage of this information. All of the above is not to say that there aren't advantages of using DNS. The fundamental disadvantage of my proposal is that we are placing an additional burden upon senders to have this server up: 1.) What happens when the sender's mail server goes down? Mail can't be authenticated. (Assuming a cached policy isn't available.) However, this really isn't a huge problem, or even a new one. What if we wanted to reply to their mail and their mail server was down? We would retry a certain number of times and then fail. So the bottom line is, the new requirement on mail senders is this: if you want to send a mail, you must have a mail server pointed to by your MX record which can deliver the sender policy, and it must be functioning AT THE TIME YOU ARE SENDING THE EMAIL. This is admitedly a new and extra burden on mail senders. But it's certainly not an unreasonable one - in fact, it's one most senders already meet, since their receiving mail server will serve this purpose. (One sticky issue is: what should the exact behaviour of a recipient be who tries to obtain the sender policy but cannot because the sender's server is down? Reject the mail, and let the sender try again? Or maybe accept the mail temporarily, but not deliver it until the sender policy has been obtained and the mail verified? However, similar problems can arise if we use DNS, although presumably less frequently.) 2.) What about people with "unusual" relationships with the mail system, like people behind relays as pointed out by Stephane? First of all, there's never a question as to where the policy will be located - it's on the same server where you receive mail. So nobody who is capable of receiving mail is excluded from sending mail. However, the point is conceded that there is additional administrative overhead to make it work. If you have a relationship with a 3rd party to send/receive your email, then this 3rd party would need to provide you with some sort of mechanism to manage your policy for your domain. Yes, this is extra work for those involved in those situations. However, people in such "unusual" situations have extra complications in any sender-authentication system, since they need to authorize this 3rd party to send mail on their behalf. It's going to be more work for them to *create* their policy than it is going to be to *distribute* it. More importantly, if we use DNS, then almost *everybody* will have to communicate with a 3rd party in order to distribute their sender policy - their DNS nameservers. Thus my proposal would actually make it easier for most senders to publish their email policy versus publishing it in DNS. So, in summary: 1.) Basic argument against DNS: Using DNS to distribute the sender policy entails a significant complication to implementation. We place a burden on every DNS server in the Internet, both an immediate burden (upgrading software/hardware) and also an ongoing burden (carrying around sender policy records). 2.) Basic argument against my proposal: Senders will have extra requirements to meet, especially senders in "unusual" situations. My feeling is that #1 is a much stronger argument than #2. Again, please shoo me away politely if this idea has already considered and discarded, or if I should ask this question elsewhere. After all, if serious consideration were to be given to my proposal, I suppose it would require the name of the group to change! (Please point me to the discussion of "to DNS or not to DNS" - I'd be interested to hear the reasoning behind chosing DNS, or what the plan is to overcome the obstacles I've mentioned.) I really am a big fan of sender authentication. I was about 15 pages into a proposal for a public/private key system before Yahoo! announced DomainKeys. I really believe that sender authentication is necessary, in fact it is *urgently* needed. I disagree with those who say that it won't have an impact on spam - the main impact being the increased effectiveness of blacklisting and (perhaps more importantly) whitelisting. Anyway, I am a major fan of the "MAR" part of MARID. I'd hate to see any MARID proposal meet resistance from the Internet community once the complications in implementation of the "ID" part are fuly realized. - Fletcher Dunn From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 19:31:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23187 for ; Mon, 5 Jul 2004 19:31:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65NDrxK071432; Mon, 5 Jul 2004 16:13:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i65NDrWv071431; Mon, 5 Jul 2004 16:13:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65NDq8C071425 for ; Mon, 5 Jul 2004 16:13:53 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Forging (was Re: Differences between CSV and Sender-ID ) Date: Mon, 5 Jul 2004 18:13:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA909@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Forging (was Re: Differences between CSV and Sender-ID ) Thread-Index: AcRiwWVU6z+vo4wOSe+LnuYbD3WQsgAIRLhA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i65NDr8C071426 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Get rid of forging and you will not reduce spamming at all. > > I've been saying that on ASRG for about a year. This isn't news. > > RBL's stop spam from one IP, but the spammer can just move, and spam > again. Does this mean that RBL's are useless? Of course not. > Similarly, MARID won't stop spam, but that doesn't mean it's > addressing a trivial problem. I don't see weekly statements on > anti-spam lists saying "RBL's won't stop spam", but I do see such > statements about MARID. I don't know why, and I just don't get it. I get it. People seem to have this belief that anti-spam tools must fail from time to time, and any better anti-spam tool is going to do more harm than good: "The cure is worse than the disease." Totally false, but still so entrenched in most users' consciousness. And apparently some designers' consciousness, too. It's just as bad with anti-virus. People have it drilled into their heads by a clueless media, other clueless people, clueless sysadmins that anti-virus must fail sometimes. In fact people buy AV tools with failure _in mind._[1] I face this daily when I try to recommend Messagelabs' or Avecho's services - how can you beat a 100% virus detection guarantee? _DNSBLs are useless_ for stopping spam[2], and this is coming from someone who operates one! Baeysian filters are _equally useless._ I've said it before and I'll say it again: I'm here to obsolete the PDL and all projects like it. I'm not saying MARID is the cure to spam. It's a cure to forgery. As Alan pointed out, it's a start for before-the-fact anti-spam. And as I've pointed out before, it's the beginning of the end for unaccountable e-mail. [1] Side story: I've also ranted at length about how I have clients who don't use anti-virus software but don't get viruses, worms, trojans, spy ware, and a whole host of other net nasties. I'm talking about thousands of dollars a month in savings on cancelled AV subscriptions, reduced computer downtime, and reduced (if not eliminated) fear of net nasties. I must be crazy, yes? To conventional computer security thinkers I must be mad. Yet the proof is in the client list. [2] There, Alan! You've heard it: "RBLs won't stop spam." If you miss hearing that, I'll say it once a week in ASRG, here, SPAM-L, and wherever else you miss hearing it. :-) -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 21:28:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27769 for ; Mon, 5 Jul 2004 21:28:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i660sdLa077278; Mon, 5 Jul 2004 17:54:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i660sdKt077277; Mon, 5 Jul 2004 17:54:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i660sccX077269 for ; Mon, 5 Jul 2004 17:54:38 -0700 (PDT) (envelope-from madman@myeastside.com) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i660sfX5003393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 5 Jul 2004 17:54:42 -0700 Message-ID: <029301c462f3$d5308bc0$3201a8c0@rasta> From: "Harold A'Hole" To: References: Subject: Re: Why DNS? Date: Mon, 5 Jul 2004 17:54:46 -0700 Organization: http://madman.myeastside.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Using DNS to deliver the policy is a hurdle toward widespread acceptance. > Here are some advantages of storing the sender policy at the sender's mail > server: > > 1.) It only requires changing one piece of software: the MTA. Assume for a > moment that we use DNS TXT records to deliver the policy, and by a fortunate > blessing all the DNS servers on the Internet implement the feature properly, > even though it is a relatively obscure feature. Even if we assume this, it > is still highly likely that there will be changes necessary for performance > reasons. This is the crux of the problem from what I can see. I think finding DNS that can correctly deliver TXT responses will be substantially higher than you'll find MTAs that would support a new protocol exchange. For example, BIND supports TXT just fine, but SENDMAIL doesn't support such a protocol now. Therefore, this upgrade would take far longer to be adopted because it would require people change their MTA rather than add a DNS record. > 2.) More importantly, using DNS requires the entire Internet to participate. > By this I don't mean that all the mail servers must participate or that > everybody must publish a sender policy - that's not the case with any sender > authentication mechanism. I also don't mean that it couldn't function *at > all* without everybody's participation - trial implementations already > exist. What I mean is that the DNS of the entire Internet must work > properly with these new features being proposed, if we're going to use DNS > to distribute the policy *reliably* and *efficiently* with widespread use. > This is a big hurdle. Second, this doesn't seem to be the case. In order to the MTA solution to work, the receiving system already has to consult DNS to retrieve the MX records. But then it not only has to retrieve the MX records, but it has to contact the MTAs behind those addresses. With a DNS-only solution using TXT, only the DNS must be consulted, but instead of returning MX, it returns TXT, and there's no overhead of going to an MTA to do yet another protocol exchange. > 3.) We've just increased our "minimum system requiremenets" for a DNS server > on the Internet. Will current DNS servers require hardware upgrades to be > able to store the extra information? (In addition to the software upgrades > that will probably be necessary.) Are we suddenly going to require more DNS > servers to be added to the infrastructure? Is that even a reasonable assumption? It would be interesting to note how much extra capacity a DNS system would need. We host only a few main domains (perhaps 20), with each having perhaps 5-10 subdomains. Adding the 20 TXT records was not much of an issue, and as I said before, the processing overhead shouldn't be much different since the query for the TXT is simply exchanged for the query for the MX. > 1.) Currently, DNS's primary role is to locate things. It's the map of the > Internet, matching up names and IP's. Should we now task DNS with > delivering a document related to a particular Internet application (mail)? > Should we distribute an FTP server's list of mirror sites or policy for > anonymous logins, or an HTTP server's policy for caching documents? Of > course, those examples seem ludicrous - if we want to know that information, > we get it directly from the server. The same applies to email - it's more > appropriate for mail policy information to be distributed via the mail > system. This philosophical question seems more to the point for me. Why should DNS have to return SMTP authentication info. Will others start to abuse DNS for their various needs? Of course, DNS already has a specialty task for email as it contains MX records. It doesn't have specialty records for HTTP or FTP today. Perhaps email is just that special!? > proposal increases the cost of *sending* a mail specifically. In contrast, > using DNS to store the policy increases the burden on recipients more than > it does on senders! This doesn't seem true to me since the TXT record had to be queried from DNS in one scenario, or the MX records from DNS in the other. > storing the policy for every domain in the Internet. However, the general > point remains that unrelated 3rd parties are unnecessarily involved in the > distribution and storage of this information. Third parties typically only store them according to their caching policies, and the MTA solution would also have a caching policy, so the it's got to be cached someplace. Why have DNS cache the MX records and the MTA cache the policies if there's a way to do it with just the TXT record being cached by DNS and the parsed TXT being cached by the MTA? > 1.) Basic argument against DNS: Using DNS to distribute the sender policy > entails a significant complication to implementation. We place a burden on > every DNS server in the Internet, both an immediate burden (upgrading > software/hardware) and also an ongoing burden (carrying around sender policy > records). > 2.) Basic argument against my proposal: Senders will have extra requirements > to meet, especially senders in "unusual" situations. > > My feeling is that #1 is a much stronger argument than #2. My basic argument against would be that it requires software changes on the MTA to function. The DNS TXT change allows you to participate by publishing your policy before you actually change the MTAs to enforce them. So, if you don't care about receiving and checking policies, you don't have to, but others can begin to check your policy without your having to install upgraded MTA software. Other than that, I see no real problem. I believe that a pure MTA solution would have been preferable beacuse I agree that using TXT is a kludge. The long term solution, assuming this sender-id change actually has positive benefits of reducing spam, is to create something like you suggest since it doesn't mess with DNS. I do see more attacks against DNS coming, more spams directed at MTAs that don't implement the receiving side of sender-id so they bounce like before back to the invalid sender, more spam blasts from ephemeral systems and more hijacked accounts on outbound SMTP servers so sender-id passes checking. Harold From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 21:49:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28552 for ; Mon, 5 Jul 2004 21:49:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i661OKwg079223; Mon, 5 Jul 2004 18:24:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i661OKD2079222; Mon, 5 Jul 2004 18:24:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (news.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i661OJIZ079215 for ; Mon, 5 Jul 2004 18:24:19 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Mon, 05 Jul 2004 21:28:18 -0400 Received: from ([65.10.108.18]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2887945610; Mon, 05 Jul 2004 21:28:16 -0400 Message-ID: <004b01c462f7$ff5744d0$6401a8c0@hdev1> From: "Hector Santos" To: "Gordon Fecyk" , "IETF-MXCOMP" References: <700EEF5641B7E247AC1C9B82C05D125DA906@srv1.pan-am.ca> Subject: Re: Is MARID-SUBMITTER is really necessary? Date: Mon, 5 Jul 2004 21:24:31 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Gordon Fecyk" To: "IETF-MXCOMP" Sent: Monday, July 05, 2004 2:17 PM Subject: RE: Is MARID-SUBMITTER is really necessary? > > > SPF(MAILFROM, IP) => FAIL > > SPF(HELO, IP) => PASS > > This causes multiple lookups, adding to an already considerable > overhead on DNS. DMP did this too, but I'd gladly not do that > if the information in SUBMITTER is available. And if it is not? And the reason why you should believe it if it was? and the reason why I should accept this? IP address in AOL network HELO santronics.com MAIL FROM : jqp@aol.com > I believe in the interest of keeping total overhead down, especially DNS > overhead, There has not been many others as vocal as I have been promoting optimization and overhead deduction implementation insights. It won't take an implementation long to see this. But you first need to have a sound concept in place before any ideas of optimization can even apply. You must look at the total picture first to see what are the forcing functions, what are all the factors that can be disseminated. From a SysAdmin perspective I can see why you might think it helps - it doesn't make any sense from a technical implementation perspective. First you have to ask the question: Does it make logical sense? It is possible to have a compliant return path domain with a non-compliant client domain? Second, you need to ask who does it address? The simple fact is that the majority of the frontal attack will be spam or spoofed is ignored. The LMAP designs (and MARID) uses an open ended lookup approach with a total disregard that the majority of the lookups will fail anyway. It also ignores another important parameter - RCPT TO: I mean, just consider that the need to answer the above rhetorical questions could be avoided if the transaction was this: IP address in AOL network HELO santronics.com MAIL FROM : jqp@aol.com RCPT TO: baduser@santronics.com For a SYSTEM that checks RCPT TO: first - no DNS overhead For a SYSTEM that ignores RCPT TO: DMP - 2 or more looks SPF - 1 lookup CVS - 3 lookups Third, does it require change? how much? Forth, similarly, does it promote change? For whom? and to what benefit? Using SUBMITTER adds a high cost to changing software. Using SUBMITTER requires a high degree of compatibility. All of which offers no added-weight or trust in the result. Even the specs indicates there is a lack of real trust. So why bother? The cost of redesign is HIGH and it won't even work well. And why should a spammer commit resources to support this? The odds are very high he won't - he can't (or wont') even fix his broken bulk mail blasters that don't even handle multiple response lines. No matter what you will need to introduce a minimum three (3) tier system: SENDER RECEIVER 3rd party Reputation system. or SENDER RECEIVER 3rd party Accreditation system. 3rd party Accreditation Reputation system. My suggestion is to take a better look at SPF with a HELO and "chain of trust" perspective. Get the proof of concept worked out first and fold in the overhead reduction concepts. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 23:08:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01332 for ; Mon, 5 Jul 2004 23:08:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i662iZ0D084887; Mon, 5 Jul 2004 19:44:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i662iZko084886; Mon, 5 Jul 2004 19:44:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i662iYBv084879 for ; Mon, 5 Jul 2004 19:44:35 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: [correction] RE: Is MARID-SUBMITTER is really necessary? Date: Mon, 5 Jul 2004 21:44:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA90C@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Is MARID-SUBMITTER is really necessary? Thread-Index: AcRi9/s5WQxGqruqREmPE1BOh5/7FQACb0/wAABeUKA= From: "Gordon Fecyk" To: "IETF-MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i662iZBv084881 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > This causes multiple lookups, adding to an already considerable > > > overhead on DNS. DMP did this too, but I'd gladly not do that > > > if the information in SUBMITTER is available. > > > > And if it is not? > > That's what Received-From: is for. Excuse me, I meant "Resent-From:". -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Mon Jul 5 23:10:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01432 for ; Mon, 5 Jul 2004 23:10:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i662hjNN084855; Mon, 5 Jul 2004 19:43:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i662hj3I084854; Mon, 5 Jul 2004 19:43:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i662hiDP084848 for ; Mon, 5 Jul 2004 19:43:44 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Is MARID-SUBMITTER is really necessary? Date: Mon, 5 Jul 2004 21:43:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA90B@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Is MARID-SUBMITTER is really necessary? Thread-Index: AcRi9/s5WQxGqruqREmPE1BOh5/7FQACb0/w From: "Gordon Fecyk" To: "IETF-MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i662hiDP084849 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > This causes multiple lookups, adding to an already considerable > > overhead on DNS. DMP did this too, but I'd gladly not do that > > if the information in SUBMITTER is available. > > And if it is not? That's what Received-From: is for. > The LMAP > designs (and MARID) uses an open ended lookup approach with a total > disregard that the majority of the lookups will fail anyway. Unless you can somehow force all domains handling mail to deploy such a solution immediately, you're going to get a majority of failures to begin with. This was hammered to death yonks ago. > It also > ignores another important parameter - RCPT TO: Where does this enter into it? Unless you're talking to a relay server (which you can just AUTH / SUBMIT against to bypass MARID anyway - and be audited in that fashion) or a forwarding server (which is going to provide SUBMITTER or Resent-From:) I think we can safely assume the recipient specified here is on the machine you're issuing this command to, anyway. > Using SUBMITTER adds a high cost to changing software. We have to do this anyway if we're asking sites to use MARID or a MARID-like protocol. And unless you know these costs you can't tell me it's less expensive to implement SPF in Sendmail, for example, than CSV or Sender-ID or DomainKeys or MARID-Core or MARID-Submitter. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Tue Jul 6 11:19:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22596 for ; Tue, 6 Jul 2004 11:19:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66EsPFk044870; Tue, 6 Jul 2004 07:54:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i66EsP0H044869; Tue, 6 Jul 2004 07:54:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i66EsPeT044855 for ; Tue, 6 Jul 2004 07:54:25 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [192.168.0.2] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 1B6A06027E for ; Tue, 6 Jul 2004 09:54:25 -0500 (CDT) Message-ID: <40EABCEC.9010300@ehsco.com> Date: Tue, 06 Jul 2004 10:53:32 -0400 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) References: <20040705184119.3269517109@mail.nitros9.org> In-Reply-To: <20040705184119.3269517109@mail.nitros9.org> 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 7/5/2004 2:41 PM, Alan DeKok wrote: > Dave Crocker wrote: > >>I did not say that forgery is not a problem. >> >>I said that it is not essential to spamming. > > It is essential to a particular class of spam, as I mentioned in my > previous message. There are a lot of tools that only stop spam on an incidental basis, but are really only useful because of that incidental benefit. Think RFC2821 syntax checks, greylisting, callback systems, etc., all of which are designed to probe implementation weaknesses instead of "block spam", but which happen to achieve that goal anyway. MARID would be the similar. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Tue Jul 6 21:44:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10770 for ; Tue, 6 Jul 2004 21:44:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i671VgkN045407; Tue, 6 Jul 2004 18:31:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i671VgZT045406; Tue, 6 Jul 2004 18:31:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i671VgDg045399 for ; Tue, 6 Jul 2004 18:31:42 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 79B82414EE for ; Tue, 6 Jul 2004 18:31:43 -0700 (PDT) Subject: Re: draft-ietf-marid-rationale-00.txt From: Douglas Otis To: MARID Content-Type: text/plain; charset=iso-8859-13 Message-Id: <1089163902.20711.150.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 06 Jul 2004 18:31:42 -0700 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit There are a few areas in this review that differs, if considering the channel versus the message. As this is a general overview for MARID, it should be more comprehensive. The intent is to focus upon claims made for Sender-ID. Page 4: In a designated sender scheme, the question becomes: "is the SMTP client of an incoming message authorized by the purported sender of that message to send the message?" The primary identity is the sender of the message --- the (administratively independent) entity responsible for the most recent injection of the message into the mailstream. Sender-ID assessment is weak and dependent upon checks made at undefined administrative boundaries. Even with full compliance, there are many areas where identification of the sender remains suspect. In addition, the ability of an administrative domain to "usurp" permissions as with list servers, or messages that originate from an "open" domain still places the burden upon the recipient to sort through these representations. Nor does Sender-ID curtail the volume of this sorting task. Should a domain offer other domains permission to originate their mail due to their use as an access provider or other related services, then this public announcement offers a means to spoof, especially when 70% of these providers do not authenticate users on their networks. Note that designated sender schemes are generally better suited to identifying senders and cryptographic schemes are better suited to identifying authorship. The "sender domain" is not always identified by the designated sender scheme. The sender domain may enable indirect authentication of other domains or leave their accountability "open" as a means to allow remote users continued use of their return address. Identification of the domain of the senders may remain indeterminate and yet be compliant with the designated sender scheme. This greatly erodes accountability, closing avenues of curtailing rogue abuse. In the case of the "open" list, this identification includes the entire Internet. This statement also leaves out the non-cryptographic method of identifying the sender (where the sender is the sending SMTP client). Page 5: Zombies versus hobbyists: A - A majority of spam today originates from end-user machines infected by viruses that send spam directly to receivers' MX servers. Such zombies should no longer be able to send direct-to-mx spam. B - Linux hobbyists should still be able to send mail from their consumer-grade broadband connections. They may have no control over the PTR records of their assigned IP addresses, but the concept of first-class and second-class citizenship rankles many idealists who believe in an unfettered end-to-end model of pure IP connectivity. Any user would be able to employ a simple mechanism that relies upon forward DNS queries. There are many offering name servers that handle dynamic IP addresses, where support for this type of name service is often included in low cost network address translators common for home use. B, in this case, is in error. In addition, many providers are offering this dynamic address name service free of charge as a means to promote other services. This would work equally well for users on static addresses. A simple forward reference allows a change from the paradigm of rejecting senders from dynamic IP addresses as a means to curtail infected systems. Stopping a virus is not a property of Sender-ID however. Page 7: Nipping the innocent in the bud: A - Spam should be stopped before it starts; to limit the cost of a spam attack, receivers should by default adopt a skeptical stance to any unknown input. In big cities, people don't talk to strangers. B - In small towns, people smile at strangers. Senders should be assumed innocent until proven guilty. Any person should be able to get onto the Internet, register a domain, and immediately email a hundred of his closest friends. This misses the possibility of allowing all sending domains (not messages) to identify themselves and thus prevent abuse before even a message is started. With a simple forward query, every sender dons a name tag. Unlike the current system of just depending upon IP addresses for vetting a connection, an authorized and authenticated name means the receiving server will know the name of the stranger allowing a determination as to whether they are new to the system. Sender-ID will always leave the door open and allow strangers to assume the identity of any domain enabling remote access. DNS: Caching versus parsing. A - To reduce the burden on clients, records should be easily cached. Records that describe the full set of designated senders up front are easily cached and require no subsequent lookups. However, such records require parsing. B - To reduce the burden on clients, records should require minimal parsing. Records that answer "yes/no" for a given query aganst a domain/IP tuple can be easily parsed using existing DNSBL logic. However, such records are not easily cached, particularly when a wide range of IP addresses produce multiple negative results. This overlooks optimizations offered by standard DNS records. These records are understood by libraries in hundreds of programming languages and do not require a special parser to run concurrent with the reception of mail. These records would be acquired once per connection rather than many per message and offer the same protections as obtained from any administrative domain that "usurps" permissions. Once implemented widely in receiving SMTP servers, Sender-ID may damage services of those domains publishing their lists as ´open¡ as a means to allow their users an ability to employ other points of access with their return address. Abusers will take advantage of published partial lists, especially those constructed with wildcards, and may inadvertently create the effect of a distributed denial of services attack by dispersing destinations from tens of thousands of machines using random sub-domains as a standard obfuscation ploy against filtering techniques. The option to partially publish should be removed due to this hazard. Once discovered as a general problem, the removal of a partial Sender-ID record would need to be done on a proactive basis, as those that abuse often do not honor DNS TTL time limits. Removal of the Sender-ID record in response to DDoS event will not provide relief, but may increase the severity of this event, as a negative response is not cached remotely for a long period of time. Should the record be changed to "closed" in response to the DDoS, then their user's mail may become silently lost. Those that operate with a large "closed" list may also become targets for an intended DDoS attack. Messages spoofed will force the entire matrix of records to be explored. The attacker's goal could be two fold. One would be to convince receiving SMTP servers to disable the Sender-ID check within the channel, and the other would be to convince those with the attacked name server to remove the Sender-ID record. No record linking or chaining could be made a requirement due to this hazard. Those unable to comply with these limits should be advised not to publish any Sender-ID records. The motivation to attack would be to instill trust by artificially obtaining a positive Sender-ID result by causing checks removed from the channel. To be abusive, spoofing a return address is not required, but Sender-ID does not remove all means for continuing this practice either. By allowing this practice to continue through exceptions made in the check, a great risk is placed upon the DNS and SMTP servers. Page 8: DNS: use of XML vs development of a little language A - The syntax should be easy for receivers to implement. The adoption of existing data formats such as XML means that existing libraries can be used to parse the data. XML is popular among the Microsoft community. B - The syntax should be easy for receivers to implement. The use of a custom-made little language means that heavyweight XML libraries are not required. XML is generally unpopular among the open community. Using standard (non-text) DNS records, no syntax needs to be developed. It also seems there should be a mention with regard to leaving these text record definitions open-ended or subject to standards review. Page 10: 4.1.2 Minimizing friction. Even the least amount of friction will impede adoption. The Design should take advantage of existing capabilities wherever possible. The design should optimize for the path of least resistance. The less overhead needed to publish a record, the better. The less overhead needed the better. Why emphasize publishing? Sender-ID changes the way mail is used. Sender-ID will cause users to change their use of mail and require updated servers and clients which will impose a slew of problems. Users may discover their SMTP transactions are transparently intercepted by their ISP thus invalidating their mail. Repair of this problem means other clients of this ISP will be able to forge mail as if from this user, but now with an indication the message has been checked. Sender-ID trades an effective means of abuse control for a mechanism that offers no control. 4.2 Design Guidelines The design guidelines that result from the above goals are: 4.2.1: optimize for ease of publishing over ease of implementation. 4.2.2: follow the path of least resistance. 4.2.3: Find a middle way by setting mechanism, not policy. Where design alternatives appear to conflict, find a technical compromise that lets each school operate; do not mandate or prohibit any of the choices. Lists published in an attempt to correlate users to domains fails to follow the path of least resistance. Ease of publishing complex relationships invites attack and will thwart deployment. Publishing the outbound SMTP servers for a single domain irrespective of return paths indicated within the mail messages is far simpler and much more effective at establishing accountability. Page 12: In accordance with its "mechanism, not policy" design philosophy, Sender ID makes the "zombies versus hobbyists" tradeoff in favour of hobbyists who are assumed to control the forward DNS of a domain they own. The important thing is to establish accountability: if a spammer wishes to designate a zombie as a permitted sender, the message is Sender-ID conformant; it is the responsibility of the reputation system to reject the message. Unlike Sender-ID, a forward DNS query can be comprehensive in that it offers no areas for abusers to hide, whereas Sender-ID will allow viruses to continue unabated. A reputation system MUST assess ONLY the domain handling policy and the mail stream. There are no sure methods using Sender-ID to enable assessment of accountability for mail found to be abusive. 6.1.2. Am I an MTA for the HELO domain? The next simplest scheme asks the domain of the HELO command if the IP address is a permitted sender for that domain. - DRIP - CSV Authenticating the HELO identity is useful for whitelisting by MTA hostname. Reputation services could evaluate relays identified in the HELO domain. CSV enables accreditation and reputation services for ALL domains sending mail, and is not limited to just use with relays. Those domains that fail to abate abuses can be themselves abated. Sender-ID does not allow accreditation and never stops the introduction of abusive messages with an ability to hide within a myriad of open Sender-ID records. Sender-ID may thwart a type of message fraud, but do not expect this to stop abuse nor fraud nor ensure its abatement. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jul 6 22:11:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12633 for ; Tue, 6 Jul 2004 22:11:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6722JHd047474; Tue, 6 Jul 2004 19:02:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6722JtI047472; Tue, 6 Jul 2004 19:02:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6722Iww047449 for ; Tue, 6 Jul 2004 19:02:18 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Tue, 06 Jul 2004 22:06:19 -0400 Received: from ([65.10.99.121]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2976626969; Tue, 06 Jul 2004 22:06:18 -0400 Message-ID: <00e001c463c6$79cfea40$6401a8c0@hdev1> From: "Hector Santos" To: "Gordon Fecyk" , "IETF-MXCOMP" References: <700EEF5641B7E247AC1C9B82C05D125DA90B@srv1.pan-am.ca> Subject: Re: Is MARID-SUBMITTER is really necessary? Date: Tue, 6 Jul 2004 22:01:17 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Gordon, I was waiting for more input before following up. ----- Original Message ----- From: "Gordon Fecyk" To: "IETF-MXCOMP" Sent: Monday, July 05, 2004 10:43 PM Subject: RE: Is MARID-SUBMITTER is really necessary? > > > This causes multiple lookups, adding to an already considerable > > > overhead on DNS. DMP did this too, but I'd gladly not do that > > > if the information in SUBMITTER is available. > > > > And if it is not? > > That's what "Resent-From:". is for. [Corrected by Gordon] And if is not there? This also implies the payload must be read too. > > The LMAP > > designs (and MARID) uses an open ended lookup approach with a total > > disregard that the majority of the lookups will fail anyway. > > Unless you can somehow force all domains handling mail to deploy such a > solution immediately, you're going to get a majority of failures to begin > with. This was hammered to death yonks ago. Exactly, which is why it needs to be hammered on again because it will become a problem once the wide adoption takes place with the "Willing." But what about the "UnWilling?" I assert the majority of the unwilling will include the exact senders were are trying to address. As long as they comply with CANSPAM, a MARID system may not have the powers to reject them, which I good I guess. > > It also ignores another important parameter - RCPT TO: > > Where does this enter into it? RCPT TO: tells you if you have a route or final destination situation. As you said, you don't need MARID for a route. It is already handled. > > Using SUBMITTER adds a high cost to changing software. > > We have to do this anyway if we're asking sites to use MARID or a MARID-like > protocol. And unless you know these costs you can't tell me it's less > expensive to implement SPF in Sendmail, for example, than CSV or Sender-ID or > DomainKeys or MARID-Core or MARID-Submitter. In my view, the only reason SPF has gain in popularity is because can work in post smtp mode operations. It allowed everyone, especially System Admins, to easily explore it with little to no change. In fact, most of the early SPF tools/libraries were all post smtp driven with an exception of a few that allowed patches to be added to existing systems. If SPF was strictly a dynamic SMTP system, I doubt the fast early adoption it experienced would of taken place. All the others require a different level of change to SMTP components. Some more than others. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 05:10:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05291 for ; Wed, 7 Jul 2004 05:10:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i678sYZE068187; Wed, 7 Jul 2004 01:54:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i678sY0f068186; Wed, 7 Jul 2004 01:54:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i678sXAN068178 for ; Wed, 7 Jul 2004 01:54:33 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i678sGl15374; Wed, 7 Jul 2004 01:54:20 -0700 Date: Wed, 7 Jul 2004 15:54:08 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1334499281.20040707155408@brandenburg.com> To: "Eric A. Hall" CC: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <40EABCEC.9010300@ehsco.com> References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric, >>>I did not say that forgery is not a problem. >>>I said that it is not essential to spamming. >> It is essential to a particular class of spam... EAH> There are a lot of tools that only stop spam on an incidental basis, but EAH> are really only useful because of that incidental benefit. Think RFC2821 EAH> syntax checks, greylisting, callback systems, etc., all of which are EAH> designed to probe implementation weaknesses instead of "block spam", but EAH> which happen to achieve that goal anyway. MARID would be the similar. There is an important difference between local algorithms that have transient utility against a problem, versus global standards that have no enduring benefit. The difference is adoption cost in terms of time and effort, notably when it requires global cooperation. Perhaps you know of a global standard that was/is designed for targeting such a narrow bit of behavior and has been beneficial, but I don't. Especially when removing the targetted behavior will do nothing to reduce the core problem. That is, none of this will reduce spam. As I say, the Internet community is going to be a bit disappointed that we spent this much time and effort and did nothing to reduce spam. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 10:49:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23857 for ; Wed, 7 Jul 2004 10:49:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67Eael2028565; Wed, 7 Jul 2004 07:36:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67EaeYO028564; Wed, 7 Jul 2004 07:36:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67EabT6028557 for ; Wed, 7 Jul 2004 07:36:40 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Forging (was Re: Differences between CSV and Sender-ID ) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 7 Jul 2004 09:36:39 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA912@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Forging (was Re: Differences between CSV and Sender-ID ) Thread-Index: AcRkAqT3mdfL8VcbQB65VUFd2WZpqQAKsGFA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i67EaeT6028558 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > As I say, the Internet community is going to be a bit disappointed > that we spent this much time and effort and did nothing to reduce > spam. I've said in counter to this that the Internet Community consists of a bunch of lazy [censored] for not acting to do something about their own spam, and a bunch of clueless [deleted] for actually responding to spam. None of us here have the solution to a clueless and lazy community. What we can do here is deliver incentive to complain, by demonstrating that who claims to have sent the spam actually sent it (accountability). IF the community decides to act on valid information, they will, and that will be the beginning of the end of spam. IF not, if the commmunity chooses to be the lazy [deleted] that they are today, then it won't. If MARID gets used by an elite few, that's OK by me. I will probably host a second domain that will require senders have MARID records or their mail will be refused. Eventually the elite minority will grow. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 11:27:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25833 for ; Wed, 7 Jul 2004 11:27:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67FC7l7032482; Wed, 7 Jul 2004 08:12:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67FC7rI032481; Wed, 7 Jul 2004 08:12:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67FC7Wg032472 for ; Wed, 7 Jul 2004 08:12:07 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 2DF961D651 for ; Wed, 7 Jul 2004 08:12:08 -0700 (PDT) Date: Wed, 07 Jul 2004 08:12:08 -0700 From: Greg Connor To: ietf-mxcomp@imc.org Subject: RE: Forging (was Re: Differences between CSV and Sender-ID ) Message-ID: <5808382.1089187928@[10.12.1.26]> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA912@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA912@srv1.pan-am.ca> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Gordon Fecyk wrote: > >> As I say, the Internet community is going to be a bit disappointed >> that we spent this much time and effort and did nothing to reduce >> spam. > > I've said in counter to this that the Internet Community consists of a > bunch of lazy [censored] for not acting to do something about their own > spam, and a bunch of clueless [deleted] for actually responding to spam. > > None of us here have the solution to a clueless and lazy community. > > What we can do here is deliver incentive to complain, by demonstrating > that who claims to have sent the spam actually sent it (accountability). > IF the community decides to act on valid information, they will, and that > will be the beginning of the end of spam. IF not, if the commmunity > chooses to be the lazy [deleted] that they are today, then it won't. > > If MARID gets used by an elite few, that's OK by me. I will probably > host a second domain that will require senders have MARID records or > their mail will be refused. Eventually the elite minority will grow. Agreed. MARID-brand LMAP probably won't noticeably reduce spam, or even forgery, at first, but if it creates a dis-incentive to forging MY domain name, I will definitely use it. At first the easiest thing for spammers to do will be to forge other domains that don't have LMAP info. Eventually, mail from domains with no LMAP info will start to get downgraded, but that will take a long time. The view that "this won't reduce spam so we shouldn't do it" is a pretty short-sighted one. Sure, everyone here would like to reduce spam, but we can serve other goals too. I think we went over this in detail during the "which identity to check" phase, so I won't rehash everything discussed before, but it seemed clear that both 2821 and 2822 identities should be protected, for different but equally valid reasons. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 14:09:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05066 for ; Wed, 7 Jul 2004 14:09:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67HpY2Z044432; Wed, 7 Jul 2004 10:51:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67HpYDg044431; Wed, 7 Jul 2004 10:51:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67HpOek044417 for ; Wed, 7 Jul 2004 10:51:27 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 8468717109 for ; Wed, 7 Jul 2004 13:58:33 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Wed, 07 Jul 2004 08:12:08 PDT." <5808382.1089187928@[10.12.1.26]> Date: Wed, 07 Jul 2004 13:58:33 -0400 Message-Id: <20040707175833.8468717109@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Connor wrote: > Agreed. MARID-brand LMAP probably won't noticeably reduce spam, or even > forgery, at first, but if it creates a dis-incentive to forging MY domain > name, I will definitely use it. Summarized in a carefully phrased sentence: MARID creates a permanent way for domains to permanently give dis-incentives for the transient problem of forgery. Domain name forgery is a transient problem, as incidents can occur sporadically, and the incidents are caused by different people at different times. The only way to stop this series of problems is with a solution which will permanently allow people to detect and prevent these attacks. MARID is one approach which creates a long-lived solution for a transient problem. Similarly, bandages solve a transient problem, but the *existence* of bandages is a permanent phenomenom. No one would claim that bandages "do nothing to reduce injuries" because the problem solved by bandages is transient in nature. To put it yet another way, MARID can be thought of as a set of distributed DNSBL's. Each domain operates its own DNSBL (or whitelist), which use a well-known format. Peers on the net can look up information for a domain via DNS, and choose to apply the DNSBL information (or not). None of this is new to the net. DNS already tells peers where to find information (e.g. MX's), and DNSBL's are already used by clients to obtain policies which they apply to data flows. MARID adds very little to this process, other than a standard for record formats, and when those record formats are used. Since MX's work, and DNSBL's work, I don't see why there's such FUD surrounding MARID. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 14:31:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06328 for ; Wed, 7 Jul 2004 14:31:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67IIOeT047033; Wed, 7 Jul 2004 11:18:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67IIOrv047032; Wed, 7 Jul 2004 11:18:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67IINFN047017 for ; Wed, 7 Jul 2004 11:18:23 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [192.168.0.2] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 665C760365; Wed, 7 Jul 2004 13:18:24 -0500 (CDT) Message-ID: <40EC3E38.8020000@ehsco.com> Date: Wed, 07 Jul 2004 14:17:28 -0400 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Crocker Cc: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> <1334499281.20040707155408@brandenburg.com> In-Reply-To: <1334499281.20040707155408@brandenburg.com> 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 7/7/2004 4:54 AM, Dave Crocker wrote: > Especially when removing the targetted behavior will do nothing to > reduce the core problem. That is, none of this will reduce spam. I don't think the results have to be binary for them to be useful, especially if the benefits are only sold as incidental. "Spammers will move to other domains" is a reasonable long-term viewpoint but on the other hand the spammers aren't that smart in the short-term, and there is some question about their intelligence over longer views as well. I mean, I still get plenty of dumbasses using localhost as their HELO identifier (rejected immediately) which everybody knows is easy to block and easy for spammers to adapt around (but they still do it), or using non-existent domains in their envelope sender addresses, or ... Lots of things that work well today are "easy to get around by doing X instead of Z", and yet the spammers keep on doing Z anyway. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 14:55:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07691 for ; Wed, 7 Jul 2004 14:55:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67Ij8R9049459; Wed, 7 Jul 2004 11:45:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67Ij8sM049458; Wed, 7 Jul 2004 11:45:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67Ij89J049451 for ; Wed, 7 Jul 2004 11:45:08 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 28BC5414F8; Wed, 7 Jul 2004 11:45:07 -0700 (PDT) Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040707175833.8468717109@mail.nitros9.org> References: <20040707175833.8468717109@mail.nitros9.org> Content-Type: text/plain Message-Id: <1089225906.21236.142.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 07 Jul 2004 11:45:06 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-07-07 at 10:58, Alan DeKok wrote: > Greg Connor wrote: > > Agreed. MARID-brand LMAP probably won't noticeably reduce spam, or even > > forgery, at first, but if it creates a dis-incentive to forging MY domain > > name, I will definitely use it. > > Summarized in a carefully phrased sentence: > > MARID creates a permanent way for domains to permanently give > dis-incentives for the transient problem of forgery. > > Domain name forgery is a transient problem, as incidents can occur > sporadically, and the incidents are caused by different people at > different times. The only way to stop this series of problems is with > a solution which will permanently allow people to detect and prevent > these attacks. MARID is one approach which creates a long-lived > solution for a transient problem. Could you define what you view to be forgery? > Similarly, bandages solve a transient problem, but the *existence* > of bandages is a permanent phenomenom. No one would claim that > bandages "do nothing to reduce injuries" because the problem solved by > bandages is transient in nature. > > > To put it yet another way, MARID can be thought of as a set of > distributed DNSBL's. Each domain operates its own DNSBL (or > whitelist), which use a well-known format. Peers on the net can look > up information for a domain via DNS, and choose to apply the DNSBL > information (or not). Listing services are often more robust than a typical DNS server. The nature of a listing service returns a single record in response to a single query. Do you see this model being changed with Sender-ID? > None of this is new to the net. DNS already tells peers where to > find information (e.g. MX's), and DNSBL's are already used by clients > to obtain policies which they apply to data flows. DNS routing information is normally obtained at a connection rate as are queries to listing services. Isn't the information for Sender-ID obtained at a much higher than these routing functions you compare it to? -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 15:24:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11222 for ; Wed, 7 Jul 2004 15:24:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67JFC9p052290; Wed, 7 Jul 2004 12:15:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67JFCjU052289; Wed, 7 Jul 2004 12:15:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67JFBtV052283 for ; Wed, 7 Jul 2004 12:15:12 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 7 Jul 2004 12:15:14 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Jul 2004 12:14:59 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jul 2004 12:15:15 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Jul 2004 12:14:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on marid-submitter-01 Date: Wed, 7 Jul 2004 12:14:29 -0700 Message-ID: Thread-Topic: Comments on marid-submitter-01 thread-index: AcRiH22EfAUsa3MuRqqYgUixjtuu9QCMtfTQ From: "Harry Katz" To: "MXCOMP" , "Dave Crocker" X-OriginalArrivalTime: 07 Jul 2004 19:14:46.0971 (UTC) FILETIME=[AADBC0B0:01C46456] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i67JFCtV052284 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sunday, July 04, 2004 4:22 PM, Dave Crocker wrote: > > Eric and Harry, > > > The next version of mail-crocker-email-architecture includes > the submitter construct. The sequence that led to your spec > convinced me that there is a core construct we need to have > be explicit in the email architecture. > > > Comments on your draft's details: Dave, thanks for the detailed review and comments on the submitter draft -- and my apologies for the delay in responding. I'm attempting to turn the crank on -02 this week or early next, so this is good timing. > > > > Abstract > > > > The responsible submitter is the e- > > mail address of the entity most recently responsible for > introducing > > a message into the transport stream. > > I find this to be a clear, concise definition and matches > what I think it should cite. > > However, I think it worth asking whether anybody has any > discomfort with it at all and if so, why? > > My reason for asking is that the definition needs to be > bullet-proof against any sort of "reasonable" misinterpretation. I've heard no objections so far, and this group isn't shy about voicing them. :-) > > > > 1. Introduction > > > > The practice of falsifying the identity of the sender of > an e-mail > > message, commonly called "spoofing", is a prevalent > tactic used by > > senders of unsolicited commercial e-mail or "spam". A number of > > proposals have been put forward to address the spoofing problem. > > Notable among them are [RMX], [SPF], [LMAP] and [CALLERID]. > > This line of discussion invites useless debate, because those > proposals generally are about RFC2821.MailFrom rather than > RFC2822.Sender or its relations and they are about spam > control rather than improving the ability of an SMTP session > to have access to the purported sender information. > > Because this is intended as a very narrow specification, > rather than either a pedagogical treatise or a broader effort > to reduce spam, etc., that you have a simpler introduction > that goes quickly to the requirement you want Submitter to satisfy. > > In general, a specification that compares itself with other > specifications is inviting debate about reportorial accuracy, > and other distractions to the technical focus. You do not > have to have the comparisons, so I strongly suggest leaving them out. > > > > Rather, how about something roughly along the lines of: > > Email abuse has highlighted the need to improve identification of > the "submitter", the entity responsible for injecting a message into > the email transport stream. The email message object current uses an > array of different headers for this identification. The current > specification codifies rules for correctly determining the submitter > and encoding that identification into an email transport > session-time field. This will permit... My intent was to put some context around the reason for creating this extension. However, your points are well taken. I'll revise and shorten the introduction. > > > In contrast, the following text: > > > Deriving the purported responsible domain from RFC 2821 data has > > the > ... > > Deriving the purported responsible domain from RFC 2822 > headers has > > is evaluating technical options that feed directly into the > design of this spec, so keeping the text IS useful > to*directly* understanding the thinking behind this specification. > > > > 4.1 Setting the SUBMITTER Parameter Value > > > > The purpose of the SUBMITTER parameter is to allow the SMTP client to > > indicate to the server the purported responsible address of the > > message directly in the RFC 2821 protocol. > > > > Therefore, SMTP clients that support the Responsible Submitter > > extension SHOULD include the SUMBITTER parameter on all messages > > where the purported responsible address, as defined in section 4 of > > [SENDER-ID] differs from the MAIL FROM address. > > > A matter of my own ietf style preference: > > The specification for determining Responsible Submitter > strikes me as having much broader utility than just the > marid-core specification. > > Although this might seem like nit-picking, I suggest you > break it out into a separate document, so that it receives > independent focus and so that it does not have to fate-share > with other documents. Further, that then means there is not > need for THIS specification to fate-share with marid-core. I think it is important to have the PRA algorithm defined in one and only one place. Marid-submitter will still have a dependency on that algorithm whether it's specified in marid-core or a stand-alone document. Let me think about this one. > > > > > > At some future time, it is likely that use of the > SUBMITTER parameter > > will be made MANDATORY whenever the purported responsible address > > differs from the MAIL FROM address. > > In my opinion, this is a very bad bit of text to have. > > Specifications quite simply should not refer to the > requirements of the future, because they are typically wrong, > especially when they refer to social requirements rather than > technical ones. Whether this is made mandatory depends upon > the social aspects of its adoption, not on the technical > aspects of its operation. > > You do not have to have this text in here, for the > specification to be whole and useful, so take it out. OK. In any case, the actions taken by receiving systems with respect to MAIL FROM are independent of any actions they take on the basis of SUBMITTER, so this really doesn't belong here. Thanks. > > > > A common model will be for the Mail User Agent (MUA) to > transmit a > > will -> could > > (submit is not yet in sufficient use to make the "will" > certain, no matter how much we all might wish otherwise.) OK > > > > 4.2 Processing the SUBMITTER Parameter > > I think this entire section is is the wrong document, so I > suggest removing it. > > It makes this specification be a customer of the marid-core > specification, rather than the reverse. > > This can (and I believe should) be a neat, clean, simple, > direct specification for adding a bit of information into the > SMTP control flow. Broader, bigger systems USES of this > information ought to go into broader, bigger specifications > that cite this specification, rather than having this > specification cite them. > > Again, this is about setting up specification dependencies in > a way that minimizes risk both of timing and distraction... Is your main concern here about the dependency on marid-core in this section? The only dependency is on the PRA algorithm, so this reinforces your suggestion to split that out into a separate spec. However, I think it's important to give some guidance in marid-submitter to receiving systems as to how to interpret and process the SUBMITTER value. Equally important, we need to give _senders_ a clear understanding of what will happen to their messages when SUBMITTER is used and abused. So, I think 4.2, in some form, needs to remain. > > > > 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server > > > > When an MTA receives a message with a SUBMITTER > parameter and must > > forward it to another MTA that does not support the SUBMITTER > > extension, the forwarding MTA MUST transmit the message > without the > > SUBMITTER parameter. > > This is a very big decision. I don't know whether I think it > is right or wrong, so I'm flagging it, hoping the working > group discusses it. > It makes it easier to adopt, but greatly weakens its import. I don't see how we can do this any other way. Otherwise, we're going to disrupt mail flow until everyone upgrades. > > > > > 6. Security Considerations > > > > The purpose of this extension is to help deter the practice of > > forging or "spoofing" the address of the sender of an > e-mail message. > > Actually, the purpose of this extension is to move RFC2822 > Sender-related identification into the email transfer control > stream, to improve its use during transfers. > > All the rest is part of the broader, grander specification, elsewhere. I'll rework this. > > > d/ > -- > Dave Crocker Brandenburg > InternetWorking Sunnyvale, CA > USA , > > From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 15:33:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12379 for ; Wed, 7 Jul 2004 15:33:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67JP7nD053155; Wed, 7 Jul 2004 12:25:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67JP7KI053154; Wed, 7 Jul 2004 12:25:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67JO6iX053072 for ; Wed, 7 Jul 2004 12:25:06 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id E78A41710A for ; Wed, 7 Jul 2004 15:31:18 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Wed, 07 Jul 2004 11:45:06 PDT." <1089225906.21236.142.camel@ddev.mail-abuse.org> Date: Wed, 07 Jul 2004 15:31:18 -0400 Message-Id: <20040707193118.E78A41710A@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > Could you define what you view to be forgery? http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-01.txt ... 2.1. Unauthorized use of a domain name as "forgery" In the context of LMAP, SMTP "forgery" is defined as: SMTP Forgery: Use of a domain name in the argument fields of SMTP EHLO/HELO and/or SMTP MAIL FROM, by an SMTP client, when the owner of the domain name did not consent to that use of their name. ... > Listing services are often more robust than a typical DNS server. If a DNS server holding MARID information isn't robust, then it will most likely also fail for MX records, in addition to MARID records. I don't see how "robustness" matters more for DNS when it contains MARID records than when it doesn't. Sure, more records are being looked up in DNS, but many MTA's already do MX lookups when receiving mail "from" a domain, in an attempt to implicitly discover the domain owners intent, even when there's no standard saying that they should do this. > The nature of a listing service returns a single record in response > to a single query. Do you see this model being changed with > Sender-ID? This is explained in: http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt My reading indicates that multiple DNS queries may be performed to discover the location of one record, but the intention of the draft appears to be that records should often be obtained via one query. The information in the record may indicate that other DNS queries may be performed (e.g. MX). Again, do you read the draft as saying otherwise? Many MTA's already do multiple DNSBL lookups. Do you see that multiple DNSBL lookups by an MTA are substantially different/better than one MARID record, possibly requiring multiple lookups? Do you see that MX lookups by existing MTA's are substantially different/better than one MARID record, possibly requiring multiple lookups? > DNS routing information is normally obtained at a connection rate as are > queries to listing services. I'm not sure what you mean by that. I'm not even sure I can parse that sentence properly. To take a wild guess, MARID lookups happen only when there are SMTP connections, therefore any lookups happen at a similar "connection rate" as queries to listing services. The constant may be different, but the dependency on connections is the same. Or, do you see Sender-ID as having an amplification problem? e.g. If MARID queries increased super-linearly with the number of connections. If so, it would be a serious flaw in the proposal. Since the distribution of SMTP traffic to/from most sites is non-linear across domains, and DNS information is cached, I would expect that MARID queries would increase linearly with the number of unique domains used in SMTP conversations, but (often) sub-linearly with the total number of SMTP connections. > Isn't the information for Sender-ID obtained at a much higher than > these routing functions you compare it to? ... much higher... what? There's a word missing. I *think* you're saying that Sender-ID requires more lookups than are currently required. This isn't news. For details as to the cost of these lookups, see the list archives. They contain posts from others with quantitative summaries, describing the extra DNS costs of MARID, and concluding that those costs are minimal. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 17:04:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17204 for ; Wed, 7 Jul 2004 17:04:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67KdF8U058484; Wed, 7 Jul 2004 13:39:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67KdF3Z058483; Wed, 7 Jul 2004 13:39:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67KdEos058471 for ; Wed, 7 Jul 2004 13:39:14 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BiJCA-0005XV-5o for ietf-mxcomp@imc.org; Wed, 07 Jul 2004 15:39:16 -0500 To: "IETF MARID WG" References: <1278665427.20040702224550@brandenburg.com> <20040703131211.3AFF617107@mail.nitros9.org> <1313037133.20040704141557@brandenburg.com> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 07 Jul 2004 15:39:10 -0500 In-Reply-To: <1313037133.20040704141557@brandenburg.com> (Dave Crocker's message of "Sun, 4 Jul 2004 14:15:57 +0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.4 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <1313037133.20040704141557@brandenburg.com> Dave Crocker writes: > Get rid of forging and you will not reduce spamming at all. I have no idea how you could prove a statement like this true or false. I've heard it said that DNSBLs have not reduced spamming at all and that if it wasn't for DNSBLs email would be unusable today. Barring the creation of alternate universes where DNSBLs didn't exist, no one will really know if either of these claims is true. Certainly spam, like other forms of theft, will never completely go away. Spam, like other forms of theft, requires many different tools, including defensive measures, identification/accreditation, and legal actions. Nothing proposed on this WG is going to stop spam. I find it amusing that Alan and Dave are discussing such issues and Alan hasn't even pointed out that even doing ICMP port unreachable responses to SMTP connections won't stop spammers. See: http://www.striker.ottawa.on.ca/ If even as an immediate and absolute response as an ICMP port unreachable won't stop spammers from attempting to send spam to striker, such things as SPF, Sender-ID, CSV, MTAmark, etc. don't have a chance. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 17:47:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19075 for ; Wed, 7 Jul 2004 17:47:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67LUer7061893; Wed, 7 Jul 2004 14:30:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i67LUe2Y061892; Wed, 7 Jul 2004 14:30:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67LUWos061881 for ; Wed, 7 Jul 2004 14:30:37 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 404C917109; Wed, 7 Jul 2004 17:37:45 -0400 (EDT) From: "Alan DeKok" To: "IETF MARID WG" , asrg@ietf.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Wed, 07 Jul 2004 15:39:10 CDT." Date: Wed, 07 Jul 2004 17:37:45 -0400 Message-Id: <20040707213745.404C917109@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > Nothing proposed on this WG is going to stop spam. No one is claiming it will. Anyone claiming that MARID will stop spam should be educated as to how it works. > I find it amusing that Alan and Dave are discussing such issues and > Alan hasn't even pointed out that even doing ICMP port unreachable > responses to SMTP connections won't stop spammers. See: > http://www.striker.ottawa.on.ca/ I have never claimed that ICMP port unreachables would stop spammers, so I don't see why you're bringing it up, or how it's relevant to MARID. See the ASRG archives, where multiple people re-establish a dormant domain after 3 years, and instantly receive spam. Spammers are sending to everyone, always, whether or not anyone is listening. And the problem behind the situation on my page about ICMP port unreachables is *not* about spam, believe it or not. It's about theft of services. The spammers were "owning" someone's machine, and they therefore didn't care what the cost of spam was, as those costs were borne by the administrators of the "owned" machine. No SMTP-based anti-spam solution can prevent these situations. Let me repeat that, in case I was unclear: Some spam is sent through otherwise legitimate "owned" MTA's, and nothing we do in SMTP, or to SMTP, will have ANY effect on that kind of spam (except turning off SMTP for that MTA). The ONLY solution to such theft is a combination of legal & non-SMTP technical approaches. > If even as an immediate and absolute response as an ICMP port > unreachable won't stop spammers from attempting to send spam to > striker, such things as SPF, Sender-ID, CSV, MTAmark, etc. don't have > a chance. I don't care about people sending spam to striker, as I have other methods to deal with that. I care about people forging mail FROM striker, as it's difficult for me to deal with those messages via local configuration or policy. I'm now starting to see spam forged FROM people I exchange email with, TO me. This says to me that spammers are not only forging messages, they're trolling list archives for pairs of addresses which will probably make it through content filters. Forgery prevention systems are therefore even more relevant. If this thread continues, please continue it only on ASRG. It's getting off-topic for MARID. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 20:39:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00794 for ; Wed, 7 Jul 2004 20:39:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i680Q6Kl073601; Wed, 7 Jul 2004 17:26:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i680Q6Dn073600; Wed, 7 Jul 2004 17:26:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i680Q6WY073594 for ; Wed, 7 Jul 2004 17:26:06 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i680Pxl01672; Wed, 7 Jul 2004 17:25:59 -0700 Date: Thu, 8 Jul 2004 07:25:31 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <265446025.20040708072531@brandenburg.com> To: "Eric A. Hall" CC: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <40EC3E38.8020000@ehsco.com> References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> <1334499281.20040707155408@brandenburg.com> <40EC3E38.8020000@ehsco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric, EAH> but on the other hand the spammers aren't that smart in the short-term, spammers have proved to be smart, adaptable and quick. the current methods of spam-sending represent highly sophisticated, large-scale distributed systems. nothing has yet reduced the amount or impact of global spam. in fact, spam has only gotten monotonically worse. so we probably should be reticent to build a global standard that assumes the spammers will be slow-witted and slow-responding. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 21:38:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03645 for ; Wed, 7 Jul 2004 21:38:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i681TRaS078968; Wed, 7 Jul 2004 18:29:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i681TRUi078967; Wed, 7 Jul 2004 18:29:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i681TQ7K078961 for ; Wed, 7 Jul 2004 18:29:26 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BiNj4-0007ca-JS for ietf-mxcomp@imc.org; Wed, 07 Jul 2004 20:29:32 -0500 To: "IETF MARID WG" References: <20040707213745.404C917109@mail.nitros9.org> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 07 Jul 2004 20:29:26 -0500 In-Reply-To: <20040707213745.404C917109@mail.nitros9.org> (Alan DeKok's message of "Wed, 07 Jul 2004 17:37:45 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.4 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040707213745.404C917109@mail.nitros9.org> "Alan DeKok" writes: > wayne wrote: >> Nothing proposed on this WG is going to stop spam. > > No one is claiming it will. Anyone claiming that MARID will stop > spam should be educated as to how it works. Alan: I think we are actually in violent agreement on these issues. While I can't recall anyone claiming that any MARID/LMAP proposal would stop spam, I have seen several comments about how not stopping spam is somehow a major flaw. While I think that many of the MARID/LMAP proposals will both reduce the rate of growth of spam and increase the costs for spammers, those aren't my main goal here. I hope to help stop forgery, (slightly) increase the accountability email, reduce the mount of bogus bounces/C-Rs/"virus" warnings, and make whitelisting far more useful. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 21:38:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03675 for ; Wed, 7 Jul 2004 21:38:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i681KRjf078489; Wed, 7 Jul 2004 18:20:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i681KR9Y078488; Wed, 7 Jul 2004 18:20:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i681KRYK078477 for ; Wed, 7 Jul 2004 18:20:27 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id A6C1D414F8; Wed, 7 Jul 2004 18:20:28 -0700 (PDT) Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040707193118.E78A41710A@mail.nitros9.org> References: <20040707193118.E78A41710A@mail.nitros9.org> Content-Type: text/plain Message-Id: <1089249627.21236.333.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 07 Jul 2004 18:20:28 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-07-07 at 12:31, Alan DeKok wrote: > Douglas Otis wrote: > > Could you define what you view to be forgery? > > http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-01.txt > > ... > 2.1. Unauthorized use of a domain name as "forgery" > > In the context of LMAP, SMTP "forgery" is defined as: > > SMTP Forgery: Use of a domain name in the argument fields of > SMTP EHLO/HELO and/or SMTP MAIL FROM, by an SMTP client, when > the owner of the domain name did not consent to that use of > their name. > ... >From this definition of forgery, it would appear you are not referring to Sender-ID. This is important as Sender-ID is changing the scope of this protection. The ASRG definition was based on an effort to reduce mail traffic by examining RFC 2821 information. Sender-ID uses RFC 2822 information and, as such, will not impact mail traffic. It also currently allows extensions beyond current definitions which impacts this concern raised regarding DNS overhead. This change in the definition of forgery changes the benefit equation, as there will be no relief from accepting the mail to offset the load placed upon the DNS server. You should consider revising this draft before using it as a reference. > > Listing services are often more robust than a typical DNS server. > > If a DNS server holding MARID information isn't robust, then it will > most likely also fail for MX records, in addition to MARID records. The rate that a Sender-ID SMTP receiver queries DNS versus that needed to find an MX server by the SMTP sender are significantly different in terms of both the number of queries and the serial sequence required. The loads and delays are not comparable to allow such an analogy to dismiss these concerns. > I don't see how "robustness" matters more for DNS when it contains > MARID records than when it doesn't. Sure, more records are being > looked up in DNS, but many MTA's already do MX lookups when receiving > mail "from" a domain, in an attempt to implicitly discover the domain > owners intent, even when there's no standard saying that they should > do this. Scale and Scope The complex linked nature of these records becomes important as this is indicative of limitations Sender-ID has with respect to scale. An MX record only refers to a set of hosts that "receive" mail for a domain. As SMTP allows this mail to be relayed, there may be many times this number of hosts that "send" mail for the same domain. In addition, all other domains that may originate mail on behalf of this domain are to be expressed by this Sender-ID record set. In addition, these records also reflect other domains that may also share these hosts. An MX record is never expected to be so expansive in scope nor is comparative to the potential size of such a response. This still excludes the "added" features. : 0 > > The nature of a listing service returns a single record in response > > to a single query. Do you see this model being changed with > > Sender-ID? > > This is explained in: > > http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt Pg. 18: 5.4 Recursion Limitations Evaluation of many of the mechanisms in section 5.1 will require additional DNS lookups. To avoid infinite recursion, and to avoid certain denial of service attacks, an MTA or other processor SHOULD limit the total number of DNS lookups that it is willing to perform in the course of a single authentication. Such a limit SHOULD allow for at least 20 lookups. If such a limit is exceeded, the result of authentication MUST be "hardError". MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to perform an authentication. Such a limit SHOULD allow at least 10 seconds. If such a limit is exceeded, the result of authentication SHOULD be "transientError". Domains publishing records SHOULD keep the number of DNS lookups to less than 20. Domains publishing records that are intended for use as the target of "indirect" elements SHOULD keep the number of DNS lookups to less than 10. It would appear if there is a dropped query, it may result in a "Transient Error" after the message has been fully received. It would also indicate delegation to other domains may easily result in a "Hard Error" because someone somewhere added another delegating indirection. What average number of indirections per record is required before hard errors are produced? > My reading indicates that multiple DNS queries may be performed to > discover the location of one record, but the intention of the draft > appears to be that records should often be obtained via one query. What leads you to this conclusion? I see the complexity of these records growing as a defense against abusers when initially expressed as an "open" list. Closing the list will require more information that must be comprehensive. The end result would be difficult to assess while many records are simply left "open" initially. > The information in the record may indicate that other DNS queries > may be performed (e.g. MX). Again, do you read the draft as saying > otherwise? There are many possible indirections that may be asserted by the Sender-ID record. Each of which may result in a sequential query. > Many MTA's already do multiple DNSBL lookups. Do you see that > multiple DNSBL lookups by an MTA are substantially different/better > than one MARID record, possibly requiring multiple lookups? Do you > see that MX lookups by existing MTA's are substantially > different/better than one MARID record, possibly requiring multiple > lookups? Multiple RBL lookups are often done in parallel and each result in a single response. Many wait for a portion of these RBL queries to return before proceeding, and do not expect all to return. Again, these RBL services are likely much more robust than the typical DNS server. As I said, there is no reason to expect the lookup of an MX record to entail anywhere near the same amounts of information as that returned by the Sender-ID record set. > > DNS routing information is normally obtained at a connection rate as are > > queries to listing services. > > I'm not sure what you mean by that. I'm not even sure I can parse > that sentence properly. > > To take a wild guess, MARID lookups happen only when there are SMTP > connections, therefore any lookups happen at a similar "connection > rate" as queries to listing services. The constant may be different, > but the dependency on connections is the same. Sender-ID record sets are examined for every message whereas the listing service record happens once per connection. Much abuse happens with long-term connections that often send a large series of small messages. In such a case, the difference in magnitude with respect to DNS query rates for Sender-ID compared to finding MX records or obtaining a listing service record could be many orders of magnitude higher. > Or, do you see Sender-ID as having an amplification problem? e.g. > If MARID queries increased super-linearly with the number of > connections. If so, it would be a serious flaw in the proposal. Serious indeed. > Since the distribution of SMTP traffic to/from most sites is > non-linear across domains, and DNS information is cached, I would > expect that MARID queries would increase linearly with the number of > unique domains used in SMTP conversations, but (often) sub-linearly > with the total number of SMTP connections. But you are not limited to a single domain with abusive mail. Often abusive mail uses a wildcard technique to obfuscate their identity. As a wildcard record is superseded by real records, caching the wildcard would be dangerous. Our clever abuser may use a random fictitious sub-domain. Disaster! Even worse, an innocent domain publishes an open list using a wildcard. This would be better than using someone else's credit card. The hapless domain may wonder what just happened to their network traffic. > > Isn't the information for Sender-ID obtained at a much higher than > > these routing functions you compare it to? > > ... much higher... what? There's a word missing. > > I *think* you're saying that Sender-ID requires more lookups than > are currently required. This isn't news. For details as to the cost > of these lookups, see the list archives. They contain posts from > others with quantitative summaries, describing the extra DNS costs of > MARID, and concluding that those costs are minimal. These conclusions vary widely. There also seems to be a reluctance to review the issue of suitable scale. On Wed, 2004-07-07 at 2:37, Alan DeKok wrote: wayne wrote: > > Nothing proposed on this WG is going to stop spam. > No one is claiming it will. Anyone claiming that MARID will stop > spam should be educated as to how it works. I will say that Sender-ID will not affect the amount of spam that people must sort and delete. Authorization and Authentication of the sender SMTP client used together with accreditation will impact the amount of spam seen. Such will also enable enforcement whereas Sender-ID will not. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 22:22:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05999 for ; Wed, 7 Jul 2004 22:22:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682D2jJ082062; Wed, 7 Jul 2004 19:13:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i682D2QG082061; Wed, 7 Jul 2004 19:13:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682D25g082055 for ; Wed, 7 Jul 2004 19:13:02 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i682D3l10775; Wed, 7 Jul 2004 19:13:04 -0700 Date: Thu, 8 Jul 2004 09:12:49 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1776922509.20040708091249@brandenburg.com> To: "Harry Katz" CC: "MXCOMP" Subject: Re: Comments on marid-submitter-01 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Harry, HK> I think it is important to have the PRA algorithm defined in one and HK> only one place. definitely. HK> Marid-submitter will still have a dependency on that HK> algorithm whether it's specified in marid-core or a stand-alone HK> document. Let me think about this one. the simple way I think of it is that PRA is a clarification to RFC2821. The rest of the spec is definition of a new capability. >> It makes this specification be a customer of the marid-core >> specification, rather than the reverse. ... >> Again, this is about setting up specification dependencies in >> a way that minimizes risk both of timing and distraction... HK> Is your main concern here about the dependency on marid-core in this HK> section? The only dependency is on the PRA algorithm, so this HK> reinforces your suggestion to split that out into a separate spec. I think that's right. HK> However, I think it's important to give some guidance in marid-submitter HK> to receiving systems as to how to interpret and process the SUBMITTER HK> value. slippery slope. in reality, doing serious justice to that goal means replicating marid-core. smtp options can be extremely small, discrete things. that they might fit into some larger, more interesting system does not require that the option document that larger thing. HK> Equally important, we need to give _senders_ a clear HK> understanding of what will happen to their messages when SUBMITTER is HK> used and abused. So, I think 4.2, in some form, needs to remain. But that is really the job of marid-core. >> > 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server .. >> This is a very big decision. I don't know whether I think it >> is right or wrong, so I'm flagging it, hoping the working >> group discusses it. >> It makes it easier to adopt, but greatly weakens its import. HK> I don't see how we can do this any other way. Otherwise, we're going to HK> disrupt mail flow until everyone upgrades. either choice has a strong and entirely legitimate basis, but it also has a strong and serious limitation. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 22:28:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06213 for ; Wed, 7 Jul 2004 22:28:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682Epfb082128; Wed, 7 Jul 2004 19:14:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i682Ep29082127; Wed, 7 Jul 2004 19:14:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682Eox8082121 for ; Wed, 7 Jul 2004 19:14:51 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [192.168.0.2] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id EACD0309BB; Wed, 7 Jul 2004 21:14:55 -0500 (CDT) Message-ID: <40ECADE2.1040109@ehsco.com> Date: Wed, 07 Jul 2004 22:13:54 -0400 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Crocker Cc: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> <1334499281.20040707155408@brandenburg.com> <40EC3E38.8020000@ehsco.com> <265446025.20040708072531@brandenburg.com> In-Reply-To: <265446025.20040708072531@brandenburg.com> 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 7/7/2004 8:25 PM, Dave Crocker wrote: > spammers have proved to be smart, adaptable and quick. Older spammers who are savvy enough to compete maybe, but not the new and/or stupid ones. Anyway, the empirical evidence shows that old filtering tools continue being useful, which is in direct contradiction to the essence of your opinion. Who am I going to believe, you or my lying logfiles? > so we probably should be reticent to build a global standard that > assumes the spammers will be slow-witted and slow-responding. The words I used were 'incidental benefit'. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 22:36:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06481 for ; Wed, 7 Jul 2004 22:36:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682P4uG082766; Wed, 7 Jul 2004 19:25:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i682P4TP082765; Wed, 7 Jul 2004 19:25:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682P41S082759 for ; Wed, 7 Jul 2004 19:25:04 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i682Oxl11812; Wed, 7 Jul 2004 19:25:03 -0700 Date: Thu, 8 Jul 2004 09:24:37 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1606182406.20040708092437@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <20040707175833.8468717109@mail.nitros9.org> References: Your message of "Wed, 07 Jul 2004 08:12:08 PDT." <5808382.1089187928@[10.12.1.26]> <20040707175833.8468717109@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i682P41S082760 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Alan, AD> Similarly, bandages solve a transient problem, but the *existence* AD> of bandages is a permanent phenomenom. No one would claim that AD> bandages "do nothing to reduce injuries" because the problem solved by AD> bandages is transient in nature. Interesting analogy. Let's explore it a bit. Bandages do not promote healing; in fact they reduce it. Their legitimate job is to keep dirt out. When I was growing up, they were used immediately whenever you got cut. Current medical wisdom is to use them judiciously. But the real problem with the analogy is that it entirely misses the nature of the email tool being built and the nature of what it is in response to. The biggest worry about 'the nature of what it is in response to' is that it has us chasing symptoms rather than causes. Spammers have proved to be astonishingly and quickly adaptable and our response times are pathetically slow. This means we will always be chasing the latest symptom, rather than going to any core characteristics of the "disease". From a standards-making point of view, the bandage image suggests selective application in quick response to special situations. Unfortunately, that's not they way global standards get used. Global standards are not used individually and they are not used selectively. They are for interoperable situations. The result means that applying a bandage becomes a required part of everyone's contact with anyone else, everytime. That is neither selective nor inexpensive. And that's just for the current symptom. And it has serious downside impact, if it constraints the transfer paths of email. All in all, this means that we are discussing major, strategic changes to the email infrastructure, for minor, tactical, transient benefits. I'd be interested in hearing of examples of useful global standards that have had similar properties. AD> To put it yet another way, MARID can be thought of as a set of AD> distributed DNSBL's. Sorry, but CSV follows the BL construct, marid-core does not. AD> Each domain operates its own DNSBL (or AD> whitelist), which use a well-known format. And each domain is supposed to maintain this list how, exactly? Note that the question is particularly relevant when spammers are quickly obtaining and using new domains with clean records. AD> Peers on the net can look AD> up information for a domain via DNS, and choose to apply the DNSBL AD> information (or not). "look up information for a domain via DNS"? what whitelisting service mechanism is specified in marid-core? AD> None of this is new to the net. DNS already tells peers where to AD> find information (e.g. MX's), THat's not what MX does. MX is a routing record, not a query record. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 22:51:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06881 for ; Wed, 7 Jul 2004 22:51:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682XLpr084214; Wed, 7 Jul 2004 19:33:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i682XL5f084213; Wed, 7 Jul 2004 19:33:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682XLhL084207 for ; Wed, 7 Jul 2004 19:33:21 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i682XIl12482; Wed, 7 Jul 2004 19:33:19 -0700 Date: Thu, 8 Jul 2004 09:33:00 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1437073093.20040708093300@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <20040707175833.8468717109@mail.nitros9.org> References: Your message of "Wed, 07 Jul 2004 08:12:08 PDT." <5808382.1089187928@[10.12.1.26]> <20040707175833.8468717109@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan, (part 2. i hit send to quickly) AD> To put it yet another way, MARID can be thought of as a set of AD> distributed DNSBL's. Each domain operates its own DNSBL (or This is exactly wrong. BL's are accreditation mechanisms, whereas marid-core is an authentication and authorization mechanism. The administrator of the author/sender domain name is authorizing the operator of a client MTA to carry its message. These are very, very different functions. Of necessity, typical accreditation mechanisms must be provided by independent sources. marid-core does not do that. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 22:51:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06900 for ; Wed, 7 Jul 2004 22:51:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682cRfP084668; Wed, 7 Jul 2004 19:38:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i682cR7Z084667; Wed, 7 Jul 2004 19:38:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682cQ5G084661 for ; Wed, 7 Jul 2004 19:38:26 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i682cLl12866; Wed, 7 Jul 2004 19:38:21 -0700 Date: Thu, 8 Jul 2004 09:37:59 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <34587928.20040708093759@brandenburg.com> To: "Eric A. Hall" CC: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <40ECADE2.1040109@ehsco.com> References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> <1334499281.20040707155408@brandenburg.com> <40EC3E38.8020000@ehsco.com> <265446025.20040708072531@brandenburg.com> <40ECADE2.1040109@ehsco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric, >> spammers have proved to be smart, adaptable and quick. EAH> Older spammers who are savvy enough to compete maybe, but not the new EAH> and/or stupid ones. Eric, your model of current, common spam-sending operations is apparently wildly different from the one I have been getting from senior, dedicated spam-chasers. EAH> Anyway, the empirical evidence shows that old filtering tools continue you continue to use experience with local, isolated mechanisms to somehow justify an approach to global, interoperable standards. I don't understand that. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 22:52:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06959 for ; Wed, 7 Jul 2004 22:52:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682g8OB084877; Wed, 7 Jul 2004 19:42:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i682g81J084876; Wed, 7 Jul 2004 19:42:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i682g7kR084870 for ; Wed, 7 Jul 2004 19:42:07 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [192.168.0.2] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 9828634429; Wed, 7 Jul 2004 21:42:13 -0500 (CDT) Message-ID: <40ECB449.2080001@ehsco.com> Date: Wed, 07 Jul 2004 22:41:13 -0400 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Crocker Cc: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> <1334499281.20040707155408@brandenburg.com> <40EC3E38.8020000@ehsco.com> <265446025.20040708072531@brandenburg.com> <40ECADE2.1040109@ehsco.com> <34587928.20040708093759@brandenburg.com> In-Reply-To: <34587928.20040708093759@brandenburg.com> 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 7/7/2004 10:37 PM, Dave Crocker wrote: > you continue to use experience with local, isolated mechanisms to > somehow justify an approach to global, interoperable standards. I > don't understand that. Nor can you understand the meaning of 'incidental benefit' apparently -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 23:32:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08861 for ; Wed, 7 Jul 2004 23:32:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i683MC1K087996; Wed, 7 Jul 2004 20:22:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i683MCxU087995; Wed, 7 Jul 2004 20:22:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i683MB4f087987 for ; Wed, 7 Jul 2004 20:22:12 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 07 Jul 2004 23:26:08 -0400 Received: from ([65.10.99.121]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 3067816860; Wed, 07 Jul 2004 23:26:08 -0400 Message-ID: <04c501c4649a$ce69adf0$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "Eric A. Hall" Cc: References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> <1334499281.20040707155408@brandenburg.com> <40EC3E38.8020000@ehsco.com> <265446025.20040708072531@brandenburg.com> Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) Date: Wed, 7 Jul 2004 23:21:24 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" To: "Eric A. Hall" Cc: Sent: Wednesday, July 07, 2004 8:25 PM Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) > > Eric, > > EAH> but on the other hand the spammers aren't that smart in the short-term, > > spammers have proved to be smart, adaptable and quick. The only evidence of adaption has been at 2822 and the hackers (the smarter ones of the abuse crowd) finally realizing they can exploit some aspects of 2821 - SORBIG! The industry really started screaming when SORBIG started to exploit everything about SMTP using a dual distribution concept. That is when I finally got involved - no more or less a reason. The payload is the responsibility of the sysop or any post smtp operation. Although there was adapation by spammers, sysops had somewhat of a handle of this with the post smtp mail filters tools. But when it wasn't spam but viruses and bounces were being forced - POOF! - Major problem. If you close 2821 - minimize payload acceptance, you drastically reduce the effectiveness of any spammer adaptation at 2822. Its a non-issue basically. MARID must be give more power to 2821. This is why I have kept repeating, any MARID logic that requires PAYLOAD to be used will suffer the consequences, not only in the 2822 adaptation but in increasing payload bandwidth as well. I should also note this is a network wide consideration, not just a local, isolated experience. All my customers are benefiting from the more SMTP enforcement concepts and DNS reductions efficiency ideas used for our SMTP server. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 23:33:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08936 for ; Wed, 7 Jul 2004 23:33:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i683OsRZ088275; Wed, 7 Jul 2004 20:24:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i683OskM088274; Wed, 7 Jul 2004 20:24:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i683Opck088255 for ; Wed, 7 Jul 2004 20:24:52 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from lustre.dyn.wiw.org (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 3A7611BDE7A for ; Thu, 8 Jul 2004 05:24:51 +0200 (CEST) Received: from [10.0.0.6] (helo=[10.0.0.6]) by lustre.dyn.wiw.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.20) id 1BiPWW-0000f8-Et for ietf-mxcomp@imc.org; Thu, 08 Jul 2004 08:54:36 +0530 Message-Id: From: Arnt Gulbrandsen To: Dave Crocker Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) Cc: "Eric A. Hall" , Dave Crocker , ietf-mxcomp@imc.org References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> <1334499281.20040707155408@brandenburg.com> <40EC3E38.8020000@ehsco.com> <265446025.20040708072531@brandenburg.com> <40ECADE2.1040109@ehsco.com> <34587928.20040708093759@brandenburg.com> In-Reply-To: <34587928.20040708093759@brandenburg.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Thu, 8 Jul 2004 05:25:59 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker writes: > Eric, your model of current, common spam-sending operations is > apparently wildly different from the one I have been getting from > senior, dedicated spam-chasers. Some spammers are smart, and are disproportionally visible to spamfighters. Others - many others - are not. Arnt From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 23:50:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09833 for ; Wed, 7 Jul 2004 23:50:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i683bx4G089543; Wed, 7 Jul 2004 20:37:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i683bxMP089542; Wed, 7 Jul 2004 20:37:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i683bwYd089533 for ; Wed, 7 Jul 2004 20:37:58 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 157C31710A for ; Wed, 7 Jul 2004 23:45:14 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Wed, 07 Jul 2004 18:20:28 PDT." <1089249627.21236.333.camel@ddev.mail-abuse.org> Date: Wed, 07 Jul 2004 23:45:14 -0400 Message-Id: <20040708034514.157C31710A@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > From this definition of forgery, it would appear you are not referring > to Sender-ID. That shouldn't be news. The original LMAP discussion paper was written over 8 months ago for ASRG, before MARID was chartered. The latest draft was written weeks before the marid-core documents, so it couldn't possibly have referred to Sender-ID. From owner-ietf-mxcomp@mail.imc.org Wed Jul 7 23:57:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10150 for ; Wed, 7 Jul 2004 23:57:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i683nKHD090239; Wed, 7 Jul 2004 20:49:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i683nK8j090238; Wed, 7 Jul 2004 20:49:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i683nJSN090232 for ; Wed, 7 Jul 2004 20:49:20 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 07 Jul 2004 23:53:21 -0400 Received: from ([65.10.99.121]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 3069448547; Wed, 07 Jul 2004 23:53:19 -0400 Message-ID: <04d101c4649e$9b087690$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "Eric A. Hall" Cc: References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> <1334499281.20040707155408@brandenburg.com> <40EC3E38.8020000@ehsco.com> <265446025.20040708072531@brandenburg.com> <04c501c4649a$ce69adf0$6401a8c0@hdev1> Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) Date: Wed, 7 Jul 2004 23:49:41 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Hector Santos" To: "Dave Crocker" ; "Eric A. Hall" Cc: Sent: Wednesday, July 07, 2004 11:21 PM Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) >> Eric Said: >> >> but on the other hand the spammers aren't that smart in the >> short-term, >> Dave Said: >> >> spammers have proved to be smart, adaptable and quick. > Hector Said: > > The only evidence of adaption has been at 2822 and the hackers (the smarter > ones of the abuse crowd) finally realizing they can exploit some aspects of > 2821 - SORBIG! I would like to add or state I have seen no adaption as of yet at 2821. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 00:00:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10330 for ; Thu, 8 Jul 2004 00:00:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i683qlZv090481; Wed, 7 Jul 2004 20:52:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i683ql2l090480; Wed, 7 Jul 2004 20:52:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i683qlTC090473 for ; Wed, 7 Jul 2004 20:52:47 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 153711710A for ; Thu, 8 Jul 2004 00:00:03 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Wed, 07 Jul 2004 18:20:28 PDT." <1089249627.21236.333.camel@ddev.mail-abuse.org> Date: Thu, 08 Jul 2004 00:00:03 -0400 Message-Id: <20040708040003.153711710A@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (continuing... hit accidentally> Douglas Otis wrote: > From this definition of forgery, it would appear you are not referring > to Sender-ID. That shouldn't be news. The original LMAP discussion paper was written over 8 months ago for ASRG, before MARID was chartered. The latest draft was written weeks before the marid-core document, so it couldn't possibly have referred to Sender-ID. > This is important as Sender-ID is changing the scope of this > protection. The ASRG definition was based on an effort to reduce > mail traffic by examining RFC 2821 information. Sender-ID uses RFC > 2822 information and, as such, will not impact mail traffic. I never discussed Sender-ID until your recent question to me. Unless I'm misreading the charter, MARID is still considering RFC 2821 information, which is where my focus has always been. So I'm not sure why you're suddenly trying to poke holes in my "Sender-ID position", when I haven't publicly taken a position on it. > It also currently allows extensions beyond current definitions which > impacts this concern raised regarding DNS overhead. Please address those concerns to the authors of the Sender-ID document. I haven't said *anything* about it recently. > This change in the definition of forgery changes the benefit > equation, as there will be no relief from accepting the mail to > offset the load placed upon the DNS server. You should consider > revising this draft before using it as a reference. Since the document was never intended to address RFC 2822 information, I don't see why any revisions are necessary. I'm not going to respond to the rest of your message, as the issues you raise would best be addressed by the authors or proponents of Sender-ID. Since I have never publicly taken a position on Sender-ID (or even mentioned it, until you asked my opinion of it), I don't see why you would be asking me to explain or defend it. My focus in ASRG & here in MARID has been RFC 2821 identities. If MARID is no longer discussing RFC 2821 identities, then that's news to me. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 03:25:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03803 for ; Thu, 8 Jul 2004 03:25:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i687EqJ3053552; Thu, 8 Jul 2004 00:14:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i687EqS1053535; Thu, 8 Jul 2004 00:14:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i687Eor1053483 for ; Thu, 8 Jul 2004 00:14:51 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BiT7E-0002Ac-DU for ietf-mxcomp@imc.org; Thu, 08 Jul 2004 02:14:50 -0500 To: "IETF MARID WG" References: <20040708040003.153711710A@mail.nitros9.org> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 08 Jul 2004 02:14:44 -0500 In-Reply-To: <20040708040003.153711710A@mail.nitros9.org> (Alan DeKok's message of "Thu, 08 Jul 2004 00:00:03 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: the focus of MARID Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.4 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040708040003.153711710A@mail.nitros9.org> "Alan DeKok" writes: > My focus in ASRG & here in MARID has been RFC 2821 identities. If > MARID is no longer discussing RFC 2821 identities, then that's news to > me. It is my understanding that, according to the MARID charter, the chairs would choose identities for this working group to focus on, and other identities would be ruled out of scope. See the MARID description, paragraph four on: http://www.ietf.org/html.charters/marid-charter.html The identities selected were the 2821 identities, not the 2822 identities. See: http://www.imc.org/ietf-mxcomp/mail-archive/msg01161.html The Sender-ID proposal, for example, deals with the 2821 SUBMITTER identity, so it is in-scope. (Or, at least that's the explanation Andy gave me a while back.) Now, I must admit that I am somewhat confused on this subject. For example, I seem to recall several hums at the very end of the May interim meeting that changed the focus from 2821 to 2822, but they weren't in minutes and others didn't seem to remember such a thing. Who knows, I could easily be confused on this also. Speaking of confusing and minutes, I know that draft minutes for the May Interim meeting were posted to this list, but I don't remember seeing any final minutes and I can't find them on the MARID charter web page. Will minutes be published for the Interim meetings? -wayne From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 07:39:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15094 for ; Thu, 8 Jul 2004 07:39:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68BPTFD032032; Thu, 8 Jul 2004 04:25:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68BPTVp032031; Thu, 8 Jul 2004 04:25:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.dcsl.com (mail1.dcsl.com [62.49.132.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68BPRhH031981 for ; Thu, 8 Jul 2004 04:25:28 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from mail pickup service by mail1.dcsl.com with Microsoft SMTPSVC; Thu, 8 Jul 2004 12:23:36 +0100 Received: from above.proper.com ([208.184.76.39]) by mail1.dcsl.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Jul 2004 01:32:28 +0100 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i680Q6Kl073601; Wed, 7 Jul 2004 17:26:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i680Q6Dn073600; Wed, 7 Jul 2004 17:26:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i680Q6WY073594 for ; Wed, 7 Jul 2004 17:26:06 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i680Pxl01672; Wed, 7 Jul 2004 17:25:59 -0700 Date: Thu, 8 Jul 2004 07:25:31 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <265446025.20040708072531@brandenburg.com> To: "Eric A. Hall" CC: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <40EC3E38.8020000@ehsco.com> References: <20040705184119.3269517109@mail.nitros9.org> <40EABCEC.9010300@ehsco.com> <1334499281.20040707155408@brandenburg.com> <40EC3E38.8020000@ehsco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 08 Jul 2004 00:32:28.0531 (UTC) FILETIME=[0C6EFC30:01C46483] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric, EAH> but on the other hand the spammers aren't that smart in the short-term, spammers have proved to be smart, adaptable and quick. the current methods of spam-sending represent highly sophisticated, large-scale distributed systems. nothing has yet reduced the amount or impact of global spam. in fact, spam has only gotten monotonically worse. so we probably should be reticent to build a global standard that assumes the spammers will be slow-witted and slow-responding. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 10:05:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22635 for ; Thu, 8 Jul 2004 10:05:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Dr9Eu042767; Thu, 8 Jul 2004 06:53:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68Dr9Jn042766; Thu, 8 Jul 2004 06:53:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from turing-police.cirt.vt.edu (IDENT:root@turing-police.cirt.vt.edu [128.173.54.129]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Dr6KY042755 for ; Thu, 8 Jul 2004 06:53:07 -0700 (PDT) (envelope-from Valdis.Kletnieks@vt.edu) Received: from turing-police.cc.vt.edu (IDENT:valdis@turing-police.cc.vt.edu [127.0.0.1]) by turing-police.cc.vt.edu (8.13.0/8.13.0) with ESMTP id i68546Fw032743; Thu, 8 Jul 2004 01:04:06 -0400 Message-Id: <200407080504.i68546Fw032743@turing-police.cc.vt.edu> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4+dev To: Gordon Fecyk Cc: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Mon, 05 Jul 2004 18:13:57 CDT." <700EEF5641B7E247AC1C9B82C05D125DA909@srv1.pan-am.ca> From: Valdis.Kletnieks@vt.edu References: <700EEF5641B7E247AC1C9B82C05D125DA909@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1330455664P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 2004 01:04:05 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --==_Exmh_1330455664P Content-Type: text/plain; charset=us-ascii (Sorry for the late reply, it's been a zoo of a week) On Mon, 05 Jul 2004 18:13:57 CDT, Gordon Fecyk said: > It's just as bad with anti-virus. People have it drilled into their heads by > a clueless media, other clueless people, clueless sysadmins that anti-virus > must fail sometimes. In fact people buy AV tools with failure _in mind._[1] > I face this daily when I try to recommend Messagelabs' or Avecho's services - > how can you beat a 100% virus detection guarantee? So you've solved the Turing Halting Problem? ;) (Fred Cohen showed that virus detection is isomorphic to that, back in his PhD thesis, if I remember correctly)... http://www.all.net/books/virus/index.html --==_Exmh_1330455664P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFA7NXFcC3lWbTT17ARAuw+AJ4jlZHmLjwu7DOih3VkfQq7pWRXrwCg3kXw 5CzY07lBSx6d+jFUYDQYSTI= =Eyli -----END PGP SIGNATURE----- --==_Exmh_1330455664P-- From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 10:38:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27164 for ; Thu, 8 Jul 2004 10:38:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68EOT4P044858; Thu, 8 Jul 2004 07:24:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68EOTiT044857; Thu, 8 Jul 2004 07:24:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68EOTMQ044851 for ; Thu, 8 Jul 2004 07:24:29 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i68EOT1m009963 for ; Thu, 8 Jul 2004 07:24:29 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jul 2004 07:24:29 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: the focus of MARID Date: Thu, 8 Jul 2004 07:24:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I still fail to see how the identities matter. All we are doing here is listing the IP addresses of our outgoing mail servers. I can be absolutely certain that is all we are doing since that is all that we will be telling the network admins to do. The consequence of that is that by applying our knowledge of how the infrastructure works we can make some deductions. The SUBMITTER spec means that we can extend the scope of those deductions further to include RFC 2812. The forwarding problem means that we can only ever validate the last link in the chain and that as a result it is only ever possible to know with certainty that a message is genuine, it is not possible using the information from Sender-ID ALONE to know that a message is defnitively fake if it purports to be forwarded. I think that what we should be doing at this point is discussing how to express the set of IP addresses. That is the part that has the impact on what other people do. The main complaint I and many others have of SPF is that it has much too much flexibility. Even if you accept the need for factored records, the macro language is far more powerful than is necessary for that purpose. Phill > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of wayne > Sent: Thursday, July 08, 2004 3:15 AM > To: IETF MARID WG > Subject: the focus of MARID > > > > In <20040708040003.153711710A@mail.nitros9.org> "Alan DeKok" > writes: > > > My focus in ASRG & here in MARID has been RFC 2821 identities. If > > MARID is no longer discussing RFC 2821 identities, then > that's news to > > me. > > It is my understanding that, according to the MARID charter, the > chairs would choose identities for this working group to focus on, and > other identities would be ruled out of scope. See the MARID > description, paragraph four on: > http://www.ietf.org/html.charters/marid-charter.html > > The identities selected were the 2821 identities, not the 2822 > identities. See: > http://www.imc.org/ietf-mxcomp/mail-archive/msg01161.html > > The Sender-ID proposal, for example, deals with the 2821 SUBMITTER > identity, so it is in-scope. (Or, at least that's the explanation > Andy gave me a while back.) > > > Now, I must admit that I am somewhat confused on this subject. For > example, I seem to recall several hums at the very end of the May > interim meeting that changed the focus from 2821 to 2822, but they > weren't in minutes and others didn't seem to remember such a thing. > Who knows, I could easily be confused on this also. > > > Speaking of confusing and minutes, I know that draft minutes for the > May Interim meeting were posted to this list, but I don't remember > seeing any final minutes and I can't find them on the MARID charter > web page. > > > Will minutes be published for the Interim meetings? > > > -wayne > From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 11:09:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29189 for ; Thu, 8 Jul 2004 11:09:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Es6rJ046698; Thu, 8 Jul 2004 07:54:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68Es61C046697; Thu, 8 Jul 2004 07:54:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Es13E046688 for ; Thu, 8 Jul 2004 07:54:03 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id A9C5716CCB for ; Thu, 8 Jul 2004 11:01:12 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Thu, 08 Jul 2004 09:24:37 +0700." <1606182406.20040708092437@brandenburg.com> Date: Thu, 08 Jul 2004 11:01:12 -0400 Message-Id: <20040708150112.A9C5716CCB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > Interesting analogy. Let's explore it a bit. Analogies are useful, but not a perfect mapping to what they're describing. > Bandages do not promote healing; in fact they reduce it. Their > legitimate job is to keep dirt out. I've worked in a clean-room environment. Bandages aren't very useful there. I've also worked on a farm, shovelling "fertilizer". Bandages are a requirement there. Bandages are a *situational* solution to a temporary problem. This is exactly how I see MARID. My situation may be helped by MARID, and yours may not be. That probably explains our respective positions. > The biggest worry about 'the nature of what it is in response to' is > that it has us chasing symptoms rather than causes. Do you have a solution which addresses the cause? > Spammers have proved to be astonishingly and quickly adaptable In some situations. In others, they are astonishingly idiotic. Once again, the behavior is situational. > This means we will always be chasing the latest symptom, rather than > going to any core characteristics of the "disease". Do you have a solution which addresses the cause? If not, why do you keep repeating this, as though it's relevant? To address your analogy, please read a medical compendium containing descriptions of diseases and their treatments. In many cases, the phrase to note is "treatment is symptomatic". That is, there is no cure, or the cure is too expensive, or the cure would take more time than letting the disease run its course. Therefore, the only relevant treatment is to address the symptoms. This is where your analogy of "disease" is directly on point. We have no cure for the "disease" of spam. We do know how to treat certain symptoms, and some people are starting that treatment. Despite the known symptoms and known treatment, others appear to be have problems with treating the symptoms, because that treatment isn't a cure. I must admit I'm confused by that attitude. Sumptomatic treatment isn't a cure, and no one expects it to be a cure. It's simply a stop-gap until a cure is found. But I don't see how treating the symptoms in any way prevents a cure from being found. > Global standards are not used individually and they are not used > selectively. They are for interoperable situations. The result > means that applying a bandage becomes a required part of everyone's > contact with anyone else, everytime. Why? You've made a leap from MARID being used by cooperating peers, to it being: a) "required" somehow, by some fiat b) used by everyone (even people who don't want to use it?) c) used always (even when whitelists make it unnecessary?) I'm confused as to why you keep making those claims, when the scope of the proposals are significantly narrower than you would make them seem. > All in all, this means that we are discussing major, strategic changes > to the email infrastructure, for minor, tactical, transient benefits. I guess my examples of how MARID can have permanent benefits didn't make it from the list to your inbox. Or maybe you think that a permanent way of treating symptom is useful only in the short term. e.g. open proxies. The symptom (abuse of open proxies) was treated by closing them down. Spammers no longer use open proxies in the same volume that they used to. But does this mean we can go back to setting up open proxies? Of course not... but you're making that same argument for methods to treat forgeries. > I'd be interested in hearing of examples of useful global standards > that have had similar properties. Since you've defined the situation to be a straw man of your own invention, you are, of course, perfectly right. No such global standards exist. > AD> To put it yet another way, MARID can be thought of as a set of > AD> distributed DNSBL's. > > Sorry, but CSV follows the BL construct, marid-core does not. Terminology. I was referring to the work in the MARID group, not to a proposal. (Which is called what, Sender-ID? Or did the WG decide that marid-core was the protocol we will standardize, and that we would call it MARID? I must have missed that...) > AD> Each domain operates its own DNSBL (or > AD> whitelist), which use a well-known format. > > And each domain is supposed to maintain this list how, exactly? Note > that the question is particularly relevant when spammers are quickly > obtaining and using new domains with clean records. I think you're missing my point. My intent was to say that each domain maintains a DNSBL (or whitelist) of IP's which it permits to use it's name. That's the basic concept behind MARID. Having domains maintain BL's about others is expensive and pointless. > AD> None of this is new to the net. DNS already tells peers where to > AD> find information (e.g. MX's), > > THat's not what MX does. MX is a routing record, not a query record. The intent of MX is that it is *interpreted* as a routing record. The MX record itself is stored in DNS, which any client may query. I can query for an MX record, and then never use that information to perform routing. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 12:35:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07623 for ; Thu, 8 Jul 2004 12:35:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68GG70M054036; Thu, 8 Jul 2004 09:16:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68GG7KC054035; Thu, 8 Jul 2004 09:16:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68GG6H4054029 for ; Thu, 8 Jul 2004 09:16:06 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i68GFpl14437; Thu, 8 Jul 2004 09:15:52 -0700 Date: Thu, 8 Jul 2004 23:15:40 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <261467659.20040708231540@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <20040708150112.A9C5716CCB@mail.nitros9.org> References: Your message of "Thu, 08 Jul 2004 09:24:37 +0700." <1606182406.20040708092437@brandenburg.com> <20040708150112.A9C5716CCB@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan, >> Spammers have proved to be astonishingly and quickly adaptable AD> In some situations. In others, they are astonishingly idiotic. AD> Once again, the behavior is situational. the folks who command estimated millions of compromised machines, with a 3- or 4-tier control hierarchy, do not count as idiotic. let's design mechanisms that deal with those guys. the rest are irritating but they are mere noise. >> This means we will always be chasing the latest symptom, rather than >> going to any core characteristics of the "disease". AD> Do you have a solution which addresses the cause? yes, but, i've been asked to refrain from pursuing that topic for a few weeks... AD> If not, why do you keep repeating this, as though it's relevant? i've explained the reason quite a few times. just so it is not missed again: Effort on a global standard that deals with a transient symptom is certain to have minimal, transient benefit, if any, but with very large opportunity and on-going costs. AD> To address your analogy, If you mean bandages, it's not mine. you introduced it, as i recall. I was simply trying to pursue it. AD> please read a medical compendium containing AD> descriptions of diseases and their treatments. In many cases, the AD> phrase to note is "treatment is symptomatic". Please show me a successful, global standard that has been designed to respond to one set of symptoms, when the source of those symptoms is constantly adapting, guaranteeing that the symptoms will become irrelevant as soon as the response begins to take effect. You characterize my query as using a straw man. However it is the conceptual summary of the current effort, from the standpoint of standard-based intervention to fix a problem. so it is not a 'straw man' because it is not creating a convenient hypothetical. it is a description of the current effort. feel free to find fault with it, preferably by citing which parts of the summary are wrong, and how. >> Global standards are not used individually and they are not used >> selectively. They are for interoperable situations. The result >> means that applying a bandage becomes a required part of everyone's >> contact with anyone else, everytime. AD> Why? You've made a leap from MARID being used by cooperating peers, AD> to it being: AD> a) "required" somehow, by some fiat to be at all effective, the mechanism must be used all the time and we will never know when or if we can stop using it. (it's in the nature of aversion reinforcement training.) that is tantamount to requiring its use forever. AD> b) used by everyone (even people who don't want to use it?) if they want their mail to get through, yes. AD> c) used always (even when whitelists make it unnecessary?) whitelists are accreditation. the marid-core is about authentication and authorization. they are independent. >> AD> To put it yet another way, MARID can be thought of as a set of >> AD> distributed DNSBL's. >> Sorry, but CSV follows the BL construct, marid-core does not. AD> Terminology. no, computer science. the difference between accreditation, versus authentication and authorization, is basic. AD> I was referring to the work in the MARID group, not to AD> a proposal. (Which is called what, Sender-ID? Or did the WG decide AD> that marid-core was the protocol we will standardize, and that we AD> would call it MARID? I must have missed that...) marid-core is the only working group document with a specification currently under discussion. whatever else folks might be mentioning, there is no working group document for it. >> AD> Each domain operates its own DNSBL (or >> AD> whitelist), which use a well-known format. >> And each domain is supposed to maintain this list how, exactly? Note >> that the question is particularly relevant when spammers are quickly >> obtaining and using new domains with clean records. AD> I think you're missing my point. My intent was to say that each AD> domain maintains a DNSBL (or whitelist) of IP's which it permits to AD> use it's name. the term whitelist usually refers to hosts or networks with behavior that is deemed likely to be acceptable to the receiver, not the sender. no, that's not quibbling. it goes to the difference between authorization and accreditation. AD> That's the basic concept behind MARID. Having domains AD> maintain BL's about others is expensive and pointless. pointless? so spamhaus and all those other lists are pointless? >> THat's not what MX does. MX is a routing record, not a query record. AD> The intent of MX is that it is *interpreted* as a routing record. it's the semantics of the record, not the "intent". d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 13:36:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11939 for ; Thu, 8 Jul 2004 13:36:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68HNwG3059881; Thu, 8 Jul 2004 10:23:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68HNwH2059880; Thu, 8 Jul 2004 10:23:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68HNpvU059843 for ; Thu, 8 Jul 2004 10:23:51 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i68HNs1m008077; Thu, 8 Jul 2004 10:23:54 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jul 2004 10:23:54 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dave Crocker'" , Alan DeKok Cc: ietf-mxcomp@imc.org Subject: RE: Forging (was Re: Differences between CSV and Sender-ID ) Date: Thu, 8 Jul 2004 10:23:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >> Spammers have proved to be astonishingly and quickly adaptable > AD> In some situations. In others, they are astonishingly idiotic. > AD> Once again, the behavior is situational. > > the folks who command estimated millions of compromised machines, with > a 3- or 4-tier control hierarchy, do not count as idiotic. > > let's design mechanisms that deal with those guys. the rest are > irritating but they are mere noise. Alan is right in pointing out that we should not overestimate these guys. Sure it is very clever to set up 3-tier botnets. Our intervention center discovers a lot of very clever stuff. But no, these guys are not half as smart as they think they are. These guys can do stuff that is amazingly complex one minute and then something really really stupid the next. Like the guys who tried to phish VeriSign on three separate occasions and used the exact same ISP in every attack. The whole theory of the type of intervention we do is that you put pressure on the attacker, the more pressure you put on them the more they are forced to react, the more likely they are to make a mistake. If you look at the first attack on the WTC, the perpetrators were captured because one of them went off to claim their deposit from the truck rental company. Ever wondered why Al Qaeda uses suicide bombers in attacks that don't need them? The guys who you can get to do that sort of stuff are not the sharpest knives in the drawer. Having them commit suicide during the attack means that the leadership don't have to worry about them getting caught. > Effort on a global standard that deals with a transient symptom is > certain to have minimal, transient benefit, if any, but with very > large opportunity and on-going costs. Everyone accepts the fact that there is a forwarding hole in SenderID. Fortunately Sender-ID is the first move, not the last. With Sender-ID you can always authenticate the party that purports to be the last link in the chain. Therefore I expect the deployment of Sender-ID to follow something like the following patterm: Phase-1: Senders are required to issue Sender-ID records. Phase-2: Forwarding specialists are required to provide either an accreditation proof or a proof of consent. Phase-3: All Senders are required to provide accreditation proofs. By 'required' I mean, that if you want to reliably send your mail to one of the major ISPs (and many smaller ones) you are going to have to comply. Over time I expect that AOL and MSN will be wanting to power down the huge server farms they currently run for the sole purpose of running spam filtering schemes. If you want to send email you are going to have to comply. Sure this is going to be unpopular in Boca Raton, Florida, and possibly other places. But at the end of the day insecure email has failed and the only choice left is a transition to secure email. > Please show me a successful, global standard that has been > designed to respond to > one set of symptoms, when the source of those symptoms is constantly > adapting, guaranteeing that the symptoms will become irrelevant as > soon as the response begins to take effect. Please show me a successful IETF security standard. Every attempt to develop end to end solutions has been a miserable failure. The only security protocol that has been successful is SSL which was successful independently. > no, computer science. > > the difference between accreditation, versus authentication and > authorization, is basic. Yes, and the MARId group continue to insist on calling a record that contains an authentication credential an authorization record. But this does not actually matter much, it just leads to fuzzy thinking. Accreditation is actually a new term introduced to describe what we used to call third party attribute assertions. > no, that's not quibbling. it goes to the difference between > authorization and accreditation. Yes, I certainly agree here. There has to be an accreditation component. > AD> That's the basic concept behind MARID. Having domains > AD> maintain BL's about others is expensive and pointless. > > pointless? so spamhaus and all those other lists are pointless? There is a big, big problem with the blackists. If you only list negative reputation you end up having to measure the whole world against a set of criteria that is imposed unilaterally. Allowing the sender to nominate the accreditation services that are relevant allows the search for positive reputation data from a source trusted by the recipient can be narrowed. This means that the market for accreditation services can contain both the 500,000 domain VDL that we publish and smaller lists from other providers with a few hundred entries. Phill From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 15:14:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20134 for ; Thu, 8 Jul 2004 15:14:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Ipbhx066254; Thu, 8 Jul 2004 11:51:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68IpbWM066253; Thu, 8 Jul 2004 11:51:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Ipaar066247 for ; Thu, 8 Jul 2004 11:51:36 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 20F921D651 for ; Thu, 8 Jul 2004 11:51:38 -0700 (PDT) Date: Thu, 08 Jul 2004 11:51:38 -0700 From: Greg Connor To: MARID Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) Message-ID: <12885268.1089287498@Ryoga.corp.sgi.com> In-Reply-To: <1089249627.21236.333.camel@ddev.mail-abuse.org> References: <1089249627.21236.333.camel@ddev.mail-abuse.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Douglas Otis wrote: > From this definition of forgery, it would appear you are not referring > to Sender-ID. This is important as Sender-ID is changing the scope of > this protection. The ASRG definition was based on an effort to reduce > mail traffic by examining RFC 2821 information. Sender-ID uses RFC 2822 > information and, as such, will not impact mail traffic. This point assumes that mail traffic will continue at the same level, even when messages are being rejected post-data. Spammers don't want to spend time and bandwidth on a losing transaction any more than receivers do. I assume the opposite: that when forgeries are being detected (even after DATA) that the traffic causing the failed messages WILL go down. This is based on the idea that spammers will adapt in order to get their messages through. >> If a DNS server holding MARID information isn't robust, then it will >> most likely also fail for MX records, in addition to MARID records. > > The rate that a Sender-ID SMTP receiver queries DNS versus that needed > to find an MX server by the SMTP sender are significantly different in > terms of both the number of queries and the serial sequence required. > The loads and delays are not comparable to allow such an analogy to > dismiss these concerns. I think the previous message was referring to MX records being looked up by the receiver (to see if the sender's MX is 127.0.0.1 for example). I believe most MARID DNS queries will be 1 or 2 per transaction and can be cached easily. I have seen nothing to suggest that the relationship is other than linear. Therefore I dismiss "these concerns" which seem to suggest that the relationship is geometric or exponential or whatever. It doesn't make sense, and is not borne out by the early adopters of SPF. > >> I don't see how "robustness" matters more for DNS when it contains >> MARID records than when it doesn't. Sure, more records are being >> looked up in DNS, but many MTA's already do MX lookups when receiving >> mail "from" a domain, in an attempt to implicitly discover the domain >> owners intent, even when there's no standard saying that they should >> do this. > > Scale and Scope > > The complex linked nature of these records becomes important as this is > indicative of limitations Sender-ID has with respect to scale. An MX > record only refers to a set of hosts that "receive" mail for a domain. > As SMTP allows this mail to be relayed, there may be many times this > number of hosts that "send" mail for the same domain. In addition, all > other domains that may originate mail on behalf of this domain are to be > expressed by this Sender-ID record set. In addition, these records also > reflect other domains that may also share these hosts. An MX record is > never expected to be so expansive in scope nor is comparative to the > potential size of such a response. This still excludes the "added" > features. : 0 Hmm, this paragraph also seems to contain high FUD-to-fact ratio. >> Or, do you see Sender-ID as having an amplification problem? e.g. >> If MARID queries increased super-linearly with the number of >> connections. If so, it would be a serious flaw in the proposal. > > Serious indeed. Hmm, in that case I would be interested to see any information that leads a reasonable person to believe that the relationship is not linear. (hint: y=20x is a linear relationship) -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 15:19:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21109 for ; Thu, 8 Jul 2004 15:19:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68J5FWG067252; Thu, 8 Jul 2004 12:05:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68J5FU2067251; Thu, 8 Jul 2004 12:05:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68J5E6f067244 for ; Thu, 8 Jul 2004 12:05:15 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B60F116CCB for ; Thu, 8 Jul 2004 15:12:27 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Thu, 08 Jul 2004 23:15:40 +0700." <261467659.20040708231540@brandenburg.com> Date: Thu, 08 Jul 2004 15:12:27 -0400 Message-Id: <20040708191227.B60F116CCB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > >> Spammers have proved to be astonishingly and quickly adaptable > AD> In some situations. In others, they are astonishingly idiotic. > AD> Once again, the behavior is situational. > > the folks who command estimated millions of compromised machines, with > a 3- or 4-tier control hierarchy, do not count as idiotic. I have two responses: a) please re-read what I wrote. I said SOME are idiotic, not ALL. It's rude to cherry-pick a complicated scenario, and make it sound like I said those people were dumb. I didn't. b) Don't mistake "script kiddies" for people with a clue, or for spammers. Computers have things called "scripts" or "programs" which idiots can run to perform complicated tasks. And idiots can buy CPU time on "owned" machines from smart people, and use that time to send spam. > i've explained the reason quite a few times. just so it is not missed > again: Shall I re-post my standard response? I don't feel we're communicating here. I try to explain my position in response to your posts, and your replies simply re-state your position. Did you think I didn't read your comments? Or maybe I didn't understand them? I thought my responses explained not only that I understood them, but that I disagreed. I even gave reasons why. > AD> To address your analogy, > > If you mean bandages, it's not mine. you introduced it, as i recall. > I was simply trying to pursue it. Uh, no. You called spam a "disease", which is either an analogy, or perjorative term. My later sentences followed the disease analogy, and didn't discuss bandages. Perhaps you were confused that both analogies had medical roots. > Please show me a successful, global standard that has been designed > to respond to one set of symptoms, when the source of those symptoms > is constantly adapting, guaranteeing that the symptoms will become > irrelevant as soon as the response begins to take effect. I could swear I had addressed that comment in my previous message. > AD> That's the basic concept behind MARID. Having domains > AD> maintain BL's about others is expensive and pointless. > > pointless? so spamhaus and all those other lists are pointless? I am continually amazed at how what appears to me to be simple english is construed to mean the most idiotic things. What I was originally discussing was ideas from this WG: domains hosting policy information about themselves in DNS. RMX, SPF, CSV, and Sender-ID all fall into this category. My comments that MARID could be construed as domains maintaining black/whitelists were intended to be taken in the context of this WG: domains maintain policy information about themselves, and that information may be used by others as input to blacklists/whitelists. You seemed to interpret that statement as saying that every domain would have to maintain information about every other domain. And when I said that was pointless, you suddenly switched to thinking that I was claiming DNSBL's were pointless. Can you explain to me how I can write simple english sentences on this list, so you don't interpret them as being blindingly idiotic statements? I'm appalled at how badly we're communicating. For the record, I believe I understand your opinion very well. You think temporary measures aren't permanent solutions. I agree. You think that these temporary measures require some kind of global coordination before they will work. I don't see why. You think that we should be looking for cures, rather than temporary measures. I agree. Where I disagree with you is in the utility of the temporary measures. You seem to think they have no longer-term utility, and I've tried to demonstrate why I think you're wrong. Rather than address my concerns, you just repeat your position. I don't see why this approach would be considered communication. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 15:24:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21466 for ; Thu, 8 Jul 2004 15:24:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68JG3KE068455; Thu, 8 Jul 2004 12:16:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68JG3fs068454; Thu, 8 Jul 2004 12:16:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68JG390068448 for ; Thu, 8 Jul 2004 12:16:03 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 2593C1D651 for ; Thu, 8 Jul 2004 12:16:07 -0700 (PDT) Date: Thu, 08 Jul 2004 12:16:07 -0700 From: Greg Connor To: "'IETF MARID WG'" Subject: RE: the focus of MARID Message-ID: <14354380.1089288967@Ryoga.corp.sgi.com> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --"Hallam-Baker, Phillip" wrote: > > I still fail to see how the identities matter. > > All we are doing here is listing the IP addresses of our outgoing > mail servers. > > I can be absolutely certain that is all we are doing since that is > all that we will be telling the network admins to do. I agree with Phill here. > The forwarding problem means that we can only ever validate the last > link in the chain and that as a result it is only ever possible > to know with certainty that a message is genuine, it is not possible > using the information from Sender-ID ALONE to know that a message is > defnitively fake if it purports to be forwarded. Agreed. The message should be shown as "from the forwarder" because that is the only step we are able to verify by IP. (If the receiver is not using a forwarding service, he will probably see the actual sender's verification, in which case LMAP has done its job and all is well.) In the future, if MARID is a success, I can see *maybe* applying a whitelist of trusted forwarders, and if the forwarder (or list robot) is trusted, using the previous-hop info that they recorded. But, this is a long-term stretch goal. MARID-brand LMAP has value in/of itself even if we never take this second step. > I think that what we should be doing at this point is discussing > how to express the set of IP addresses. That is the part that has > the impact on what other people do. > > The main complaint I and many others have of SPF is that it has > much too much flexibility. Even if you accept the need for > factored records, the macro language is far more powerful than > is necessary for that purpose. Yes, this is a frequent complaint, though I think each of the macros are there because someone came up for a reasonable explanation why they might be needed (maybe for logging or creating bounce-explanation messages and not for actual delivery). Would you like to take a stab at naming some macros to be dropped? (And yes, it's a serious suggestion; I'm not trying to be facetious or anything :) -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 16:08:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24940 for ; Thu, 8 Jul 2004 16:08:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68JsWk1072598; Thu, 8 Jul 2004 12:54:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68JsWgj072597; Thu, 8 Jul 2004 12:54:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68JsVjw072591 for ; Thu, 8 Jul 2004 12:54:31 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id i68JsaXM027320; Thu, 8 Jul 2004 12:54:36 -0700 Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jul 2004 12:54:36 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Greg Connor'" , "'IETF MARID WG'" Subject: RE: the focus of MARID Date: Thu, 8 Jul 2004 12:54:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > In the future, if MARID is a success, I can see *maybe* applying a > whitelist of trusted forwarders, and if the forwarder (or > list robot) is > trusted, using the previous-hop info that they recorded. > But, this is a > long-term stretch goal. MARID-brand LMAP has value in/of > itself even if we > never take this second step. One point I forgot. Even if all MARID does is to make life easier for mailing list admins it is a start. Serious amounts of spam get sent at mailing lists. If you restrict posting to members only there is no real need to moderate every post provided that you can authenticate the sender. All you need to do is to put new users on probationary status. The fact that most mailing lists are getting moderated indicates to me that there is a serious amount of forgery using mailing list archives to seed the from addresses. Phill From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 16:54:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27753 for ; Thu, 8 Jul 2004 16:54:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Kc32M076060; Thu, 8 Jul 2004 13:38:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68Kc3bq076059; Thu, 8 Jul 2004 13:38:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Kc3PB076031 for ; Thu, 8 Jul 2004 13:38:03 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 83A15414FE; Thu, 8 Jul 2004 13:37:58 -0700 (PDT) Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) From: Douglas Otis To: Greg Connor Cc: MARID In-Reply-To: <12885268.1089287498@Ryoga.corp.sgi.com> References: <1089249627.21236.333.camel@ddev.mail-abuse.org> <12885268.1089287498@Ryoga.corp.sgi.com> Content-Type: text/plain Message-Id: <1089319077.21784.310.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 08 Jul 2004 13:37:57 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-08 at 11:51, Greg Connor wrote: > --Douglas Otis wrote: > > > From this definition of forgery, it would appear you are not referring > > to Sender-ID. This is important as Sender-ID is changing the scope of > > this protection. The ASRG definition was based on an effort to reduce > > mail traffic by examining RFC 2821 information. Sender-ID uses RFC 2822 > > information and, as such, will not impact mail traffic. > > This point assumes that mail traffic will continue at the same level, even > when messages are being rejected post-data. Spammers don't want to spend > time and bandwidth on a losing transaction any more than receivers do. I > assume the opposite: that when forgeries are being detected (even after > DATA) that the traffic causing the failed messages WILL go down. This is > based on the idea that spammers will adapt in order to get their messages > through. Trojans sending much of the viruses (for more Trojans) and spam (for revenue) are not concerned about full compliance to a specification, nor do they implement proper states for an SMTP client. Why attribute abuse to malevolent intent when expediency is more likely a principle motivation. So stopping a message after wasting the full bandwidth of the rejected message may seem like a small concern, but there may be another 100,000 more of these Trojans requesting service. The extra bandwidth to get them to leave is never recovered by their rejection. In addition, many of these spammers use a technique that appends a random sub-domain resolved using a wildcarded record as a means to obfuscate filters. It also means data needed for a repeated visit or a repeated message will not be in a DNS cache. A loss of even more bandwidth on the DNS queries, possibly more than from the messages being checked. > >> If a DNS server holding MARID information isn't robust, then it will > >> most likely also fail for MX records, in addition to MARID records. > > > > The rate that a Sender-ID SMTP receiver queries DNS versus that needed > > to find an MX server by the SMTP sender are significantly different in > > terms of both the number of queries and the serial sequence required. > > The loads and delays are not comparable to allow such an analogy to > > dismiss these concerns. > > > I think the previous message was referring to MX records being looked up by > the receiver (to see if the sender's MX is 127.0.0.1 for example). > > I believe most MARID DNS queries will be 1 or 2 per transaction and can be > cached easily. I have seen nothing to suggest that the relationship is > other than linear. Therefore I dismiss "these concerns" which seem to > suggest that the relationship is geometric or exponential or whatever. It > doesn't make sense, and is not borne out by the early adopters of SPF. Could you explain the premise used for this assumption? > >> I don't see how "robustness" matters more for DNS when it contains > >> MARID records than when it doesn't. Sure, more records are being > >> looked up in DNS, but many MTA's already do MX lookups when receiving > >> mail "from" a domain, in an attempt to implicitly discover the domain > >> owners intent, even when there's no standard saying that they should > >> do this. > > > > Scale and Scope > > > > The complex linked nature of these records becomes important as this is > > indicative of limitations Sender-ID has with respect to scale. An MX > > record only refers to a set of hosts that "receive" mail for a domain. > > As SMTP allows this mail to be relayed, there may be many times this > > number of hosts that "send" mail for the same domain. In addition, all > > other domains that may originate mail on behalf of this domain are to be > > expressed by this Sender-ID record set. In addition, these records also > > reflect other domains that may also share these hosts. An MX record is > > never expected to be so expansive in scope nor is comparative to the > > potential size of such a response. This still excludes the "added" > > features. : 0 > > > Hmm, this paragraph also seems to contain high FUD-to-fact ratio. Sending hosts > Receiving hosts (increases scale and scope) Originating domains > Receiving domain (increases scale and scope) Receiving Domain sets > Receiving domain (increases scale and scope) What are you disputing by making such a statement? My premise is that abuse of published partial lists left open will ensure either the removal of these records, or an attempt to fully publish a comprehensive record set. A desire to delegate to other domains providing services runs the risk that as they add a few indirections, this may cause hard errors and the complete loss of mail service without the administrator of the domain having done anything atypical or perhaps having done nothing. > >> Or, do you see Sender-ID as having an amplification problem? e.g. > >> If MARID queries increased super-linearly with the number of > >> connections. If so, it would be a serious flaw in the proposal. > > > > Serious indeed. > > > Hmm, in that case I would be interested to see any information that leads a > reasonable person to believe that the relationship is not linear. (hint: > y=20x is a linear relationship. In reference to the information added to the core document http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt Pg. 18: 5.4 Recursion Limitations Evaluation of many of the mechanisms in section 5.1 will require additional DNS lookups. To avoid infinite recursion, and to avoid certain denial of service attacks, an MTA or other processor SHOULD limit the total number of DNS lookups that it is willing to perform in the course of a single authentication. Such a limit SHOULD allow for at least 20 lookups. If such a limit is exceeded, the result of authentication MUST be "hardError". MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to perform an authentication. Such a limit SHOULD allow at least 10 seconds. If such a limit is exceeded, the result of authentication SHOULD be "transientError". Domains publishing records SHOULD keep the number of DNS lookups to less than 20. Domains publishing records that are intended for use as the target of "indirect" elements SHOULD keep the number of DNS lookups to less than 10. Using an assumption that Sender-ID records are able to limit the required queries to 10 and set the "transientError" timeout at 10 seconds, what will be the impact on network integrity? The transport for SMTP uses TCP, but now Sender-ID interjects 10 UDP queries per message that "must" occur or the connection suffers a temporary error event requiring a repeat of a message transfer. The default for a resolver lookup timeout is typically set to 5 seconds (a minimum of 2 seconds) as RFC 1035 recommends, where 10 seconds is considered worst case. Should there be a another timeout, this limit often doubles. The connection is tasked with making 10 UDP queries within 10 seconds however. Should the network suffer a 5% packet loss rate, then 1 packet will be lost on average within these 10 lookups. This will invoke the 5 second timeout which then reduces the time for the remainder of the queries (possibly leaving half a second apiece to resolve each new query). Depending upon the distribution of lost packets, the connection could be lost after reception of the first message, only to be retried again later and could make a large transfer of messages impractical. TCP used for SMTP could deal with this packet loss rate, but because of Sender-ID and these many queries with a short timeout, the integrity of SMTP is significantly reduced. If the timeout are restored to normal limits for these DNS queries, Sender-ID may dramatically reduce performance of the SMTP server and the reason for imposing the hazardous time constraint. The trade-off becomes either a possibly dramatic reduction in performance of the SMTP server, or a dramatic reduction in the network integrity for the SMTP server during times of network congestion. The use of the RFC 2822 identities for Sender-ID means messages are transferred regardless whether they become rejected. A loss of integrity will then add to network congestion and thereby possibly leading to a collapse of the network due to the non-linear effect caused by congestion, redundant transfers by Sender-ID, and the reduced network integrity. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 16:54:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27771 for ; Thu, 8 Jul 2004 16:54:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Kcrha076102; Thu, 8 Jul 2004 13:38:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68Kcr5B076101; Thu, 8 Jul 2004 13:38:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68KcpXe076092 for ; Thu, 8 Jul 2004 13:38:52 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 31A00132CDB; Thu, 8 Jul 2004 16:38:47 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id F107567D; Thu, 8 Jul 2004 16:38:46 -0400 (EDT) Date: Thu, 8 Jul 2004 16:38:46 -0400 From: Meng Weng Wong To: Greg Connor , markl@glyphic.com, wayne@midwestcs.com Cc: "'IETF MARID WG'" Subject: some thoughts on SUBMITTER Message-ID: <20040708203846.GD16317@dumbo.pobox.com> References: <14354380.1089288967@Ryoga.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14354380.1089288967@Ryoga.corp.sgi.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jul 08, 2004 at 12:16:07PM -0700, Greg Connor wrote: | | >The forwarding problem means that we can only ever validate the last | >link in the chain and that as a result it is only ever possible | >to know with certainty that a message is genuine, it is not possible | >using the information from Sender-ID ALONE to know that a message is | >defnitively fake if it purports to be forwarded. | | Agreed. The message should be shown as "from the forwarder" because that | is the only step we are able to verify by IP. (If the receiver is not | using a forwarding service, he will probably see the actual sender's | verification, in which case LMAP has done its job and all is well.) I would like to suggest we keep in mind: Where the mass majority of normal email is concerned, forwarding is an edge case. Failure of SenderID due to noncompliant forwarding is a corner case. Therefore the failure scenario should be noted in detail and announced to the industry so that troubleshooters can recognize it when it happens. But it is not big enough a problem to keep us from moving forward. We should also keep in mind the positive scenario for SenderID: If the mail is sent directly from Citibank to enduser, then SenderID returns an authentication PASS, and the reputation system returns a thumbs up, so the message gets a positive overall result, and the MUA displays a little green light or whatever. The positive scenario is the scenario we are trying to enable. At the highest levels, this is also true: we're moving toward a paradigm of "assumed guilty until proven innocent" (AGUPI). In the AGUPI paradigm, the positive scenario becomes the goal, and anything that falls short is deemed to be in the YMMV zone. Legitimate senders are assumed to have the means, motive, and the opportunity to do what it takes to get themselves into the positive scenario. Legitimate forwarders are also assumed to have the means, motive, and opportunity to do their part, which is to say, prepend a header and add SUBMITTER. * * * I also want to point out that SUBMITTER: - should appear rarely, - is more flexible than it seems, and - is amenable to AGUPI practices, which is to say unrecognized SUBMITTERs can be safely rejected. I will explain each of these points. * SUBMITTER should appear rarely. SUBMITTER need not be used when the MAIL-FROM is identical to the Sender. This is a very common case. * SUBMITTER is more flexible than it seems. Even if the MAIL-FROM is different from the Sender, SUBMITTER may still not need to be provided by the sender MTA. Why? SenderID stipulates that the PRA must match the SUBMITTER; a transaction in which PRA does not match SUBMITTER is deemed to be noncompliant. In discussion with Daniel Quinlan, he asked if that means an MDA needs to have access to SUBMITTER. This is when it dawned on me that in practice, PRA doesn't always need to match SUBMITTER. After all, it's meant as an optimization. If it isn't there, the PRA algorithm still works. A receiver need test only two of the following three: - The PRA in the headers authenticates and passes reputation. - The SUBMITTER in the envelope authenticates and passes reputation. - The PRA must match the SUBMITTER. This opens the door to a disconnect between PRA and SUBMITTER. Is this exploitable? I don't think so, because for anti-phishing purposes, we really only want the end-user-visible address (the PRA) to authenticate and pass reputation. SUBMITTER is an optimization. If the SUBMITTER authenticates, and the PRA authenticates, then they're really both okay. They don't have to be the same! Example: MAIL FROM: SUBMITTER= Resent-Sender: From: The PRA is real-alias@pobox.com. SUBMITTER is anonymous@pobox.com. But both will pass authentication! But anyway, this is a distraction. * SUBMITTER can be safely rejected when it is not recognized. When does SUBMITTER occur? In forwarding. What is the difference between legitimate forwarding and spam trying to masquerade as a forwarder? In legitimate forwarding, I know that mengwong@pobox.com forwards to me; it is my alias, and I am responsible for setting up that relationship. If I see mail that says MAIL FROM: SUBMITTER= I know that it's good. If I see MAIL FROM: SUBMITTER= then maybe it's a spammer trying to joe-job original@sender.com. If the above is true, we can apply AGUPI. We can simply construct a per-recipient whitelist of recognized SUBMITTER addresses. And we can reject everything else. So I hope the above discussion has illuminated the role of SUBMITTER in more detail. From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 17:29:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01748 for ; Thu, 8 Jul 2004 17:29:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68LEhlF080153; Thu, 8 Jul 2004 14:14:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68LEhMA080152; Thu, 8 Jul 2004 14:14:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68LEg42080146 for ; Thu, 8 Jul 2004 14:14:42 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 87A5D132CD1; Thu, 8 Jul 2004 17:14:46 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 63167672; Thu, 8 Jul 2004 17:14:46 -0400 (EDT) Date: Thu, 8 Jul 2004 17:14:46 -0400 From: Meng Weng Wong To: "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: terminology: authentication / authorization Message-ID: <20040708211446.GE16317@dumbo.pobox.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jul 08, 2004 at 10:23:48AM -0700, Hallam-Baker, Phillip wrote: | | Yes, and the MARId group continue to insist on calling a record that | contains an authentication credential an authorization record. But | this does not actually matter much, it just leads to fuzzy thinking. Perhaps it depends on point of view. From the sender's point of view, the record authorizes MTAs to use the sender's name. From the receiver's point of view, the record authenticates MTAs as being permitted by the sender. If you have been thinking in terms of one of those points of view, try turning the chessboard around and put yourself in the other person's shoes. Whether the receiver then wants to authorize further delivery is a policy matter dependent on reputation which depends on (you guessed it) accreditation. In the simplest case, if a receiver chooses to trust all accreditors, their reputation system component is essentially a "| cat |". In the next simplest case, a receiver chooses to trust only certain accreditors of good repute, their reputation system is essentially a "| egrep 'acc1|acc2|acc3...' |" | There is a big, big problem with the blackists. If you only | list negative reputation you end up having to measure the | whole world against a set of criteria that is imposed | unilaterally. | | Allowing the sender to nominate the accreditation services that | are relevant allows the search for positive reputation data from | a source trusted by the recipient can be narrowed. | | This means that the market for accreditation services can contain | both the 500,000 domain VDL that we publish and smaller lists from | other providers with a few hundred entries. Yes, selective whitelisting based on whatever inputs you have is better in an AGUPI world than attempts to whack-a-mole using blacklists. From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 17:38:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03460 for ; Thu, 8 Jul 2004 17:38:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68LTSdi082952; Thu, 8 Jul 2004 14:29:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68LTSCm082951; Thu, 8 Jul 2004 14:29:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68LTQia082944 for ; Thu, 8 Jul 2004 14:29:27 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i68LTP1m014084; Thu, 8 Jul 2004 14:29:25 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jul 2004 14:29:25 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Meng Weng Wong'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: RE: terminology: authentication / authorization Date: Thu, 8 Jul 2004 14:29:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Thu, Jul 08, 2004 at 10:23:48AM -0700, Hallam-Baker, Phillip wrote: > | > | Yes, and the MARId group continue to insist on calling a record that > | contains an authentication credential an authorization record. But > | this does not actually matter much, it just leads to fuzzy thinking. > > Perhaps it depends on point of view. > > From the sender's point of view, the record authorizes MTAs > to use the sender's name. > > From the receiver's point of view, the record authenticates > MTAs as being permitted by the sender. No, from the sender's point of view the record enables the MTA to properly authenticate itself to third parties. From the receiver's point of view enables a legitimate MTA to be properly authenticated. I think that the fact that your interpretation is context sensitive and mine is not indicates that I have the correct definition. The record is simply an authentication credential. > Whether the receiver then wants to authorize further > delivery is a policy matter dependent on reputation which > depends on (you guessed it) accreditation. The receiver decides whether the transaction is permitted or not, this is the authorization step. It is the only place where a machine is executing a conditional instruction ergo it is the only authorization step according to the standard terminology. From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 18:27:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08500 for ; Thu, 8 Jul 2004 18:27:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68MGPUD087632; Thu, 8 Jul 2004 15:16:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68MGPO3087631; Thu, 8 Jul 2004 15:16:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68MGPq4087625 for ; Thu, 8 Jul 2004 15:16:25 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id EB9011D651 for ; Thu, 8 Jul 2004 15:16:29 -0700 (PDT) Date: Thu, 08 Jul 2004 15:16:30 -0700 From: Greg Connor To: MARID Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) Message-ID: <25177082.1089299790@Ryoga.corp.sgi.com> In-Reply-To: <1089319077.21784.310.camel@ddev.mail-abuse.org> References: <1089319077.21784.310.camel@ddev.mail-abuse.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Douglas Otis wrote: > > Could you explain the premise used for this assumption? > No. I am not making an assumption, just dismissing yours ;) >> Hmm, in that case I would be interested to see any information that >> leads a reasonable person to believe that the relationship is not >> linear. (hint: y=20x is a linear relationship. > > In reference to the information added to the core document > > http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt > > Pg. 18: > > 5.4 Recursion Limitations > > Evaluation of many of the mechanisms in section 5.1 will require > additional DNS lookups. To avoid infinite recursion, and to avoid > certain denial of service attacks, an MTA or other processor SHOULD > limit the total number of DNS lookups that it is willing to perform > in the course of a single authentication. Such a limit SHOULD allow > for at least 20 lookups. If such a limit is exceeded, the result of > authentication MUST be "hardError". > > MTAs or other processors MAY also impose a limit on the maximum > amount of elapsed time to perform an authentication. Such a limit > SHOULD allow at least 10 seconds. If such a limit is exceeded, the > result of authentication SHOULD be "transientError". > > Domains publishing records SHOULD keep the number of DNS lookups to > less than 20. Domains publishing records that are intended for use > as the target of "indirect" elements SHOULD keep the number of DNS > lookups to less than 10. > > > Using an assumption that Sender-ID records are able to limit the > required queries to 10 and set the "transientError" timeout at 10 > seconds, what will be the impact on network integrity? > > The transport for SMTP uses TCP, but now Sender-ID interjects 10 UDP > queries per message that "must" occur or the connection suffers a > temporary error event requiring a repeat of a message transfer. The > default for a resolver lookup timeout is typically set to 5 seconds (a > minimum of 2 seconds) as RFC 1035 recommends, where 10 seconds is > considered worst case. Should there be a another timeout, this limit > often doubles. The connection is tasked with making 10 UDP queries > within 10 seconds however. > > Should the network suffer a 5% packet loss rate, then 1 packet will be > lost on average within these 10 lookups. This will invoke the 5 second > timeout which then reduces the time for the remainder of the queries > (possibly leaving half a second apiece to resolve each new query). > Depending upon the distribution of lost packets, the connection could be > lost after reception of the first message, only to be retried again > later and could make a large transfer of messages impractical. TCP used > for SMTP could deal with this packet loss rate, but because of Sender-ID > and these many queries with a short timeout, the integrity of SMTP is > significantly reduced. > > If the timeout are restored to normal limits for these DNS queries, > Sender-ID may dramatically reduce performance of the SMTP server and the > reason for imposing the hazardous time constraint. The trade-off > becomes either a possibly dramatic reduction in performance of the SMTP > server, or a dramatic reduction in the network integrity for the SMTP > server during times of network congestion. The use of the RFC 2822 > identities for Sender-ID means messages are transferred regardless > whether they become rejected. A loss of integrity will then add to > network congestion and thereby possibly leading to a collapse of the > network due to the non-linear effect caused by congestion, redundant > transfers by Sender-ID, and the reduced network integrity. I interpret the above as "Given sufficiently bad networks and servers, DNS queries might take a long time." Of course SenderID would be affected by this. So would CSV. This does not show the relationship is non-linear. Do you need more information as to what linear means, or are you ignoring the point and spreading FUD on purpose? -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 19:31:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13782 for ; Thu, 8 Jul 2004 19:31:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68N6ssZ092980; Thu, 8 Jul 2004 16:06:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68N6s4t092979; Thu, 8 Jul 2004 16:06:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68N6rKu092972 for ; Thu, 8 Jul 2004 16:06:53 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i68N6w1m025557; Thu, 8 Jul 2004 16:06:58 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jul 2004 16:06:58 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Douglas Otis'" , Greg Connor Cc: MARID Subject: RE: Forging (was Re: Differences between CSV and Sender-ID ) Date: Thu, 8 Jul 2004 16:06:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Trojans sending much of the viruses (for more Trojans) and spam (for > revenue) are not concerned about full compliance to a > specification, nor do they implement proper states for an SMTP client. OK. > Why attribute abuse > to malevolent intent when expediency is more likely a principle > motivation. I don't care what the motivation is. > So stopping a message after wasting the full bandwidth of > the rejected message may seem like a small concern, but there may be > another 100,000 more of these Trojans requesting service. I don't much care when the message is rejected. It is great if the message can be rejected early on, but that does not mean that I am going to reject a scheme just because it does not make this possible. In the real world spam zombies have a finite life. Sure some botnets have 100,000 machines, most do not and there is a lot of work going on to reduce the value of hijacked machines as spambots. If you think there is a problem here, suggest a fix. spreading FUD about a mechanism that is not intended to address the problem does not help. > In addition, many of these spammers use a technique that appends a > random sub-domain resolved using a wildcarded record as a means to > obfuscate filters. It also means data needed for a repeated > visit or a > repeated message will not be in a DNS cache. A loss of even more > bandwidth on the DNS queries, possibly more than from the > messages being checked. Sounds like a very noticable scheme to me. > > I believe most MARID DNS queries will be 1 or 2 per > transaction and can be > > cached easily. I have seen nothing to suggest that the > relationship is > > other than linear. Therefore I dismiss "these concerns" > which seem to > > suggest that the relationship is geometric or exponential > or whatever. It > > doesn't make sense, and is not borne out by the early > adopters of SPF. > > Could you explain the premise used for this assumption? Observation of the deployed SPF records perhaps??? > > Hmm, this paragraph also seems to contain high FUD-to-fact ratio. > > Sending hosts > Receiving hosts (increases scale and scope) > Originating domains > Receiving domain (increases scale and scope) > Receiving Domain sets > Receiving domain (increases scale and scope) I do not have the slightest idea what point you are trying to make here and I don't think you do either. > My premise is that abuse of published partial lists left open will > ensure either the removal of these records, or an attempt to fully > publish a comprehensive record set. A desire to delegate to other > domains providing services runs the risk that as they add a few > indirections, this may cause hard errors and the complete loss of mail > service without the administrator of the domain having done anything > atypical or perhaps having done nothing. The posts I made earlier describing a means of applying a restriction on indirections have not made it to the list yet. It is really easy to do. > Using an assumption that Sender-ID records are able to limit the > required queries to 10 and set the "transientError" timeout at 10 > seconds, what will be the impact on network integrity? If you end up with a problem process offline, but I don't see why a problem should arise. The Internet stops working if you hypothesize worst case response for every transaction, so what? we knew that. From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 20:42:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18291 for ; Thu, 8 Jul 2004 20:42:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i690PqQc099683; Thu, 8 Jul 2004 17:25:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i690PqZm099682; Thu, 8 Jul 2004 17:25:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i690PpHX099672 for ; Thu, 8 Jul 2004 17:25:51 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id BF3C44148A for ; Thu, 8 Jul 2004 17:25:52 -0700 (PDT) Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) From: Douglas Otis To: MARID In-Reply-To: <25177082.1089299790@Ryoga.corp.sgi.com> References: <1089319077.21784.310.camel@ddev.mail-abuse.org> <25177082.1089299790@Ryoga.corp.sgi.com> Content-Type: text/plain Message-Id: <1089332752.2475.78.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 08 Jul 2004 17:25:52 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-08 at 15:16, Greg Connor wrote: > --Douglas Otis wrote: > > > Could you explain the premise used for this assumption? > > No. I am not making an assumption, just dismissing yours ;) Based upon what? You should at least attempt to support this conjecture as to the number of queries. If this is a valid position, then the draft should reflect these constraints. You may notice, it does not. > >> Hmm, in that case I would be interested to see any information that > >> leads a reasonable person to believe that the relationship is not > >> linear. (hint: y=20x is a linear relationship. > > > > In reference to the information added to the core document > > > > http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt > > > > Pg. 18: > > > > 5.4 Recursion Limitations > > > > Evaluation of many of the mechanisms in section 5.1 will require > > additional DNS lookups. To avoid infinite recursion, and to avoid > > certain denial of service attacks, an MTA or other processor SHOULD > > limit the total number of DNS lookups that it is willing to perform > > in the course of a single authentication. Such a limit SHOULD allow > > for at least 20 lookups. If such a limit is exceeded, the result of > > authentication MUST be "hardError". > > > > MTAs or other processors MAY also impose a limit on the maximum > > amount of elapsed time to perform an authentication. Such a limit > > SHOULD allow at least 10 seconds. If such a limit is exceeded, the > > result of authentication SHOULD be "transientError". > > > > Domains publishing records SHOULD keep the number of DNS lookups to > > less than 20. Domains publishing records that are intended for use > > as the target of "indirect" elements SHOULD keep the number of DNS > > lookups to less than 10. > > > > > > Using an assumption that Sender-ID records are able to limit the > > required queries to 10 and set the "transientError" timeout at 10 > > seconds, what will be the impact on network integrity? > > > > The transport for SMTP uses TCP, but now Sender-ID interjects 10 UDP > > queries per message that "must" occur or the connection suffers a > > temporary error event requiring a repeat of a message transfer. The > > default for a resolver lookup timeout is typically set to 5 seconds (a > > minimum of 2 seconds) as RFC 1035 recommends, where 10 seconds is > > considered worst case. Should there be a another timeout, this limit > > often doubles. The connection is tasked with making 10 UDP queries > > within 10 seconds however. > > > > Should the network suffer a 5% packet loss rate, then 1 packet will be > > lost on average within these 10 lookups. This will invoke the 5 second > > timeout which then reduces the time for the remainder of the queries > > (possibly leaving half a second apiece to resolve each new query). > > Depending upon the distribution of lost packets, the connection could be > > lost after reception of the first message, only to be retried again > > later and could make a large transfer of messages impractical. TCP used > > for SMTP could deal with this packet loss rate, but because of Sender-ID > > and these many queries with a short timeout, the integrity of SMTP is > > significantly reduced. > > > > If the timeout are restored to normal limits for these DNS queries, > > Sender-ID may dramatically reduce performance of the SMTP server and the > > reason for imposing the hazardous time constraint. The trade-off > > becomes either a possibly dramatic reduction in performance of the SMTP > > server, or a dramatic reduction in the network integrity for the SMTP > > server during times of network congestion. The use of the RFC 2822 > > identities for Sender-ID means messages are transferred regardless > > whether they become rejected. A loss of integrity will then add to > > network congestion and thereby possibly leading to a collapse of the > > network due to the non-linear effect caused by congestion, redundant > > transfers by Sender-ID, and the reduced network integrity. > > > I interpret the above as "Given sufficiently bad networks and servers, DNS > queries might take a long time." Of course SenderID would be affected by > this. So would CSV. I did not say sufficiently bad networks and servers. I said congestion at 5% loss. This rate does not change behaviors of congestion algorithms significantly. As you may know, UDP traffic does not have congestion avoidance, and yet there could be a blizzard of UDP traffic with Sender-ID. Add to this, repeated transfers of messages exhibited during times of congestion exacerbated by the reduced integrity of SMTP when using Sender-ID. Breakdown of the network throughput would be a complex non-linear function for this scenario. CSV would reject a connection without affecting the timeout on the DNS query and compensate for DNS overhead by blocking transfer of all unwanted messages. Nor would CSV require information to be repeated. Nor would there be such a predominance of UDP traffic with CSV. But this is not about CSV. This is about Sender-ID. > This does not show the relationship is non-linear. Do you need more > information as to what linear means, or are you ignoring the point and > spreading FUD on purpose? You have not offered simulations for traffic flow to counter this claim. You have not offered a premise for your assumptions regarding the number of queries needed. An effective proponent would not resort to personal berating to dissuade critics. "The rare happiness of times, when we may think what we please, and express what we think." Cornelius Tacitus -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jul 8 22:09:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26947 for ; Thu, 8 Jul 2004 22:09:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i691xbo3006313; Thu, 8 Jul 2004 18:59:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i691xbdO006312; Thu, 8 Jul 2004 18:59:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i691waSY006274 for ; Thu, 8 Jul 2004 18:59:36 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i691wg1m008524; Thu, 8 Jul 2004 18:58:42 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jul 2004 18:58:42 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Douglas Otis'" , MARID Subject: RE: Forging (was Re: Differences between CSV and Sender-ID ) Date: Thu, 8 Jul 2004 18:58:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > You have not offered simulations for traffic flow to counter this > claim. You have not offered a premise for your assumptions regarding > the number of queries needed. An effective proponent would not resort > to personal berating to dissuade critics. You have not offered simulations to establish this claim. All you have done is to make a series of claims that I and the others who have attempted to answer them are barely able to parse, let alone understand. If you seriously believe that there is a chance that Sender-ID would bring the network down you are going to have to get someone else to put the case in a form that I or others can understand. I suggest that further discussion of this issue is futile until such time as Doug provides a simulation that demonstrates that there is a real risk of catastrophe under realistic network conditions. From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 03:11:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07548 for ; Fri, 9 Jul 2004 03:11:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69723aU074577; Fri, 9 Jul 2004 00:02:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69723jo074576; Fri, 9 Jul 2004 00:02:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69722vu074568 for ; Fri, 9 Jul 2004 00:02:02 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6971gl25101; Fri, 9 Jul 2004 00:01:44 -0700 Date: Fri, 9 Jul 2004 14:01:22 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <712793410.20040709140122@brandenburg.com> To: Meng Weng Wong CC: ietf-mxcomp@imc.org Subject: Re: terminology: authentication / authorization In-Reply-To: <20040708211446.GE16317@dumbo.pobox.com> References: <20040708211446.GE16317@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng, MWW> Perhaps it depends on point of view. MWW>From the sender's point of view, the record authorizes MTAs MWW> to use the sender's name. MWW>From the receiver's point of view, the record authenticates MWW> MTAs as being permitted by the sender. Here is a really revolutionary idea. Why do we not, instead, start using standard technical terms in their standard technical way? This groups needs to stop re-defining well-established security terminology, especially when the primary effect of those redefinitions is to make everything less consistent and precise, not more. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 03:38:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08776 for ; Fri, 9 Jul 2004 03:38:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i697MkBi081916; Fri, 9 Jul 2004 00:22:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i697MkrS081915; Fri, 9 Jul 2004 00:22:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mxr.enom.com (mxr.enom.com [63.251.174.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i697MhET081865 for ; Fri, 9 Jul 2004 00:22:44 -0700 (PDT) (envelope-from aland@ox.org) Received: from mail pickup service by mxr.enom.com with Microsoft SMTPSVC; Fri, 9 Jul 2004 00:19:40 -0700 Received: from above.proper.com ([208.184.76.39]) by mxr.enom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Jul 2004 12:15:01 -0700 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68J5FWG067252; Thu, 8 Jul 2004 12:05:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68J5FU2067251; Thu, 8 Jul 2004 12:05:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68J5E6f067244 for ; Thu, 8 Jul 2004 12:05:15 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B60F116CCB for ; Thu, 8 Jul 2004 15:12:27 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Thu, 08 Jul 2004 23:15:40 +0700." <261467659.20040708231540@brandenburg.com> Date: Thu, 08 Jul 2004 15:12:27 -0400 Message-Id: <20040708191227.B60F116CCB@mail.nitros9.org> List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 08 Jul 2004 19:15:01.0875 (UTC) FILETIME=[DE27AC30:01C4651F] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > >> Spammers have proved to be astonishingly and quickly adaptable > AD> In some situations. In others, they are astonishingly idiotic. > AD> Once again, the behavior is situational. > > the folks who command estimated millions of compromised machines, with > a 3- or 4-tier control hierarchy, do not count as idiotic. I have two responses: a) please re-read what I wrote. I said SOME are idiotic, not ALL. It's rude to cherry-pick a complicated scenario, and make it sound like I said those people were dumb. I didn't. b) Don't mistake "script kiddies" for people with a clue, or for spammers. Computers have things called "scripts" or "programs" which idiots can run to perform complicated tasks. And idiots can buy CPU time on "owned" machines from smart people, and use that time to send spam. > i've explained the reason quite a few times. just so it is not missed > again: Shall I re-post my standard response? I don't feel we're communicating here. I try to explain my position in response to your posts, and your replies simply re-state your position. Did you think I didn't read your comments? Or maybe I didn't understand them? I thought my responses explained not only that I understood them, but that I disagreed. I even gave reasons why. > AD> To address your analogy, > > If you mean bandages, it's not mine. you introduced it, as i recall. > I was simply trying to pursue it. Uh, no. You called spam a "disease", which is either an analogy, or perjorative term. My later sentences followed the disease analogy, and didn't discuss bandages. Perhaps you were confused that both analogies had medical roots. > Please show me a successful, global standard that has been designed > to respond to one set of symptoms, when the source of those symptoms > is constantly adapting, guaranteeing that the symptoms will become > irrelevant as soon as the response begins to take effect. I could swear I had addressed that comment in my previous message. > AD> That's the basic concept behind MARID. Having domains > AD> maintain BL's about others is expensive and pointless. > > pointless? so spamhaus and all those other lists are pointless? I am continually amazed at how what appears to me to be simple english is construed to mean the most idiotic things. What I was originally discussing was ideas from this WG: domains hosting policy information about themselves in DNS. RMX, SPF, CSV, and Sender-ID all fall into this category. My comments that MARID could be construed as domains maintaining black/whitelists were intended to be taken in the context of this WG: domains maintain policy information about themselves, and that information may be used by others as input to blacklists/whitelists. You seemed to interpret that statement as saying that every domain would have to maintain information about every other domain. And when I said that was pointless, you suddenly switched to thinking that I was claiming DNSBL's were pointless. Can you explain to me how I can write simple english sentences on this list, so you don't interpret them as being blindingly idiotic statements? I'm appalled at how badly we're communicating. For the record, I believe I understand your opinion very well. You think temporary measures aren't permanent solutions. I agree. You think that these temporary measures require some kind of global coordination before they will work. I don't see why. You think that we should be looking for cures, rather than temporary measures. I agree. Where I disagree with you is in the utility of the temporary measures. You seem to think they have no longer-term utility, and I've tried to demonstrate why I think you're wrong. Rather than address my concerns, you just repeat your position. I don't see why this approach would be considered communication. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 04:18:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10599 for ; Fri, 9 Jul 2004 04:18:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6988l6t097838; Fri, 9 Jul 2004 01:08:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6988liq097837; Fri, 9 Jul 2004 01:08:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6988kI9097829 for ; Fri, 9 Jul 2004 01:08:46 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i69883l30351; Fri, 9 Jul 2004 01:08:06 -0700 Date: Fri, 9 Jul 2004 15:07:19 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <107381084.20040709150719@brandenburg.com> To: Meng Weng Wong CC: "'IETF MARID WG'" Subject: Re: some thoughts on SUBMITTER In-Reply-To: <20040708203846.GD16317@dumbo.pobox.com> References: <14354380.1089288967@Ryoga.corp.sgi.com> <20040708203846.GD16317@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng, MWW> I would like to suggest we keep in mind: MWW> Where the mass majority of normal email is concerned, MWW> forwarding is an edge case. MWW> Failure of SenderID due to noncompliant forwarding is a MWW> corner case. I would like to suggest that we keep in mind: We do not have statistics about the extent of use of forwarding scenarios, although we do know that it is used quite a lot, by many people and in a variety of ways. Changing a legitimate practise that has widespread use tends to be a good way to get the community to reject a proposal. So, let me suggest that trying to marginalizing the problems caused with forwarding scenarios is not such a good idea. MWW> We should also keep in mind the positive scenario for SenderID: Perhaps you are suggesting modifying the specification -- by the way, are talking about marid-core? if not, then what specification are you discussing? -- to explicitly list the scenarios for which it works well, that is, the ones for which it is not problematic? That would be very helpful. MWW> The positive scenario is the scenario we are trying to enable. Right. Unfortunately, global standards usually need to work across the entire architecture of the service they are modifying. MWW> I also want to point out that SUBMITTER: MWW> - should appear rarely, this is because you believe that rfc2821.mailfrom and rfc2821.submitter will usually be the same? MWW> * SUBMITTER should appear rarely. MWW> SUBMITTER need not be used when the MAIL-FROM is identical MWW> to the Sender. This is a very common case. So you do not mean that the syntactic form should appear rarely, not that the semantics of submitter-based authentication and authorization should get used rarely? But the semantics are the issue, not the syntax. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 06:17:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15184 for ; Fri, 9 Jul 2004 06:17:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69A1DkS040015; Fri, 9 Jul 2004 03:01:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69A1DOG040014; Fri, 9 Jul 2004 03:01:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69A18si039985 for ; Fri, 9 Jul 2004 03:01:09 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i69A0sl06517; Fri, 9 Jul 2004 03:00:55 -0700 Date: Fri, 9 Jul 2004 17:00:39 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <126368773.20040709170039@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <20040708191227.B60F116CCB@mail.nitros9.org> References: Your message of "Thu, 08 Jul 2004 23:15:40 +0700." <261467659.20040708231540@brandenburg.com> <20040708191227.B60F116CCB@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan, AD> a) ... I said SOME are idiotic, not ALL. AD> It's rude to cherry-pick a complicated scenario, and make it AD> sound like I said those people were dumb. I didn't. In fact, you have been focussing entirely on the 'dumb' spammers, whereas I have chosen to focus entirely on the smart ones. You are citing the dumb ones on the basis of making certain decisions for global standards to be reasonable. I am citing the smart ones because they will roll past any standard that is not robust against them. AD> b) Don't mistake "script kiddies" for people with a clue, or for AD> spammers. I wasn't. That is why I'm citing the smart guys. The ones with multi-level control mechanisms and many thousands or millions of compromised machines. AD> Computers have things called "scripts" or "programs" AD> which idiots can run to perform complicated tasks. And idiots AD> can buy CPU time on "owned" machines from smart people, and use AD> that time to send spam. I guess I am missing the point behind citing how dumb these guys are. What does that fact do with respect to protocol standards decisions? AD> What I was originally discussing was ideas from this WG: domains AD> hosting policy information about themselves in DNS. RMX, SPF, CSV, AD> and Sender-ID all fall into this category. My comments that MARID AD> could be construed as domains maintaining black/whitelists were AD> intended to be taken in the context of this WG: domains maintain AD> policy information about themselves, and that information may be used AD> by others as input to blacklists/whitelists. The terms whitelist and blacklist have significant and rather consistent history. I fail to see the benefit in redefining them for this working group. Besides being seriously confusing, the definition is not written down in a working group document. AD> For the record, I believe I understand your opinion very well. You AD> think temporary measures aren't permanent solutions. Tautologies can be humorous, but that isn't what I said. I said that temporary measures are highly inappropriate for global standardization. AD> Where I disagree with you is in the utility of the temporary AD> measures. And that is why I keep asking for examples of comparable efforts -- global standards that provide temporary measures against side-effects rather than core aspects of a problem. When has such an approach worked? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 06:57:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17330 for ; Fri, 9 Jul 2004 06:57:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69AjuZK048164; Fri, 9 Jul 2004 03:45:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69Aju0Z048163; Fri, 9 Jul 2004 03:45:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69AjtuQ048156 for ; Fri, 9 Jul 2004 03:45:55 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:44556) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1Bist4-0002yD-Nw for ietf-mxcomp@imc.org; Fri, 09 Jul 2004 11:45:50 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Bist3-00021y-Tq; Fri, 09 Jul 2004 11:45:49 +0100 Date: Fri, 9 Jul 2004 11:45:49 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Dave Crocker cc: Meng Weng Wong , "'IETF MARID WG'" Subject: Re: some thoughts on SUBMITTER In-Reply-To: <107381084.20040709150719@brandenburg.com> Message-ID: References: <14354380.1089288967@Ryoga.corp.sgi.com> <20040708203846.GD16317@dumbo.pobox.com> <107381084.20040709150719@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 9 Jul 2004, Dave Crocker wrote: > > We do not have statistics about the extent of use of forwarding > scenarios, although we do know that it is used quite a lot, by many > people and in a variety of ways. We have about 32,000 accounts on the University of Cambridge's central message store, and about 7400 (23%) of them have some kind of Sieve redirect set up. 4700 of them are to non-Cambridge addresses, i.e. FIFTEEN PERCENT of our users will have trouble with the deployment of designated sender schemes such as SPF and SenderID. Note that this is a view of outgoing email; it's much harder to tell what proportion of our users have forwarding aliases that direct email here. If the outgoing figure is any kind of indicator it would be irresponsible of me to enable SPF checks on incoming email. I'll be disabling that part of SpamAssassin 3.0 when I deploy it. On Thu, 8 Jul 2004, Meng Weng Wong wrote: > > We should also keep in mind the positive scenario for SenderID: I think this is a bad idea, because it is the negative scenario that is the problem. Neglecting that means you are not clearly defining the cases in which your protocol can be reliably used to identify junk email. > we're moving toward a paradigm of "assumed guilty until > proven innocent" (AGUPI). I note that no satisfactory fixes have been suggested for the forwarding problem. Some, such as SRS and the PRA algorithm require modification of the email software at any site which implements forwarding, and in the case of Cambridge it will require a complete re-engineering of our virtual domain system with a significant increase in complexity and decrease in performance. Others, such as trusted-forwarder.org, drive a coach and horses through the security model and completely negate AGUPI. If SenderID is ratified and people start using it, I would expect a very large proportion of the academic world to sign up to trusted-forwarder.org which would in turn make them a really choice target for hacker-phishers. Tony. -- f.a.n.finch http://dotat.at/ ST DAVIDS HEAD TO COLWYN BAY, INCLUDING ST GEORGES CHANNEL: NORTHWEST 4 OR 5, OCCASIONALLY 6 BECOMES WEST TO NORTHWEST 3. RAIN OR SHOWERS BECOMES MAINLY FAIR LATER. MODERATE OR GOOD. OCCASIONALLY ROUGH AT FIRST, OTHERWISE MODERATE DECAYING LOCALLY SLIGHT. From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 09:24:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26449 for ; Fri, 9 Jul 2004 09:24:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69DFp0I066246; Fri, 9 Jul 2004 06:15:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69DFpeC066245; Fri, 9 Jul 2004 06:15:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69DFoa7066238 for ; Fri, 9 Jul 2004 06:15:50 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:60419) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1BivEA-00002G-IS for ietf-mxcomp@imc.org; Fri, 09 Jul 2004 14:15:46 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BivE9-00087m-Ig; Fri, 09 Jul 2004 14:15:45 +0100 Date: Fri, 9 Jul 2004 14:15:45 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk cc: Dave Crocker , Meng Weng Wong , "'IETF MARID WG'" Subject: Re: some thoughts on SUBMITTER In-Reply-To: Message-ID: References: <14354380.1089288967@Ryoga.corp.sgi.com> <20040708203846.GD16317@dumbo.pobox.com> <107381084.20040709150719@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 9 Jul 2004, Tony Finch wrote: > > We have about 32,000 accounts on the University of Cambridge's central > message store, and about 7400 (23%) of them have some kind of Sieve > redirect set up. 4700 of them are to non-Cambridge addresses, i.e. > FIFTEEN PERCENT of our users will have trouble with the deployment of > designated sender schemes such as SPF and SenderID. I just realised that I counted everyone twice because of our replication system, so these proportions should be more like 11% and 7%. The stats from Oxford University are within a percentage point or so of my corrected numbers, and more broadly in line with what I expected before running the script. This is still a significant proportion of our user base. Tony. -- f.a.n.finch http://dotat.at/ LUNDY FASTNET: WEST OR NORTHWEST 3 INCREASING 4 OR 5, OCCASIONALLY 6. SHOWERS THEN RAIN. GOOD BECOMING MODERATE. From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 09:35:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26929 for ; Fri, 9 Jul 2004 09:35:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69DRKNU067527; Fri, 9 Jul 2004 06:27:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69DRKEQ067526; Fri, 9 Jul 2004 06:27:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mxr.enom.com (mxr.enom.com [63.251.174.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69DR4Yo067479 for ; Fri, 9 Jul 2004 06:27:18 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mail pickup service by mxr.enom.com with Microsoft SMTPSVC; Fri, 9 Jul 2004 05:48:49 -0700 Received: from above.proper.com ([208.184.76.39]) by mxr.enom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Jul 2004 19:03:20 -0700 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i691xbo3006313; Thu, 8 Jul 2004 18:59:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i691xbdO006312; Thu, 8 Jul 2004 18:59:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i691waSY006274 for ; Thu, 8 Jul 2004 18:59:36 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i691wg1m008524; Thu, 8 Jul 2004 18:58:42 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jul 2004 18:58:42 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Douglas Otis'" , MARID Subject: RE: Forging (was Re: Differences between CSV and Sender-ID ) Date: Thu, 8 Jul 2004 18:58:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 09 Jul 2004 02:03:20.0671 (UTC) FILETIME=[E89346F0:01C46558] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > You have not offered simulations for traffic flow to counter this > claim. You have not offered a premise for your assumptions regarding > the number of queries needed. An effective proponent would not resort > to personal berating to dissuade critics. You have not offered simulations to establish this claim. All you have done is to make a series of claims that I and the others who have attempted to answer them are barely able to parse, let alone understand. If you seriously believe that there is a chance that Sender-ID would bring the network down you are going to have to get someone else to put the case in a form that I or others can understand. I suggest that further discussion of this issue is futile until such time as Doug provides a simulation that demonstrates that there is a real risk of catastrophe under realistic network conditions. From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 10:24:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00398 for ; Fri, 9 Jul 2004 10:24:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69EDp0q072857; Fri, 9 Jul 2004 07:13:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69EDpq9072856; Fri, 9 Jul 2004 07:13:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69EDpxU072848 for ; Fri, 9 Jul 2004 07:13:51 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i69EDr1m026930 for ; Fri, 9 Jul 2004 07:13:53 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Jul 2004 07:13:53 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: FW: Comments on draft-ietf-marid-core-01.txt Date: Fri, 9 Jul 2004 07:13:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This did not make it to the list yesterday. -----Original Message----- From: Hallam-Baker, Phillip Sent: Thursday, July 08, 2004 11:38 AM To: 'IETF MARID WG' Subject: Comments on draft-ietf-marid-core-01.txt Some comments on the draft: 1) Section 5. The scope here is outgoing email policy, identified by . Since we have a 500 byte limit we are working inside and since outgoing and incomming policies will always be used in separate operation I suggest that we recognize this at the selector prefix level: _out._ep. - For outgoing email policy _in._ep - For incomming policy I think that incomming policy will be very useful when domains are communicating information like 'I process MARID records' or 'I accept S/MIME & PGP signed email'. Arguably such information could be exchanged inband in SMTP, but this is not guaranteed to be possible. Section 5.2 Are these macro expansions really necessary? Would it be possible to eliminate them entirely or if some form of indirection is needed could we simply define an element for that purpose. I am unconvinced by the claims that MARID could be used for DDoS purposes, but there are certainly lots of moving parts here. Regardless, I am unable to parse the explanation of the macro functions: l = local-part passed to the client authorization function. s = Same as "%{l}@%{o}". o = original domain passed to the client authorization function. d = current domain passed to the client authorization function. i = SMTP client IP (nibble format when an IPv6 address). p = SMTP client domain name v = client IP version string: "in-addr" for ipv4 or "ip6" for ipv6 r = domain name of the SMTP server. local part OF WHAT? If s is the same as "%{l}@%{o}" then why duplicate it? I find it very hard to work out precisely what the terms original and current mean in this context. I really cannot see a justification for all this mechanism unless the idea here is that the spec is going to somehow conform to legacy data sources such as blacklists. That does not make a lot of sense to me since a blacklist is accreditation data which by definition comes from a third party and cannot therefore be interpreted without reference to the reputation of the acreditation provider. If the receiver is tracking said reputation it makes best sense for the receiver to also track the correct way to extract the data from the service. I would like to see some use cases to motivate this whole section. My strong beleif is that it is possible to address this issue using elements such as and for include:%{l}.domain and include:%{i}.domain and meet all the interesting use cases. This approach would allow the spec to be further constrained so that a factored record of this type cannot itself reference a factored record. This ensures that the type of DoS attack hypothesized is completely eliminated. There are at most two branches in the tree and only one branch is to be followed. Removing the macro expansions limits flexibility on the part of administrators in the way that they format their data. This is usually a good thing. Give two ways to express the same data that offer no advantage and you create two code paths that have to be maintained, more importantly you have two un-fun legacy protocol issues down the road. The restricted examples given are still sufficient to allow support of use cases such as delegating particular usernames to a specific email provider. They can use a to break up the record and service@anybank.com can point to a record at constant contact. Equally if a person wants to set up an outgoing mail server on a mobile machine they can do that using an and dynamic DNS. Of course this still leaves a problem if you are behind a NAT box, but the external NAT box address is discoverable. Phill From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 10:41:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03056 for ; Fri, 9 Jul 2004 10:41:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69EURKP075959; Fri, 9 Jul 2004 07:30:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69EURDT075958; Fri, 9 Jul 2004 07:30:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69EUQwL075949 for ; Fri, 9 Jul 2004 07:30:26 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id EB7EEE0665; Fri, 9 Jul 2004 10:30:28 -0400 (EDT) Date: Fri, 9 Jul 2004 10:30:28 -0400 From: John Leslie To: Dave Crocker Cc: Meng Weng Wong , ietf-mxcomp@imc.org Subject: Re: terminology: authentication / authorization Message-ID: <20040709143028.GH57106@verdi> References: <20040708211446.GE16317@dumbo.pobox.com> <712793410.20040709140122@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <712793410.20040709140122@brandenburg.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > > This groups needs to stop re-defining well-established security > terminology, especially when the primary effect of those redefinitions > is to make everything less consistent and precise, not more. I've been trying to hunt down useful definitions in common use; I can supply links if anyone's a glutton for punishment. The only source I feel able to recommend for our use is RFC 2828: "Internet Security Glossary", May 2000. It lists several categories of entries: - "I" identifies a RECOMMENDED Internet definition. - "N" identifies a RECOMMENDED non-Internet definition. - "O" identifies a definition that is not recommended as the first choice for Internet documents but is something that authors of Internet documents need to know. - "D" identifies a term or definition that SHOULD NOT be used in Internet documents. - "C" identifies commentary or additional usage guidance. From RFC 2828, I extract: ] accreditation ] (I) An administrative declaration by a designated authority that ] an information system is approved to operate in a particular ] security configuration with a prescribed set of safeguards. ] [FP102] (See: certification.) ] (C) An accreditation is usually based on a technical certification ] of the system's security mechanisms. The terms "certification" ] and "accreditation" are used more in the U.S. Department of ] Defense and other government agencies than in commercial ] organizations. However, the concepts apply any place where ] managers are required to deal with and accept responsibility ] for security risks. The American Bar Association is developing ] accreditation criteria for CAs. ] ] authentication ] (I) The process of verifying an identity claimed by or for a ] system entity. (See: authenticate, authentication exchange, ] authentication information, credential, data origin ] authentication, peer entity authentication.) ] (C) An authentication process consists of two steps: ] 1. Identification step: Presenting an identifier to the ] security system. (Identifiers should be assigned carefully, ] because authenticated identities are the basis for other ] security services, such as access control service.) ] 2. Verification step: Presenting or generating authentication ] information that corroborates the binding between the entity ] and the identifier. (See: verification.) ] (C) See: ("relationship between data integrity service and ] authentication services" under) data integrity service. ] ] authorization ] (I) (1.) An "authorization" is a right or a permission that is ] granted to a system entity to access a system resource. ] (2.) An "authorization process" is a procedure for granting ] such rights. ] (3.) To "authorize" means to grant such a right or permission. ] (See: privilege.) Since only the (I) items are "recommended", is there any reason we can't live with: " Accreditation is an administrative declaration by a designated authority " that an information system is approved to operate in a particular " security configuration with a prescribed set of safeguards. " Authentication is the process of verifying an identity claimed by or " for a system entity. " Authorization is a right or a permission that is granted to a system " entity to access a system resource. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 11:41:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06148 for ; Fri, 9 Jul 2004 11:41:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69FVtDf082453; Fri, 9 Jul 2004 08:31:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69FVto6082452; Fri, 9 Jul 2004 08:31:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69FVfDf082422 for ; Fri, 9 Jul 2004 08:31:45 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id CDBC216CCB for ; Fri, 9 Jul 2004 11:38:53 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Fri, 09 Jul 2004 17:00:39 +0700." <126368773.20040709170039@brandenburg.com> Date: Fri, 09 Jul 2004 11:38:53 -0400 Message-Id: <20040709153853.CDBC216CCB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > In fact, you have been focussing entirely on the 'dumb' spammers, > whereas I have chosen to focus entirely on the smart ones. Yes. I know how to stop the dumb spammers, but I don't know how to stop the smart ones. So far as I can tell from your posts, neither do you. > You are citing the dumb ones on the basis of making certain > decisions for global standards to be reasonable. Because they will stop dumb spammers. Do you believe that dumb spammers will go away? Do you believe that in the absence of new measures, spammers will voluntarily stop spamming? Do you believe that the flaws in SMTP which enable undetectable forgery shouldn't be changed? You don't address any of these issues in your posts. You just keep focussing on a never-never land scenario, where there is somehow a magical way to stop the smart spammers. But since that scenario doesn't exist, you're stuck opposing people who are trying to work on solutions they know how to implement. > I guess I am missing the point behind citing how dumb these guys are. > > What does that fact do with respect to protocol standards decisions? Because the dumb guys won't go away until you make them go away. > AD> My comments that MARID > AD> could be construed as domains maintaining black/whitelists were > AD> intended to be taken in the context ... > The terms whitelist and blacklist have significant and rather > consistent history. I fail to see the benefit in redefining them > for this working group. I talked about analogies and comparisons. You took that to mean I was re-defining common terms. Very cute. My conclusion is that your position is absolutist, and you filter everything you read through an absolutist interpretation. I say "may be", and you read "is required to be". I say "can be seen as", and you read "re-defined to be". The problem is that *my* position is not absolutist, and there's nothing I can do to convince you of that fact, or to get you to read my statements in anything other than absolutist terms. What's worse, is that your absolutist view results in wild misinterpretations of what I've said, which you then claim is my position. > Tautologies can be humorous, but that isn't what I said. I said that > temporary measures are highly inappropriate for global standardization. Like NAT? Most people would agree that it's an ugly hack, and is highly inappropriate for global standardization. Yet everyone also agrees it won't be going away any time soon. > And that is why I keep asking for examples of comparable efforts -- > global standards that provide temporary measures against side-effects > rather than core aspects of a problem. When has such an approach > worked? Do you believe that in the absence of MARID, spammers will stop forging on their own? Do you believe that if MARID is deployed for a short while, spammers will forever stop forging? Do you believe that if MARID deployed is temporarily, that people can later stop using it? The problem of forgery is a permanent design flaw in SMTP. The problem of bounce-path verification is a permanent design flaw in SMTP. Methods like MARID will address these flaws, and will permanently fix the underlying problem. Calling forgery a "convenient hack", and MARID a "temporary measure" is a viewpoint that is not in agreement with the facts. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 12:04:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07433 for ; Fri, 9 Jul 2004 12:04:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Fpg78084204; Fri, 9 Jul 2004 08:51:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69FpgoY084203; Fri, 9 Jul 2004 08:51:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Fpfik084197 for ; Fri, 9 Jul 2004 08:51:41 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 240A916CCB for ; Fri, 9 Jul 2004 11:58:56 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Thu, 08 Jul 2004 17:25:52 PDT." <1089332752.2475.78.camel@ddev.mail-abuse.org> Date: Fri, 09 Jul 2004 11:58:56 -0400 Message-Id: <20040709155856.240A916CCB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > > This does not show the relationship is non-linear. Do you need more > > information as to what linear means, or are you ignoring the point and > > spreading FUD on purpose? > > You have not offered simulations for traffic flow to counter this > claim. The original question was entirely independent of traffic flow. > You have not offered a premise for your assumptions regarding the > number of queries needed. The relationship I originally discussed, and what Greg was talking about, was how the number of DNS queries depended on the number of incoming SMTP connections. Let's define some terms: N = number of SMTP connections to an MTA D = number of DNS queries performed by that MTA, per SMTP connection. T = total number of Sender-ID DNS queries performed by the MTA. Q: Is T = \theta(N)? Your response was that D was large, and would cause the net to collapse. I don't see how that could be construed as answering the question. > An effective proponent would not resort to personal berating to > dissuade critics. An effective opponent would answer questions, and would not resort to avoiding the issue. The alleged ad hominem was directly on point: You were asked a question, and you refused to answer it. Your answer was ambiguous as to whether or not you even understood the question. From my reading of Sender-ID, all of the DNS lookups it performs are initiated from SMTP connections. Therefore, the relationship must be that T=\theta(N), and probably T=DN. Your argument that D is large is a nice one, but irrelevant to the question you were asked. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 12:54:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10251 for ; Fri, 9 Jul 2004 12:54:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Gg6j2088889; Fri, 9 Jul 2004 09:42:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69Gg6QW088888; Fri, 9 Jul 2004 09:42:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Gg51T088881 for ; Fri, 9 Jul 2004 09:42:06 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i69Gg21m006502; Fri, 9 Jul 2004 09:42:02 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Jul 2004 09:42:02 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'John Leslie'" , Dave Crocker Cc: Meng Weng Wong , ietf-mxcomp@imc.org Subject: RE: terminology: authentication / authorization Date: Fri, 9 Jul 2004 09:42:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The Internet Security glossary is not a definitive work, it is an attempt to describe definitions that already existed in the field. The real definition of the terms authentication and authorization is Butler Lampson's work in the 1970s. The problem with pulling terms from the glossary is that there are a bunch of assumptions built into the definitions that have to be understood. It is even worse because the typography does not allow terms of art to be distinguished. The computer security nomenclature was developed for non-networked machines. Granting the right to perform an action is synonymous with the ability to perform it. Take a look at the definition itself and this becomes clear: An "authorization" is a right or a permission that is granted to A SYSTEM entity to access A SYSTEM resource. An authorization is NOT a right that is granted to an entity on one system to access a resource on another system which is what people are trying to make it. According to the glossary what we have is a credential: $ credential(s) (I) Data that is transferred or presented to establish either a claimed identity or the authorizations of a system entity. (See: authentication information, capability, ticket.) Most authentication credentials conflate authorization information in some degree. A username and password record conflates permission to log on to the machine, an SSL certificate conflates permission to turn on the padlock icon. This does not mean that it is useful to call authentication and authorization the same thing. A MARID record answers the question 'does the mail come from the purported domain', that makes it an authentication credential. The motives of the writer are completely irrelevant, what is important here is the interpretation of the reader, that is the only thing that gives the record meaning. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of John Leslie > Sent: Friday, July 09, 2004 10:30 AM > To: Dave Crocker > Cc: Meng Weng Wong; ietf-mxcomp@imc.org > Subject: Re: terminology: authentication / authorization > > > > Dave Crocker wrote: > > > > This groups needs to stop re-defining well-established security > > terminology, especially when the primary effect of those > redefinitions > > is to make everything less consistent and precise, not more. > > I've been trying to hunt down useful definitions in common use; > I can supply links if anyone's a glutton for punishment. > > The only source I feel able to recommend for our use is RFC 2828: > "Internet Security Glossary", May 2000. It lists several categories > of entries: > > - "I" identifies a RECOMMENDED Internet definition. > - "N" identifies a RECOMMENDED non-Internet definition. > - "O" identifies a definition that is not recommended as the > first choice > for Internet documents but is something that authors of Internet > documents need to know. > - "D" identifies a term or definition that SHOULD NOT be used > in Internet > documents. > - "C" identifies commentary or additional usage guidance. > > From RFC 2828, I extract: > > ] accreditation > ] (I) An administrative declaration by a designated authority that > ] an information system is approved to operate in a particular > ] security configuration with a prescribed set of safeguards. > ] [FP102] (See: certification.) > ] (C) An accreditation is usually based on a technical certification > ] of the system's security mechanisms. The terms "certification" > ] and "accreditation" are used more in the U.S. Department of > ] Defense and other government agencies than in commercial > ] organizations. However, the concepts apply any place where > ] managers are required to deal with and accept responsibility > ] for security risks. The American Bar Association is developing > ] accreditation criteria for CAs. > ] > ] authentication > ] (I) The process of verifying an identity claimed by or for a > ] system entity. (See: authenticate, authentication exchange, > ] authentication information, credential, data origin > ] authentication, peer entity authentication.) > ] (C) An authentication process consists of two steps: > ] 1. Identification step: Presenting an identifier to the > ] security system. (Identifiers should be assigned carefully, > ] because authenticated identities are the basis for other > ] security services, such as access control service.) > ] 2. Verification step: Presenting or generating authentication > ] information that corroborates the binding between > the entity > ] and the identifier. (See: verification.) > ] (C) See: ("relationship between data integrity service and > ] authentication services" under) data integrity service. > ] > ] authorization > ] (I) (1.) An "authorization" is a right or a permission that is > ] granted to a system entity to access a system resource. > ] (2.) An "authorization process" is a procedure for granting > ] such rights. > ] (3.) To "authorize" means to grant such a right or permission. > ] (See: privilege.) > > Since only the (I) items are "recommended", is there any reason we > can't live with: > > " Accreditation is an administrative declaration by a > designated authority > " that an information system is approved to operate in a particular > " security configuration with a prescribed set of safeguards. > > " Authentication is the process of verifying an identity claimed by or > " for a system entity. > > " Authorization is a right or a permission that is granted to a system > " entity to access a system resource. > > -- > John Leslie > From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 15:04:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20496 for ; Fri, 9 Jul 2004 15:04:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69IpkT2097717; Fri, 9 Jul 2004 11:51:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69IpkkV097716; Fri, 9 Jul 2004 11:51:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Ipfdt097695 for ; Fri, 9 Jul 2004 11:51:41 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id A4FF9414F4; Fri, 9 Jul 2004 11:51:40 -0700 (PDT) Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040709155856.240A916CCB@mail.nitros9.org> References: <20040709155856.240A916CCB@mail.nitros9.org> Content-Type: text/plain Message-Id: <1089399100.3159.151.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 09 Jul 2004 11:51:40 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-07-09 at 08:58, Alan DeKok wrote: > Douglas Otis wrote: > > > This does not show the relationship is non-linear. Do you need more > > > information as to what linear means, or are you ignoring the point and > > > spreading FUD on purpose? > > > > You have not offered simulations for traffic flow to counter this > > claim. > > The original question was entirely independent of traffic flow. Any question of network stability would, by its very nature, be related to traffic flow. : ) > > You have not offered a premise for your assumptions regarding the > > number of queries needed. > > The relationship I originally discussed, and what Greg was talking > about, was how the number of DNS queries depended on the number of > incoming SMTP connections. > > Let's define some terms: > > N = number of SMTP connections to an MTA > D = number of DNS queries performed by that MTA, per SMTP connection. > T = total number of Sender-ID DNS queries performed by the MTA. > > Q: Is T = \theta(N)? > > Your response was that D was large, and would cause the net to > collapse. I don't see how that could be construed as answering the > question. Taking the limits recommended by the draft (as a should), there may be as many as 20 DNS queries per message, or more! If compared to normal SMTP use where, as example, 100 messages are being transfered, at the receiving SMTP server, there may be a single DNS lookup at the beginning of the session. Assuming an average message size of 4k bytes in this example, where the average TCP packet payload is 1,400 bytes, this means within about 300 TCP packets received, there would be one small UDP query. For Sender-ID, the number of DNS queries added if at the should not exceed limits, would be 2000 UDP queries. The ratio of UDP queries to TCP packets, in this case, goes from 0.3 % to 666.0 % of TCP packets. > > An effective proponent would not resort to personal berating to > > dissuade critics. > > An effective opponent would answer questions, and would not resort > to avoiding the issue. The alleged ad hominem was directly on point: > You were asked a question, and you refused to answer it. Your answer > was ambiguous as to whether or not you even understood the question. > > From my reading of Sender-ID, all of the DNS lookups it performs are > initiated from SMTP connections. Therefore, the relationship must be > that T=\theta(N), and probably T=DN. > > Your argument that D is large is a nice one, but irrelevant to the > question you were asked. The limits as to the number of DNS queries per message should have some basis. : > My question, I thought, was clear. What is the basis of this limit in terms of DNS queries per message? This is expressed within the draft. I simply asked what the basis of this limit was. The next related question, of course, is what is the basis of the 10 second recommended timeout for the total of these 20 DNS queries? This is referencing information added to the core document http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt Pg. 18: 5.4 Recursion Limitations Evaluation of many of the mechanisms in section 5.1 will require additional DNS lookups. To avoid infinite recursion, and to avoid certain denial of service attacks, an MTA or other processor SHOULD limit the total number of DNS lookups that it is willing to perform in the course of a single authentication. Such a limit SHOULD allow for at least 20 lookups. If such a limit is exceeded, the result of authentication MUST be "hardError". MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to perform an authentication. Such a limit SHOULD allow at least 10 seconds. If such a limit is exceeded, the result of authentication SHOULD be "transientError". Domains publishing records SHOULD keep the number of DNS lookups to less than 20. Domains publishing records that are intended for use as the target of "indirect" elements SHOULD keep the number of DNS lookups to less than 10. Please notice, these limits are expressed only as SHOULD. I know a particular vendor was hoping to add to this and may explain why these limits are so large. : 0 I assume these numbers were not pulled from someone's hat. ; > Using these limits, how does the nature of the traffic change? These DNS queries will be comprised of Ethernet (26), IPv4 (20), and UDP (8) for about 54 bytes of transport overhead. Add to this the size of TXT record with about another 56 bytes response overhead and the size of the name referenced. Add to this the SOA field and Additional Data field. I will assume an average DNS response to be 350 bytes (out of a 576 byte packet limit) and about 100 bytes for the query. (The 512 byte DNS limit allows for transport overhead.) So for the TCP traffic of about 400 kbytes, 900 kbytes is used for the DNS queries. This recommended limit changes the traffic ratio of UDP/TCP traffic from 0.007 % to 225.0 % at the 666.0 % UDP/TCP packet ratio. Such a change to the amount of UDP traffic will impact the amount of packet loss, as UDP does not have congestion avoidance. I looked at a 5% packet loss to make a rough estimate of what this could mean with respect to the timeout on these series of DNS queries being produced for each message. With 20 DNS queries (40 packets) and a 5% packet loss and a 5 second DNS query retry period, the 10 second recommended timeout forces a 450 error at the end of the data phase for first message of 4 kbytes (although completely received in this storm of DNS traffic). This message will be discarded and require a retransmission at some later point as well as stopping the remaining messages. A few points added to this was that a common technique used by spammers was employing a random (often several) sub-domains accessing a wildcarded record to obfuscate their identity as a ploy to thwart filtering. This means the DNS cache will not contain this record. This is an important consideration as with the Sender-ID, all traffic is received before being discarded and a high percentage of this will be spam. The behavior of many spammers is not to remember the message rejected with an error or to wait any period of time before retrying. A different message identity will appear, still not found in the cache, and where the rejection process does not lessen the traffic load. As legitimate data attempts to slog through this blizzard of UDP, they will be dropped rather often and forced to retry as the per DNS query set allotment ensures a reduction of connection integrity compared to TCP. A basis for these numbers before making a serious assessment would be expected of anyone asked to take on such a difficult endeavor. The impression I have is these numbers were simply guesses and do not justify such examination until there is some expectation these will not change again and again. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 15:30:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23964 for ; Fri, 9 Jul 2004 15:30:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69JLJk5099425; Fri, 9 Jul 2004 12:21:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69JLJqJ099424; Fri, 9 Jul 2004 12:21:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69JLIqN099418 for ; Fri, 9 Jul 2004 12:21:18 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id BA588E052E; Fri, 9 Jul 2004 15:21:18 -0400 (EDT) Date: Fri, 9 Jul 2004 15:21:18 -0400 From: John Leslie To: "Hallam-Baker, Phillip" Cc: "'John Leslie'" , Dave Crocker , Meng Weng Wong , ietf-mxcomp@imc.org Subject: Re: terminology: authentication / authorization Message-ID: <20040709192118.GK57106@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (To tell truth, I _don't_ enjoy arguing semantics!) Hallam-Baker, Phillip wrote: > > The Internet Security glossary is not a definitive work, it is an > attempt to describe definitions that already existed in the field. Quite true; but it does recommend usage, which I'd like to believe we could agree to follow. > The computer security nomenclature was developed for non-networked > machines. Granting the right to perform an action is synonymous > with the ability to perform it. May I remind everyone that RFC2828 is dated May, 2000, and discusses terms in use to describe "Internet" ideas. Whatever baggage the definitions may carry from pre-network days, I'm sure the issue was carefully considered in relation to thirty years of internetworking experience. > Take a look at the definition itself and this becomes clear: > > An "authorization" is a right or a permission that is > granted to A SYSTEM entity to access A SYSTEM resource. "System" is a handwaving term, IMHO. (BTW, I agree with Phil that this definition may not fit perfectly. But we must consider it, since the IESG carefully chose to name this group "MTA Authorization Records in DNS".) > An authorization is NOT a right that is granted to an entity > on one system to access a resource on another system which is > what people are trying to make it. I agree completely. I find "permission" to be more useful than "right" in our context. Also, IMHO "system" must be interpreted broadly to consider the cloud of MTAs that constitute the email system on today's Internet. Thus, I must believe that IESG was thinking in terms of the granting of "permission" to access the TCP connectivity of the Internet in order to transfer email to other MTAs in the overall email system. (I'm not sure how helpful that is: personally, I want authorization to mean is that the management of the domain doing the authorizing agrees to accept responsibility for actions it authorizes. But I've come to accept that we can't squeeze that into the meaning of "authorization".) > According to the glossary what we have is a credential: > > $ credential(s) > (I) Data that is transferred or presented to establish either a > claimed identity or the authorizations of a system entity. (See: > authentication information, capability, ticket.) (That is accurately quoting RFC2828. I'll be happy to agree with it, if anyone thinks that will help.) We do, however, need to be careful _what_ we claim is a credential. (This question hasn't arisen much; so I'm not anxious to argue it.) > Most authentication credentials conflate authorization information > in some degree. If you insist on "conflate", I'll have to disagree. To the extent you mean "combine", though, I'm willing to agree. (I've long since given up hope anyone will believe I don't _enjoy_ semantic arguments.) > A username and password record conflates permission to log on to > the machine, an SSL certificate conflates permission to turn on the > padlock icon. Username/password is pure authentication, by whatever process it may be accomplished. The authentication module is virtually always unaware of what permissions may follow from the authentication. Indeed permissions are checked by entirely different processes at entirely different times. (SSL doesn't deserve discussion right now, IMHO.) > This does not mean that it is useful to call authentication and > authorization the same thing. I agree 100%. > A MARID record answers the question 'does the mail come from the > purported domain', that makes it an authentication credential. You're losing me, Phil. What MARID record are you talking about? In CSV we'd be talking about the SRV record, which is quite clearly "transferred" to "establish" the "authorization" to access the network as an MTA client. The "authentication" comes along for the ride, based on DNS servers automatically returning Address RRs as additional info. The CSV record makes no statement whatsoever about author, sender, or forwarder, merely about the assertion of the EHLO string. In Sender-ID, the spec is clear that the TXT record contains a statement of "policy"; and that its active elements are to be interpreted as a "function" returning "pass" or not. "Pass" means: ] ] 6.1 pass ] A "pass" result from the check means that the domain has authorized ] the sending of the message in question. An SMTP server receiving this ] result SHOULD accept the message. I really don't see how that is equivalent to "does the mail come from the purported domain?" Further, I don't see how it's "transferred" to "establish" a "claimed identity", which is the only way I could see it as an "authentication credential". > The motives of the writer are completely irrelevant, I sincerely hope we don't need to discuss those. > what is important here is the interpretation of the reader, that is > the only thing that gives the record meaning. Hopefully, specs will define interpretation well enough that we don't need to guess at how each reader will interpret it... ==== Oh, one last thing: > > [John Leslie wrote:] >> >> Since only the (I) items are "recommended", is there any reason we >> can't live with: >> >> " Accreditation is an administrative declaration by a designated authority >> " that an information system is approved to operate in a particular >> " security configuration with a prescribed set of safeguards. >> >> " Authentication is the process of verifying an identity claimed by or >> " for a system entity. >> >> " Authorization is a right or a permission that is granted to a system >> " entity to access a system resource. Did you intend to answer "Yes" or "No"? -- John Leslie From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 17:38:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02891 for ; Fri, 9 Jul 2004 17:38:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LQUPC009049; Fri, 9 Jul 2004 14:26:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69LQU5d009048; Fri, 9 Jul 2004 14:26:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LQHtT009014 for ; Fri, 9 Jul 2004 14:26:29 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: by neko-base.nekodojo.org (Postfix, from userid 500) id 870FF1D656; Fri, 9 Jul 2004 14:26:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 847701D651; Fri, 9 Jul 2004 14:26:20 -0700 (PDT) Date: Fri, 9 Jul 2004 14:26:20 -0700 (PDT) From: Greg Connor To: Dave Crocker Cc: Meng Weng Wong , Subject: Re: terminology: authentication / authorization In-Reply-To: <712793410.20040709140122@brandenburg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I object to the condescending tone used here. It's OK to be frustrated and it's also OK to say you're frustrated at something. But emotional outbursts like this one aren't professional behavior. gregc On Fri, 9 Jul 2004, Dave Crocker wrote: > > Meng, > > MWW> Perhaps it depends on point of view. > MWW>From the sender's point of view, the record authorizes MTAs > MWW> to use the sender's name. > MWW>From the receiver's point of view, the record authenticates > MWW> MTAs as being permitted by the sender. > > > Here is a really revolutionary idea. Why do we not, instead, start > using standard technical terms in their standard technical way? > > This groups needs to stop re-defining well-established security > terminology, especially when the primary effect of those redefinitions > is to make everything less consistent and precise, not more. > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > -- -- Greg Connor gconnor@nekodojo.org Everyone says that having power is a great responsibility. This is a lot of bunk. Responsibility is when someone can blame you if something goes wrong. When you have power you are surrounded by people whose job it is to take the blame for your mistakes. If they're smart, that is. -- Cerebus, "On Governing" From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 18:20:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07790 for ; Fri, 9 Jul 2004 18:20:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69MDPDY012974; Fri, 9 Jul 2004 15:13:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69MDP0U012973; Fri, 9 Jul 2004 15:13:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69MDOj4012962 for ; Fri, 9 Jul 2004 15:13:25 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 6709F132CD6; Fri, 9 Jul 2004 18:13:23 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id D3D215F6; Fri, 9 Jul 2004 18:13:23 -0400 (EDT) Date: Fri, 9 Jul 2004 18:13:23 -0400 From: Meng Weng Wong To: John Leslie Cc: ietf-mxcomp@imc.org Subject: Re: terminology: authentication / authorization Message-ID: <20040709221323.GF16317@dumbo.pobox.com> References: <20040709192118.GK57106@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040709192118.GK57106@verdi> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jul 09, 2004 at 03:21:18PM -0400, John Leslie wrote: | > Most authentication credentials conflate authorization information | > in some degree. | | If you insist on "conflate", I'll have to disagree. To the extent | you mean "combine", though, I'm willing to agree. (I've long since | given up hope anyone will believe I don't _enjoy_ semantic arguments.) I think we need to agree on terminology here. Is there an RFC that defines "conflate" versus "combine"? Just kidding. :) From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 18:23:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08137 for ; Fri, 9 Jul 2004 18:23:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69MHnpD013341; Fri, 9 Jul 2004 15:17:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69MHnpb013340; Fri, 9 Jul 2004 15:17:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69MHnwe013333 for ; Fri, 9 Jul 2004 15:17:49 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: by neko-base.nekodojo.org (Postfix, from userid 500) id 266761D656; Fri, 9 Jul 2004 15:17:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 258611D651; Fri, 9 Jul 2004 15:17:54 -0700 (PDT) Date: Fri, 9 Jul 2004 15:17:54 -0700 (PDT) From: Greg Connor To: Douglas Otis Cc: MARID Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: <1089399100.3159.151.camel@ddev.mail-abuse.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 1. Your assertion was that the relationship between SMTP connections and DNS requests is not linear. This is clearly false. You can admit that was a mistake, and retract it, or you can explain why you said it. Doing neither is called "spreading FUD". > Such a change to the amount of UDP traffic will impact the amount of > packet loss, as UDP does not have congestion avoidance. I looked at a > 5% packet loss to make a rough estimate of what this could mean with 2. You seem to be implying that UDP packets are more likely to be dropped than TCP packets. This is clearly false. 3. Any hypothetical situation prefixed by "Assume 5% packet loss" is pretty worthless. 5% packet loss is something to yell at your ISP about, not something you just assume as part of normal operation. > For Sender-ID, the number of DNS queries added if at the should > not exceed limits, would be 2000 UDP queries. The ratio of UDP queries > to TCP packets, in this case, goes from 0.3 % to 666.0 % of TCP packets. 4. A statement like "666% UDP to TCP ratio" seems to imply that an average SMTP transaction requires 20 DNS UDP packets, but only 3 TCP packets. Do you really believe it's possible to deliver a message with only 3 TCP packets? My rough guess was at least 14 and usually 20. > So for the TCP traffic of about 400 > kbytes, 900 kbytes is used for the DNS queries. This recommended limit > changes the traffic ratio of UDP/TCP traffic from 0.007 % to 225.0 % at > the 666.0 % UDP/TCP packet ratio. 5. You seem to be assuming that UDP packets have overhead and TCP packets do not. Also you seem to be assuming that since 20 lookups is the limit, that it will also be the average. 6. In practice, mail receivers already do plenty of DNS lookups, including the sender domain, the PTR of the IP, its corresponding A, the MX of the purported sender, one or more DNSBLs and/or RHSBLs. You don't appear to be taking this into account. It is unrealistic to expect an SMTP transaction to be accepted with "only one" DNS lookup. I don't think it's productive for me to reply to you anymore on this thread. My feeling is that your "concern" is not consistent with the reality, and you have not produced any "real world" measurements enough to merit attention for any "concern". I refuse to spend my time trying to disprove something that has not been supported at all (let alone proved) in the first place. Especially given that every time I reply to this thread I get back MORE FUD. If you are really "concerned" your best bet is to try to explain the "concern" to someone else, offline, who can understand it, AND who can write about it clearly and concisely. If you are not really concerned and are just spreading FUD because you don't like SenderID, well, have fun, but I am not going to play that game anymore and I expect others will get tired of it soon too. -- Greg Connor gconnor@nekodojo.org Everyone says that having power is a great responsibility. This is a lot of bunk. Responsibility is when someone can blame you if something goes wrong. When you have power you are surrounded by people whose job it is to take the blame for your mistakes. If they're smart, that is. -- Cerebus, "On Governing" From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 19:54:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14398 for ; Fri, 9 Jul 2004 19:54:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Nf5F0019237; Fri, 9 Jul 2004 16:41:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69Nf5sW019236; Fri, 9 Jul 2004 16:41:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mxr.enom.com (mxr.enom.com [63.251.174.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Nf4jS019221 for ; Fri, 9 Jul 2004 16:41:05 -0700 (PDT) (envelope-from dot@dotat.at) Received: from mail pickup service by mxr.enom.com with Microsoft SMTPSVC; Fri, 9 Jul 2004 09:18:04 -0700 Received: from above.proper.com ([208.184.76.39]) by mxr.enom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 9 Jul 2004 06:19:02 -0700 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69DFp0I066246; Fri, 9 Jul 2004 06:15:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69DFpeC066245; Fri, 9 Jul 2004 06:15:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69DFoa7066238 for ; Fri, 9 Jul 2004 06:15:50 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:60419) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1BivEA-00002G-IS for ietf-mxcomp@imc.org; Fri, 09 Jul 2004 14:15:46 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BivE9-00087m-Ig; Fri, 09 Jul 2004 14:15:45 +0100 Date: Fri, 9 Jul 2004 14:15:45 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk cc: Dave Crocker , Meng Weng Wong , "'IETF MARID WG'" Subject: Re: some thoughts on SUBMITTER In-Reply-To: Message-ID: References: <14354380.1089288967@Ryoga.corp.sgi.com> <20040708203846.GD16317@dumbo.pobox.com> <107381084.20040709150719@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 09 Jul 2004 13:19:02.0890 (UTC) FILETIME=[4D9EF4A0:01C465B7] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 9 Jul 2004, Tony Finch wrote: > > We have about 32,000 accounts on the University of Cambridge's central > message store, and about 7400 (23%) of them have some kind of Sieve > redirect set up. 4700 of them are to non-Cambridge addresses, i.e. > FIFTEEN PERCENT of our users will have trouble with the deployment of > designated sender schemes such as SPF and SenderID. I just realised that I counted everyone twice because of our replication system, so these proportions should be more like 11% and 7%. The stats from Oxford University are within a percentage point or so of my corrected numbers, and more broadly in line with what I expected before running the script. This is still a significant proportion of our user base. Tony. -- f.a.n.finch http://dotat.at/ LUNDY FASTNET: WEST OR NORTHWEST 3 INCREASING 4 OR 5, OCCASIONALLY 6. SHOWERS THEN RAIN. GOOD BECOMING MODERATE. From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 21:09:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19760 for ; Fri, 9 Jul 2004 21:09:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A0xb1b024300; Fri, 9 Jul 2004 17:59:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6A0xbeo024299; Fri, 9 Jul 2004 17:59:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A0xav2024292 for ; Fri, 9 Jul 2004 17:59:36 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id F39D4414F3; Fri, 9 Jul 2004 17:59:37 -0700 (PDT) Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) From: Douglas Otis To: Greg Connor Cc: MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1089421177.3159.472.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 09 Jul 2004 17:59:37 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-07-09 at 15:17, Greg Connor wrote: > 1. Your assertion was that the relationship between SMTP connections and DNS > requests is not linear. This is clearly false. You can admit that was a > mistake, and retract it, or you can explain why you said it. Doing neither is > called "spreading FUD". Here is the offending comment that I think you are referring to: http://www.imc.org/ietf-mxcomp/mail-archive/msg02586.html : On Wed, 2004-07-07 at 12:31, Alan DeKok wrote: : > Or, do you see Sender-ID as having an amplification problem? e.g. : > If MARID queries increased super-linearly with the number of : > connections. If so, it would be a serious flaw in the proposal. : : Serious indeed. : I see this as my agreeing to Alan Dekok's statement. But what you missed is that there was an amplification problem that Alan overlooked because he was still using the ASRG assumptions of RFC 2821 information used to reject messages. He admitted this difference in a subsequent message. I also started this message by indicating his reference to the LMAP discussion would be in error because of this, as it effected the benefit equations. To say I agreed with the statement does not mean I agreed with his example. I started this message making this concern explicit. Or so I had thought. : ( It was an example giving by Alan regarding a general concern. I felt there was an amplification problem that results from the use of the RFC 2822 information and an integrity problem causing repeated data. As the load on the network increases, a greater amount of data will need to be repeated. Rejection of messages subsequent to their receipt due to timeout conditions reaching much abbreviated limits for DNS responses will lead to this instability. High levels of DNS traffic will exacerbate such a problem. The sender of the message may have done nothing wrong, but the data must be resent adding to the network load. As this load increases, the amount of traffic that must be resent increases further. I would describe this a non-linear amplification problem and my reason for saying "Serious indeed." > > Such a change to the amount of UDP traffic will impact the amount of > > packet loss, as UDP does not have congestion avoidance. I looked at a > > 5% packet loss to make a rough estimate of what this could mean with > > 2. You seem to be implying that UDP packets are more likely to be dropped than > TCP packets. This is clearly false. Where do I say this? When the predominate traffic goes from a small percentage of UDP traffic, to where UDP traffic becomes the prevalent traffic, there will be a higher rate of packet loss. Unlike TCP, there is no direct means to signal a lost packet except by the lapse of time. Unlike TCP, UDP can not detect congestion and resorts to an exponentially increasing timeout on retries in an effort to avoid packet loss. This defensive strategy is defeated if the amount of independent UDP queries exceed network capacity. : ( > 3. Any hypothetical situation prefixed by "Assume 5% packet loss" is pretty > worthless. 5% packet loss is something to yell at your ISP about, not > something you just assume as part of normal operation. Yes, 5% would be a rather high level of loss, but I would not blame my ISP if most of my traffic was mostly UDP. : 0 > > For Sender-ID, the number of DNS queries added if at the should > > not exceed limits, would be 2000 UDP queries. The ratio of UDP queries > > to TCP packets, in this case, goes from 0.3 % to 666.0 % of TCP packets. > > 4. A statement like "666% UDP to TCP ratio" seems to imply that an average > SMTP transaction requires 20 DNS UDP packets, but only 3 TCP packets. Do you > really believe it's possible to deliver a message with only 3 TCP packets? My > rough guess was at least 14 and usually 20. This does not change the fact that the payload of UDP traffic went from .007 % to 225.0 %. Whether there are a few smaller TCP packets is of minor importance or that the numbers were .01 % to 225 %, I think this should provide a clear picture of the problem. > > So for the TCP traffic of about 400 kbytes, 900 kbytes is used for > > the DNS queries. This recommended limit changes the traffic ratio of > > UDP/TCP traffic from 0.007 % to 225.0 % at the 666.0 % UDP/TCP > > packet ratio. > > 5. You seem to be assuming that UDP packets have overhead and TCP packets do > not. Also you seem to be assuming that since 20 lookups is the limit, that it > will also be the average. It is expressed as a limit. If there are domains permitting this number of lookups, there is nothing wrong according to the draft. I was illustrating the absurd levels of UDP traffic the 20 DNS lookups per message would entail. I had started out using half of this number, but it did not seem to make an impression. Typically there are 4 DNS retries for a query where the timeout doubles each time. In an attempt repair the DDoS problem, the time cap for the entire set of queries was added to prevent the type of exposure to unknown servers as clarified in John Levine's tests: http://www.imc.org/ietf-mxcomp/mail-archive/msg02436.html > 6. In practice, mail receivers already do plenty of DNS lookups, including the > sender domain, the PTR of the IP, its corresponding A, the MX of the purported > sender, one or more DNSBLs and/or RHSBLs. You don't appear to be taking this > into account. It is unrealistic to expect an SMTP transaction to be accepted > with "only one" DNS lookup. Yes, there will be queries to RBLs in most cases and a few other DNS checks. RBL checks are to known servers that are often fairly robust. This fully misses the concern raised however, as none of these normal checks will cause good messages to be repeated. Nor will these rise to a level of UDP requests that may overwhelm network traffic with respect to payload, as it can for Sender-ID. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 22:02:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23452 for ; Fri, 9 Jul 2004 22:02:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A1okQM029204; Fri, 9 Jul 2004 18:50:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6A1okla029203; Fri, 9 Jul 2004 18:50:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A1okx6029197 for ; Fri, 9 Jul 2004 18:50:46 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i6A1oq1m017166; Fri, 9 Jul 2004 18:50:52 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Jul 2004 18:50:52 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Greg Connor'" , Douglas Otis Cc: MARID Subject: RE: Forging (was Re: Differences between CSV and Sender-ID ) Date: Fri, 9 Jul 2004 18:50:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > For Sender-ID, the number of DNS queries added if at the should > > not exceed limits, would be 2000 UDP queries. The ratio of > UDP queries > > to TCP packets, in this case, goes from 0.3 % to 666.0 % of > TCP packets. > > > 4. A statement like "666% UDP to TCP ratio" seems to imply > that an average > SMTP transaction requires 20 DNS UDP packets, but only 3 TCP > packets. Do you > really believe it's possible to deliver a message with only 3 > TCP packets? My > rough guess was at least 14 and usually 20. Come on, in the real world we send powerpoint slides and word documents arround. I send and receive emails in the 500Kb to 1Mb range on a daily basis. If we assume that only 5% of the emails have attachments thats 2,700-5,000 packets right there. Doug insists on assuming worst case, in practice Sender-ID is going to be no more than 3 lookups in 95% of cases. I really don't think that it is worth continuing this discussion. If the attack is real expect to see complaints from the large ISPs and the operators of outsourced spam filtering solutions, companies like Postini, Frontbridge, Messagelabs and VeriSign. From owner-ietf-mxcomp@mail.imc.org Fri Jul 9 22:14:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24525 for ; Fri, 9 Jul 2004 22:14:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A1vhYb029773; Fri, 9 Jul 2004 18:57:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6A1vhdJ029772; Fri, 9 Jul 2004 18:57:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6A1vgwN029765 for ; Fri, 9 Jul 2004 18:57:42 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 09 Jul 2004 22:01:41 -0400 Received: from ([65.10.99.121]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 3235549016; Fri, 09 Jul 2004 22:01:40 -0400 Message-ID: <020501c46621$5c714ea0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" Subject: Improving SUBMITTER - Persisent User Address/Account (PUA) Date: Fri, 9 Jul 2004 21:58:11 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Maybe I didn't quite see if this is "implied" in SUBMITTER proposal. If not, then the following may add some strength to the proposal. o Suggestion to improve SUBMITTER proposal: Persistent User Account (PUA) Background: Currently SUBMITTER is used basically when the return path has changed programmatically. Under common standards and BCP, an ISP will accept an user account MUA message for routing as long as there an MUA IP trust or a persistent user account (PUA) SMTP AUTH authentication process has taken place. Under these standard/BCP conditions, the MAIL FROM address can be any address like. Some systems, like an intranet, may offer an option to force the MAIL FROM to be a local domain account/address. This is not the general case for an open internet system. And the MUA uses a different address that is not part of the ISP controlled domain, it causes a problem for the server because there might not be any information to provide a submitter address. This can and will occur with legacy or non-submitter compliant clients. It also causes problem downlink when a responsible domain is not used. Solution: A SUBMITTER compliant server *MUST* use the ISP user account's persistent user address (PUA) for the SUBMITTER address when the return path is not part of the ISP domain. I believe that has been the missing ingredient in all this. It helps complete a circle of trust with the MSA/ISP providing a link to the responsible domain with a verifiable and responsible address, i.e, the user account mail address. For example: ISP: isp.example.com user account address: jqp@example.com User connected via PPP/DSL and is authorized to route via IP relay or SMTP AUTH. The user wants to use a different return path. Ergonomically, the MUA shows this as a Reply Address in the Account manager dialog box. A outbound MUA --> MSA transaction: S: 220 isp.example.com, Welcome EMSTP server ready C: HELO netbiosname S: 240 Hello isp.example.com C: mail from: private@alias.com S: 250 mail from ok C: rcpt to: S: 250 rcpt to ok This would be a typical situation. The MSA will use the real user account address because the return path was not part of the ISP domain. No dependency on MUA compliance. This adds great strength the transaction process because the ISP has taken the responsible duty to account for the authorized sender or return path. The message is routed to santronics.com: S: 220 mail.santronics.com, Welcome EMSTP server ready C: HELO isp.example.com S: 240 Hello mail.santronics.com C: mail from: , submitter=jpq@example.com S: 250 mail from ok C: rcpt to: S: 250 rcpt to ok Of course, there are all the other issues that make SUBMITTER problematic. But from a specification standpoint, this suggestion helps improve the SUBMITTER server logic with both functional and technical operational expectations. Benefits: - MUA compliancy not required. - SUBMITTER design usage and consistent structure. - Higher degree of persistent verifiable responsible "contact" address. Summary: The basic goal of SUBMITTER was to accomplish the idea of providing: o PRA - Purported Responsible Address o PRD - Purported Responsible Domain. The Persistent User Address (PUA) consideration removes the ambiguity with the fuzzy term - PURPORTED. The usage of submitter should only be provided when a non-MARID responsible domain has been removed from the transaction process. While a typical Mail Forwarding situation may create such a situation, the current SUBMITTER specification doesn't address other non-mail forwarding situations where the responsible domain is not longer used. The SUBMITTER server can use the PUA to provide this consistency in design structure. o Security Considerations: Off the top of my head, I can only see a "privacy issue" where the MUA may not want the MSA to use the PUA in the user's electronic communications. Comments? Please tell me where this PUA idea flawed so I can nix it and more on. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sat Jul 10 03:43:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27873 for ; Sat, 10 Jul 2004 03:43:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A7Toim007162; Sat, 10 Jul 2004 00:29:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6A7ToX3007161; Sat, 10 Jul 2004 00:29:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A7Toh3007154 for ; Sat, 10 Jul 2004 00:29:50 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6A7Thl12260 for ; Sat, 10 Jul 2004 00:29:44 -0700 Date: Sat, 10 Jul 2004 14:14:45 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <9819027.20040710141445@brandenburg.com> To: ietf-mxcomp@imc.org Subject: Comments on marid-core-01 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Herewith my "review" comments on marid-core-01. Given the history Quoted text, from the specification, is indented) My comments follow the quoted text and begin at the margin. MTA Authentication Records in DNS The described mechanism does MTA authorization, not authentication. If this is an authentication mechanism, it needs to explain how and what it authenticates. Given the confusion on the mailing list, this specification needs to list an acronym for referencing it. I assume that this is the document folks mean when they say Sender-ID, but whatever the right acronym, please list it. 1. Introduction In order to avoid further fragmentation of the Internet email system," There is nothing in the document that makes a case that Internet mail has become "fragmented" or that this particular technique will freeze the fragmentation (though I suspect you mean "eliminate" or somesuch.) The goal of the technique is to detect certain kinds of forgery and those kinds of forgery are popular right now. This is an inherently legitimate goal, so the disaster language is not needed. I think the document, as a specification, is better if the entire paragraph is dropped. However, as noted above, the document seems to confuse authentication and authorization. It should separate these constructs and deal with them in some detail. 2.1 Positive Problem Statement ... When a message is transferred via SMTP between two UNRELATED parties, does the SMTP client host have permission to send mail on behalf of the mailbox that allegedly caused the most recent introduction of the message into the mail delivery system? The phrasing and scope of the problem statement question is excellent. It describes a concern for author/sender authorization of the MTA path that a message follows. 2.2 Negative Problem Statement This section describes alternate questions, which this document makes no attempt to solve. This section is rather different from what it purports to be. In reality, it attempts to comment on related techniques. Given that this is a specification document, no such comparison is really needed. Worse, I know that the CSV description is flawed, and suspect that others are. The section is not needed for the coherence or correctness of the specification, so I suggest removing it. Given an email message, and given an IP address from which it has been (or will be) received, is the SMTP client at that host address authorized to send that email message? I suggest: Given an email message, and given the IP address of the sending SMTP client, from which it has been (or will be) received, is the SMTP client at that host address authorized by the Purported Responsible Address to transmit that email message. Because of the store-and-forward nature of email, there are lots of senders and receivers for a message, so it is best to be quite explicit that this is the latest-hop SMTP client that is being evaluated by the latest-hop receiving SMTP server, and that authorization comes from the RS. (The caps show that it is a formal term.) (3) Find the E-mail Policy Document for the purported responsible domain. Section 5.1 below describes the semantics of an E-mail Policy Document. Section 5.2 below describes how to find the document for a domain. The E-mail Policy Document contains a description of a "client authorization function". This function <<<< computational cost/complexity, dos exposure, etc >>> 4. Determining the Purported Responsible Address I am skipping over direct evaluation of the contents of this section in favor of a 'strategic' suggestion for it. I believe this section is a pure clarification to RFC2821/RFC2822 and stands independent of the current specification. I suggest breaking it out into a separate document and, especially, circulating it through the 2821/2822 community (ietf-smtp and ietf-822 mailing lists). Let me state this differently: marid-core does not innovate the construct of responsible sender. Its purpose is to use that construct in some specific ways. However you have noticed that existing Internet mail specifications leaves the construct fuzzy and you have contributed text that seeks to clarify it. All of this is goodness. What is not so good is to bury this clarification of a basic email construct in an MTA authorization specification. (I know we went over this in my comments on the Submitter document; but I'm trying to be complete, here. Plus I'm phrasing the basis for the suggestion a bit differently.) 5. E-mail Policy Document An E-mail Policy Document is modeled by an XML infoset that contains, among other things, a definition of the function ... I have always understood that a "function" has operators. In the definition of the infoset, I do not see any operators. So isn't this is really something akin to a macro-based access control list? (By the way, the IESG is going to ask about the computational complexity and load of this mechanism, and of the exposure to DOS attacks. I've just had them challenge a rather more modest spec on these grounds.) 7.2 TCP Attacks This mechanism is designed to be used in conjunction with SMTP over TCP. A sufficiently resourceful attacker might be able to send TCP packets with forged from-addresses, and thus execute an entire SMTP TCP has segments, not packets, and it has no "from-addresses", so I am not sure what sort of TCP Attack is being described here. My guess is you mean "SMTP Attack" or, rather "Email Sender Forgery Attack" but the rest of the section appears to be about a replay attack based on predictable SMTP and TCP content from the server. blind û the attack will be unable hear any of the server's side of note the problem character after 'blind'. Attacks of this sort can be ameliorated if IP gateways refuse to forward packets when the source address is clearly bogus. what "IP Gateway" are you referring to and what do you mean by gateway, here? How is the gateway to know that the source address is bogus? 7.3 Forged Resent-From Attacks ... In order to avoid this attack, MUAs will need to start displaying at least the header that was verified. This section highlights that this specification is about accountability and not accreditation. The suggestion about displaying the Resent-From header presumes that this is a useful technique for detecting forgery. It presumes some human factors that do not match empirical evidence. 9.2 E-mail Forwarders A program that forwards received mail to other addresses MUST add an appropriate header that contains an email address that it is authorized to use. Such programs SHOULD use the Resent-From header for this purpose. Resent-From is a pretty interesting choice to suggest. At the least, it is worth noting that this is a change from existing mailing list behavior, since they usually set Sender. I'm not saying that Resent-From is a bad choice, but merely that the fact of changing mailer behavior is probably worth noting. I'm also not sure whether I think that Resent-Sender is better than Resent-From. Mumble. Oh... You distinguish email forwarders from mailing list systems. I do not understand this. what, then, is an email forwarder? d/ ----- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA ; From owner-ietf-mxcomp@mail.imc.org Sat Jul 10 06:17:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02670 for ; Sat, 10 Jul 2004 06:17:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AA7Ykf065380; Sat, 10 Jul 2004 03:07:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6AA7YSp065378; Sat, 10 Jul 2004 03:07:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AA7YaN065370 for ; Sat, 10 Jul 2004 03:07:34 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip.cob.sjsu.edu (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6AA7Wl22275 for ; Sat, 10 Jul 2004 03:07:33 -0700 Date: Sat, 10 Jul 2004 17:07:14 +0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <545729098.20040710170714@brandenburg.com> To: ietf-mxcomp@imc.org Subject: Re: terminology: authentication / authorization In-Reply-To: <20040709192118.GK57106@verdi> References: <20040709192118.GK57106@verdi> 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 JL> May I remind everyone that RFC2828 is dated May, 2000, and discusses JL> terms in use to describe "Internet" ideas. Whatever baggage the JL> definitions may carry from pre-network days, I'm sure the issue was JL> carefully considered in relation to thirty years of internetworking JL> experience. For reference, folks, the current IETF Security ADs suggest using this document. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Sat Jul 10 07:39:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08073 for ; Sat, 10 Jul 2004 07:39:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ABK0k2075515; Sat, 10 Jul 2004 04:20:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6ABK0Ft075514; Sat, 10 Jul 2004 04:20:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ABJwAn075508 for ; Sat, 10 Jul 2004 04:19:59 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55007) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1BjFtc-00067f-B8 for ietf-mxcomp@imc.org; Sat, 10 Jul 2004 12:19:56 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BjFtb-0008Cx-N3 for ietf-mxcomp@imc.org; Sat, 10 Jul 2004 12:19:55 +0100 Date: Sat, 10 Jul 2004 12:19:55 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: Re: Comments on marid-core-01 In-Reply-To: <9819027.20040710141445@brandenburg.com> Message-ID: References: <9819027.20040710141445@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 10 Jul 2004, Dave Crocker wrote: > > By the way, the IESG is going to ask about the computational > complexity and load of this mechanism, and of the exposure to DOS > attacks. I've just had them challenge a rather more modest spec on > these grounds. I reviewed the SPF spec from this point of view a couple of months ago, and I concluded that it was only just short of being Turing-complete (ignoring the implementation limits that restrict the size of the computation). A slight enhancement to the macro language would give it full computational ability. http://archives.listbox.com/spf-discuss@v2.listbox.com/200405/0075.html http://archives.listbox.com/spf-discuss@v2.listbox.com/200405/0080.html However from the point of view of protocol design Turing completeness isn't such an important property. Based on some quick hand-waving, I believe it is possible to create SPF records that require an execution time that's exponential in the size of the record, with storage requirements that are linear in the record size. I can't think of a construction that would require enormous storage. Implementation limits are ABSOLUTELY REQUIRED to avoid problems. I have not reviewed the current specification with this in mind. Tony. -- f.a.n.finch http://dotat.at/ FAEROES SOUTHEAST ICELAND: VARIABLE 3 OR 4. OCCASIONAL RAIN OR DRIZZLE. MODERATE OR GOOD &NBSP;. From owner-ietf-mxcomp@mail.imc.org Sat Jul 10 11:11:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18013 for ; Sat, 10 Jul 2004 11:11:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AEqUis094704; Sat, 10 Jul 2004 07:52:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6AEqUaT094703; Sat, 10 Jul 2004 07:52:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6AEqTc0094694 for ; Sat, 10 Jul 2004 07:52:29 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 16200 invoked from network); 10 Jul 2004 14:53:46 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 10 Jul 2004 14:53:46 -0000 In-Reply-To: <020501c46621$5c714ea0$6401a8c0@hdev1> References: <020501c46621$5c714ea0$6401a8c0@hdev1> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "IETF-MXCOMP" From: Margaret Olson Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA) Date: Sat, 10 Jul 2004 10:52:26 -0400 To: "Hector Santos" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think I may have gotten lost reading this proposal, here are some comments based on my best understanding. Let me know if I'm just missing the point: On Jul 9, 2004, at 9:58 PM, Hector Santos wrote: > > Maybe I didn't quite see if this is "implied" in SUBMITTER proposal. > If > not, then the following may add some strength to the proposal. > > o Suggestion to improve SUBMITTER proposal: Persistent User Account > (PUA) > How does this proposal work where the return path domain does not have a PUA for this user? This is common for ESPs and various forms of transactional messages (outsourced shopping carts). Modifying your example a bit for clarity (please let me know if I misunderstood it!): > > ISP: isp.example.com > user account address: jqp@example.com 2821 MAIL-FROM: private@alias.com 2822 FROM private@alias.com In this case, alias.com must have a MARID record that authorizes example.com to send mail on it's behalf. Why is anything more necessary? If you meant: 2821 MAIL-FROM: private@alias.com 2822 FROM jqp@example.com then the SUBMITTER must match the 2822 from which in this case is jqp@example.com, so additional restrictions are not necessary. If you meant: 2821 MAIL-FROM: private@alias.com 2822 FROM someone@somewhere.com then somewhere.com still has to have authorized example.com to send mail on it's behalf. As many people have pointed out, somewhere.com may be a pretty worthless domain, and authentication is not sufficient to end spam. If example.com is well run, they will have their own policies to make sure that someone@somewhere.com is legitimate regardless of whether or not somewhere.com has authorized them to send mail on their behalf. I can see the option of forcing the SUBMITTER to the PUA as being one way for an ISP to enforce such a policy, but I'm not clear on how it works with the rest of the PRD algorithm. ESPs and hosted vertical applications will need to use other methods, and a large majority already have some level of controls in place. This does serve as a reminder of Dave Crocker's point at the interim meeting that channel does matter, but I am inclined to think that channel validation and domain validation should be kept separate. I'll observe that ISP email accounts are in general a fair amount (sometimes infinitely) cheaper than ESP or vertical application accounts that permit anything other than trivial volume, and therefore the cost constraints in these sectors are quite different. I would not expect to find a single end user verification method that worked well for all types of channel. Margaret. From owner-ietf-mxcomp@mail.imc.org Sat Jul 10 14:00:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23887 for ; Sat, 10 Jul 2004 14:00:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AHnBRT007971; Sat, 10 Jul 2004 10:49:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6AHnB7L007970; Sat, 10 Jul 2004 10:49:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server.moongroup.com (server.moongroup.com [24.172.57.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AHnApT007954 for ; Sat, 10 Jul 2004 10:49:10 -0700 (PDT) (envelope-from csm@MoonGroup.com) Received: from [192.168.0.10] (rdu74-169-100.nc.rr.com [24.74.169.100]) (authenticated bits=0) by server.moongroup.com (8.12.11/8.12.11) with ESMTP id i6ALVLHC000781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 10 Jul 2004 17:31:22 -0400 Message-ID: <40F02C16.5050507@MoonGroup.com> Date: Sat, 10 Jul 2004 13:49:10 -0400 From: Chuck Mead Organization: MoonGroup.com User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: SPF-Classic X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been following these discussions for some time and not had a thing ~ to say as it has appeared to me that a lot of balls are being juggled simultaneously. That said I have 3 points I would like to make. 1. SPF Classic DNS records are dead simple to publish. This makes adoption a matter of a few seconds per domain even for a DNS admin who does his zone management on the command line. Ease of adoption is a huge factor in the success of any new protocol or standard. I did all of my domains (30 or so) in less than a half hour a few months back and it just worked and it has ever since. It was simple to do and that ease of implementation was a big factor in my taking the time to adopt SPF-Classic. In the real world network admins are busy and do not want to take time for "yet another major roll out" of some new high falutin' technology (yes I'm southern born and bred so just deal with it! :-). 2. SPF Classic for the MTA is also ridiculously simple to implement and this is another big boost as we not only want the DNS records published but we need the MTA's to play their part as well. Now I'll grant that I use postfix so that's the only MTA I've set up with SPF but it truly was a simple thing to do. From what I gather the other OSS MTA's are as simple or a bit more difficult but doable in any event. I have also seen a commercial add on implementation of SPF for Exchange so it seems that Microsoft's MTA is taken care of as well. This takes care of both sides of the equation! 3. Given these two previous points what in the world are we doing talking about changing things up? We have a working implementation that fulfills the intent we all need. Why not write it up as is and have done with it? The point of it all is that people adopt it yes? If they don't we fail in our ultimate objective right? So why not go for SPF Classic? It's proven and it works *TODAY*! Given that we have a working, free and open source implementations available that is doing the job today for thousands of domains already what is the reason for continued debate and constant proposals for change? It seems a waste of time to me and as I mentioned in point #1 above network admins are busy. It seems to me that what's really happening is a bit of "jockeying" around for position and advantage by a certain large, Washington state based corporation. Now if I have mis-read the situation I apologize in advance but if my suspicions are correct this is uncalled for and unwanted. The problem we're trying to solve is immediate and growing... to overcomplicate it in pursuit of some mystery corporate objectives seems to be a waste of everyone's time but theirs. Is there some reason that SPF classic DNS TXT records won't work with the Microsoft nameservers? I run bind on Linux so I have no personal knowledge of it but I suspect SPF Classic records ought to work just fine. Lets roll with Meng and have done with the brouhaha! - -- csm@moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA8CwWv6Gjsf2pQ0oRAmtqAJ9MQ9+8JFe+6WXckiHUn+/rYQAnHgCgtFgA LvZxw5SbHzUhvqHh4yWtOjs= =7zP7 -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Sat Jul 10 16:03:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29732 for ; Sat, 10 Jul 2004 16:03:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AJsCJM016266; Sat, 10 Jul 2004 12:54:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6AJsC9A016265; Sat, 10 Jul 2004 12:54:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6AJs90u016259 for ; Sat, 10 Jul 2004 12:54:12 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 71946 invoked from network); 10 Jul 2004 19:54:09 -0000 Received: from 181.sub-166-145-237.myvzw.com (HELO 5nn0011) (166.145.237.181) by relay.pair.com with SMTP; 10 Jul 2004 19:54:09 -0000 X-pair-Authenticated: 166.145.237.181 From: "Scott Kitterman" To: Subject: RE: Improving SUBMITTER - Persisent User Address/Account (PUA) Date: Sat, 10 Jul 2004 15:54:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <020501c46621$5c714ea0$6401a8c0@hdev1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hector Santos > Sent: Friday, July 09, 2004 9:58 PM > To: IETF-MXCOMP > Subject: Improving SUBMITTER - Persisent User Address/Account (PUA) > > > Maybe I didn't quite see if this is "implied" in SUBMITTER proposal. If > not, then the following may add some strength to the proposal. > > o Suggestion to improve SUBMITTER proposal: Persistent User Account (PUA) > > Background: > > Currently SUBMITTER is used basically when the return path has changed > programmatically. > > Under common standards and BCP, an ISP will accept an user account MUA > message for routing as long as there an MUA IP trust or a persistent user > account (PUA) SMTP AUTH authentication process has taken place. > > Under these standard/BCP conditions, the MAIL FROM address can be any > address like. Some systems, like an intranet, may offer an > option to force > the MAIL FROM to be a local domain account/address. This is not > the general > case for an open internet system. > > And the MUA uses a different address that is not part of the ISP > controlled > domain, it causes a problem for the server because there might not be any > information to provide a submitter address. > > This can and will occur with legacy or non-submitter compliant clients. > > It also causes problem downlink when a responsible domain is not used. > > Solution: > > A SUBMITTER compliant server *MUST* use the ISP user account's persistent > user address (PUA) for the SUBMITTER address when the return path is not > part of the ISP domain. > > I believe that has been the missing ingredient in all this. It helps > complete a circle of trust with the MSA/ISP providing a link to the > responsible domain with a verifiable and responsible address, > i.e, the user > account mail address. > > For example: > > ISP: isp.example.com > user account address: jqp@example.com > > User connected via PPP/DSL and is authorized to route via IP relay or SMTP > AUTH. The user wants to use a different return path. Ergonomically, the > MUA shows this as a Reply Address in the Account manager dialog box. > > A outbound MUA --> MSA transaction: > > S: 220 isp.example.com, Welcome EMSTP server ready > C: HELO netbiosname > S: 240 Hello isp.example.com > C: mail from: private@alias.com > S: 250 mail from ok > C: rcpt to: > S: 250 rcpt to ok > > This would be a typical situation. > > The MSA will use the real user account address because the return path was > not part of the ISP domain. No dependency on MUA compliance. > > This adds great strength the transaction process because the ISP has taken > the responsible duty to account for the authorized sender or return path. > > The message is routed to santronics.com: > > S: 220 mail.santronics.com, Welcome EMSTP server ready > C: HELO isp.example.com > S: 240 Hello mail.santronics.com > C: mail from: , submitter=jpq@example.com > S: 250 mail from ok > C: rcpt to: > S: 250 rcpt to ok > > Of course, there are all the other issues that make SUBMITTER problematic. > > But from a specification standpoint, this suggestion helps improve the > SUBMITTER server logic with both functional and technical operational > expectations. > > Benefits: > > - MUA compliancy not required. > - SUBMITTER design usage and consistent structure. > - Higher degree of persistent verifiable responsible "contact" address. > > Summary: > > The basic goal of SUBMITTER was to accomplish the idea of providing: > > o PRA - Purported Responsible Address > o PRD - Purported Responsible Domain. > > The Persistent User Address (PUA) consideration removes the ambiguity with > the fuzzy term - PURPORTED. > > The usage of submitter should only be provided when a non-MARID > responsible > domain has been removed from the transaction process. While a > typical Mail > Forwarding situation may create such a situation, the current SUBMITTER > specification doesn't address other non-mail forwarding > situations where the > responsible domain is not longer used. > > The SUBMITTER server can use the PUA to provide this consistency in design > structure. > > o Security Considerations: > > Off the top of my head, I can only see a "privacy issue" where the MUA may > not want the MSA to use the PUA in the user's electronic communications. > > Comments? > > Please tell me where this PUA idea flawed so I can nix it and more on. > I think this is absolutely brilliant. From the perspective of a small domain owner that doesn't run my own MTA (aka vanity domain), this has the potential to resolve my concerns about use of shared MTAs as designated senders. I would go one step farther and allow authorized submitters to be identified in the sender policy. I currently use SPF, but have ?include:isp.net in my SPF record because I am concerned about someone else forging my domain from the isp. This isn't much use. If I could designate an authorized submitter, then I would be in a position to make a stronger statement about the message being auuthorized. If I could, instead, have +submitter:username@isp.net in my record it would say something positive. Receivers could then retrieve my sender policy record and match the submitter against my policy statement. If they don't match (and if nothing else matches in the record) then the test fails. If the submitter matches what's in my policy record, then they would have to retrieve isp.net's policy record to see if the mesage really came from their network, but they would have to do that anyway to support the include: that's there now. I believe that your proposal in combination with supporting changes in sender policy definition would add significant strength to the Sender-ID proposal. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Sun Jul 11 03:00:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09148 for ; Sun, 11 Jul 2004 03:00:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B6ilDO096807; Sat, 10 Jul 2004 23:44:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6B6ilSb096806; Sat, 10 Jul 2004 23:44:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B6ikTt096790 for ; Sat, 10 Jul 2004 23:44:46 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id B265A1D651; Sat, 10 Jul 2004 23:44:44 -0700 (PDT) Date: Sat, 10 Jul 2004 23:44:45 -0700 From: Greg Connor To: Hector Santos Cc: IETF-MXCOMP Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA) Message-ID: <29107774.1089503085@[10.12.1.26]> In-Reply-To: <020501c46621$5c714ea0$6401a8c0@hdev1> References: <020501c46621$5c714ea0$6401a8c0@hdev1> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Hector Santos wrote: > > Maybe I didn't quite see if this is "implied" in SUBMITTER proposal. If > not, then the following may add some strength to the proposal. > > o Suggestion to improve SUBMITTER proposal: Persistent User Account (PUA) Actually, that is very close to the original intent of PRA I think... Your explanation of what Persistent User Account would mean sounds almost exactly like what I think "Sender:" is supposed to mean and how it is used. This is probably the reason Sender: was included as a part of the PRA spec. I think everything you suggested here is consistent with the SUBMITTER draft, though it's probably a good idea to improve the draft with a couple of use cases so that this is more clear. More info on Sender: and return path follows... RFC2476 went into some detail about Sender:, saying for example that if the local user is known on initial submission (MUA to MSA) then MSA may put in Sender: based on what it knows. > 8.1. Add 'Sender' > The MSA MAY add or replace the 'Sender' field, if the identity of the > sender is known and this is not given in the 'From' field. > > The MSA MUST ensure that any address it places in a 'Sender' field is > in fact a valid mail address. So there is already a precedent that says MSA should put in the user's information and make sure Sender: is right... but unfortunately RFC2476 is not followed as often as it should be. Perhaps the best thing we can do in this case is to remind users (and sysadmins and support people) that if their From: address is not local to the network they are currently on, at least Sender: should be. We *could* do this in the document that defines PRA and refer people to RFC2476 to lend strength to our assertion that the MSA should add Sender: if the locally-known user is different from the claimed From: address. Based on this, I think your explanation of PUA is consistent with the way PRA and SUBMITTER are already described. PRA is a formula to determine "who injected this message into the mail stream" in a way that lends itself well to IP-based checking. Forwarding is one example of this, but when From: != Sender: this also applies. SUBMITTER augments PRA by saying if PRA != MAIL FROM, use SUBMITTER to tell who the PRA is. Therefore ISPs have a choice - either force outgoing mail to have a local account in MAIL FROM, or use PRA and SUBMITTER by way of setting Sender: to the local account. I believe this is almost exactly what you are proposing with PUA. RFC2476 also talks about "return path" - and this is interesting in the case where ISP allows users to specify any MAIL FROM they want. > If an MSA is not able to determine a return path to the submitting > user, from a valid MAIL FROM, a valid source IP address, or based on > authenticated identity, then the MSA SHOULD immediately reject the > message. It goes on to say that an MSA can deal with problems by rejecting inline with SMTP, or by accepting and sending a bounce message, but it specifically says that bounce messages are not acceptable in the case where it can't correlate the return path to the submitting user. I think this is a key difference between MSA and MTA, but unfortunately a lot of ISPs don't follow RFC2476 closely enough. (I think if more ISPs would take this part seriously there would be a lot less forgery going around.) So, how does an ISP "determine a return path to the submitting user"? ISPs could easily do this by asking users what other email addresses they would like to use, even non-local ones, and sending a verification email to the claimed address to ensure it really belongs to the user. (If they want to use any localpart in their entire domain, the verification email could be sent to postmaster@domain.) This would allow users to use return addresses not local to their ISP, and keep the ISP compliant... If the return path is non-local they would still need Sender: or SUBMITTER or PUA or something, so that the receiver has something to check besides the non-local name. Anyway this is yet another way that RFC2476 has given us some ammunition we can use -- we just need point people at it and remind them that this has been expected of them for 5.5 years and what we are proposing is not that dramatic. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Mon Jul 12 14:37:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29905 for ; Mon, 12 Jul 2004 14:37:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CIPGt2050576; Mon, 12 Jul 2004 11:25:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CIPGtY050575; Mon, 12 Jul 2004 11:25:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CIPGBE050569 for ; Mon, 12 Jul 2004 11:25:16 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (verisign.com [65.205.251.33] (may be forged)) by pigeon.verisign.com (8.12.10/) with ESMTP id i6CIP6bt020022 for ; Mon, 12 Jul 2004 11:25:19 -0700 Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <3ZJMAZZ8>; Mon, 12 Jul 2004 11:21:09 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: Comments on draft-ietf-marid-core-01.txt Date: Thu, 8 Jul 2004 08:37:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some comments on the draft: 1) Section 5. The scope here is outgoing email policy, identified by . Since we have a 500 byte limit we are working inside and since outgoing and incomming policies will always be used in separate operation I suggest that we recognize this at the selector prefix level: _out._ep. - For outgoing email policy _in._ep - For incomming policy I think that incomming policy will be very useful when domains are communicating information like 'I process MARID records' or 'I accept S/MIME & PGP signed email'. Arguably such information could be exchanged inband in SMTP, but this is not guaranteed to be possible. Section 5.2 Are these macro expansions really necessary? Would it be possible to eliminate them entirely or if some form of indirection is needed could we simply define an element for that purpose. I am unconvinced by the claims that MARID could be used for DDoS purposes, but there are certainly lots of moving parts here. Regardless, I am unable to parse the explanation of the macro functions: l = local-part passed to the client authorization function. s = Same as "%{l}@%{o}". o = original domain passed to the client authorization function. d = current domain passed to the client authorization function. i = SMTP client IP (nibble format when an IPv6 address). p = SMTP client domain name v = client IP version string: "in-addr" for ipv4 or "ip6" for ipv6 r = domain name of the SMTP server. local part OF WHAT? If s is the same as "%{l}@%{o}" then why duplicate it? I find it very hard to work out precisely what the terms original and current mean in this context. I really cannot see a justification for all this mechanism unless the idea here is that the spec is going to somehow conform to legacy data sources such as blacklists. That does not make a lot of sense to me since a blacklist is accreditation data which by definition comes from a third party and cannot therefore be interpreted without reference to the reputation of the acreditation provider. If the receiver is tracking said reputation it makes best sense for the receiver to also track the correct way to extract the data from the service. I would like to see some use cases to motivate this whole section. My strong beleif is that it is possible to address this issue using elements such as and for include:%{l}.domain and include:%{i}.domain and meet all the interesting use cases. This approach would allow the spec to be further constrained so that a factored record of this type cannot itself reference a factored record. This ensures that the type of DoS attack hypothesized is completely eliminated. There are at most two branches in the tree and only one branch is to be followed. Removing the macro expansions limits flexibility on the part of administrators in the way that they format their data. This is usually a good thing. Give two ways to express the same data that offer no advantage and you create two code paths that have to be maintained, more importantly you have two un-fun legacy protocol issues down the road. The restricted examples given are still sufficient to allow support of use cases such as delegating particular usernames to a specific email provider. They can use a to break up the record and service@anybank.com can point to a record at constant contact. Equally if a person wants to set up an outgoing mail server on a mobile machine they can do that using an and dynamic DNS. Of course this still leaves a problem if you are behind a NAT box, but the external NAT box address is discoverable. Phill From owner-ietf-mxcomp@mail.imc.org Mon Jul 12 14:37:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29935 for ; Mon, 12 Jul 2004 14:37:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CIRGeL050707; Mon, 12 Jul 2004 11:27:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CIRG1x050706; Mon, 12 Jul 2004 11:27:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CIRF9P050699 for ; Mon, 12 Jul 2004 11:27:16 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (verisign.com [65.205.251.33] (may be forged)) by pigeon.verisign.com (8.12.10/) with ESMTP id i6CIRAbp021832; Mon, 12 Jul 2004 11:27:18 -0700 Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <3ZJMA5S2>; Mon, 12 Jul 2004 11:22:06 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Greg Connor'" , "'IETF MARID WG'" Subject: RE: the focus of MARID Date: Thu, 8 Jul 2004 12:51:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Err I tried to do that at 11am this morning... I think we need two forms of expansion, by IP address and by username component of the sender address. I don't think that there is anything else that is absolutely essential. I would prefer to require information providers to present their information in a restricted format rather that attempting to support flexibility. The premise here is that the MARID info is here for MARID use only. > Would you like to take a stab at naming some macros to be > dropped? (And > yes, it's a serious suggestion; I'm not trying to be > facetious or anything > :) > > -- > Greg Connor > From owner-ietf-mxcomp@mail.imc.org Mon Jul 12 23:03:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18623 for ; Mon, 12 Jul 2004 23:03:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D2oGxJ091961; Mon, 12 Jul 2004 19:50:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D2oG0m091960; Mon, 12 Jul 2004 19:50:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6D2oFjB091897 for ; Mon, 12 Jul 2004 19:50:15 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Mon, 12 Jul 2004 22:54:20 -0400 Received: from ([65.2.204.75]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 3497907985; Mon, 12 Jul 2004 22:54:19 -0400 Message-ID: <00c201c46884$36432b80$6401a8c0@hdev1> From: "Hector Santos" To: "Margaret Olson" Cc: "IETF-MXCOMP" References: <020501c46621$5c714ea0$6401a8c0@hdev1> Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA) Date: Mon, 12 Jul 2004 22:48:38 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I was waiting for more input or comments. I guess it is still early. I will follow up on some of you input. ----- Original Message ----- From: "Margaret Olson" To: "Hector Santos" Cc: "IETF-MXCOMP" Sent: Saturday, July 10, 2004 10:52 AM Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA) > > o Suggestion to improve SUBMITTER proposal: Persistent User Account > > (PUA) > > > How does this proposal work where the return path domain does not have > a PUA for this user? This is common for ESPs and various forms of > transactional messages (outsourced shopping carts). If we are all the same wavelength, I would presume this with be a prior arrangement situation, hence trust is already established. However, in the name of a domain authorization, a PUA can be administratively assigned to the relay sender. > Modifying your example a bit for clarity (please let me know if I > misunderstood it!): > > > > ISP: isp.example.com > > user account address: jqp@example.com > > 2821 MAIL-FROM: private@alias.com > 2822 FROM private@alias.com The problem statement is drastically reduced and solved by removing 2nd level processes from the 1st level process - "chicken vs egg." From what I understand the basic argument for 2822 is to statisfy an ergomic requirement for the end user - "the look and feel." That still doesn't address the question; "Well it looks and feels good, but who is he and why did I get it in the first place?" Anyway, there are far too many direct and indirect implied assumptions and requirements with this. It presumes the MUA is compliant and it presumes the entire end to end process is compliant. What I don't understand here if is the MUA mail creation and sender process must change to comply, then why doesn't does the MUA mail pickup and mail display logic doesn't change as well? Why isn't POP3 or IMAP involed here? If there is a Sender: or other header, the MUA can change its display. In all, far too many conflictive design issues that in my view isn't call far. We didn't even address the full address yet, and that is one of the main points about PUA suggestion. It immediately provides strength to the MSA for immediate impact for ALL current MUAs without alteration a reliable mode of user operations. Again, that still doesn't resolve down links possible issues. But PUA I think gets the ball rolling. When downlinks do adapt, they will understand that the PUA is must closer to a valid address than anything that is being proposed. I should state that I suggest PUA only because we have a big company behind it, not really because I think SUBMITTER/SENDER-ID is a good idea. I think they are kludges and are bad terrible ideas. I predict undesirable new situations. I won't go into them again, but I will ask this rethorical question: If there is such as high requirement of software change for SUBMITTER/SENDER-ID compliant, then why not just add a new HEAD command at SMTP? From a design and implementation standard, that would be far easier to help addresss the qoals of SUBMITTER/SENDER-ID and it also prepares us for the future for other ideas as well. Finally, there is no justice in all this generalization. That is what makes this all thing so complex. But I do have a perspective of looking at ALL that is being proposed from an implementation standpoint, I do have tons of operational experience with a real customer base provided valuable feedback. I'll be among the first to implement sound ideas that first well and also helps solve the problem. No matter what we do, we still need to able to address the guy that sends a support question I just say today: How to I get Joe's mom using an AOL account whitelisted to by-pass the AOL rejecting of mom's address using a CBV? I mean, AOL is saying the address is no good at the MX and this guy is saying it is good! SPF returned a neutral result so that didn't help. But lets said that AOL got its act together and did validate the IP, we still have not addressed the "Email Address Validation" problem. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Mon Jul 12 23:22:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19891 for ; Mon, 12 Jul 2004 23:22:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3AxB2093260; Mon, 12 Jul 2004 20:10:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D3Axop093259; Mon, 12 Jul 2004 20:10:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6D3Aw2W093251 for ; Mon, 12 Jul 2004 20:10:58 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Mon, 12 Jul 2004 23:15:04 -0400 Received: from ([65.2.204.75]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 3499152110; Mon, 12 Jul 2004 23:15:03 -0400 Message-ID: <00c301c46887$1bdcdef0$6401a8c0@hdev1> From: "Hector Santos" To: "Greg Connor" Cc: "IETF-MXCOMP" References: <020501c46621$5c714ea0$6401a8c0@hdev1> <29107774.1089503085@[10.12.1.26]> Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA) Date: Mon, 12 Jul 2004 23:11:34 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Greg Connor" To: "Hector Santos" Cc: "IETF-MXCOMP" Sent: Sunday, July 11, 2004 2:44 AM Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA) > I think everything you suggested here is consistent with the SUBMITTER > draft, though it's probably a good idea to improve the draft with a couple > of use cases so that this is more clear. Well, it is all indirectly implied, but it has all the conflict direct and indirect "implied" requirements for compliance at the MUA. > Based on this, I think your explanation of PUA is consistent with the way > PRA and SUBMITTER are already described. > > .... > > Anyway this is yet another way that RFC2476 has given us some ammunition we > can use -- we just need point people at it and remind them that this has > been expected of them for 5.5 years and what we are proposing is not that > dramatic. Reminder: ESMTP AUTH is still an extension hence the E in SMTP. :-) Oh, It is extremely dramatic. From a user support standpoint, support requirements are drastically reduced when the user is authenticated by IP. Since ESMTP AUTH was an extension, early wide adaptation was unrealistic hence the usage of POP B4 SMTP to resolve the issue. (Note: This is how a ISP customer explained it to me in how POP B4 SMTP help reduced his support requirements for end-users not having ESMTP AUTH support). Starting on July 13, Bellsouth now requiring ESMTP AUTH for all MUAs is to resolve their growing wireless roaming user market. It had nothing to do with address the spam problem per se, SPF or the yet to be endorsed and supported SUBMITTER. Bellsouth.net added an neutral SPF and it is now force all users to use a Bellsouth.net SPF domain. I really don't think bellsouth.net realized this. They don't see it yet because I am white listing bellsouth.net at my final destination. But when you remove the white list, you run into situations where the return path identity is changed and accepted at the MSA but rejected at the MDA. This implies a chain of compliance and trust across the board. Not just at the MSA. When you see a problem in your face, you immediate see what are the ideal required technical solutions. The PUA only reduces the compliance requirement at the initial MUA and MSA not requiring ESMTP AUTH (for SUBMITTER reasons) and at the same time, provides some level of confidence and accountability for a full address validation. Not just the domain. In no case , however, it does not address the downlink compatibility requirements. That still needs to be address. :-) and if we must change everything, well, there are full better ideas than SUBMITTER/SENDER-ID, like just having a HEAD command. Thanks for your input Greg. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Mon Jul 12 23:36:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20367 for ; Mon, 12 Jul 2004 23:36:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3J5cV093877; Mon, 12 Jul 2004 20:19:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D3J5vZ093876; Mon, 12 Jul 2004 20:19:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3J4iv093869 for ; Mon, 12 Jul 2004 20:19:04 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BkDop-00080z-S2 for ietf-mxcomp@imc.org; Mon, 12 Jul 2004 22:19:09 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 12 Jul 2004 22:18:59 -0500 In-Reply-To: (wayne@midwestcs.com's message of "Thu, 01 Jul 2004 00:39:15 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Obstacles between us and the finish line Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.4 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: About two weeks ago, I posted the following summary of things I see as major obstacles between us and an acceptable standard-track RFC. In wayne writes: > Deadlines for this working group are rapidly approaching. According > to Andy's recent post, we have about 2 weeks (until 07/18) to finish > things up. > > In my (oh so very humble) opinion, I see the following obstacles in > the way: > > 1) Proposals must have solid I-Ds I is my understanding that the design-team meeting last Friday made significant progress on the RFCs. In particular, it is my understanding that much of marid-core has been replaced by a chopped up version of the SPF-classic spec, which I personally think is likely to be a huge improvement. That said, such significant changes only a week before the IETF-60 I-D submission deadline does not leave much time for real working group review and changes/fixes. I am almost certain that I will have a number of things that I would like see changed in the SenderID "protocol" RFC in order to deal with issues such as DDoS potentials. > 2) Proposals must have working code Now that XML has been eliminated, the SPF-classic libraries/implementations can be used to check the PRA and no new code really needs to be written. That is, except for the code to extract the PRA. If the PRA RFC is going to be advanced by this working group, those that think it is a good idea should create some working code. Otherwise, I don't think we will reach a rough consensus as to whether it is a useful RFC to introduce onto such an important part of the Internet. > 3) Proposals must have been tested on real world data Like 2), there is *still* zero published data on how effective the PRA algorithm is on real world data. I know that it would create a false positive on the only email account that I have forwarded to my main email address. I know that it will break on many mailing lists. I don't know much more than that. > 4) Proposals must have IP licensing terms that allow for use in both > commercial and GPLed MTAs. Again, the PRA RFC has IPR claims. It is my understanding (IANAL) that there is a very good chance that these license offered with the PRA is incompatible with the GPL, and may have other problems. There are significant MTAs out there (e.g. Postfix and Exim) along with spam filters and MUAs that the current PRA license would prevent the implementation of SenderID. If, indeed, the PRA license is incompatible, I do not think we should advance it as an RFC. > 5) Proposals must not have gratuitous incompatibilities with an > installed base. It is my understanding that most of the problems between SPF-classic (e.g. the installed base of SPF records) and Sender-ID have been resolved. If forced to hum today, I would have to say that SenderID is not ready for submission as a standard-track RFC. We don't have much time to fix things before IETF-60. It is my gut feel that we will not be able to do a working group last call until after IETF-60, pushing the whole schedule back by several weeks or a month. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jul 13 00:04:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21659 for ; Tue, 13 Jul 2004 00:04:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3mioe095781; Mon, 12 Jul 2004 20:48:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D3miVF095780; Mon, 12 Jul 2004 20:48:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6D3miVl095774 for ; Mon, 12 Jul 2004 20:48:44 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Mon, 12 Jul 2004 23:52:50 -0400 Received: from ([65.2.204.75]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 3501417563; Mon, 12 Jul 2004 23:52:48 -0400 Message-ID: <00e401c4688c$6240a390$6401a8c0@hdev1> From: "Hector Santos" To: "Scott Kitterman" , References: Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA) Date: Mon, 12 Jul 2004 23:49:17 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Scott Kitterman" To: Sent: Saturday, July 10, 2004 3:54 PM Subject: RE: Improving SUBMITTER - Persisent User Address/Account (PUA) > > o Suggestion to improve SUBMITTER proposal: > > Persistent User Account (PUA) > I think this is absolutely brilliant. From the perspective of a small > domain owner that doesn't run my own MTA (aka vanity domain), this has the > potential to resolve my concerns about use of shared MTAs as designated > senders. I would go one step farther and allow authorized submitters to be > identified in the sender policy. > I currently use SPF, but have ?include:isp.net in my SPF record because I am > concerned about someone else forging my domain from the isp. At first, I was thinking you meant just having a MX directive in your own SPF records, but you are adding a directive exposing a 3rd party SPF policy. Right? > This isn't much use. Right. That would solve the problem for a changed return path that is SPF ready at the MDA but is not part of the original ISP SPF domain at the MSA. > If I could designate an authorized submitter, then I would be in > a position to make a stronger statement about the message being auuthorized. > If I could, instead, have +submitter:username@isp.net in my record it would > say something positive. At first thought, ideas like this is "scary" when exposing this type of information. It might be exploitable, in this or other ways, possibly. But I can see where it works. > I believe that your proposal in combination with supporting changes in > sender policy definition would add significant strength to the Sender-ID > proposal. Yes. If anything, if it does get adopted this way, I can see the ISP having no qualm about providing a WEB base form where the user can supply a list of his non ISP domain identities. The USER may have an privacy issue with that but atleast the ISP is making the offering :-) -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Tue Jul 13 02:52:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15797 for ; Tue, 13 Jul 2004 02:52:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D6guEA024264; Mon, 12 Jul 2004 23:42:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D6guaf024263; Mon, 12 Jul 2004 23:42:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6D6gtE4024255 for ; Mon, 12 Jul 2004 23:42:56 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Tue, 13 Jul 2004 02:46:57 -0400 Received: from ([65.2.204.75]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 3511865125; Tue, 13 Jul 2004 02:46:56 -0400 Message-ID: <012501c468a4$b5d95160$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" Subject: SUBMITTER for Bounce Messages Date: Tue, 13 Jul 2004 02:43:28 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Unless I missed it, but can submitter be used or expected for system notifications: MAIL FROM: <> submitter=sender@domain.com -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Tue Jul 13 14:55:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03598 for ; Tue, 13 Jul 2004 14:55:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DISvj9070096; Tue, 13 Jul 2004 11:28:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DISvlX070095; Tue, 13 Jul 2004 11:28:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server.moongroup.com (server.moongroup.com [24.172.57.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DISu4C070077 for ; Tue, 13 Jul 2004 11:28:56 -0700 (PDT) (envelope-from csm@moongroup.com) Received: from [192.168.0.20] (64-205-130-223.client.dsl.net [64.205.130.223]) (authenticated bits=0) by server.moongroup.com (8.12.11/8.12.11) with ESMTP id i6DMAVrY009514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jul 2004 18:10:32 -0400 Message-ID: <40F429E3.7060704@moongroup.com> Date: Tue, 13 Jul 2004 14:28:51 -0400 From: Chuck Mead User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Obstacles between us and the finish line References: In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 wayne wrote: | Again, the PRA RFC has IPR claims. It is my understanding (IANAL) | that there is a very good chance that these license offered with the | PRA is incompatible with the GPL, and may have other problems. There | are significant MTAs out there (e.g. Postfix and Exim) along with spam | filters and MUAs that the current PRA license would prevent the | implementation of SenderID. | | If, indeed, the PRA license is incompatible, I do not think we should | advance it as an RFC. Licenses which limit a technology make the supporting RFC a waste of time. I won't use it... nor will I support it's use if there are artificial limits created by licensing. |>5) Proposals must not have gratuitous incompatibilities with an |> installed base. | | | It is my understanding that most of the problems between SPF-classic | (e.g. the installed base of SPF records) and Sender-ID have been | resolved. | | | | If forced to hum today, I would have to say that SenderID is not ready | for submission as a standard-track RFC. We don't have much time to | fix things before IETF-60. It is my gut feel that we will not be able | to do a working group last call until after IETF-60, pushing the whole | schedule back by several weeks or a month. I usually don't give a single ditto as it's not typically useful but in this case I think that would be the wrong approach so... like a clarion bell let me say as clearly as possible... ME TOO! NB. Let's get on with it! Shall we? - -- Chuck Mead csm@moongroup.com Chief Tech @ http://moongroup.com - http://anirononline.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA9Cnjv6Gjsf2pQ0oRAhpIAJwIA+UosQF9DsdgA6aIHsmYWQf4kACfdOIZ tn4Mhvr+lx0MZUULS6buhWM= =LYAN -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Tue Jul 13 16:14:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11560 for ; Tue, 13 Jul 2004 16:14:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DK39Nk076935; Tue, 13 Jul 2004 13:03:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DK39Db076934; Tue, 13 Jul 2004 13:03:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DK368Y076925 for ; Tue, 13 Jul 2004 13:03:09 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10259; Tue, 13 Jul 2004 16:03:08 -0400 (EDT) Message-Id: <200407132003.QAA10259@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-protocol-00.txt Date: Tue, 13 Jul 2004 16:03:08 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : The SPF Record Format and Test Protocol Author(s) : M. Wong, M. Lentczner Filename : draft-ietf-marid-protocol-00.txt Pages : 30 Date : 2004-7-13 This document defines the format of a record that domains publish to authorize a set of hosts to send mail on its behalf. This document also defines the check_host() function that mail receivers evaluate to see if a particular host is authorized to submit a particular piece of mail. This document only describes the particulars of the syntax and the algorithm of the function. See the MARID Core draft (draft-ietf-marid-core) for how these are used in the context of sending and receiving Internet mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-protocol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-protocol-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-13145156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-13145156.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Tue Jul 13 17:00:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17228 for ; Tue, 13 Jul 2004 17:00:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKcmXx079573; Tue, 13 Jul 2004 13:38:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKcmtr079572; Tue, 13 Jul 2004 13:38:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKclx6079565 for ; Tue, 13 Jul 2004 13:38:47 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i6DKcq7O011360 for ; Tue, 13 Jul 2004 13:38:52 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Jul 2004 13:38:52 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: Obstacles between us and the finish line Date: Tue, 13 Jul 2004 13:38:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > 4) Proposals must have IP licensing terms that allow for use in both > > commercial and GPLed MTAs. > > Again, the PRA RFC has IPR claims. It is my understanding (IANAL) > that there is a very good chance that these license offered with the > PRA is incompatible with the GPL, and may have other problems. There > are significant MTAs out there (e.g. Postfix and Exim) along with spam > filters and MUAs that the current PRA license would prevent the > implementation of SenderID. > > If, indeed, the PRA license is incompatible, I do not think we should > advance it as an RFC. I can't find any statement in draft-ietf-marid-submitter-01.txt that would support this claim. Note that to go forward the only requirement is code, and that is strictly speaking only required to go to draft. There has never been a requirement for open source code, let alone open source code that is compatible with any given license. It should be possible to write code to the spec and release it as public domain (which is in my view the only real open source license). If you can do that you can meet any other license term. From owner-ietf-mxcomp@mail.imc.org Tue Jul 13 20:25:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13829 for ; Tue, 13 Jul 2004 20:25:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E0878L095287; Tue, 13 Jul 2004 17:08:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E0874c095286; Tue, 13 Jul 2004 17:08:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E0865e095280 for ; Tue, 13 Jul 2004 17:08:06 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BkXJa-00022F-TP for ietf-mxcomp@imc.org; Tue, 13 Jul 2004 19:08:12 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Tue, 13 Jul 2004 19:08:02 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 13 Jul 2004 13:38:51 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Obstacles between us and the finish line Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.4 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: >> > 4) Proposals must have IP licensing terms that allow for use in both >> > commercial and GPLed MTAs. >> >> Again, the PRA RFC has IPR claims. [...] >> >> If, indeed, the PRA license is incompatible, I do not think we should >> advance it as an RFC. > > I can't find any statement in draft-ietf-marid-submitter-01.txt that > would support this claim. Indeed, the submitter draft has nothing to support the claim that the PRA has a license. It is the marid-core document, where the PRA algorithm is described, that supports that claim. > Note that to go forward the only requirement is code, and that is strictly > speaking only required to go to draft. *sigh* Let me quote RFC2026 yet again: 4.1.1 Proposed Standard [snip] Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. Now, whether the IESG considers the SenderID to "have significant operational impact on the Internet" or not, I can't say. What I can say is what I think, and I think it does. (Note where I said "I think" in the stuff you quoted above.) In fact, I will go so far as to say that if there is no working code and no testing by several independant organizations, I will argue against advancing the SenderID proposal both during the WG last call and during the IETF last call. I realize that this would create a risk that the SenderID proposal will not advance. However I consider that slightly more acceptable than the risks associated with advancing a completely untested proposal that has such a huge impact on such an important part of the internet. Mind you, I would *much* prefer to simply have a well tested RFC. I would *much* prefer not having a messy "discussion" during the last call periods. > There has never been a requirement > for open source code, let alone open source code that is compatible with > any given license. Nice red herring there. I have never said that the code must be open source. However RFC3668 says that a working group can consider the IPR issues and that we should prefer technologies that do not have IPR problems. RFC3668 is a good document, I recommend people read it. Again, I think that any proposals that will prevent any significant MTAs/spam filters from implementing this technology, whether the are GPLed, commercial, or because the developer wears blue shoes, is simply not acceptable. The fact that the SenderID proposal has been allowed by the co-chairs to advance this far without making the required RFC3668 disclosures is troublesome. I really don't want to see the "discussions" during the IETF last call that will happen if MARID advances a proposal that is incompatible with the GPL. If these IPR issues can't be resolved soon, I suggest that this working group start considering other technologies that do not have such problems. > It should be possible to write code to the spec and release it as public > domain (which is in my view the only real open source license). If you > can do that you can meet any other license term. I agree, it *should* possible, but the SenderID requires a license from MicroSoft. We have already had enough messy "discussions" here. Let's not repeat the fun that was had with RSA. For people who like the SenderID proposal, I highly recommend taking the time to address these concerns. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jul 13 20:41:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15780 for ; Tue, 13 Jul 2004 20:41:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E0VuiT097630; Tue, 13 Jul 2004 17:31:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E0VuNG097629; Tue, 13 Jul 2004 17:31:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6E0VtYp097623 for ; Tue, 13 Jul 2004 17:31:55 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 45331 invoked from network); 14 Jul 2004 00:31:44 -0000 Received: from 176.sub-166-154-180.myvzw.com (HELO 5nn0011) (166.154.180.176) by relay.pair.com with SMTP; 14 Jul 2004 00:31:44 -0000 X-pair-Authenticated: 166.154.180.176 From: "Scott Kitterman" To: Subject: FW: Improving SUBMITTER - Persisent User Address/Account (PUA) Date: Tue, 13 Jul 2004 20:31:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hector Santos > Sent: Monday, July 12, 2004 11:49 PM > To: Scott Kitterman; ietf-mxcomp@imc.org > Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA) > ----- Original Message ----- > From: "Scott Kitterman" > To: > Sent: Saturday, July 10, 2004 3:54 PM > > > > o Suggestion to improve SUBMITTER proposal: > > > Persistent User Account (PUA) > > > I think this is absolutely brilliant. From the perspective of a small > > domain owner that doesn't run my own MTA (aka vanity domain), > this has the > > potential to resolve my concerns about use of shared MTAs as designated > > senders. I would go one step farther and allow authorized submitters to > be > > identified in the sender policy. > > > I currently use SPF, but have ?include:isp.net in my SPF record > because I > am > > concerned about someone else forging my domain from the isp. > > At first, I was thinking you meant just having a MX directive in your own > SPF records, but you are adding a directive exposing a 3rd party > SPF policy. > Right? > Right. The domain is hosted at, nominally, host.net. The MX is servername.host.net. What I want to include is the DSL provider (that I described as isp.net). So currently I put the ? in front of the include:isp.net because there is no way to tell if an e-mail from the isp.net smtp server was actually sent by my account or someone else's. Your suggestion allows a resolution to that problem. > > This isn't much use. > > Right. That would solve the problem for a changed return path that is SPF > ready at the MDA but is not part of the original ISP SPF domain > at the MSA. > > > If I could designate an authorized submitter, then I would be in > > a position to make a stronger statement about the message being > authorized. > > If I could, instead, have +submitter:username@isp.net in my record it > would > > say something positive. > > At first thought, ideas like this is "scary" when exposing this type of > information. It might be exploitable, in this or other ways, > possibly. But > I can see where it works. Yes, I expose to the spammers the name of a valid e-mail address, but other than getting more spam, I don't think there's a major risk here. If they can break SMTP Auth, we have bigger problems than this. > > > I believe that your proposal in combination with supporting changes in > > sender policy definition would add significant strength to the Sender-ID > > proposal. > > Yes. If anything, if it does get adopted this way, I can see the ISP > having no qualm about providing a WEB base form where the user > can supply a > list of his non ISP domain identities. The USER may have an privacy issue > with that but atleast the ISP is making the offering :-) > Actually I was hoping to avoid the sign up part. The ISP really has no good way to validate who is authorized to send for what external domain. By adding an authorized submitter to the SPF (or whatever) record, then the domain owner can make a positive statement about who is authorized to submit for the domain. No added work for the isp, other that adding SUBMITTER into their SMTP setup. Could do it your way too, but that would put more of a burden on the ISP's. I don't know that they'd sign up for all the validation effort that would be required. I think this is a critical change for small domain owners that outsource their MTA services (vanity domains). As it stands now, almost all valid e-mail from my domain will come back neutral because of the exact problem your suggestion can solve. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Tue Jul 13 21:19:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20705 for ; Tue, 13 Jul 2004 21:19:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E19Wmx001537; Tue, 13 Jul 2004 18:09:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E19Wlo001536; Tue, 13 Jul 2004 18:09:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org ([168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E19WNv001515 for ; Tue, 13 Jul 2004 18:09:32 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 4526741495 for ; Tue, 13 Jul 2004 18:09:03 -0700 (PDT) Subject: Submitter shown the DOR From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1089767342.15308.577.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 13 Jul 2004 18:09:02 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In Monday's Jabber session, in the few minutes spent reviewing Sender-ID, there was a statement made a new name may need to be created. I had a few questions regarding Sender-ID I hoped to broach before the topic was changed to CSV or should I say "How CSV is different from SPF et al" that lasted two hours." I must say, that I found such attention remarkable. Morph lives. :^) Submitter 01 Draft Quotes: 4.2 Processing the SUBMITTER Parameter ... Verifying MTAs are strongly urged to validate the SUBMITTER parameter against the RFC 2822 headers; otherwise, an attacker can trivially defeat the algorithm. Sender-ID states in the Security Considerations: This extension offers no protection against a user in one domain spoofing another user within the same domain. Example of a Domain of Responsibility Tag: C: MAIL FROM: DOR:t:"ddddd.dddddd";x:"ddddd";a:"ttttt"; s:"tttttttt"; b:"tttttttttttttttttttttttttttttttttttt"; d:"alumni.almamater.edu"; (a:algorithm, t:time-stamp, x:expiry, b:base64 signature, s:selector, d:domain) Submitter adds another mailbox within the RFC 2821 parameters. The user may not wish to expose this additional mailbox, however, and it would be remarkable if the user was aware of specific mail infrastructure to make such assertions in a responsible manner. In this vein, the draft allows the MUA to issue this information outside the SMTP server's authentication of the client? The goal of protecting return addresses is thwarted if a Resent-Sender header and a matching Submitter header is added to a message intended to continue spoofing the return address, where this obscures the path of the message. In other words, the return address continues to be spoofed through permissions provided by this new mailbox. In addition, this new mailbox then requires yet another accreditation, while yet the insecure pathway in need of repair to abate a problem remains obscured. :^0 There are strong methods for commerce to ensure messages have been received from the indicated domains. As example, the following proposal shows how a DNS based domain key can be used to sign the entire message. http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt Could such a method be used to ensure the Submitter information is not forged? Yes, absolutely. :^) Change the name of Submitter to Domain of Responsibility (DOR). This would be the domain that authenticated the SMTP client for forwarding rather than direct submission. The DOR tag would be the method this server accepts responsibility by signing the adjoining MAIL FROM statement with a time stamp and its own domain as a statement of having authenticated the SMTP client. The DOR tag then locates the source of abuse should there be a problem later uncovered with the message without exposing more information about the user than needed. This method would help large ISPs ensure accreditation is properly assigned to their customers operating different domains as well. :^) Examples of signing individual headers is provided in: http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt Just as the Submitter proposal does not directly involve DNS, none of these proposals are directly associated with DNS, so a full discussion should involve a greater audience it would seem. Implications of Submitter tags: If Big-Bank.com left their outbound SMTP server lists "open", then they hope to ensure only communications directly from their mail servers would have the "Checked for Big-Bank.com" marking. (Assuming the customer's local ISP mail infrastructure is secure.) If Big-Bank.com "closed" their list, they then must vouch for the integrity of servers used by their sub-contractors. This may place Big-Bank.com in an unpleasant situation. Either have their clients see mail arrive "Unchecked for Big-Bank.com", or "Checked for Ads-R-Us.com" or risk trusting their subcontractors to ensure the security of these systems. Can you see the finger pointing? :^( Big-Bank.com should expect those wishing to spoof their return address to use similar domains allowed by the Submitter alternative address that may not be fully understood by their customers. The submitter address could be Big-Bank.info as example, where the return address remains the address their customers expect to see, such as accounts@big-bank.com. The bad news would be that if Big-Bank.com did not "close" their lists and accept responsibility for their sub-contractors, those spoofing their address would have the spoofed address indicated as "Checked for Big-Bank.info" appear more convincing than their bulk ads marked as "Unchecked for Big-Bank.com" or "Checked for Ads-R-Us.com". For that matter, if the lists were left "open", spoofing would continue, looking as mail being sent through their subcontractors. Confusing? Not to overlook the likelihood that channel checks for this information will not function when attacked, where these checks then become removed. This leaves Big-Bank.com customers to be informed not to trust any information appearing as originating from Big-Bank.com even if their customer's mail program indicates "Checked for Big-Bank.com". If the goal is to stop abuse, then the DOR tag rather than the Submitter tags provides the same function, but would never be emitted by the MUA, nor would it expose more user information. The DOR tag can withstand channel checks being disabled. If there is abuse, the DOR tag would allow authorities to find the door of the entity causing the problem. The Submitter tag allows abusers to continue to hide in the muck and mire of often open or unscaleable lists demanded in an effort to publish all SMTP clients used for all domains authorized to originate mail on behalf of a domain. Moving closer to the source of the problem helps close the door on abuse. The DOR tag will allow an accurate post delivery assessment as to the source of the problem and enable accurate accreditation of domains and their policies. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 00:18:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12023 for ; Wed, 14 Jul 2004 00:18:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E48V2t014925; Tue, 13 Jul 2004 21:08:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E48V9V014924; Tue, 13 Jul 2004 21:08:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E48UBs014916 for ; Tue, 13 Jul 2004 21:08:31 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Obstacles between us and the finish line MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 13 Jul 2004 23:08:37 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA920@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Obstacles between us and the finish line Thread-Index: AcRoiz6vsbt0VL/fS/mPuPAG5Vlp3wAy2w1Q From: "Gordon Fecyk" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6E48VBs014918 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > 3) Proposals must have been tested on real world data > > Like 2), there is *still* zero published data on how effective the PRA > algorithm is on real world data. I know that it would create a false > positive on the only email account that I have forwarded to my main > email address. I know that it will break on many mailing lists. I > don't know much more than that. How about trying the information I was lent by the IMS Users mailing list? There's over a year and a half of real world data on real and fake sender domains, HELO identities, message sizes, IP addresses and so on. I'll bet others can come up with similar logs. Sure there isn't any DOR/Submitter information or headers or whatever. Some of this could be synthesized for the purposes of testing, like setting some bogus rule like, "if [host] has [domain] in part of its name, treat it like [something]." It would be enough to do inital testing before putting it on a live server. I'll yank out the Access database and leave the raw plain text log in a separate archive. I can provide separate domain and host information in a different archive if it's difficult to separate it all out. http://www.pan-am.ca/smtp.zip In addition, the Win2K event sink shell I've asked to have coded up is being worked on. The event sink itself will call an external library, which actually implements MARID. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 03:10:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27612 for ; Wed, 14 Jul 2004 03:10:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E6wpXh046639; Tue, 13 Jul 2004 23:58:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E6wpoj046638; Tue, 13 Jul 2004 23:58:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E6woL8046602 for ; Tue, 13 Jul 2004 23:58:50 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 13 Jul 2004 23:58:39 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 Jul 2004 23:58:47 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Jul 2004 23:58:47 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Jul 2004 23:58:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SUBMITTER for Bounce Messages Date: Tue, 13 Jul 2004 23:58:45 -0700 Message-ID: Thread-Topic: SUBMITTER for Bounce Messages thread-index: AcRopYhUuJZgQUTITbSYUXjKlgpImQAya0Qc From: "Harry Katz" To: "Hector Santos" , "IETF-MXCOMP" X-OriginalArrivalTime: 14 Jul 2004 06:58:46.0366 (UTC) FILETIME=[01FA6FE0:01C46970] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6E6woL8046629 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The draft is not explicit on this subject, but I would say, yes, it should be used when MAIL FROM is <>. The value whould be based on the RFC 2822 headers of the system notification message, and I would expect that in most cases it would be something like postmaster@example.com. ________________________________ From: owner-ietf-mxcomp@mail.imc.org on behalf of Hector Santos Sent: Mon 7/12/2004 11:43 PM To: IETF-MXCOMP Subject: SUBMITTER for Bounce Messages Unless I missed it, but can submitter be used or expected for system notifications: MAIL FROM: <> submitter=sender@domain.com -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 06:07:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06590 for ; Wed, 14 Jul 2004 06:07:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E9s0ZF097468; Wed, 14 Jul 2004 02:54:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6E9s0ff097467; Wed, 14 Jul 2004 02:54:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E9rx6i097457 for ; Wed, 14 Jul 2004 02:54:00 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39604) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1BkgST-0008Dy-Jl for ietf-mxcomp@imc.org; Wed, 14 Jul 2004 10:53:49 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BkgSS-0002vv-Oz; Wed, 14 Jul 2004 10:53:48 +0100 Date: Wed, 14 Jul 2004 10:53:48 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Douglas Otis cc: MARID Subject: Re: Submitter shown the DOR In-Reply-To: <1089767342.15308.577.camel@ddev.mail-abuse.org> Message-ID: References: <1089767342.15308.577.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 13 Jul 2004, Douglas Otis wrote: > > Example of a Domain of Responsibility Tag: > > C: MAIL FROM: > DOR:t:"ddddd.dddddd";x:"ddddd";a:"ttttt"; > s:"tttttttt"; > b:"tttttttttttttttttttttttttttttttttttt"; > d:"alumni.almamater.edu"; > > (a:algorithm, > t:time-stamp, > x:expiry, > b:base64 signature, > s:selector, > d:domain) Why not just get the originator's MSA to sign the original return path? This gives end-to-end authentication of the MSA, does not require any change to aliasing/forwarding systems or to SMTP, and works well with callback verification. Dave Crocker's BTAV draft is a start at a specification. Tony. -- f.a.n.finch http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: WEST OR NORTHWEST 3 OR 4 BACKING SOUTHEAST, THEN VEERING WEST 4 OR 5 LOCALLY 6 ON WEDNESDAY. PATCHY RAIN AND PERHAPS LOCAL MIST CLEARING TO SCATTERED SHOWERS ON WEDNESDAY. MODERATE OR GOOD, BUT PERHAPS LOCALLY POOR IN MIST FOR A TIME. MODERATE IN NORTH BUT SLIGHT IN SOUTH. From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 11:44:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24668 for ; Wed, 14 Jul 2004 11:44:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFQk4O007731; Wed, 14 Jul 2004 08:26:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFQkiJ007729; Wed, 14 Jul 2004 08:26:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFQYDC007627 for ; Wed, 14 Jul 2004 08:26:36 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 0A15C16CCB for ; Wed, 14 Jul 2004 11:33:53 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Forging (was Re: Differences between CSV and Sender-ID ) In-Reply-To: Your message of "Thu, 08 Jul 2004 10:23:48 PDT." Date: Wed, 14 Jul 2004 11:33:52 -0400 Message-Id: <20040714153353.0A15C16CCB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hallam-Baker, Phillip" wrote: > Alan is right in pointing out that we should not overestimate > these guys. > > Sure it is very clever to set up 3-tier botnets. Our intervention > center discovers a lot of very clever stuff. > > But no, these guys are not half as smart as they think they are. It's a common fallacy to "romanticise" criminal activities. News programs describe "daring robberies", and "skilled attacks". Movies have exciting teams of interesting people working closely together in a well-coordinated and professional manner. In reality, criminals aren't as professional or exciting as the popular media portrays. They're often losers who can muster up the gumption to stick a gun in someones face, or break a window, but they can't hold down a steady job, or interact well with others. We shouldn't make the same mistake when describing spammers. The skills required to set up a spam operation cannot compare to the skills required to operate and maintain an ISP, or other legitimate business. > These guys can do stuff that is amazingly complex one minute and > then something really really stupid the next. They make these mistakes for the same reason they chose to engage in criminal behavior: certain psychological characteristics. Few non-criminals, or non-spammers share those characteristics. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 12:41:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27498 for ; Wed, 14 Jul 2004 12:41:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGKOJ2025256; Wed, 14 Jul 2004 09:20:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EGKOP8025255; Wed, 14 Jul 2004 09:20:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGKN9a025238 for ; Wed, 14 Jul 2004 09:20:23 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BkmUV-0001RE-DP for ietf-mxcomp@imc.org; Wed, 14 Jul 2004 11:20:24 -0500 To: "IETF MARID WG" From: wayne Reply-To: "IETF MARID WG" Date: Wed, 14 Jul 2004 11:20:19 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: where are the new drafts for SenderID? time is running out. Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.4 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Where are the new drafts for SenderID that were developed at last Friday's design-team meeting? It is my understanding that many changes have been made. The deadline for revisions is next monday. Even if these revised documents were released today, that would only leave a few days for this working group to study the changes, make recommendations, and let the authors get another round of revisions through. Ok, it the new marid-protocal I-D is out, but what about the critical and heavily changed marid-core document? Will it include the required RFC3668 text about IPR? What changes have been made to the marid-submitter I-D? -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 13:00:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29002 for ; Wed, 14 Jul 2004 13:00:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGi159028737; Wed, 14 Jul 2004 09:44:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EGi1rt028736; Wed, 14 Jul 2004 09:44:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from kanga.astray.com (kanga.astray.com [195.82.114.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGhxp9028719 for ; Wed, 14 Jul 2004 09:44:00 -0700 (PDT) (envelope-from shevek@astray.com) Received: from shevek (helo=localhost) by kanga.astray.com with local-esmtp (Exim 4.12) id 1BkmrN-0007Bt-00 for ietf-mxcomp@imc.org; Wed, 14 Jul 2004 17:43:57 +0100 Date: Wed, 14 Jul 2004 17:43:57 +0100 (BST) From: Shevek X-X-Sender: shevek@astray.com To: IETF MARID WG Subject: Re: Obstacles between us and the finish line In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 1 Jul 2004, wayne wrote: > 4) Proposals must have IP licensing terms that allow for use in both > commercial and GPLed MTAs. The requirement to even THINK about licensing terms when one is implementing a "standard" internet protocol is almost unimaginable. The IETF is supposed to promote interoperability without precondition. The introduction of any form of license in order to use a "standard" mail protocol raises the possibility that certain parties will not be able to participate fully on the internet for legal reasons. There is no precedent for such an ugly situation, and I am strongly opposed to creating it now. It doesn't matter what the terms are or how open or simple they are. Licensing terms should NOT exist for an IETF "standard" protocol. Implementors are not lawyers, and generally have better things to do with their time. S. Optional bootnote: A similar argument applies to the use of well-known licenses for software. I believe that a large part of the reason for the success of the GPL, BSD or Apache licenses is that the rights of the user and developer are particularly well understood in those cases. It's frequently simpler to pick a GPL'd package than to understand the license of a (possibly better) package under a custom license. The same applies here: we should be applying a standard and well understood set of terms to any proposed protocol, and the "standard and well understood" set of terms is "You can do what you like with it, and are beholden unto nobody." Anything else is an obstacle and will cause division. -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 13:54:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01698 for ; Wed, 14 Jul 2004 13:54:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHir53038832; Wed, 14 Jul 2004 10:44:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EHir6u038831; Wed, 14 Jul 2004 10:44:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHiqlB038792 for ; Wed, 14 Jul 2004 10:44:52 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i6EHig57004721; Wed, 14 Jul 2004 10:44:42 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i6EHidBl029056; Wed, 14 Jul 2004 10:44:40 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Wed, 14 Jul 2004 10:44:40 -0700 To: Shevek , IETF MARID WG From: Ted Hardie Subject: Re: Obstacles between us and the finish line Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 5:43 PM +0100 7/14/04, Shevek wrote: >On Thu, 1 Jul 2004, wayne wrote: > >> 4) Proposals must have IP licensing terms that allow for use in both >> commercial and GPLed MTAs. > >The requirement to even THINK about licensing terms when one is >implementing a "standard" internet protocol is almost unimaginable. > >. I believe that a large part of the reason for the >success of the GPL, BSD or Apache licenses is that the rights of the user >and developer are particularly well understood in those cases. It's >frequently simpler to pick a GPL'd package than to understand the license >of a (possibly better) package under a custom license. The GPL, BSD, and Apache licenses are just as much licenses with terms to be followed as are commercial licenses with RAND, royalty-free, or reciprocal terms. Asserting that a working group should not THINK about licensing and then recommending particular licenses is a contradiction. More importantly, this general topic is not salient for this list. The IPR mailing list exists for discussion of the IETF's IPR policy, and general discussion belongs there. Please see the archives before posting, however, as the topics raised here have been discussed before. The group can discuss specific IPR issues with proposals before the working group, but please note that while the IPR forms request that a new IPR statement be filed for each document, it is widely understood that successor documents are covered by the statement relating to the original version. Getting a new one in for each version is busywork, and this working group has no time for such busywork. Getting a final copy in before the documents become RFCs can be handled at the appropriate time, and I am recommend to the working group that they let the chairs follow up with the editors and those who have filed early statements at that time. For those of you not familiar with the IETF's IPR declaration site, it is at http://www.ietf.org/ipr.html. The caller-id original is covered in this document: http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt with the following licensing declaration: b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers ** Check here if this commitment to license is limited solely to standards-track RFCs ___ I urge the working group to stop fixating on this and go back to reviewing and contributing to the specifications. This list is intended to focus on the engineering needed to get its charter done, and we have enough distractions without raising this spectre from its well-deserved grave. regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 14:05:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02293 for ; Wed, 14 Jul 2004 14:04:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHwCbQ041134; Wed, 14 Jul 2004 10:58:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EHwCs2041133; Wed, 14 Jul 2004 10:58:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6EHwBjc041116 for ; Wed, 14 Jul 2004 10:58:11 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 14 Jul 2004 14:02:06 -0400 Received: from ([65.10.105.236]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 3638773500; Wed, 14 Jul 2004 14:02:04 -0400 Message-ID: <00a901c469cc$3591f7e0$6401a8c0@hdev1> From: "Hector Santos" To: "Shevek" , "IETF MARID WG" References: Subject: Re: Obstacles between us and the finish line Date: Wed, 14 Jul 2004 13:53:52 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I second your concerns. This is completely disturbing. Not only do I think the proposals are faulty, will incur a high degree of compatibility issues, will translates to a high revamping and resign cost, I now have to worry about fighting what would be prior art issues anyway? No, there is got to be a better answer to all this. This is fast becoming a "MICROSOFT" only solution and Bill Gates recent quote saying using security as a "Strategic Competitive Advantage" might come back to bite him in the anti-trust area. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Shevek" To: "IETF MARID WG" Sent: Wednesday, July 14, 2004 12:43 PM Subject: Re: Obstacles between us and the finish line > > On Thu, 1 Jul 2004, wayne wrote: > > > 4) Proposals must have IP licensing terms that allow for use in both > > commercial and GPLed MTAs. > > The requirement to even THINK about licensing terms when one is > implementing a "standard" internet protocol is almost unimaginable. The > IETF is supposed to promote interoperability without precondition. The > introduction of any form of license in order to use a "standard" mail > protocol raises the possibility that certain parties will not be able to > participate fully on the internet for legal reasons. > > There is no precedent for such an ugly situation, and I am strongly > opposed to creating it now. > > It doesn't matter what the terms are or how open or simple they are. > Licensing terms should NOT exist for an IETF "standard" protocol. > Implementors are not lawyers, and generally have better things to do with > their time. > > S. > > Optional bootnote: A similar argument applies to the use of well-known > licenses for software. I believe that a large part of the reason for the > success of the GPL, BSD or Apache licenses is that the rights of the user > and developer are particularly well understood in those cases. It's > frequently simpler to pick a GPL'd package than to understand the license > of a (possibly better) package under a custom license. > > The same applies here: we should be applying a standard and well > understood set of terms to any proposed protocol, and the "standard and > well understood" set of terms is "You can do what you like with it, and > are beholden unto nobody." > > Anything else is an obstacle and will cause division. > > -- > Shevek http://www.anarres.org/ > I am the Borg. http://www.gothnicity.org/ > > From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 14:55:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06323 for ; Wed, 14 Jul 2004 14:55:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIhA8k050110; Wed, 14 Jul 2004 11:43:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIhA7H050109; Wed, 14 Jul 2004 11:43:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from kanga.astray.com (kanga.astray.com [195.82.114.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIh9c5050101 for ; Wed, 14 Jul 2004 11:43:10 -0700 (PDT) (envelope-from shevek@astray.com) Received: from shevek (helo=localhost) by kanga.astray.com with local-esmtp (Exim 4.12) id 1Bkoil-0001ZA-00 for ietf-mxcomp@imc.org; Wed, 14 Jul 2004 19:43:11 +0100 Date: Wed, 14 Jul 2004 19:43:11 +0100 (BST) From: Shevek X-X-Sender: shevek@astray.com To: IETF MARID WG Subject: Re: Obstacles between us and the finish line In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 14 Jul 2004, Ted Hardie wrote: > At 5:43 PM +0100 7/14/04, Shevek wrote: > >On Thu, 1 Jul 2004, wayne wrote: > > > >> 4) Proposals must have IP licensing terms that allow for use in both > >> commercial and GPLed MTAs. > > > >The requirement to even THINK about licensing terms when one is > >implementing a "standard" internet protocol is almost unimaginable. > > The GPL, BSD, and Apache licenses are just as much licenses > with terms to be followed as are commercial licenses with > RAND, royalty-free, or reciprocal terms. Asserting that > a working group should not THINK about licensing and then > recommending particular licenses is a contradiction. I am sorry that you did not actually read my original mail. I will rephrase the salient parts of it in the hope of better luck this time. I request that any protocol standardised by the IETF be entirely free of license restrictions in order that implementors clearly understand their right to implement the protocol. I specifically oppose the adoption of SenderID as a standard since it imposes licensing terms on the user. > More importantly, this general topic is not salient for this list. This is not a general topic. This is a specific opposition to SenderID. SenderID has licensing terms which an implementor must spend time reading and understanding before implementing, distributing or otherwise sneezing on SenderID or implementations thereof. If the implementors do not clearly understand their rights, RAND or otherwise, then they are unlikely to implement, or implementation will be divided. We only have to look at the three-dozen competing CDMA specifications for an example of this. At no point did I suggest an alternative license, and I do not do so now. I propose and recommend the absence of any license or restriction whatsoever on any eventual protocol. S. -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 15:16:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08542 for ; Wed, 14 Jul 2004 15:16:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJ3tuA053300; Wed, 14 Jul 2004 12:03:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJ3tRf053299; Wed, 14 Jul 2004 12:03:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJ3t0p053293 for ; Wed, 14 Jul 2004 12:03:55 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 14 Jul 2004 12:03:46 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 14 Jul 2004 12:03:58 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jul 2004 12:03:45 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 12:03:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Obstacles between us and the finish line Date: Wed, 14 Jul 2004 12:04:07 -0700 Message-ID: Thread-Topic: Obstacles between us and the finish line thread-index: AcRpzMyO6+IctLAuROuycVvscHSoWwABE7kw From: "Harry Katz" To: "Hector Santos" , "Shevek" , "IETF MARID WG" X-OriginalArrivalTime: 14 Jul 2004 19:03:57.0029 (UTC) FILETIME=[505AB950:01C469D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6EJ3t0p053294 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, July 14, 2004 10:54 AM, Hector Santos wrote: > I second your concerns. This is completely disturbing. Not > only do I think the proposals are faulty, will incur a high > degree of compatibility issues, will translates to a high > revamping and resign cost, I now have to worry about > fighting what would be prior art issues anyway? > > No, there is got to be a better answer to all this. This is > fast becoming a "MICROSOFT" only solution and Bill Gates > recent quote saying using security as a "Strategic > Competitive Advantage" might come back to bite him in the > anti-trust area. > First, please read Ted Hardie's posting about our IP filing with respect to the original Caller ID specification from which Sender ID is derived. Second, to suggest that this is becoming a Microsoft only solution is outrageous, abusrd and without any basis in fact! In reality we have been working in good faith within this group to arrive at an Internet standard that the whole industry can support with the objective of addressing a problem that we are all concerned about. The current drafts, and the revisions we are now working on following last week's design review, are dramatically different from our original Caller ID proposal -- a fact that reflects our willingness to compromise with others in order to arrive at a common solution. If you cannot restrain yourself from gratuitous Microsoft-bashing, I strongly suggest that you A) Do it somewhere else so you won't be disturbing people who are trying to accomnplish meaningful work, and B) Get your facts right. From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 15:26:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09625 for ; Wed, 14 Jul 2004 15:26:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJA6RO054208; Wed, 14 Jul 2004 12:10:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJA67m054207; Wed, 14 Jul 2004 12:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJA6Ar054176 for ; Wed, 14 Jul 2004 12:10:06 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 475E741497; Wed, 14 Jul 2004 12:10:01 -0700 (PDT) Subject: Re: Submitter shown the DOR From: Douglas Otis To: Tony Finch Cc: MARID In-Reply-To: References: <1089767342.15308.577.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1089832200.16131.261.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 14 Jul 2004 12:10:00 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-07-14 at 02:53, Tony Finch wrote: > On Tue, 13 Jul 2004, Douglas Otis wrote: > > > > Example of a Domain of Responsibility Tag: > > > > C: MAIL FROM: > > DOR:t:"ddddd.dddddd";x:"ddddd";a:"ttttt"; > > s:"tttttttt"; > > b:"tttttttttttttttttttttttttttttttttttt"; > > d:"alumni.almamater.edu"; > > > > (a:algorithm, > > t:time-stamp, > > x:expiry, > > b:base64 signature, > > s:selector, > > d:domain) > > Why not just get the originator's MSA to sign the original return path? > This gives end-to-end authentication of the MSA, does not require any > change to aliasing/forwarding systems or to SMTP, and works well with > callback verification. > > Dave Crocker's BTAV draft is a start at a specification. http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html You are right, this could be used in the same manner as the BATV draft presented at the interim meeting, if done at the entry point into the channel, where the MUA has been authenticated by the SMTP server. This also has the advantage of being recognizable by the recipient of the mail, prior to bouncing if detecting fraudulent mail and discarding it, without slogging through the dozen or so DNS text records to decide whether the message is a member of a set. DOR (of access) works without changing the way mail works nor does it require channel checks. :^) I suggested down stream to use the SPF algorithm. On considering the advantages, it would be better to do this as Dave Crocker had structured it. I doubt DNS can scale to allow the SPF algorithm to be "closed" as needed to abate spam and fraud. With the submitter mailbox being assigned by the MUA, as done with the Submitter proposal, this simply allows fraud to continue unabated with publicly published records allowing points of access for fraud. It also allows deny-ability, as anyone could become victim of fraud, both the recipient of the mail as well as the records used to allow the fraudulent mail to be delivered, because of Sender-ID allowably broad definitions. With the DOR scheme, the bounce could be avoided where it saves bandwidth as well as preventing fraud from otherwise reputable domains. There would also be a verifiable domain to handle abuse where this domain is able to associate the local account with the abusive mail. This is much more information than that obtainable from Sender-ID which leaves the authenticating domain indeterminate. Sender-ID would leave open the question as to how any abuse is to be abated or how rules are to be enforced. Sender-ID does not permit accrediting abuse from an open list or a broadly defined region of address space. Because Sender-ID can be so broadly defined, enforcement would be virtually impossible. The DOR tag can close the door or else a bad accreditation results. :^) -Doug -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 15:53:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12260 for ; Wed, 14 Jul 2004 15:53:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJhwCI060006; Wed, 14 Jul 2004 12:43:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJhwvX060005; Wed, 14 Jul 2004 12:43:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJhwho059999 for ; Wed, 14 Jul 2004 12:43:58 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 14 Jul 2004 12:43:50 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 14 Jul 2004 12:44:02 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jul 2004 12:44:00 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 12:44:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: where are the new drafts for SenderID? time is running out. Date: Wed, 14 Jul 2004 12:44:17 -0700 Message-ID: Thread-Topic: where are the new drafts for SenderID? time is running out. thread-index: AcRpwKXvXev0DD2eSFKfgRN8qdorOgAGcxxw From: "Harry Katz" To: "IETF MARID WG" X-OriginalArrivalTime: 14 Jul 2004 19:44:00.0043 (UTC) FILETIME=[E8A98FB0:01C469DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6EJhwho060000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, July 14, 2004 9:20 AM, wayne wrote: > Where are the new drafts for SenderID that were developed at > last Friday's design-team meeting? It is my understanding > that many changes have been made. > > The deadline for revisions is next monday. Even if these > revised documents were released today, that would only leave > a few days for this working group to study the changes, make > recommendations, and let the authors get another round of > revisions through. > > Ok, it the new marid-protocal I-D is out, but what about the > critical and heavily changed marid-core document? Will it > include the required > RFC3668 text about IPR? What changes have been made to the > marid-submitter I-D? > These are in progress. We have committed to submitting these to the IETF drafts editor by Monday's deadline. Unfortunately we will not have time for a subsequent round of revisions before then. From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 16:05:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13265 for ; Wed, 14 Jul 2004 16:05:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJkbK0060480; Wed, 14 Jul 2004 12:46:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJkbYg060479; Wed, 14 Jul 2004 12:46:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJkbaR060471 for ; Wed, 14 Jul 2004 12:46:37 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 14 Jul 2004 15:46:39 -0400 id 000DF94F.40F58D9F.000044C1 In-Reply-To: <00a901c469cc$3591f7e0$6401a8c0@hdev1> References: <00a901c469cc$3591f7e0$6401a8c0@hdev1> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8442BC56-D5CE-11D8-B298-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: Obstacles between us and the finish line Date: Wed, 14 Jul 2004 15:46:36 -0400 To: "Hector Santos" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 14, 2004, at 1:53 PM, Hector Santos wrote: > No, there is got to be a better answer to all this. This is fast > becoming a > "MICROSOFT" only solution and Bill Gates recent quote saying using > security > as a "Strategic Competitive Advantage" might come back to bite him in > the > anti-trust area. I specifically stated earlier that discussion of hidden agendas and similar topics is forbidden. This statement does not constitute constructive technical discussion nor administrative discussion within the bounds of the working group's chartered scope. This is your first and last warning. -andy From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 17:57:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26977 for ; Wed, 14 Jul 2004 17:57:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ELfgK9080467; Wed, 14 Jul 2004 14:41:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6ELfgTN080466; Wed, 14 Jul 2004 14:41:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from server.moongroup.com (server.moongroup.com [24.172.57.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ELffxb080450 for ; Wed, 14 Jul 2004 14:41:41 -0700 (PDT) (envelope-from csm@moongroup.com) Received: from [198.18.6.255] ([12.4.216.138]) (authenticated bits=0) by server.moongroup.com (8.12.11/8.12.11) with ESMTP id i6F1N3ar010410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jul 2004 21:23:04 -0400 Message-ID: <40F5A896.3080706@moongroup.com> Date: Wed, 14 Jul 2004 17:41:42 -0400 From: Chuck Mead User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: Obstacles between us and the finish line References: In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bitten by the Reply-to! I sent this directly to Harry instead of the list which was my intent. Harry Katz wrote: | On Wednesday, July 14, 2004 10:54 AM, Hector Santos wrote: | | |>I second your concerns. This is completely disturbing. Not |>only do I think the proposals are faulty, will incur a high |>degree of compatibility issues, will translates to a high |>revamping and resign cost, I now have to worry about |>fighting what would be prior art issues anyway? |> |>No, there is got to be a better answer to all this. This is |>fast becoming a "MICROSOFT" only solution and Bill Gates |>recent quote saying using security as a "Strategic |>Competitive Advantage" might come back to bite him in the |>anti-trust area. |> | | | First, please read Ted Hardie's posting about our IP filing with respect | to the original Caller ID specification from which Sender ID is derived. Sender ID is derived only from Caller-ID? Gee... there's a concept... Where did SPF come from then? | Second, to suggest that this is becoming a Microsoft only solution is | outrageous, abusrd and without any basis in fact! For my part I don't claim that... I worry about it but I'm not making the claim. The issue we've been talking about though is that the Caller-ID spec and it's attendant RAND license is being mis-applied to what is, essentially, SPF Classic. THAT is what we're talking about and I don't think any amount of crying that we're wasting *YOUR* time and effort worrying about it is going to shut those of us who care about it as an issue *UP*! | In reality we have been working in good faith within this group to | arrive at an Internet standard that the whole industry can support with | the objective of addressing a problem that we are all concerned about. | The current drafts, and the revisions we are now working on following | last week's design review, are dramatically different from our original | Caller ID proposal -- a fact that reflects our willingness to compromise | with others in order to arrive at a common solution. 'zactly... thus we need to change the point of reference for the license as we are *NOT* talking about Caller-ID anymore. We are talking about SPF as far as I can see and that's not under RAND or anything else so far as licensing is concerned. Is it? I suspect that if someone would simply clarify it we'd likely be satisfied as I strongly believe what we've been discussing is *NOT* Called-ID which, consequently, kicks the CID RAND restriction to the curb doesn't it? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA9aiWv6Gjsf2pQ0oRArCHAJkBeTLWkhjTmnUjshe10fR8OZ73dQCdEjUL VJmu/58rLGvJeunFzZMNIiE= =3nNb -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 18:40:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02993 for ; Wed, 14 Jul 2004 18:40:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EMTEh9088325; Wed, 14 Jul 2004 15:29:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EMTD7Y088324; Wed, 14 Jul 2004 15:29:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EMTDpV088318 for ; Wed, 14 Jul 2004 15:29:13 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i6EMXNgA007809; Wed, 14 Jul 2004 15:33:23 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i6EMXMva007806; Wed, 14 Jul 2004 15:33:22 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 14 Jul 2004 15:33:22 -0700 (PDT) From: "william(at)elan.net" To: Ted Hardie cc: IETF MARID WG Subject: Re: Obstacles between us and the finish line In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 14 Jul 2004, Ted Hardie wrote: > The group can discuss specific IPR issues with proposals before the working > group, but please note that while the IPR forms request that a new IPR > statement be filed for each document, it is widely understood that > successor documents are covered by the statement relating to the original > version. Getting a new one in for each version is busywork, and this > working group has no time for such busywork. Getting a final copy in > before the documents become RFCs can be handled at the appropriate time, > and I am recommend to the working group that they let the chairs follow > up with the editors and those who have filed early statements at that time. While I agree with you in general, I do believe in our case, new IPR statement is appropriate. My undersnding is that before Microsoft claimed IPR rights because of use of XML in DNS TXT records (or was it in dns in general? I asked that question and was promised detailed answer during MARID jabber session, but never got it, eventhough Microsoft people present were directed to work on it). We're no longer considering use of XML in DNS and will use original SPF syntax, so my understanding based on previously expressed IPR claims that none should apply to now. Perhaps I do not understand correctly and Microsoft had other IPR claims that dod not concern XML, in that case, Microsoft should explain more clearly and tell exactly what these IPR claims cover and that is why new statement seems appropriate. > For those of you not familiar with the IETF's IPR declaration site, it > is at http://www.ietf.org/ipr.html. The caller-id original > is covered in this document: > > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt I note that the section V(C) which from that document is which is supposed to explain which parts of internet draft are covered by IPR is not filled out by Microsoft nor was there patent# provided under section V(A). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Jul 14 18:43:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03544 for ; Wed, 14 Jul 2004 18:43:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EMXM9A088835; Wed, 14 Jul 2004 15:33:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EMXMdD088834; Wed, 14 Jul 2004 15:33:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EMXMbR088827 for ; Wed, 14 Jul 2004 15:33:22 -0700 (PDT) (envelope-from jutta@sendmail.com) Received: from jutta.sendmail.com ([10.210.202.25]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i6EMXRlp003306 for ; Wed, 14 Jul 2004 15:33:27 -0700 Received: by jutta.sendmail.com (Postfix, from userid 500) id D974E1799D; Wed, 14 Jul 2004 15:32:07 -0700 (PDT) Date: Wed, 14 Jul 2004 15:32:07 -0700 From: Jutta Degener To: ietf-mxcomp@imc.org Subject: draft-ietf-marid-protocol-00.txt Message-ID: <20040714223207.GE1498@jutta.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.24i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The recent draft-ietf-marid-protocol-00.txt cites this mailing list as one of two addresses for discussion of the draft. I've got some technical quibbles with that draft's grammar. Sorry if they've been brought up before; I'm new to this set of documents. From the ABNF: : unknown-mechanism = name [ ":" macro-string ] *[ "/" *DIGIT ] What's the parse tree for foo:pi/2 ? The "/2" can be parsed either as part of the "macro-string" or as part of the [/*DIGIT] suffix. "/" and digits are valid VCHARs, and a macro-string can contain VCHARs. Well, this is an unknown-mechanism, so we don't really care; but the grammars for known mechanisms suffer from the same problem. : A = "a" [ ":" domain-spec ] [ dual-cidr-length ] The domain-spec can expand to macro-string, and a macro-string can end in anything %x21-7F, including "/2". This doesn't yield a definitive parse. The default way of resolving such conflicts would parse greedily and pack as much as possible into the macro-string--which would lead to nothing to ever being interpreted as a cidr-length. .. The definition of macro-string itself doesn't make clear that "%" must not be interpreted as a VCHAR, but as part of a "macro-char" sequence. : macro-string = *( macro-char / VCHAR ) : macro-char = ( "%{" ALPHA transformer *delimiter "}" ) / "%%" / "%_" / "%-" VCHAR also contains %. But at least here, parsing greedily has the desired result. .. As mentioned in the context of A, the definition of domain-spec competes with a more generic definition: : domain-spec = domain-name / macro-string Since domain-names are subsets of macro-strings, this says exactly the same as domain-spec = macro-string Maybe what you mean to express is "evaluate the macro string, and the result must fit this grammar" -- but that's not what the ABNF actually means. (*Do* you mean that? That would mean that the string must not evaluate to domain names containing "_", such as names starting with _spf.) .. : domain-part = as defined in [RFC 1034] Authors can make it easier for developers by giving them the specific token name to search for. (RFC 1034 doesn't define the token "domain-part".) I'm guessing this is referring to a
 
------_=_NextPart_001_01C46DD7.9B7C7B17-- From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 17:43:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13138 for ; Mon, 19 Jul 2004 17:43:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLWDMI045917; Mon, 19 Jul 2004 14:32:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JLWDgh045916; Mon, 19 Jul 2004 14:32:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLWCbG045898 for ; Mon, 19 Jul 2004 14:32:12 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 1469B40DD for ; Mon, 19 Jul 2004 14:32:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> Content-Type: multipart/mixed; boundary=Apple-Mail-10-296393120 Message-Id: <1EE98B0E-D9CB-11D8-896F-000393A56BB6@glyphic.com> From: Mark Lentczner Subject: PRA Algorithm Stats Date: Mon, 19 Jul 2004 14:32:22 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-10-296393120 Content-Type: multipart/alternative; boundary=Apple-Mail-11-296393120 --Apple-Mail-11-296393120 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Thanks, Andy for your stats. I've been running my own this weekend, and I came up with slightly different results. I started with four data sets: my inbox from 2003 (~1500 messages), my last three days of spam (~500 messages), and two from Chuck Mead (ham @ ~1000 messages and spam @ ~4000 messages). I took messages, computed the PRA and compared it's domain to the domain of the envelope from. If they were the same, I did no more checks, since they would use the same record and have the same results (barring records that make distinctions based on localparts.) The percentage where they differ is: ham1 17% ham2 16% spam1 8% spam2 9% I then ran the SPF record check against the PRA and env. MAIL FROM identities on these messages. I considered both only messages where the SPF records were published, and all cases using guesses for the SPF records when missing. Here is the percentage of time a guess was used: PRA FROM ham1 82% 92% ham2 72% 75% spam1 67% 94% spam2 78% 89% Unlike Andy, the query results differed some percentage of the time: ham1 66% ham2 27% spam1 43% spam2 31% Lastly, like Andy, I looked at the Pass and Fail percentages (for both only published and published + guessed records): Ham1 Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 11 ( 24%) 81 ( 31%) env. from Pass: 18 (100%) 241 ( 94%) PRA Fail: 0 ( 0%) 0 ( 0%) env. from Fail: 0 ( 0%) 0 ( 0%) Ham2 Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 14 ( 53%) 62 ( 64%) env. from Pass: 16 ( 66%) 72 ( 75%) PRA Fail: 7 ( 26%) 7 ( 7%) env. from Fail: 0 ( 0%) 0 ( 0%) Spam1 Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 2 ( 16%) 6 ( 16%) env. from Pass: 0 ( 0%) 10 ( 27%) PRA Fail: 5 ( 41%) 5 ( 13%) env. from Fail: 2 (100%) 2 ( 5%) Spam2 Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 40 ( 44%) 94 ( 22%) env. from Pass: 0 ( 0%) 97 ( 23%) PRA Fail: 22 ( 24%) 22 ( 5%) env. from Fail: 13 ( 29%) 13 ( 3%) While the numbers are low, and I'd be first to worry about generalizing from these stats, I can begin to see a trend: 1) Over 80% of mail is not complicated and the PRA produces the same domain as env. from. Oddly enough, even more so for spam. (I suppose spammers just haven't caught on.) 2) While still only a small percentage of sites have records, more sites identified by PRA had records than env. from. This could be because the PRA is more often a bigger site. 3) When the domains differ, the check result from PRA vs. env. from is often different. This is the only stat. that is at odds with Andy's findings. 4) For ham, env. from produces a greater percentage of passes than PRA. It also produces few fails, but the numbers here are very low. For ham, more passes and fewer fails is good. 5) For spam, the numbers seem less conclusive, but PRA seems to produce more definite results (passes and fails) than env. from. I've attached the detailed output of my script runs for anyone that wants to plunge in deeper... - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com --Apple-Mail-11-296393120 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Thanks, Andy for your stats. I've been running my own this weekend, and I came up with slightly different results. I started with four data sets: my inbox from 2003 (~1500 messages), my last three days of spam (~500 messages), and two from Chuck Mead (ham @ ~1000 messages and spam @ ~4000 messages). I took messages, computed the PRA and compared it's domain to the domain of the envelope from. If they were the same, I did no more checks, since they would use the same record and have the same results (barring records that make distinctions based on localparts.) The percentage where they differ is: Courier ham1 17% ham2 16% spam1 8% spam2 9% I then ran the SPF record check against the PRA and env. MAIL FROM identities on these messages. I considered both only messages where the SPF records were published, and all cases using guesses for the SPF records when missing. Here is the percentage of time a guess was used: Courier PRA FROM ham1 82% 92% ham2 72% 75% spam1 67% 94% spam2 78% 89% Unlike Andy, the query results differed some percentage of the time: Courier ham1 66% ham2 27% spam1 43% spam2 31% Lastly, like Andy, I looked at the Pass and Fail percentages (for both only published and published + guessed records): CourierHam1 Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 11 ( 24%) 81 ( 31%) env. from Pass: 18 (100%) 241 ( 94%) PRA Fail: 0 ( 0%) 0 ( 0%) env. from Fail: 0 ( 0%) 0 ( 0%) Ham2 Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 14 ( 53%) 62 ( 64%) env. from Pass: 16 ( 66%) 72 ( 75%) PRA Fail: 7 ( 26%) 7 ( 7%) env. from Fail: 0 ( 0%) 0 ( 0%) Spam1 Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 2 ( 16%) 6 ( 16%) env. from Pass: 0 ( 0%) 10 ( 27%) PRA Fail: 5 ( 41%) 5 ( 13%) env. from Fail: 2 (100%) 2 ( 5%) Spam2 Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 40 ( 44%) 94 ( 22%) env. from Pass: 0 ( 0%) 97 ( 23%) PRA Fail: 22 ( 24%) 22 ( 5%) env. from Fail: 13 ( 29%) 13 ( 3%) While the numbers are low, and I'd be first to worry about generalizing from these stats, I can begin to see a trend: 1) Over 80% of mail is not complicated and the PRA produces the same domain as env. from. Oddly enough, even more so for spam. (I suppose spammers just haven't caught on.) 2) While still only a small percentage of sites have records, more sites identified by PRA had records than env. from. This could be because the PRA is more often a bigger site. 3) When the domains differ, the check result from PRA vs. env. from is often different. This is the only stat. that is at odds with Andy's findings. 4) For ham, env. from produces a greater percentage of passes than PRA. It also produces few fails, but the numbers here are very low. For ham, more passes and fewer fails is good. 5) For spam, the numbers seem less conclusive, but PRA seems to produce more definite results (passes and fails) than env. from. I've attached the detailed output of my script runs for anyone that wants to plunge in deeper... - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com --Apple-Mail-11-296393120-- --Apple-Mail-10-296393120 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="all-results2" Content-Disposition: attachment; filename=all-results2 Content-Transfer-Encoding: 7bit :::::::::::::::::::::: ::: Data set Ham 1 ::: :::::::::::::::::::::: messages: 1506 (100%) pra and env. from differ: 261 ( 17%) pra steps used: step3-sender 90 ( 5%) step4-from 1416 ( 94%) queries made: 261 (100%) pra and env. from differ: 173 ( 66%) Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 11 ( 24%) 81 ( 31%) env. from Pass: 18 (100%) 241 ( 94%) PRA Fail: 0 ( 0%) 0 ( 0%) env. from Fail: 0 ( 0%) 0 ( 0%) PRA Query Stats: published SPF guessed SPF ---------------- --------------- --------------- pass 11 ( 24%) 70 ( 33%) fail 0 ( 0%) 0 ( 0%) softfail 0 ( 0%) 0 ( 0%) neutral 34 ( 75%) 139 ( 65%) unknown 0 ( 0%) 0 ( 0%) error 0 ( 0%) 2 ( 0%) -------- --------------- --------------- total 45 ( 17%) 211 ( 82%) Env. From Query Stats: published SPF guessed SPF ----------------------- --------------- --------------- pass 18 (100%) 223 ( 93%) fail 0 ( 0%) 0 ( 0%) softfail 0 ( 0%) 0 ( 0%) neutral 0 ( 0%) 13 ( 5%) unknown 0 ( 0%) 0 ( 0%) error 0 ( 0%) 2 ( 0%) -------- --------------- --------------- total 18 ( 7%) 238 ( 92%) :::::::::::::::::::::: ::: Data set Ham 2 ::: :::::::::::::::::::::: messages: 1023 (100%) pra and env. from differ: 169 ( 16%) pra steps used: step2-resent-from 5 ( 0%) step3-sender 88 ( 8%) step4-from 928 ( 90%) step4-from-malformed 1 ( 0%) step6-no-valid 1 ( 0%) queries made: 169 (100%) pra and env. from differ: 46 ( 27%) Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 14 ( 53%) 62 ( 64%) env. from Pass: 16 ( 66%) 72 ( 75%) PRA Fail: 7 ( 26%) 7 ( 7%) env. from Fail: 0 ( 0%) 0 ( 0%) PRA Query Stats: published SPF guessed SPF ---------------- --------------- --------------- pass 14 ( 53%) 48 ( 68%) fail 7 ( 26%) 0 ( 0%) softfail 0 ( 0%) 0 ( 0%) neutral 3 ( 11%) 20 ( 28%) unknown 2 ( 7%) 0 ( 0%) error 0 ( 0%) 2 ( 2%) -------- --------------- --------------- total 26 ( 27%) 70 ( 72%) Env. From Query Stats: published SPF guessed SPF ----------------------- --------------- --------------- pass 16 ( 66%) 56 ( 77%) fail 0 ( 0%) 0 ( 0%) softfail 0 ( 0%) 0 ( 0%) neutral 1 ( 4%) 14 ( 19%) unknown 7 ( 29%) 0 ( 0%) error 0 ( 0%) 2 ( 2%) -------- --------------- --------------- total 24 ( 25%) 72 ( 75%) ::::::::::::::::::::::: ::: Data set Spam 1 ::: ::::::::::::::::::::::: messages: 460 (100%) pra and env. from differ: 37 ( 8%) pra steps used: step3-sender 7 ( 1%) step4-from 453 ( 98%) queries made: 37 (100%) pra and env. from differ: 16 ( 43%) Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 2 ( 16%) 6 ( 16%) env. from Pass: 0 ( 0%) 10 ( 27%) PRA Fail: 5 ( 41%) 5 ( 13%) env. from Fail: 2 (100%) 2 ( 5%) PRA Query Stats: published SPF guessed SPF ---------------- --------------- --------------- pass 2 ( 16%) 4 ( 16%) fail 4 ( 33%) 0 ( 0%) softfail 1 ( 8%) 0 ( 0%) neutral 2 ( 16%) 16 ( 64%) unknown 3 ( 25%) 0 ( 0%) error 0 ( 0%) 5 ( 20%) -------- --------------- --------------- total 12 ( 32%) 25 ( 67%) Env. From Query Stats: published SPF guessed SPF ----------------------- --------------- --------------- pass 0 ( 0%) 10 ( 28%) fail 0 ( 0%) 0 ( 0%) softfail 2 (100%) 0 ( 0%) neutral 0 ( 0%) 21 ( 60%) unknown 0 ( 0%) 0 ( 0%) error 0 ( 0%) 4 ( 11%) -------- --------------- --------------- total 2 ( 5%) 35 ( 94%) ::::::::::::::::::::::: ::: Data set Spam 2 ::: ::::::::::::::::::::::: messages: 4222 (100%) pra and env. from differ: 421 ( 9%) pra steps used: step2-resent-from 3 ( 0%) step3-sender 295 ( 6%) step4-from 3917 ( 92%) step4-from-malformed 4 ( 0%) step6-no-valid 3 ( 0%) queries made: 421 (100%) pra and env. from differ: 133 ( 31%) Summary: published SPF + guessed SPF ----------------------- --------------- --------------- PRA Pass: 40 ( 44%) 94 ( 22%) env. from Pass: 0 ( 0%) 97 ( 23%) PRA Fail: 22 ( 24%) 22 ( 5%) env. from Fail: 13 ( 29%) 13 ( 3%) PRA Query Stats: published SPF guessed SPF ---------------- --------------- --------------- pass 40 ( 44%) 54 ( 16%) fail 21 ( 23%) 0 ( 0%) softfail 1 ( 1%) 0 ( 0%) neutral 13 ( 14%) 249 ( 75%) unknown 15 ( 16%) 0 ( 0%) error 0 ( 0%) 28 ( 8%) -------- --------------- --------------- total 90 ( 21%) 331 ( 78%) Env. From Query Stats: published SPF guessed SPF ----------------------- --------------- --------------- pass 0 ( 0%) 97 ( 25%) fail 11 ( 25%) 0 ( 0%) softfail 2 ( 4%) 0 ( 0%) neutral 18 ( 40%) 254 ( 67%) unknown 13 ( 29%) 0 ( 0%) error 0 ( 0%) 26 ( 6%) -------- --------------- --------------- total 44 ( 10%) 377 ( 89%) --Apple-Mail-10-296393120-- From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 17:48:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14205 for ; Mon, 19 Jul 2004 17:48:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLeIk4048043; Mon, 19 Jul 2004 14:40:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JLeIMX048042; Mon, 19 Jul 2004 14:40:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLeIBj048015 for ; Mon, 19 Jul 2004 14:40:18 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 56BD240DD for ; Mon, 19 Jul 2004 14:40:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <41E771B0-D9CC-11D8-896F-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: PRA algorithm and use of non-standard header fields Date: Mon, 19 Jul 2004 14:40:30 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andy wrote: > 1) The six-steps really ought to be put into pseudo-code with each > step spelled out in a separate routine. I found that the textual > descriptions were a little confusing. If need be, I can contribute my > Python code. My stats also collected how often each step was used in yielding the result. Out of over 7,000 messages, only 8 ever used step 2 (Resent-From:) and none used step 1 (Resent-Sender:). Perhaps these aren't important and only complicate the issue. Without them, the "Sender if it is there, otherwise From" logic is just the 2822 definition of who the injector is. > 2) Many of the steps talk about a "non-Empty" header. Isn't this > requirement also fulfilled by step 5, therefore making this > requirement in the subsequent steps redundant? I agree, though my implementation followed the text to the letter - (some of them didn't say non-empty, and I distinguished these cases.) I doubt it, not one header in my 7,000 messages was empty. > 3) It may be necessary to modify the check of the "Sender" header > because many systems do not attach a domain name to a mailbox address > if the injection and delivery are on the same box. Or perhaps this > should go into an applicability statement section 7 regarding checking > of email local to the system. In my analysis I immediately discarded all local messages, so I can't comment. But this does bring up the question about what constitutes "malformed". While 2822's intentions are pretty strict, it does seem to allow for the realities of decades of older mail with not-so-strict header formatting. I'm not sure where to go on this, but I do realize that we only expect the PRA to be computed over newly created messages, that should, by now, conform to the stricter intentions of 2822. - Mark From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 18:01:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17133 for ; Mon, 19 Jul 2004 18:01:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLq9T0050287; Mon, 19 Jul 2004 14:52:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JLq9jB050286; Mon, 19 Jul 2004 14:52:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6JLq8Ec050280 for ; Mon, 19 Jul 2004 14:52:08 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 18269 invoked from network); 19 Jul 2004 21:53:38 -0000 Received: from unknown (HELO ?192.168.254.158?) (208.198.98.2) by ns1.hoster907.com with SMTP; 19 Jul 2004 21:53:38 -0000 In-Reply-To: <1209038868.20040719135944@brandenburg.com> References: <70DDD67E-D9BB-11D8-BD4A-000A95B3BA44@hxr.us> <7A8B6FC8-D9BF-11D8-AE38-000A95BC6A7E@margaretolson.com> <1209038868.20040719135944@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Andrew Newton , IETF MARID WG From: Margaret Olson Subject: Re: Schedule for Sender-ID Date: Mon, 19 Jul 2004 17:52:10 -0400 To: Dave Crocker X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 19, 2004, at 4:59 PM, Dave Crocker wrote: > > I strongly urge Marid to get some senior IETF review of the sender-id > stuff from security and operations geeks. One source candidate > reviewers is at . > What is the process for selecting a reviewer? The WG chairs? The proposal authors? I guess I have an opinion (being familiar with the work for about half the people on that list), but I'm not convinced that my opinion matters or that a group discussion is the best way to proceed. Margaret. From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 18:05:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17961 for ; Mon, 19 Jul 2004 18:05:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLv7ji050998; Mon, 19 Jul 2004 14:57:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JLv752050997; Mon, 19 Jul 2004 14:57:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLv6eO050983 for ; Mon, 19 Jul 2004 14:57:06 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i6JM2CVp024777; Mon, 19 Jul 2004 15:02:12 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i6JM2CNO024774; Mon, 19 Jul 2004 15:02:12 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 19 Jul 2004 15:02:12 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: IETF MARID WG Subject: Re: Schedule for Sender-ID In-Reply-To: <86D478C1-D9C9-11D8-BD4A-000A95B3BA44@hxr.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 19 Jul 2004, Andrew Newton wrote: > Given that the drafts are fresh, I would not be surprised if many > people have not had the chance to read them. Can you have the latest versions posted to WG homepage at ietf. The links are valid there only when these documents are passed through ietf editor process and are oficially posted as drafts, but we need to be able to access them easily even before that time given short timeframe involved. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 18:14:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20029 for ; Mon, 19 Jul 2004 18:14:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JM6ekr052660; Mon, 19 Jul 2004 15:06:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JM6emT052659; Mon, 19 Jul 2004 15:06:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JM6dPc052649 for ; Mon, 19 Jul 2004 15:06:39 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57214) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1BmgHS-0006CA-AK for ietf-mxcomp@imc.org; Mon, 19 Jul 2004 23:06:42 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BmgHR-0001J2-Qc; Mon, 19 Jul 2004 23:06:41 +0100 Date: Mon, 19 Jul 2004 23:06:41 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Lentczner cc: IETF MARID WG Subject: Re: PRA algorithm and use of non-standard header fields In-Reply-To: <41E771B0-D9CC-11D8-896F-000393A56BB6@glyphic.com> Message-ID: References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> <41E771B0-D9CC-11D8-896F-000393A56BB6@glyphic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 19 Jul 2004, Mark Lentczner wrote: > My stats also collected how often each step was used in yielding the result. > Out of over 7,000 messages, only 8 ever used step 2 (Resent-From:) and none > used step 1 (Resent-Sender:). Perhaps these aren't important and only > complicate the issue. Without them, the "Sender if it is there, otherwise > From" logic is just the 2822 definition of who the injector is. No, you have to include the Resent- headers in the algorithm to be properly conformant with RFC 2822 and RFC 822. One of the standard MUAs at our site for over 10 years has been Pine which does roughly the right thing with Resent- headers (it uses 822 rather than 2822 syntax in this respect). It might be a bit rare but it isn't unimportant. > But this does bring up the question about what constitutes "malformed". While > 2822's intentions are pretty strict, it does seem to allow for the realities > of decades of older mail with not-so-strict header formatting. I'm not sure > where to go on this, but I do realize that we only expect the PRA to be > computed over newly created messages, that should, by now, conform to the > stricter intentions of 2822. I recently experimented with header syntax verification as an anti-spam measure, and I found out quite how atrociously bad modern software is at following RFC 2822. Particularly bad examples include the Microsoft MUA which produces headers like To: or bare local parts in Sender: headers, or nothing but a display-name, or the display-name following the angle-addr instead of coming before it, or an unquoted addr-spec before an angle-addr. Utterly hopeless. Tony. -- f.a.n.finch http://dotat.at/ NORTHWEST FITZROY SOLE: SOUTHERLY VEERING WESTERLY 5 OR 6. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 18:34:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24517 for ; Mon, 19 Jul 2004 18:34:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMR1Ec056977; Mon, 19 Jul 2004 15:27:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JMR1JX056976; Mon, 19 Jul 2004 15:27:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMR0vU056970 for ; Mon, 19 Jul 2004 15:27:00 -0700 (PDT) (envelope-from roy+dated+1092868021.a19988@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i6JMR1WE046473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Jul 2004 22:27:02 GMT (envelope-from roy+dated+1092868021.a19988@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i6JMR11i047440 for ; Mon, 19 Jul 2004 23:27:01 +0100 (BST) (envelope-from roy+dated+1092868021.a19988@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i6JMR1do047439 for ietf-mxcomp@imc.org; Mon, 19 Jul 2004 23:27:01 +0100 (BST) (envelope-from roy+dated+1092868021.a19988@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Mon, 19 Jul 2004 23:27:00 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16636.19123.764925.304266@giles.gnomon.org.uk> Date: Mon, 19 Jul 2004 23:26:59 +0100 To: Andrew Newton Cc: Mark Lentczner , "IETF MARID WG" Subject: Re: PRA algorithm and use of non-standard header fields In-Reply-To: <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Andrew" == Andrew Newton writes: Andrew> 2) Many of the steps talk about a "non-Empty" header. Andrew> Isn't this requirement also fulfilled by step 5, therefore Andrew> making this requirement in the subsequent steps redundant? No. Consider an message that contains a valid From header and an empty sender header. Currently, step 3 will ignore the (illegal) empty Sender header, and step 4 will select the From header. If the words "non-empty" were removed, step 3 would select the empty Sender header, and step 5 would then fail to determine a PRA because the header was malformed. Whether this case is important in practice, I don't know. The current PRA algorithm is based on a proposal I made to this WG in response to -core-00. I specifically specified it this way because the Caller ID PRA algorithm considered only non-empty headers, and handling of empty headers wasn't the issue I was concerned about. (My proposal was intended to be a "minimum change" proposal from the original algorithm.) I raised the question a week or so ago as to whether it might be an idea to remove the words "non-empty". There seems no pressing need for them in the PRA algorithm as currently defined. It adds a (small) amount of complexity, and only changes the outcome for ill-formed messages. The cost is small, and if there is a belief that spurious empty headers occur in otherwise well-formed messages in the wild, then I'm all for keeping the wording. But since checking whether the headers are empty is an extra conceptual step, if we retain it, we should at least have some idea as to why we're doing this... -roy From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 18:52:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28281 for ; Mon, 19 Jul 2004 18:52:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMcSa3058872; Mon, 19 Jul 2004 15:38:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JMcScE058871; Mon, 19 Jul 2004 15:38:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts16-srv.bellnexxia.net (tomts16.bellnexxia.net [209.226.175.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMcRUd058857 for ; Mon, 19 Jul 2004 15:38:27 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.206.18]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040719223831.OZPS9492.tomts16-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 19 Jul 2004 18:38:31 -0400 From: "John Glube" To: "'Ted Hardie'" , Subject: RE: Regarding the recent licensing thread Date: Mon, 19 Jul 2004 18:38:30 -0400 Message-ID: <000001c46de1$1d91a550$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6JMcSUd058860 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In the Canadian justice system of which I have some familiarity, upon a Supreme Court Justice making his or her ruling, it is proper for the losing advocate to rise on his hind legs and say "Thank you My Lord or My Lady," as applicable. Accordingly, speaking on my behalf as an individual, who put forward certain concerns relating to the licensing issue, I say "Thank you Mr. Hardie for your guidance." John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 09/07/2004 From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 18:53:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28320 for ; Mon, 19 Jul 2004 18:53:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMhBRT059780; Mon, 19 Jul 2004 15:43:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JMhBE2059779; Mon, 19 Jul 2004 15:43:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMhBTS059772 for ; Mon, 19 Jul 2004 15:43:11 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6JMhFi08690; Mon, 19 Jul 2004 15:43:15 -0700 Date: Mon, 19 Jul 2004 15:43:07 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <198477938.20040719154307@brandenburg.com> To: Margaret Olson CC: Andrew Newton , IETF MARID WG Subject: Re: Schedule for Sender-ID In-Reply-To: References: <70DDD67E-D9BB-11D8-BD4A-000A95B3BA44@hxr.us> <7A8B6FC8-D9BF-11D8-AE38-000A95BC6A7E@margaretolson.com> <1209038868.20040719135944@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Margaret, MO> What is the process for selecting a reviewer? The WG chairs? The MO> proposal authors? I guess I have an opinion (being familiar with the there is not an official answer to that, yet, since SIRS was only an independent experiment. the icar working group is going through a formal specification effort. my own answer is "whatever". as long as someone gets the reviews, that's all that counts. in other words, it's the information in the reviews, rather than the process of getting them, that is important. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 19:21:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03608 for ; Mon, 19 Jul 2004 19:21:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JN5mcH063762; Mon, 19 Jul 2004 16:05:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JN5m0n063761; Mon, 19 Jul 2004 16:05:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JN5lk3063747 for ; Mon, 19 Jul 2004 16:05:47 -0700 (PDT) (envelope-from roy+dated+1092870350.c30f84@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i6JN5nWE077890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Jul 2004 23:05:50 GMT (envelope-from roy+dated+1092870350.c30f84@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i6JN5oQ3047666 for ; Tue, 20 Jul 2004 00:05:50 +0100 (BST) (envelope-from roy+dated+1092870350.c30f84@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i6JN5oQm047665 for ietf-mxcomp@imc.org; Tue, 20 Jul 2004 00:05:50 +0100 (BST) (envelope-from roy+dated+1092870350.c30f84@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 20 Jul 2004 00:05:49 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16636.21453.113096.471578@giles.gnomon.org.uk> Date: Tue, 20 Jul 2004 00:05:49 +0100 To: Mark Lentczner Cc: IETF MARID WG Subject: Re: PRA algorithm and use of non-standard header fields In-Reply-To: <41E771B0-D9CC-11D8-896F-000393A56BB6@glyphic.com> References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> <41E771B0-D9CC-11D8-896F-000393A56BB6@glyphic.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Mark" == Mark Lentczner writes: Mark> My stats also collected how often each step was used in Mark> yielding the result. Out of over 7,000 messages, only 8 Mark> ever used step 2 (Resent-From:) and none used step 1 Mark> (Resent-Sender:). Perhaps these aren't important and only Mark> complicate the issue. Without them, the "Sender if it is Mark> there, otherwise From" logic is just the 2822 definition of Mark> who the injector is. I disagree. The PRA algorithm, in its current form, is a perfect description of the 2822 semantics. Surely if the message contains a Resent-From (and no Resent-Sender), then according to 2822 the Resent-From is the person who sent you this message? And if it contains Resent-From and Resent-Sender, then the Resent-Sender is the person who sent you the message on behalf of the Resent-From. Personally I think this analysis of statistics is useful, but possibly misguided in intent (or at least misconstrued in intent by some participants). I don't see the PRA algorithm as some heuristic to try and construct some new kind of identity from the headers; the PRA is a natural concept that falls out of the headers defined by 822. If you want to know who (according to the headers) sent you a message, would you do anything substantially different from what the PRA algorithm specifies? If we're going to use a header identity rather than the envelope identity, then the PRA is the only obvious identity to use; I've believed that since before Caller ID was proposed, and I have yet to see anyone make a convincing argument for any other header identity. An IP-based authentication scheme obviously needs to look at who actually sent the message, not on whose behalf it was sent (that implies using Sender in preference to From). And it needs to look at the immediate sender, which implies using the Resent headers in the case of a resent message. And using the most recent resent headers in the case of a multiply-resent message (which is permitted by 2822). If we're going to spend time on the PRA, I think we should be analysing it semantically, not statistically. We should be looking at the details and the corner cases. How does the current algorithm handle borderline messages (ie technically malformed, but acceptable to a liberal parser)? Are there any important corner cases that occur in the wild due to non-compliant systems? What are the issues with header order and the algorithm for selecting the Resent header? (822 restricted messages to a single set of Resent headers, but places no restrictions on placement. 2822 contrains placement and allows multiple resending, but qualifies this with a confusing SHOULD in the description of Resent headers which seems to be at odds with the BNF.) We know the broad outline of what is going to go to last call. Unless anyone thinks that they can gain concensus for a significant change of tack, lets focus on the little details. I certainly wasn't expecting my proposal for revising the PRA algorithm to be adopted with absolutely no discussion or even comment. It was the product of several minutes of consideration on my part, and was intended to be a starting point for discussion, not a fait accomplis. I think it works, and the -core authors have done a decent job of restating it more succinctly, but have we got the semantics exactly right? I _think_ so (besides my doubts about retain the "non-empty" check) but I don't have confidence that anyone other than myself and the ID authors have spent any time looking at it with a critical eye. This is really a general complaint about the way this WG has operated; there has been _far_ too little technical discussion of the details of the proposals that are supposed to be going to last call in a very small number of weeks. Lots of discussion of the big picture, at times verging on out-of-scope, but little discussion of the actual documents that we are supposed to be advancing... (This complaint is in no way directed at Mark or any other specific contributors to this thread, but to the WG as a whole.) -roy From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 19:40:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07621 for ; Mon, 19 Jul 2004 19:40:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JNWqCx068403; Mon, 19 Jul 2004 16:32:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JNWqMu068402; Mon, 19 Jul 2004 16:32:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JNWp9m068396 for ; Mon, 19 Jul 2004 16:32:51 -0700 (PDT) (envelope-from roy+dated+1092871975.a8e095@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i6JNWsWE098708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Jul 2004 23:32:55 GMT (envelope-from roy+dated+1092871975.a8e095@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i6JNWtHB047912 for ; Tue, 20 Jul 2004 00:32:55 +0100 (BST) (envelope-from roy+dated+1092871975.a8e095@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i6JNWtfQ047911 for ietf-mxcomp@imc.org; Tue, 20 Jul 2004 00:32:55 +0100 (BST) (envelope-from roy+dated+1092871975.a8e095@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 20 Jul 2004 00:32:53 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16636.23077.394364.23379@giles.gnomon.org.uk> Date: Tue, 20 Jul 2004 00:32:53 +0100 To: Tony Finch Cc: Mark Lentczner , IETF MARID WG Subject: Re: PRA algorithm and use of non-standard header fields In-Reply-To: References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> <41E771B0-D9CC-11D8-896F-000393A56BB6@glyphic.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tony" == Tony Finch writes: Tony> No, you have to include the Resent- headers in the algorithm Tony> to be properly conformant with RFC 2822 and RFC 822. One of Tony> the standard MUAs at our site for over 10 years has been Tony> Pine which does roughly the right thing with Resent- headers Tony> (it uses 822 rather than 2822 syntax in this respect). It Tony> might be a bit rare but it isn't unimportant. VM (for EMACS) uses Resent headers, too. Admitedly it does it in a slightly weird way, adding only a Resent-To and relying on the MTA/MSP to add the Resent-From. But it does roughly the right thing, at least when used with sendmail. -roy From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 20:52:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17359 for ; Mon, 19 Jul 2004 20:52:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K0iDMM082231; Mon, 19 Jul 2004 17:44:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K0iDCH082230; Mon, 19 Jul 2004 17:44:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K0iBKD082214 for ; Mon, 19 Jul 2004 17:44:12 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: MTAs should focus on email TRANSPORT not email CONTENT Date: Tue, 20 Jul 2004 10:44:16 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K0iDKD082222 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit All, I have tried to read all of the Marid discussions almost since inception but I have not contributed anything to date. I hope what I have to say is not a waste of time or merely repeating what has already been said, however it is a view that I hold quite strongly. I am a system administrator that supports email servers for multiple organisations. Mostly small businesses that want fairly automated low maintenance solutions. MTAs should focus on email transport. Many proprietary solutions have MTAs dipping inside the email content to perform various tests looking for spam or otherwise. Surfcontrol is the example that I am most familiar with. Antivirus solutions are another obvious example. This is all fine; however I do not believe that any of it should be a standard function of an MTA. An MTA is a "message TRANSFER agent". Its job should not necessitate reading the DATA content of email. My view is that the MARID standard should proceed as follows:- 1. Use SPF classic to verify the MAIL FROM address. 2. Use SUBMITTER as an alternative test point if the sending MTA supports it. Otherwise break forwarding after the flag date. If SUBMITTER does not match the FROM address within the DATA section of an email then the email content can be considered to be malformed. However it should be up to the MUA to deal with this, not the MTA. This would mean that most email forgery could be cured by MTAs doing SPF checking. There would still be a phishing opportunity for spammers etc that could claim a false SUBMITTER address. However once this becomes the dominant loophole for spammers and viruses then MUA developers would have user pressure expecting a relevant patch to fix the loophole. The MUA is the correct place to fix this problem. Conceptually the postal worker should not be opening mail in order to make the delivery. The content should be private. Maybe even encrypted (if we want to). If the content is all in Latin the postal worker should not be concerned. Just as the postal worker should not need to look at mail content so the MTA should not be looking at the DATA section of email. A mismatch between the SUBMITTER address and the FROM address is a content problem not a transport problem. MTAs should deal with transport. MUAs should deal with content. Of course proprietary anti-spam gateways could still do non-standard MUA type testing. However they would remain proprietary. Just as looking for spam keywords in the content of the DATA section is totally proprietary MTA function. Would anybody wish to make the lists of keywords checked by anti-spam gateways a "standard" MTA job? I think not. Having the MTA dip inside the DATA section in order to complete its job breaks the layered approach to transport. Breaking the layering limits the future potential of SMTP. Layering should not be broken without good cause. MARID should separate what is transport and what is content. Separate what is an MTA job and what is an MUA job. Moving MUA functions into the MTA should be proprietary not standard.   Regards, TERJE PETERSEN ExceLAN Sydney - Australia From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 20:53:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17468 for ; Mon, 19 Jul 2004 20:53:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K0jqkg082700; Mon, 19 Jul 2004 17:45:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K0jq5M082699; Mon, 19 Jul 2004 17:45:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K0jqDX082688 for ; Mon, 19 Jul 2004 17:45:52 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.152] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 19 Jul 2004 20:45:55 -0400 id 000DFBA9.40FC6B43.000041BA In-Reply-To: <16636.19123.764925.304266@giles.gnomon.org.uk> References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> <16636.19123.764925.304266@giles.gnomon.org.uk> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <271F485A-D9E6-11D8-BD4A-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Mark Lentczner , "IETF MARID WG" From: Andrew Newton Subject: Re: PRA algorithm and use of non-standard header fields Date: Mon, 19 Jul 2004 20:45:52 -0400 To: Roy Badami X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 19, 2004, at 6:26 PM, Roy Badami wrote: > If the words "non-empty" were removed, step 3 would select the empty > Sender header, and step 5 would then fail to determine a PRA because > the header was malformed. Makes sense to me. -andy From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 20:53:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17501 for ; Mon, 19 Jul 2004 20:53:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K0fDuK081338; Mon, 19 Jul 2004 17:41:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K0fDZb081337; Mon, 19 Jul 2004 17:41:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K0fBCV081320 for ; Mon, 19 Jul 2004 17:41:12 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.206.18]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040720004116.PHLV21087.tomts13-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 19 Jul 2004 20:41:16 -0400 From: "John Glube" To: "'Dave Crocker'" , "'Margaret Olson'" Cc: "'Andrew Newton'" , "'IETF MARID WG'" Subject: RE: Schedule for Sender-ID Date: Mon, 19 Jul 2004 20:41:14 -0400 Message-ID: <000001c46df2$4318d2b0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <198477938.20040719154307@brandenburg.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K0fDCV081332 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Four questions: * Since CSV and Sender ID are still on the table is it appropriate for this review to be carried out for both proposals, even though it is my understanding the schedule is to review Sender-ID first and then CSV second? * Given the WG has two technical advisors is it appropriate for the WG Chairs to ask for their guidance as to whom should be selected from the greybeard list to provide this independent review? * As to the parameters of the review, is it appropriate for Marid to ask the WG Chairs in consultation with the WG technical advisors to have a senior IETF review conducted of both Sender-Id and CSV from the perspective of "security and operations issues?" * In conducting their review, given the guidance of Mr. Hardie on the licensing issue, is it appropriate to ask that this issue be considered as part of the review, on the limited basis as outlined in his guidance, or should this be simply "digged?" John Glube Toronto, Canada The FTC Calls For One Standard For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 09/07/2004 From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 21:15:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18710 for ; Mon, 19 Jul 2004 21:15:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K16Lck086160; Mon, 19 Jul 2004 18:06:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K16LMc086159; Mon, 19 Jul 2004 18:06:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K16LTT086153 for ; Mon, 19 Jul 2004 18:06:21 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6K16Qi21158; Mon, 19 Jul 2004 18:06:26 -0700 Date: Mon, 19 Jul 2004 18:06:21 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <601886006.20040719180621@brandenburg.com> To: "John Glube" CC: "'IETF MARID WG'" Subject: Re: Schedule for Sender-ID In-Reply-To: <000001c46df2$4318d2b0$6c62fea9@ibmrkydk2ufvdd> References: <198477938.20040719154307@brandenburg.com> <000001c46df2$4318d2b0$6c62fea9@ibmrkydk2ufvdd> 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 John, JG> Four questions: JG> * Since CSV and Sender ID are still on the table is it JG> appropriate for this review to be carried out for both JG> proposals, even though it is my understanding the schedule JG> is to review Sender-ID first and then CSV second? any interesting specification should get reviews. however, yes, the chairs asked for discussion of csv to be deferred for awhile. in any event, separate specifications warrant separate reviews. and i've already started to recruit reviews for csv. JG> * In conducting their review, given the guidance of Mr. JG> Hardie on the licensing issue, is it appropriate to ask JG> that this issue be considered as part of the review, licenscing is legal. the reviews are technical. how could licenscing "be considered as part of the review"? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 21:21:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19088 for ; Mon, 19 Jul 2004 21:21:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K17HDg086314; Mon, 19 Jul 2004 18:07:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K17HD8086313; Mon, 19 Jul 2004 18:07:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K17Gfe086285 for ; Mon, 19 Jul 2004 18:07:17 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 81AC02836F for ; Tue, 20 Jul 2004 03:07:15 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08762-06 for ; Tue, 20 Jul 2004 03:07:12 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id DB742283C1; Tue, 20 Jul 2004 03:07:12 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT Date: Tue, 20 Jul 2004 03:07:12 +0200 User-Agent: KMail/1.6.1 References: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407200307.12432@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le mardi 20 Juillet 2004 02:44, Terje Petersen a écrit : > > [...] An MTA is a "message TRANSFER agent". Its job should not necessitate > reading the DATA content of email. I agree. > My view is that the MARID standard should proceed as follows:- > > 1. Use SPF classic to verify the MAIL FROM address. Yes. > 2. Use SUBMITTER as an alternative test point if the sending MTA supports > it. Otherwise break forwarding after the flag date. I would personally rather drop the SUBMITTER concept completely. It looks to me like a kludge that tries to give before the DATA stream the results of a computation made with this DATA stream contents. This solution doesn't look right to me. (Shevek also discusses SUBMITTER at the end of his http://www.libsrs2.org/srs/srs.pdf document, finds it to be bad, and I share his point of view regarding this) > Conceptually the postal worker should not be opening mail in order to make > the delivery. [...] Just as the postal worker should not need to look at > mail content so the MTA should not be looking at the DATA section of email. I agree. > MTAs should deal with transport. > MUAs should deal with content. Again, I 100% agree with this statement. > Having the MTA dip inside the DATA section in order to complete its job > breaks the layered approach to transport. Breaking the layering limits the > future potential of SMTP. Layering should not be broken without good cause. Yes, yes, and yes. Regards. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 21:44:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20318 for ; Mon, 19 Jul 2004 21:44:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K1UmBR091867; Mon, 19 Jul 2004 18:30:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K1UmTk091866; Mon, 19 Jul 2004 18:30:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K1Uj8v091841 for ; Mon, 19 Jul 2004 18:30:45 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 19 Jul 2004 18:30:49 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Jul 2004 18:30:47 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jul 2004 18:30:49 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7345.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT Date: Mon, 19 Jul 2004 18:30:30 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF63DE3C@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: MTAs should focus on email TRANSPORT not email CONTENT thread-index: AcRt81uFF9/F1DAzRr2LP9MRmxtv3AABQgZg From: "Jim Lyon" To: "Terje Petersen" , X-OriginalArrivalTime: 20 Jul 2004 01:30:49.0339 (UTC) FILETIME=[3008E4B0:01C46DF9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K1Uj8v091855 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Terje Petersen wrote: > ... An MTA is a "message TRANSFER agent". Its job should not necessitate reading the DATA content of email. However, MARID's job is to verify the identity of the sender of a message, and the sender isn't expressed anywhere except in the message body. That's exactly why the PRA algorithm exists: to determine who sent the message. The mis-named "MAIL FROM:" doesn't tell you who sent the message, but who wants to receive the bounce if any. Much confusion would have been avoided if the 2821 command were spelled "MAIL BOUNCETO:". Many people, including me, have gone down the path of erroneously trying to use "MAIL FROM:" for authentication. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 22:34:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23735 for ; Mon, 19 Jul 2004 22:34:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K2OF5X003515; Mon, 19 Jul 2004 19:24:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K2OF25003514; Mon, 19 Jul 2004 19:24:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K2OD39003500 for ; Mon, 19 Jul 2004 19:24:14 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT Date: Tue, 20 Jul 2004 12:24:19 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7801@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K2OF39003506 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Jim Lyon > > However, MARID's job is to verify the identity of the sender of a > message, and the sender isn't expressed anywhere except in the message > body. That's exactly why the PRA algorithm exists: to determine who > sent the message. Yes. That's why I agree entirely with the proposed SUBMITTER extension. Currently the MUA displays the FROM address to the end user as being the originator of the email. Once the SUBMITTER extension is in use then the MUA can do one of two things to stop phishing:- 1. Instead of displaying the FROM address as the originator it can display the SUBMITTER address. Or 2. Dump messages where FROM <> SUBMITTER. There is little practical difference between these options although down the track I would have a strong preference for option 1. The MUA can not do real time SPF checking to stop spoofing; however we happily leave that job to the MTA. We just ask the MUA to take care of any content presentation problems (eg phishing) on its own. SPF empowers the MTA to put a stop to spoofing. SUBMITTER empowers the MUA to put a stop to phishing. I am sure some proprietary MTA solutions are going to want to do this MUA function for their mailbox users. That is fine. Plenty of notional MTA like devices such as antivirus gateways and spam filters already stick their nose into the email content. However that is a proprietary "MTA+MUA gizmo" edge solution. There is no IETF standard that says an MTA should look inside the message for spam or viruses. Just as there should be no standard that tells the MTA to look inside the DATA section of an email for delivery details. Whether a device is an MTA or an MUA is up to the programmers. However the standards should clearly delineate on MTA standard functions and MUA standard functions. As far as I am concerned comparing SUBMITTER and FROM is not a job for the MTA. It's an MUA function. From owner-ietf-mxcomp@mail.imc.org Mon Jul 19 22:52:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24829 for ; Mon, 19 Jul 2004 22:52:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K2dFr5006380; Mon, 19 Jul 2004 19:39:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K2dFs2006379; Mon, 19 Jul 2004 19:39:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts36-srv.bellnexxia.net (tomts36-srv.bellnexxia.net [209.226.175.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K2dEiI006373 for ; Mon, 19 Jul 2004 19:39:14 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.206.18]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040720023920.BSTU4787.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 19 Jul 2004 22:39:20 -0400 From: "John Glube" To: "'Dave Crocker'" Cc: "'IETF MARID WG'" Subject: RE: Schedule for Sender-ID Date: Mon, 19 Jul 2004 22:39:17 -0400 Message-ID: <000001c46e02$c1149cc0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <601886006.20040719180621@brandenburg.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K2dEiI006374 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dave, JG> Four questions: JG> * Since CSV and Sender ID are still on the table is it JG> appropriate for this review to be carried out for both JG> proposals, even though it is my understanding the schedule JG> is to review Sender-ID first and then CSV second? "any interesting specification should get reviews. however, yes, the chairs asked for discussion of csv to be deferred for awhile. in any event, separate specifications warrant separate reviews. and i've already started to recruit reviews for csv." I simply thought it might be best to do both at the same time. This would allow for a comparative analysis to aid in the decision process. However, I understand your position. To me, as long as there is an independent review, this is what is important. JG> * In conducting their review, given the guidance of Mr. JG> Hardie on the licensing issue, is it appropriate to ask JG> that this issue be considered as part of the review, "licenscing is legal. the reviews are technical. how could licenscing "be considered as part of the review"?" Only to the limited extent as suggested by Ted Hardie that: "The IETF is an engineering body, and it makes engineering decisions. It cares about licensing only as it affects the ability to implement and deploy a standard." So one of the questions put to the reviewers could be "will the royalty free license in the form as tabled by Microsoft with the FAQ have any negative affect on the ability to implement and deploy Sender-ID from an engineering perspective and if so, what is the nature and significance of that affect?" Engineers as contract managers have to make decisions based on specifications and contracts all the time. I suggest the package put to the reviewers include the MS license along with the FAQ, being what "implementors, contractors, software firms and others" will have in hand. If the answer comes back no, this puts the issue to rest from an engineering perspective. If the answer comes back yes, then the issue becomes a factor given section 8 of RFC 3688 as to what protocol the WG recommends, based on the signficance of the yes. The reviewers may come back and say for example, we can't answer the question based on the license and FAQ without consulting with lawyers. This is a factor in and of itself, as that becomes a cost and a friction in dealing with implementation. * Is this an acceptable factor? For medium and large corporations it is part of doing business. For the independent developer/implementor it may be an undue burden. * Is there a need for independent developers/implementors to expidite the process? It depends on one's perspective, but at least the issue has then been framed and people can make an informed decision. MS can deal with the issue as it considers proper, presuming there is time. This in turn requires a fair selection process of the reviewers. Which is why I suggested the WG Chairs with the guidance of the WG Technical Advisors select the reviewers for both proposals. Of course, it is quite appropriate for the proponents to recruit reviewers and submit a panel for consideration. Doing it this way maintains the atmosphere of collegiality, while ensuring the appearance of fairness, if that makes any sense. Just some suggestions for people to mull over. John John Glube Toronto, Canada The FTC Calls For One Standard For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 09/07/2004 From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 00:46:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01930 for ; Tue, 20 Jul 2004 00:46:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K4WE6r027662; Mon, 19 Jul 2004 21:32:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K4WElQ027661; Mon, 19 Jul 2004 21:32:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K4WEnP027638 for ; Mon, 19 Jul 2004 21:32:14 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 75CA440DF for ; Mon, 19 Jul 2004 21:32:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <16636.21453.113096.471578@giles.gnomon.org.uk> References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> <41E771B0-D9CC-11D8-896F-000393A56BB6@glyphic.com> <16636.21453.113096.471578@giles.gnomon.org.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: PRA algorithm and use of non-standard header fields Date: Mon, 19 Jul 2004 21:32:29 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 19, 2004, at 4:05 PM, Roy Badami wrote: > I don't see the PRA algorithm as some heuristic to try and construct > some new kind of identity from the headers; the PRA is a natural > concept that falls out of the headers defined by 822. If you want to > know who (according to the headers) sent you a message, would you do > anything substantially different from what the PRA algorithm > specifies? Well, when Caller-ID was first presented to me, it was presented as a heuristic. And later evolutions of the algorithm seemed to get even more based on heuristics. I was told that the X-Envelope, etc... things were added as they bettered some score on a test of "typical mail". However, I agree with you that the current form attempts to encapsulate some notion of "who sent you this mail", as claimed by the headers. Alas, any such definition comes up against two problems: 1) RFC 2822 doesn't talk in those terms, so we must infer, and 2) Current wide spread usage may or may not conform. For example, RFC 2822 says "Resent fields are used to identify a message as having been reintroduced into the transport system by a user." -- and yet none of the mailing lists I use, which seem to be doing precisely this, add such headers. Nor do any of my mailers when I choose "Forward". So, practice and RFC are in conflict. When, in practice, are these fields added? Almost none of the mail I scanned had them. On the other hand, wide spread use of a PRA check will probably cause wider use of the headers, in situations which may or may not be warranted. On the other hand, RFC 2822 says "Resent fields are strictly informational. They MUST NOT be used in the normal processing of replies or other such automatic actions on messages." So, while it might represent who re-injected the mail, the user is to treat the mail as coming from the Sender:/From: addresses. Hence, perhaps that is the identity that should be checked. I have seen it requested that MUAs should change to show the PRA address to users as the sender of the e-mail, but that would seem to be in direct opposition to RFC 2822's intent of these headers. Though I'm sure this is open to interpretation. I point this out not because I have a strong feeling one way or the other, but because I think it should be clear that we are going to have to interpret 2822 and make some choices, and this will result in changes in practice. Hence, I think it is reasonable to investigate, via both technical arguments and statistics, how well these ideas work. > If we're going to use a header identity rather than the envelope > identity, then the PRA is the only obvious identity to use; I've > believed that since before Caller ID was proposed, and I have yet to > see anyone make a convincing argument for any other header identity. See above for perhaps why just Sender:/From: could be argued for. > An IP-based authentication scheme obviously needs to look at who > actually sent the message, not on whose behalf it was sent (that > implies using Sender in preference to From). Well, to the end user this may not be so clear. Because of the fractured nature of the mail identities (who gets bounces, who injected, who will get replies, who the user will see as the sender, etc...), there are several options for what you might want to check. The IP address isn't necessarily tied only to the concept of who injected it. This is because the IP that injected the mail is in control of (can forge) any of those other identities. So an IP-base authentication scheme is essentially asking a domain "Is this IP authorized to inject mail with your domain name in the following identity?". I can see how a reasonable argument could be made for any of those identities. As an end user I might even want them all checked, and flagged when I try to base actions upon them. > If we're going to spend time on the PRA, I think we should be > analysing it semantically, not statistically. If the semantics of mail identity were clear cut, and common practice generally compliant, I'd agree. Alas, neither of these are true. I think both semantics and statistics (testing with real world data) will have to come into play. > (This complaint is in no way directed at Mark or any other specific > contributors to this thread, but to the WG as a whole.) No offense taken, and hopefully none given. I also don't want others to take this as a position against PRA. PRA is a fine identity to check. As we come closer to some consensus on PRA, and as we fine tune it, I want express how I view this check as a guide to how we might refine it. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 03:06:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24860 for ; Tue, 20 Jul 2004 03:06:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K6tI3i091765; Mon, 19 Jul 2004 23:55:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K6tIbU091764; Mon, 19 Jul 2004 23:55:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K6tH5X091756 for ; Mon, 19 Jul 2004 23:55:17 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6K6tHi15134; Mon, 19 Jul 2004 23:55:17 -0700 Date: Mon, 19 Jul 2004 23:55:14 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1679192673.20040719235514@brandenburg.com> To: "Jim Lyon" CC: ietf-mxcomp@imc.org Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF63DE3C@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF63DE3C@df-fido-msg.exchange.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jim, JL> The mis-named "MAIL FROM:" doesn't tell you who sent the message, but JL> who wants to receive the bounce if any. Much confusion would have been JL> avoided if the 2821 command were spelled "MAIL BOUNCETO:". Many people, JL> including me, have gone down the path of erroneously trying to use "MAIL JL> FROM:" for authentication. given that the misnomer dates back to rfc 821, it's rather impressive that it took more than 20 years for us to notice the error! in an odd way, this highlights the difficulty of preventing scaling problems. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 06:39:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07228 for ; Tue, 20 Jul 2004 06:39:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KANXg0084930; Tue, 20 Jul 2004 03:23:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KANXtr084926; Tue, 20 Jul 2004 03:23:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KANWgT084899 for ; Tue, 20 Jul 2004 03:23:32 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57462) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1BmrmT-0002GE-4o for ietf-mxcomp@imc.org; Tue, 20 Jul 2004 11:23:29 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BmrmT-0002vP-3X; Tue, 20 Jul 2004 11:23:29 +0100 Date: Tue, 20 Jul 2004 11:23:29 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Lentczner cc: IETF MARID WG Subject: Re: PRA algorithm and use of non-standard header fields In-Reply-To: Message-ID: References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> <41E771B0-D9CC-11D8-896F-000393A56BB6@glyphic.com> <16636.21453.113096.471578@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 19 Jul 2004, Mark Lentczner wrote: > > For example, RFC 2822 says "Resent fields are used to identify a message as > having been reintroduced into the transport system by a user." -- and yet none > of the mailing lists I use, which seem to be doing precisely this, add such > headers. I think the choice of the word "user" is intended to exclude mailing lists. > Nor do any of my mailers when I choose "Forward". The Resent- headers are explicitly not for forwarding messages, in either the encapsulated message sense or in the alias address sense. Read the second paragraph after the syntax in section 3.6.6 of RFC 2822. This has implications for other parts of the current MARID drafts, but PRA itself is OK. > So, practice and RFC are in conflict. When, in practice, are these > fields added? Using the "bounce" (i.e. resend) function in Pine or Mutt, for example. > On the other hand, RFC 2822 says "Resent fields are strictly informational. > They MUST NOT be used in the normal processing of replies or other such > automatic actions on messages." So, while it might represent who re-injected > the mail, the user is to treat the mail as coming from the Sender:/From: > addresses. Hence, perhaps that is the identity that should be checked. That wouldn't make sense. An example use of the resend function where I work is our staff who read webmaster or postmaster email resending a message to the person best able to deal with it. Clearly this person should reply to the original sender of the message since that is who has the problem, but they received the message from the webmaster/postmaster staff so that is what should be checked. Tony. -- f.a.n.finch http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: SOUTHEAST 3 INCREASES 5 TO 7. SCATTERED SHOWERS THEN RAIN. GOOD BECOMES OCCASIONALLY MODERATE. SLIGHT BUILDS MODERATE OR ROUGH IN EAST. From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 07:38:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10979 for ; Tue, 20 Jul 2004 07:38:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KBOSE8001438; Tue, 20 Jul 2004 04:24:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KBOSGQ001437; Tue, 20 Jul 2004 04:24:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts25-srv.bellnexxia.net (tomts25-srv.bellnexxia.net [209.226.175.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KBORYK001428 for ; Tue, 20 Jul 2004 04:24:28 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.206.18]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040720112428.LHCV28143.tomts25-srv.bellnexxia.net@ibmrkydk2ufvdd>; Tue, 20 Jul 2004 07:24:28 -0400 From: "John Glube" To: "'Margaret Olson'" , "'Mark Lentczner'" Cc: "'IETF MARID WG'" Subject: RE: MARID compatibility with SPF records Date: Tue, 20 Jul 2004 07:24:24 -0400 Message-ID: <000001c46e4c$1ca67f60$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6KBOSYK001432 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit A quick comment on the compatibility of MARID with SPF records. Let me use the example of mydomain.com. Mydomain.com sends email through its ISP and also uses the services of a 3rd party email service provider to send out its newsletter. In setting up its SPF record, mydomain.com proposes initially to publish a record: mydomain.com.IN TXT "v=spf1 +a:mx.bigisp.com +a:mx.bulkmailer.com -all" (I am using the same record for ease of comparison.) In discussions with bulkmailer.com, the owner says this is not necessary as SPF authenticates the MAIL FROM address in the envelope header and we use a root email address for our domain. Since Sender-ID is not in the wild, by including +a:mx.bulkmailer.com in the SPF record this will throw an extra burden on our DNS server. Please don't do this. The response from mydomain.com is ok. Now with Sender-ID a number of things happen: * mydomain.com needs to amend its MARID record. * Receiving MTA's may do a check on mydomain.com and bulkmailer.com resulting in two queries of bulkmailer.com's DNS server. (This may not be a problem if the query is cached.) * If mydomain.com wishes to be accredited for newsletter sends, it can no longer rely on the accreditation of bulkmailer.com, which is already included as part of bulkmailer.com's service fee. Since the only mail sent through its ISP is response to customer queries, it now has to pay an extra charge to have its domain accredited, not having established a reputation for mydomain.com, relying on the services of bulkmailer.com. Since mydomain.com already follows best list management practice of using closed loop verification through bulkmailer.com, this is an extra financial cost. Some may say, well this is the cost people will have to bear if they want their domain protected against being used for fraudulent purposes and to get through all the intervening filters on an "express basis." I would argue this is an unnecessary cost for mydomain.com since the business owner is already paying for accreditation once through bulkmailer.com. Now, the business owner has to pay twice. As was pointed out, with SPF the authentication cost for the business owner is perceived to be free. However, with Sender-ID the mix has now changed and although there is no cost in publishing a record, the cost implications of the change on the accreditation side are significant. I simply ask these matters be considered as Sender-ID moves forward. John Glube Toronto, Canada The FTC Calls For One Standard For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 09/07/2004 From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 12:09:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01123 for ; Tue, 20 Jul 2004 12:09:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KFlTK7045115; Tue, 20 Jul 2004 08:47:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KFlTTB045114; Tue, 20 Jul 2004 08:47:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KFlRYx045098 for ; Tue, 20 Jul 2004 08:47:27 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1Bmwpm-0001II-VT for ietf-mxcomp@imc.org; Tue, 20 Jul 2004 10:47:27 -0500 To: "IETF MARID WG" References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 20 Jul 2004 10:47:14 -0500 In-Reply-To: <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> (Andrew Newton's message of "Mon, 19 Jul 2004 12:13:07 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: PRA algorithm and use of non-standard header fields Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.5 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On the same day that Caller-ID was announce to this mailing list (April 6th, about three and a half months ago), I posted the following question: : In <9156B81DAA29204989AD43E88688FAAB01373697@df-lassie.dogfood> "Harry Katz" writes: : : > [snip] But let's start with the base case - one address on the From line : > - and work our way from there. : : I am very concerned with, as you say, the many special cases of : dealing with the RFC2822 data. While working code is not required at : this stage of RFC development, it is certainly very helpful in trying : to get a grasp on the whole problem and learning about subtle, but : critical details. : : Do you have any working code that validates the RFC2822 that we can : look at, test, analyze and collect data with? I realize that the C-ID : doc on the microsoft website has an algorithm outline, but that would : require a lot of work to turn into working code. : : If you can't provide working code, can you provide data and your own : analysis of the situation? I would like to thank both Andy and Mark for finally providing some data on the Caller-ID algorithm (aka PRA/PRD). I think it is especially nice of them since neither of them are the ones that have been pushing for the PRA the hardest. This working group is supposed to do engineering ("application of scientific and mathematical principles to practical ends"), and it is hard for me to believe that a huge amount of engineering has gone on WRT the PRA when there has been no to base things on. In <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> Andrew Newton writes: > I reran my tests using PRA and SPF-classic. Here are the results: > > HAM - 15678 messages (most from mailing lists, btw) > ==== Msgs w/usable RR Deny Pass > ---------------- ----- ----- > SPF-C 32% 3.9% 23.5% > PRA 32% 4.5% 23.7% Andy: I'm not sure what these numbers are supposed to be. What exactly are "messages with usable RRs"? Are you saying that about one third of all email that you checked had an SPF record for the domain? If so, that is higher than the data I'm seeing. The "deny" percentages are also much higher than I would expect. Have you checked into why these messages are being rejected? Are they due to forgeries, or badly constructed SPF records, or fundamental flaws in SPF-classic/SenderID? In <1EE98B0E-D9CB-11D8-896F-000393A56BB6@glyphic.com> Mark Lentczner writes: > I took messages, computed the PRA and compared it's domain to the > domain of the envelope from. [snip] The > percentage where they differ is: > > ham1 17% > ham2 16% > spam1 8% > spam2 9% > > [mongo snip!] > > 1) Over 80% of mail is not complicated and the PRA produces the same > domain as env. from. Oddly enough, even more so for spam. (I suppose > spammers just haven't caught on.) My guess is that the higher rate of 2821.FROM differing from the PRA is caused by email sent through mailing lists. I think it would be interesting to dig into this to make sure we know what is going on. > 2) While still only a small percentage of sites have records, more > sites identified by PRA had records than env. from. This could be > because the PRA is more often a bigger site. Again, I suspect that this has to do with mailing lists. From skimming my own mail folders, it appears that domains that host mailing lists are much less likely to publish SPF records. > 4) For ham, env. from produces a greater percentage of passes than > PRA. It also produces few fails, but the numbers here are very low. > For ham, more passes and fewer fails is good. Yes, this is a very small test case, but both your data and Andy's seems to show that the PRA has a higher rate of rejecting valid email than SPF-classic. I think more interesting numbers are actually in the attachment that Mark included that had more detailed data. > ::: Data set Ham 1 ::: > > PRA Query Stats: published SPF > ---------------- --------------- > pass 11 ( 24%) > fail 0 ( 0%) > softfail 0 ( 0%) > neutral 34 ( 75%) > unknown 0 ( 0%) > error 0 ( 0%) > > Env. From Query Stats: published SPF > ----------------------- --------------- > pass 18 (100%) > fail 0 ( 0%) > softfail 0 ( 0%) > neutral 0 ( 0%) > unknown 0 ( 0%) > error 0 ( 0%) Both Andy and Mark appeared to concentrate more on the pass/fail results, but I think we need to look much closer at the neutrals. There are quite a few major email domains that are currently publishing SPF records that end in ?all. I think we all want to see the day when most people publish -all, so we need to look at why the neutrals are happening and what can be done to make them pass. My guess is, again, mailing lists. If joe-sixpack@aol.com sends email to some-mailinglist@groups.yahoo.com and it is received by Andy or Mark, the result will be a neutral for the PRA but for the 2821.FROM, there will be no SPF record found. This is because AOL publishes an SPF record that ends in ?all, and Yahoo Groups doesn't add a Sender: header to their mailing lists, although the do correctly use a Yahoo domain for the 2821.FROM. So, in this first set of ham, there are no outright rejections of valid email for either PRA or SPF-classic, the PRA looks like it might be generating a huge number of incorrect results. > ::: Data set Ham 2 ::: > > PRA Query Stats: published SPF > ---------------- --------------- > pass 14 ( 53%) > fail 7 ( 26%) > softfail 0 ( 0%) > neutral 3 ( 11%) > unknown 2 ( 7%) > error 0 ( 0%) > > Env. From Query Stats: published SPF > ----------------------- --------------- > pass 16 ( 66%) > fail 0 ( 0%) > softfail 0 ( 0%) > neutral 1 ( 4%) > unknown 7 ( 29%) > error 0 ( 0%) Again, the PRA has returned more neutrals and, percentage wise, a huge number of fails. As both Andy and Mark pointed out, these are small datasets and are probably not very diverse. It is far too little data to draw any conclusions from, but it does show that much more data needs to be looked at. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 12:59:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05262 for ; Tue, 20 Jul 2004 12:59:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGaeXo052962; Tue, 20 Jul 2004 09:36:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KGaen7052961; Tue, 20 Jul 2004 09:36:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6KGadoP052946 for ; Tue, 20 Jul 2004 09:36:39 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 29328 invoked from network); 20 Jul 2004 16:38:06 -0000 Received: from unknown (HELO ?192.168.254.158?) (208.198.98.2) by ns1.hoster907.com with SMTP; 20 Jul 2004 16:38:06 -0000 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Margaret Olson Subject: Re: PRA algorithm and use of non-standard header fields Date: Tue, 20 Jul 2004 12:36:39 -0400 To: "IETF MARID WG" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 20, 2004, at 11:47 AM, wayne wrote: > > I would like to thank both Andy and Mark for finally providing some > data on the Caller-ID algorithm (aka PRA/PRD). I think it is > especially nice of them since neither of them are the ones that have > been pushing for the PRA the hardest. > > The thing I don't understand about all this data is - what is the PRA analysis and particularly the PRA "pass/fail" analysis based on? Caller-ID records? It's hard to imagine that there is significant SenderID volume yet, since the specs are so new. There are not many Caller-ID records, let alone a representative cross section of domains. Evaluating the PRA based on records published for SPF-classic is not valid. SPF-classic publication is itself a non-representative subsection of the net, and on top of that SPF classic records are not Sender ID records - the semantics are different - so "pass" and "fail" does not mean anything. Also, where are the input mail samples coming from? If it is the inboxes of technical folks then it is not representative. To get a representative cross section of mail you need to look at a random cross section of consumer mailboxes on the big ISPs and also, separately, mail coming into corporate domains. B to B and B to C mail have very different characteristics. You also have to make sure the inbox owners agree with your "ham/spam" assignments. I agree that generating meaningful data here is extremely difficult, but how are these stats anything other than anecdotes with numbers? I agree it's very interesting, but I don't see how this data can be used for anything other than an aide to designing conclusive tests. From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 13:52:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09836 for ; Tue, 20 Jul 2004 13:52:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KHdYdY063448; Tue, 20 Jul 2004 10:39:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KHdYjh063447; Tue, 20 Jul 2004 10:39:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KHdYoh063439 for ; Tue, 20 Jul 2004 10:39:34 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 20 Jul 2004 13:39:35 -0400 id 000DFBE2.40FD58D7.00001D0C Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: PRA algorithm and use of non-standard header fields Date: Tue, 20 Jul 2004 13:39:34 -0400 To: "IETF MARID WG" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 20, 2004, at 11:47 AM, wayne wrote: > I'm not sure what these numbers are supposed to be. What exactly are > "messages with usable RRs"? Are you saying that about one third of > all email that you checked had an SPF record for the domain? If so, > that is higher than the data I'm seeing. That is what I'm saying. And I would agree that it isn't representative of the domain space. What it really points out is that I have a very non-diverse data set. > The "deny" percentages are also much higher than I would expect. Have > you checked into why these messages are being rejected? Are they due > to forgeries, or badly constructed SPF records, or fundamental flaws > in SPF-classic/SenderID? It would be the latter since those were all ham and I had no dns errors or bad syntax in any of the ham (not true for the spam). Also another indicator that my data set was not well diversified. -andy From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 14:48:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14919 for ; Tue, 20 Jul 2004 14:48:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KIXbI8072743; Tue, 20 Jul 2004 11:33:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KIXbmg072742; Tue, 20 Jul 2004 11:33:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KIXSV8072678 for ; Tue, 20 Jul 2004 11:33:37 -0700 (PDT) (envelope-from daryl.odnert@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v6.0.0)); Tue, 20 Jul 2004 11:33:06 -0700 X-Server-Uuid: 2FF20946-3D64-4888-885C-250F7FE4E04F Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Tue, 20 Jul 2004 11:33:12 -0700 Message-ID: From: "Daryl Odnert" To: "'Jim Lyon'" , "'Meng Weng Wong'" cc: "'IETF MARID WG'" Subject: Two Minor Points On MARID CORE Draft 02 Date: Tue, 20 Jul 2004 11:33:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6CE3BAEB2X44638750-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46E88.029C4A4B" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46E88.029C4A4B Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Jim, Meng, Page 5: The draft says: MTAs performing the Sender ID check as part of receiving a message SHOULD reject... and The result is that corner cases may result in messages of questionable deliverability, but they will never result in an MTA doing MARID checks ... Are the terms "Sender ID check" and "MARID check" being used interchangeably? Perhaps the document be more explicit about what these terms mean? Page 5. In Sections 5.1, 5.4, and 5.5, I suggest dropping the word "anti-spam" when discussing the additional scrutiny that may be applied to messages that do not get a Pass or Fail result from the Sender ID test. I think its sufficient to say that messages receiving a certain result may be given heightened scrutiny without saying exactly what type of scrutiny will be performed. Or at least, let's make it clear that spam probability analysis is just one example of the type of scrutiny that may be applied. Regards, Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C46E88.029C4A4B Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

Jim, Meng,

Page 5: The draft says:

MTAs performing the Sender ID check as part of receiving a message SHOULD reject...

and

The result is that corner cases may result in messages of questionable deliverability, but they will never result in an MTA doing MARID checks ...

Are the terms "Sender ID check" and "MARID check" being used interchangeably?  Perhaps the document be more explicit about what these terms mean?

Page 5.  In Sections 5.1, 5.4, and 5.5, I suggest dropping the word "anti-spam" when discussing the additional scrutiny that may be applied to messages that do not get a Pass or Fail result from the Sender ID test.  I think its sufficient to say that messages receiving a certain result may be given heightened scrutiny without saying exactly what type of scrutiny will be performed.  Or at least, let's make it clear that spam probability analysis is just one example of the type of scrutiny that may be applied.

Regards,
Daryl Odnert
Tumbleweed Communications
Redwood City, California
------_=_NextPart_001_01C46E88.029C4A4B-- From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 15:25:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19129 for ; Tue, 20 Jul 2004 15:25:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KJFV21079438; Tue, 20 Jul 2004 12:15:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KJFVDJ079437; Tue, 20 Jul 2004 12:15:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KJFULc079431 for ; Tue, 20 Jul 2004 12:15:31 -0700 (PDT) (envelope-from roy+dated+1092942933.d0eade@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i6KJFWWE079649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 Jul 2004 19:15:33 GMT (envelope-from roy+dated+1092942933.d0eade@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i6KJFX4G053034 for ; Tue, 20 Jul 2004 20:15:33 +0100 (BST) (envelope-from roy+dated+1092942933.d0eade@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i6KJFXTj053033 for ietf-mxcomp@imc.org; Tue, 20 Jul 2004 20:15:33 +0100 (BST) (envelope-from roy+dated+1092942933.d0eade@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 20 Jul 2004 20:15:21 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16637.28488.958898.593154@giles.gnomon.org.uk> Date: Tue, 20 Jul 2004 20:15:20 +0100 To: "Terje Petersen" Cc: Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A7801@ltwd-svr2.lightwood.com.au> References: <3CA474173FC0274799F97F3AB3BD25EE1A7801@ltwd-svr2.lightwood.com.au> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Terje" == Terje Petersen writes: Terje> 2. Dump messages where FROM <> SUBMITTER. But an MTA can reject the message at the MTA level. Quietly dumping messages anywhere is a bad thing, and it violates the spirit of the reliable mail delivery prinicple, even if perhaps not the letter. -roy From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 15:54:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21664 for ; Tue, 20 Jul 2004 15:54:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KJiLHO084337; Tue, 20 Jul 2004 12:44:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KJiLmN084336; Tue, 20 Jul 2004 12:44:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KJiLA4084330 for ; Tue, 20 Jul 2004 12:44:21 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6KJiPi16886 for ; Tue, 20 Jul 2004 12:44:25 -0700 Date: Tue, 20 Jul 2004 12:44:19 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <379047120.20040720124419@brandenburg.com> To: ietf-mxcomp@imc.org Subject: smtp mailfrom meta-syntax issues 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 Folks, there has been discussion about meta-syntax restrictions in the rfc2821.mailfrom field. I am forgetting what restrictions were cited. That is, what will break existing MTAs? Which characters and what string sizes? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 16:23:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26406 for ; Tue, 20 Jul 2004 16:23:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KKFcKg087937; Tue, 20 Jul 2004 13:15:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KKFc3q087936; Tue, 20 Jul 2004 13:15:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KKFbAh087930 for ; Tue, 20 Jul 2004 13:15:38 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24784; Tue, 20 Jul 2004 16:15:39 -0400 (EDT) Message-Id: <200407202015.QAA24784@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-core-02.txt Date: Tue, 20 Jul 2004 16:15:39 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : MTA Authentication Records in DNS Author(s) : J. Lyon, M. Wong Filename : draft-ietf-marid-core-02.txt Pages : 12 Date : 2004-7-20 Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- 'spoofed' in this case means the address is used without the permission of the domain owner. This document describes the following: mechanisms by which a domain owner can publish its set of outgoing MTAs, mechanisms by which SMTP servers can determine what email address is allegedly responsible for most proximately introducing a message into the Internet mail system, and whether that introduction is authorized by the owner of the domain contained in that email address. The specification is carefully tailored to ensure that the overwhelming majority of legitimate emailers, remailers and mailing list operators are already compliant. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-core-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-core-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20160140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-core-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-core-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160140.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 16:24:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26499 for ; Tue, 20 Jul 2004 16:24:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KKGGSj087971; Tue, 20 Jul 2004 13:16:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KKGG4D087970; Tue, 20 Jul 2004 13:16:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KKGFUQ087964 for ; Tue, 20 Jul 2004 13:16:15 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24871; Tue, 20 Jul 2004 16:16:17 -0400 (EDT) Message-Id: <200407202016.QAA24871@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-submitter-02.txt Date: Tue, 20 Jul 2004 16:16:17 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message Author(s) : E. Allman, H. Katz Filename : draft-ietf-marid-submitter-02.txt Pages : 13 Date : 2004-7-20 This memo defines an extension to the Simple Mail Transfer Protocol SMTP) service, which allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e- mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-submitter-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-submitter-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20160146.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-submitter-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-submitter-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160146.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Tue Jul 20 23:27:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11775 for ; Tue, 20 Jul 2004 23:27:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L3AcHI021814; Tue, 20 Jul 2004 20:10:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L3AcCq021813; Tue, 20 Jul 2004 20:10:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L3AasT021774 for ; Tue, 20 Jul 2004 20:10:37 -0700 (PDT) (envelope-from sb0-0620f50f86-johnl@iecc.com) Received: (qmail 15363 invoked by uid 100); 21 Jul 2004 03:10:40 -0000 Date: 21 Jul 2004 03:10:40 -0000 Message-ID: <20040721031040.15362.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: MTAs should do what they're good at In-Reply-To: <16637.28488.958898.593154@giles.gnomon.org.uk> Organization: I.E.C.C., Trumansburg NY USA Cc: roy@gnomon.org.uk Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Terje> 2. Dump messages where FROM <> SUBMITTER. > >But an MTA can reject the message at the MTA level. Right -- the MTA can easily look at the header as it receives the message data and reject the message at the end of the data if it fails the test. While I sympathize with the goal of separating function, it's been apparent for a long time that you often need to combine the implementation of multiple levels to get acceptable performance. If I had to push all my MTA spam filtering into the MUA, the load on my mail servers would go up an order of magnitude. Even if it has to read the whole message before rejecting it, MTA time rejection is a lot cheaper than MUA rejection because it avoids the entire queue and deliver process. For that matter, since no spammer with a room temperature IQ will ever send spam with a SUBMITTER that doesn't pass, we're going to have to check SUBMITTER vs. From: on every message anyway, so we might as well skip a lot of useless programming and just check the From: directly. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 02:40:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21316 for ; Wed, 21 Jul 2004 02:40:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L6S1jn067692; Tue, 20 Jul 2004 23:28:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L6S18u067690; Tue, 20 Jul 2004 23:28:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L6Rv05067608 for ; Tue, 20 Jul 2004 23:28:00 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MTAs should do what they're good at Date: Wed, 21 Jul 2004 16:27:47 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7802@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6L6S105067676 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit >>> Terje> 2. Dump messages where FROM <> SUBMITTER. >>> >>But an MTA can reject the message at the MTA level. In theory an MTA can server up web pages and wash laundry also. However it's not in the standards. Just because some MTAs can or currently do some function that does not mean that it's a good idea to make it a standard function for all MTAs (or all MARID compliant MTAs). And just because washing laundry is not a standard MTA function it does not mean that you are stopped from having an MTA that does wash laundry. I agree that it's bad for an MTA to dump email silently. However I was saying that the MUA should do it not the MTA. Still I would agree that this is also not such a good idea so let's propose the following:- As a default a well designed MUA would be expected to check that SUBMITTER equals FROM and if it does not then the SUBMITTER address should be displayed to the user as the SENDER of the email instead of the FROM address. This way nothing gets silently dumped. Certainly the SUBMITTER address might be forged (so might the FROM address) but since the SUBMITTER address is likely to have been SPF checked at the MTA level it is a safer bet. >Right -- the MTA can easily look at the header as it receives the >message data and reject the message at the end of the data if it fails >the test. Yes but that means that forever more the content of email is locked down by the way that we have made MTAs work. MTAs should not fail just because we decide at some future date to redefine the way that content is structured. That's how layering should work. And making the SUBMITTER/FROM comparison an MUA function does not stop your anti-virus/spam gateway rejecting email actively in real time due to malformed content. However it's purely a proprietary implementation to suit a local policy decision in that instance. Not an MTA standard. As a proprietary solution we could right now make MTAs that reject the transmission of email if the DATA section contains a virus or spam. We don't need a standard to make this possible. It's just a local policy decision. >While I sympathize with the goal of separating function, it's been >apparent for a long time that you often need to combine the >implementation of multiple levels to get acceptable performance. If I >had to push all my MTA spam filtering into the MUA, the load on my >mail servers would go up an order of magnitude. Even if it has to >read the whole message before rejecting it, MTA time rejection is a >lot cheaper than MUA rejection because it avoids the entire queue and >deliver process. Your anti-spam gateway is already doing stuff that is not defined as a standard MTA function. It is already a proprietary "MTA+MUA gizmo". So in essence you have already put such stuff in the MUA. And rejection during transmission is not much cheaper than letting the MUA deal with it. You still need to receive the entire DATA section before the MTA can make a reject response. From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 04:00:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25988 for ; Wed, 21 Jul 2004 04:00:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L7oREE001827; Wed, 21 Jul 2004 00:50:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L7oRkd001826; Wed, 21 Jul 2004 00:50:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6L7oQOr001796 for ; Wed, 21 Jul 2004 00:50:27 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 21 Jul 2004 03:54:26 -0400 Received: from ([65.2.216.171]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 4207113750; Wed, 21 Jul 2004 03:54:25 -0400 Message-ID: <001d01c46ef7$43dde6d0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" Subject: Comments and Concern about MARID-CORE: A Proposal Date: Wed, 21 Jul 2004 03:49:29 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I had a CPU burnout problem (silicon variety) so this delayed a proposal about revisiting the MARID-CORE, not to change the scope but to remove most, if not all, the "real" concerns about it. I put together 5-6 drafts that illustrate how MARID can still be used yet resolve for the most part two concerns: - IP concerns - Better "Mouse Traps" I put a lot of time into this and it is NOT my goal to buck the system here. The status-quo of MARID is a major problem for many and in my belief not suitable to become a "world-wide standard." I think a simple reorganization will address all the concerns on both sides and still have a "MARID" offering for the world. Here is my summary of all the drafts that begin a core abstract framework called "Data Transaction End Point Validation Framework." They keyword here is "abstract." I would like to see comments on this before I proceed with the draft complete which basically is putting them into a IETF draft format. Data Transaction End Point Validation Framework By Hector Santos Santronics Software, Inc. July 16, 2004 Summary: The EPV-CORE abstract functional model: EPV = EPV-METHOD (EPV-DATA) Where EPV is the end point validation result of the EPV-METHOD function generator with EPV-DATA environment variables in the process domain. The End Points in the EPV-CORE framework are: - Client connecting to server, - Sender of transaction - Receiver of the transaction The EPV-CORE functional model for SMTP: EPV = EPV-METHOD (EPV-SMTP-DATA) Where EPV-SMTP-DATA is the set of SMTP process variables: CIP Client IP Address CDN Client Domain Name, HELO/EHLO (RFC2821) AUA Authentication User Access, AUTH (RFC2821) TRP Transaction Return Address, MAIL FROM (RFC2821) TFP Transaction Forward Address, RCPT TO (RFC2821) TPL Transaction Payload, DATA (RFC 2822) DNS Domain Name Server Database UDB Server-side User Database (i.e., LDAP) PUA Persistent User Address (from UDB) Current EPV-METHOD implementations: EPV = EPVM-RBL (CIP, DNS) EPV = EPVM-DMP (CIP, TRP, CDN, DNS) EPV = EPVM-SPF (CIP, TRP, CDN, DNS) EPV = EPVM-CSV (CIP, CDN, DNS) EPV = EPVM-SENDERID (CIP, AUA, TPL, DNS) EPV = EPVM-SUBMITTER (CIP, AUA, PRA, DNS) EPV = EPVM-MARID (CIP, AUA, TRP, PRA, TPL, DNS) EPV = EPVM-LUV (TFP, UDB) EPV = EPVM-CBV (TRP, DNS) The EPVM-SUBMITTER method requires the introduction on a new ENV-DATA variable called PRA using a ESMTP MAIL FROM modifier "SUBMITTER=" The EPVM-SENDERID method requires the usage of TPL when the PRA is not available. The EPVM-MARID method combines SPF, SENDERID and SUBMITTER. In other words the MARID-CORE can be reorganized in such a way to be based on totally on prior art and public domain technology that exist TODAY. Yet, the EPV-CORE framework does not take away individual IP claims isolated to the METHOD in place - not the framework. The IP claim can not use the EPV-CORE SMTP basic model as a IP protected enscapulated element to the IP claim. This allows for "better mouse traps" EPV-METHOD implementations to be invented. MARID-CORE should be an Framework that provides technology to propers as it comes along. Not locked into one or more specific technology that will limit the future options of better EPV-METHOD solutions. This is the major concern I have with the current MARID. It was something that made sense and worked to a very high degree, that would be wonderful. But it isn't reliably technologically and with all the required cost requirements for implementation and its IP related possible issues, it makes MARID extremely hard to swallow and adopt. It doesn't have to be this way. We can have "our cake and eat it too." -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 04:45:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28833 for ; Wed, 21 Jul 2004 04:45:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L8W6Nc018501; Wed, 21 Jul 2004 01:32:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L8W6Ot018499; Wed, 21 Jul 2004 01:32:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.199.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L8W5W5018469 for ; Wed, 21 Jul 2004 01:32:05 -0700 (PDT) (envelope-from td@nominet.org.uk) Received: from wds1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 717A0E7EED for ; Wed, 21 Jul 2004 09:32:00 +0100 (BST) MIME-Version: 1.0 To: IETF MARID WG Subject: nits with marid-core-02 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Jay Daley Date: Wed, 21 Jul 2004 09:32:21 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 07/21/2004 09:32:22 AM, Serialize complete at 07/21/2004 09:32:22 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Two small things 1. In 7.2/7.3 and 7.4 why is the use of Resent-From or Sender a SHOULD rather than a MUST? Is there an alternative that would be acceptable and what would be gained by that? 2. Typo in 7.4 first sentence. Says 'than' where it should say 'that'. Jay Daley From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 06:54:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06743 for ; Wed, 21 Jul 2004 06:54:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LAc2Ma065844; Wed, 21 Jul 2004 03:38:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LAc2uY065843; Wed, 21 Jul 2004 03:38:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost4.mail.uk.easynet.net (smarthost4.mail.uk.easynet.net [212.135.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LAc1Ha065830 for ; Wed, 21 Jul 2004 03:38:02 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost4.mail.uk.easynet.net with smtp (Exim 4.10) id 1BnEU6-000K9L-00 for ietf-mxcomp@imc.org; Wed, 21 Jul 2004 11:38:02 +0100 Message-ID: <128301c46f0e$b67b0f80$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: Protocol - Support for internationalization? Date: Wed, 21 Jul 2004 11:37:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: 8bit Referencing: draft-ietf-marid-spf-3-protocol-00.txt Section 5.2 ext: Explanation The explanation string is intended to be displayed to legitimate senders in the form of a short message or URL, via the SMTP receiver. I.e. it is intended to be read by 'end user', probably non-technical, humans. I can't see any support for international characters in the draft. RFC1035 section 3.3.14 (which defines DNS TXT records) appears to delegate the semantics of the text to the using domain/context, and seems to have nothing to say about the encoding of a . If international characters are to be supported there would have to be: (1) Either a specification of the mandatory character set to be used (e.g. Unicode), and the encoding to be used (e.g. UTF-8) or some means of indicating that character set/encoding on a message -specific basis, (1) The details of how code points (characters) in this encoding are to be represented in the DNS TXT record (such as %-escaped UTF-8). The protocol macro language (section 7.1) states that uppercased macros are URL-encoded and references RFC2396. This implies that the URL %HH method of inserting non-ASCII and URL-illegal octet values may (MUST?) be used, but, like RFC2396, says nothing about points (1) and (2) above. There has been a lot of W3C work recently on Internationalised Resource Identifiers (IRI): http://www.w3.org/International/iri-edit/draft-duerst-iri-09.txt Using IRI syntax, if Mike Dürst wanted to put his name into the DNS TXT explanation (the ü has an umlaut) he would encode it in UTF-8 using the % URL escaping as "Mike D%C3%BCrst". Explanations are intended to be used in 'bounces'. The explanations are associated with the domain of the message originator, the bounce message generation is done by the MTA of the receiving domain, so the receiving MTA MUST assume that all explanations are UTF-8 encoded. Note: US-ASCII is a sub-set of UTF-8, so all 'plain english' messages would be correctly represented. The bounce message generator will have to tag _all_ messages containing explanations as using UTF-8 (by using the appropriate message / MIME-part Header). Should the protocol use / reference IRIs and require bounces incorporating originator-supplied explanations to assume the use of UTF-8? Or is there / should there be some other way of supporting internationalized messages? Or is only US-ASCII to be supported? Chris Haynes From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 07:34:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09006 for ; Wed, 21 Jul 2004 07:34:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LBNUgD070704; Wed, 21 Jul 2004 04:23:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LBNUkm070703; Wed, 21 Jul 2004 04:23:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vweb.nass.com.au (vweb.nass.com.au [203.202.24.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LBNRxJ070674 for ; Wed, 21 Jul 2004 04:23:27 -0700 (PDT) (envelope-from davidb@nass.com.au) Received: from localhost (localhost.localdomain [127.0.0.1]) by vweb.nass.com.au (Postfix) with ESMTP id 98D623C9155; Wed, 21 Jul 2004 21:23:51 +1000 (EST) Received: from vweb.nass.com.au ([127.0.0.1]) by localhost (vweb.nass.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31001-02; Wed, 21 Jul 2004 21:23:51 +1000 (EST) Received: from nass3 (bri0.router.nass.com.au [203.25.102.2]) by vweb.nass.com.au (Postfix) with SMTP id 216813C8825; Wed, 21 Jul 2004 21:23:51 +1000 (EST) Message-ID: <042f01c46f15$27ceff10$034aa8c0@nass3> From: "David Beveridge" To: "Terje Petersen" Cc: References: <3CA474173FC0274799F97F3AB3BD25EE1A7802@ltwd-svr2.lightwood.com.au> Subject: Re: MTAs should do what they're good at Date: Wed, 21 Jul 2004 21:23:32 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at nass.com.au Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed Terje wrote > > > In theory an MTA can server up web pages and wash laundry also. However > it's You know what, MTA's today are good at is transmitting spam. Are you suggesting they just stick to that or, do we make some changes. It's all very well to let the MUA block it but what if you get 100 spams to every real email. That means your email costs just got multiplied by 100. Your are not solving the problem by using MUA filtering. And what do you do when the MUA blocks, you can't reject it's too late, so you're going to pester the poor sucker that got joe-jobbed for not publishing spf records. You need to change your thinking from "accept & bounce" to "reject" Rejecting can only be done by the MTA. Rejection puts the emphasis onto the sender to prove their authenticity. dave From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 09:55:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18148 for ; Wed, 21 Jul 2004 09:55:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LDXwva082721; Wed, 21 Jul 2004 06:33:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LDXwKZ082720; Wed, 21 Jul 2004 06:33:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6LDXvUS082714 for ; Wed, 21 Jul 2004 06:33:57 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 21 Jul 2004 09:38:07 -0400 Received: from ([65.2.216.171]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 4227735204; Wed, 21 Jul 2004 09:38:06 -0400 Message-ID: <002501c46f27$46abac00$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" References: <001d01c46ef7$43dde6d0$6401a8c0@hdev1> Subject: Example EPV-CORE MARID Implementation: [ Re: Comments and Concern about MARID-CORE: A Proposal] Date: Wed, 21 Jul 2004 09:33:13 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit To illustration how current framework, here is how the current MARID-CORE framework can be viewed and based on the EPV-CORE-MARID framework to resolve many of our concerns. I emphasise the fact that I am not a "Chair" I am just trying to help. One extremely important point: What I do best is "solve problems." If any of this is taken seriously and it is a approach to further pursue, I would prefer for someone more suitable with an IETF working background to take over this work. If no one else is available, I will accept the challenge. EPV-CORE-MARID - A new open standard MARID core generalized framework based on prior art. o Summary: The current MARID-CORE should allow for a better mouse trap EPV methods. and implementations. To isolate it for a specific invention only introduces a wide range of issues. While a EPV-CORE MARID framework based on SUBMITTER and SENDERID may became the new pseudo and accepted standard, that shouldn't mean that new possible ideas can't replace what should basically be a "plus and play" EPV-CORE framework. The way MARID-CORE is designed now, it stops such process. Who knows? Maybe tomorrow Dave Crocker's CSV proposals will replaced methods used by SMTP software? So EPV-CORE should be the core model for MARID that outlines HOOKS into the system. It should not isolate itself to specific methods and it should consider all End Points, including RCPT TO: If EPV-CORE-MARID framework is adoptted, there will be minimum impact on the current scope, timeline, milestones including Micrososft IP efforts. I propose the following: 1) A reorganization for a generalized, open standard MARID-CORE framework 100% based on prior art. The new MARID-CORE framework based on EPV-CORE removes specific methods and technologies allowing for future MARID end point validation concepts to evolved, 2) Sugggestion split/new MARID working groups: - MARID-EPV-CORE - solidifying, fine tuning a strong open standard generialized framework for EPV - MARID-EPV-SPF/SENDERID - getting a implementation standard for usage. - MARID-EPV-CSV - exploring a future network infrastructure o Background: The MARID-CORE can be modeled as followed using the EPV-CORE framework: EPV = EPV-CORE-MARID(EPVD-MARID) where EPVD-MARID is the process or domain elements: CIP Client IP Address CDN Client Domain Name, HELO/EHLO (RFC2821) AUA Authentication User Access, AUTH (SUBMIT) TRP Transaction Return Address, MAIL FROM (RFC2821) TFP Transaction Forwarding Address, RCPT TO (RFC2821) PRA Purported Responsible Address TPL Transaction Payload, DATA (RFC 2822) DNS Domain Name Server Database Note: TPL includes the SMTP envelope and Received. The EPV-CORE-MARID framework provides a functional model: EPV = EPVM-MARID(EPVM-SUBMITTER, EPVM-SENDERID) where EPV = EPVM-SUBMITTER (EPVD-SUBMITTER) EPV = EPVM-SENDERID (EPVD-SENDERID) where EPVD-SUBMITTER is the SUBMITTER protocol domain data: CIP Client IP Address CDN Client Domain Name, HELO/EHLO (RFC2821) AUA Authentication User Access, AUTH (SUBMIT) TRP Transaction Return Address, MAIL FROM (RFC2821) PRA Purported Responsible Address DNS Domain Name Server Database where EPVD-SENDERID is the SENDERID protocol domain data: TPL Transaction Payload, DATA (RFC 2822) DNS Domain Name Server Database o Implementation: The pseudo code for thie EPMV-MARID model would be: EPV = EPVM-SUBMITTER(EPVD-SUBMITTER) and EPVM-SENDERID (EPVD-SENDERID) The following show the implementation and SMTP integration possibilities with both POST SMTP (old software) and DYNAMIC SMTP (new software) mode of operations. The SMTP state points are shown to gain a perspective of how MARID fits into the SMTP model. The first set is based on current SMTP usage where administrators use MARID in post-SMTP operations: 1.0 - Current SMTP, Post SMTP operations 1.1 - Full MARID support HELO MAIL FROM: RCPT TO: DATA QUIT Post SMTP EPVM-MARID 1.2 - SUBMITTER support only HELO MAIL FROM: RCPT TO: DATA QUIT Post SMTP EPVM-SUBMITTER 1.3 - SENDERID support only HELO MAIL FROM: RCPT TO: DATA QUIT Post SMTP EPVM-SENDERID 2.0 - New SMTP, Dynamic SMTP operations 2.1 - DATA event, full MARID support HELO: MAIL FROM: RCPT TO: DATA EPVM-MARID QUIT Post SMTP 2.2 - MAIL FROM and DATA events, full MARID support HELO: MAIL FROM: EPVM-SUBMITTER RCPT TO: DATA EPVM-SENDERID QUIT Post SMTP 2.3 - MAIL FROM event, SUBMITTER support only HELO: MAIL FROM: EPVM-SUBMITTER RCPT TO: DATA QUIT Post SMTP 2.4 - DATA event, SENDERID support only HELO: MAIL FROM: RCPT TO: DATA EPVM-SENDERID QUIT Post SMTP o Implementation Issues and Problems: Problem #1: Exclusive Technology - stops "better mouse traps" MARID-CORE is locked into using two specific methods with questionable technology and implementations. This stops MARID from growing with new and better "mouse traps." Problem #2: Dependency on PAYLOAD Based on the possible implementations, some may not be compliant with MARID-CORE. This suggests that a system who can not use SUBMITTER must use SENDERID to complete the EPV. Problem #3: IP Conflicts? The reasons for drafting the EPV-CORE framework are: o Outline a prior art generalized EPV framework that models the basic concept of validating end points in a C/S or P2P session. o Escapulate all prior art SMTP process elements into a generalized EPV-CORE SMTP framework. o Illustrate EPV-CORE modeling of current implementations o Provide an open standard framework, o Isolate IP issues outside the basic EPV-CORE framework. Example: Microsoft IP issues regarding SUBMITTER and SENDERID One the main problems with the current MARID framework is its dependency on specific technologies. Ironically, one of the IP issues in question is the SENDERID proposal which seems to gain some sort of "IP" strength based on the introduction of this new MAIL FROM modifier, SUBMITTER, which is currently non-existing in the process space. Microsoft can not claim a right to SUBMITTER for the following reasons: - ESMTP MAIL FROM Modifier SUBMITTER is based on prior art and usage of a ESMTP MAIL FROM modifier. So no IP can be claimed with this mechanism. All that can be possible be claimed is a copyright on the term "SUBMITTER" but the data itself is already within the process space. The PUA (Persistent User Address) is already in the process space which the MSA can automatically use and the AUA (Authentication User Account) can also be used to define this element. The MUA can provide it itself, but the MSA still needs to validate it as well against its own process space. In other words, it is not new "data" which is one basic requirement for a software method patentability - a new piece of information. - Optimization Microsoft documents SUBMITTER as an "Optimization" technique. This is good excellent material for patentability - improving an existing process always gets bonus checks. However, the key words is "existing process." SUBMITTER is based on improving the SENDERID "process" as a way to optimize the SMTP transaction. While it quite conceivable to obtain a patent for the two where one if lacking, the overall concept linking RFC 2821 MAIL FROM with RFC 2822 for optimization is already prior art. RFC 2821 Section 3.3 - "Mail Transactions" Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. In other words, RFC 2821 had the vision to deal with this real "chicken and egg" problem. If Microsoft can make a claim on SUBMITTER/SENDERID for optimization, then it would be possible for other people to make a claim for "optimization" the entire MARID-CORE method as follows: Problem #4: What about other End Point - RCPT TO? Can we try to make an IP claim here with this specific and quite possibly unique Optimization method? Based on the possible implementations, post SMTP MARID operation will have a major bounce problem which contributes to the SORBIG bounce mail distribution problem. The #1 defense against SORBIG is to stop the transaction for non-delivery mail before the payload is accepted. MARID-CORE implies a large dependency on dynamic operations, and hence new designs. It would be illogical for software developers to allocate redesign resources for a new dynamic SMTP implementation of MARID-CORE without considering other optimization ideas. For example: MAIL FROM: EPVM-SUBMITTER RCPT TO: ? DATA EPVM-SENDERID It is illogical to put such a high emphasis on the sender EPV with little to no focus on the receiver EPV. While one might view this as an "implementation" issue, in my view from a MARID-CORE "Framework," the possibility should not be excluded and it isn't in current prior art. For example: One MARID optimization implementation is shown with the EPV-CORE model for the Wildcat! SMTP server (WCSMTP) EPV = EPVM-WCSMTP(EPV-RCPT, EPV-FROM) where EPV-RCPT = EPVM-LUV (TFP, UDB) EPV-FROM = EPMV-WCSAP (CIP, CDN, TRP, TFP, DNS) An alternative WCSMTP functional model representation using a short-circuit conditional statement would be: EPV = EPVM-LUV(TFP,UDB) and EPMV-WCSAP(CIP, CDN, TRP, TFP, DNS) EPVM-LUV is a Local User/Domain Validation to validate the RCPT TO end point. If unsuccessful, the EPVM-WCSAP is bypassed. EPVM-WCSAP offers a suite of sysop optional EPV methods to validate the MAIL FROM end point: EPV-FROM = EPVM-FILTER (CIP, CDN, TRP, TFP) EPV-FROM = EPVM-RBL (CIP, DNS) EPV-FROM = EPVM-SPF (CIP, CDN, TRP, DNS) EPV-FROM = EPVM-MCEP(CIP, TRP, DNS) EPV-FROM = EPVM-CBV (TRP, DNS) where EPVM-FILTER - Internal rule based white/black action list EPVM-RBL - DNS based RBL lookup EPVM-SPF - Sender Policy Framework EPVM-MCEP - Microsoft CallerID Email Policy EPVM-CBV - SMTP based Call back Verifier. The EPVM-WCSMTP model basically adds a local user EPV to RPCT TO before attempting to validate the sender: MAIL FROM: 250 Sender Validation Pending. Continue. RCPT TO: EPVM-LUV(TFP,UDB) and EPMV-WCSAP(CIP, CDN, TRP, TFP, DNS) DATA: If EPV-CORE-MARID is going to be added, the WCSMTP model would will change like so: MAIL FROM: 250 Sender Validation Pending. Continue. RCPT TO: EPVM-LUV(TFP,UDB) and EPMV-WCSAP(CIP, CDN, AUA, PRA, TRP, TFP, DNS) DATA: EPVM-SENDERID (TPL, DNS) And in EPVM-WCSAP, we would replace EPVM-SPF and EPVM-MCEP with EPVM-SUBMITTER: EPV-FROM = EPVM-FILTER (CIP, CDN, TRP, TFP) EPV-FROM = EPVM-RBL (CIP, DNS) EPV-FROM = EPVM-SUBMITTER (CIP, CDN, AUA, PRA, DNS) EPV-FROM = EPVM-CBV (TRP, DNS) I can't patent this MARID-CORE implemention method by throwing in a EPV-LUV() method because RFC 2821 already provides a priort art technical consideration of delaying the "MAIL FROM" EPV until the "RCPT TO" EPV is known. If RFC 2821 did not say this, then there I would a strong basis for patentability (with today relaxed "computer methods" quidelines). -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 11:55:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28990 for ; Wed, 21 Jul 2004 11:55:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LFeaYG095544; Wed, 21 Jul 2004 08:40:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LFeaHa095543; Wed, 21 Jul 2004 08:40:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LFeZgR095537 for ; Wed, 21 Jul 2004 08:40:35 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 21 Jul 2004 08:40:16 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Jul 2004 08:40:38 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jul 2004 08:40:39 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Jul 2004 08:40:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-cc032167-439c-4f13-b4b1-459ba375e978" Subject: RE: Comments on draft-ietf-marid-submitter-02 Date: Wed, 21 Jul 2004 08:40:36 -0700 Message-ID: Thread-Topic: Comments on draft-ietf-marid-submitter-02 thread-index: AcRt2MLYJa73Rp7RQeiIpJQbg45s0wA773Ng From: "Harry Katz" To: "Daryl Odnert" , X-OriginalArrivalTime: 21 Jul 2004 15:40:37.0646 (UTC) FILETIME=[11D8DAE0:01C46F39] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPartTM-000-cc032167-439c-4f13-b4b1-459ba375e978 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46F39.116ACFA5" ------_=_NextPart_001_01C46F39.116ACFA5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Daryl. These are good suggestions. I'll batch these up for the -03 rev which will also include any feedback from the upcoming IETF meeting in a couple of weeks.=20 ________________________________ From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Daryl Odnert Sent: Monday, July 19, 2004 5:30 PM To: 'ietf-mxcomp@imc.org' Subject: Comments on draft-ietf-marid-submitter-02 =09 =09 Greetings, =20 I've got no big technical issues here. Just a couple of suggested wording changes. =20 On page 2: "Deriving the purported responsible domain from RFC 2822 headers has the advantage of basing the sender validation on an identity that can be made visible to the end recipient of the message." I think this needs to be restated. Isn't the advantage here based on an assumption that we don't expect many MUAs to be changed to display the RFC 2821 sender as well as the RFC 2822 sender? I suggest that the sentence should be modified to explain that deriving the PRD from the RFC 2822 headers has the advantage of basing the validation on the identity that is most commonly displayed to recipients by existing MUAs as the sender's identity. =20 On page 4: "This includes messages where the MAIL FROM address is empty or "<>"." The language in RFC 2821 refers to this as a "null reverse-path", not an empty address. I think it would be helpful to be consistent with that language. =20 One final comment: Even though its obvious to everyone who participates in the MARID WG, I think it would be a good idea to add text advising implementers that the presence of the SUBMITTER parameter to the MAIL command MUST NOT change the effective reverse-path of a message. Any delivery status notifications must be sent to the reverse-path, if one exists, as per RFC 2821 section 3.7 regardless of the presence of a SUBMITTER address. If the reverse-path is null, delivery status notifications MUST NOT be sent to the SUBMITTER address. =20 Regards, Daryl Odnert Tumbleweed Communications Redwood City, California daryl.odnert@tumbleweed.com =20 ------_=_NextPart_001_01C46F39.116ACFA5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks=20 Daryl.  These are good suggestions.  I'll batch these up for = the -03=20 rev which will also include any feedback from the upcoming IETF meeting = in a=20 couple of weeks.

From: = owner-ietf-mxcomp@mail.imc.org=20 [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Daryl=20 Odnert
Sent: Monday, July 19, 2004 5:30 PM
To:=20 'ietf-mxcomp@imc.org'
Subject: Comments on=20 draft-ietf-marid-submitter-02

Greetings,
 
I've got no big=20 technical issues here.  Just a couple of suggested wording=20 changes.
 
On = page=20 2: "Deriving the purported responsible domain from RFC 2822 = headers=20 has the advantage of basing the sender validation on an identity that=20 can be made visible to the end recipient of the message." =20 I=20 think this needs to be restated.  Isn't=20 the advantage here based on an assumption that we don't = expect=20 many MUAs to be changed to display the RFC 2821 sender as well as = the RFC=20 2822 sender?  I suggest that the sentence should be modified to = explain=20 that deriving the PRD from the RFC 2822 headers has the advantage of = basing=20 the validation on the identity that is most commonly displayed to = recipients=20 by existing MUAs as the sender's identity.
 
On = page 4:=20 "This includes messages where the MAIL FROM address is empty or=20 "<>"."  The language in RFC 2821 refers to this as = a "null=20 reverse-path", not an empty address.  I think it would be helpful = to be=20 consistent with that language.
 
One final=20 comment: Even though its obvious to everyone who = participates=20 in the MARID WG, I think it would be a good idea to add text = advising=20 implementers that the presence of the SUBMITTER parameter to the MAIL = command=20 MUST NOT change the effective reverse-path of a = message.  Any=20 delivery status notifications must be sent to the reverse-path, = if one=20 exists, as per RFC 2821 section 3.7 regardless of the = presence of a=20 SUBMITTER address.  If the reverse-path is null, delivery status=20 notifications MUST NOT be sent to the SUBMITTER = address.
 
Regards,
Daryl=20 Odnert
Tumbleweed=20 Communications
Redwood City,=20 California
 
= ------_=_NextPart_001_01C46F39.116ACFA5-- ------=_NextPartTM-000-cc032167-439c-4f13-b4b1-459ba375e978-- From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 12:20:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00660 for ; Wed, 21 Jul 2004 12:20:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LG6YTA098208; Wed, 21 Jul 2004 09:06:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LG6YYZ098207; Wed, 21 Jul 2004 09:06:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6LG6XpX098198 for ; Wed, 21 Jul 2004 09:06:34 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 21 Jul 2004 12:10:44 -0400 Received: from ([65.2.216.171]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 4236891985; Wed, 21 Jul 2004 12:10:43 -0400 Message-ID: <005101c46f3c$98492d70$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" References: <001d01c46ef7$43dde6d0$6401a8c0@hdev1> <002501c46f27$46abac00$6401a8c0@hdev1> Subject: Example EPV-CORE CSV Implementation: [ Re: Comments and Concern about MARID-CORE: A Proposal] Date: Wed, 21 Jul 2004 12:05:49 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I wasn't pretty clear on a very fundamental consideration about EPV-CORE. EPV-CORE is based on a concept of having a "BlackBox" EPV capability at each point in the SMTP state machine model: connect EPV = EPVM-CIP(CIP) HELO/EHLO EPV = EPVM-CDN(CIP,CDN) MAIL FROM EPV = EPVM-TRP(CIP,CDN,TRP) RCPT TO EPV = EPVM-TFP(CIP,CDN,TRP,TFP) DATA EPV = EPVM-CDN(CIP,CDN,TRP,TFP,TPL) In general, the EPV has six basic interpretations: epvNone EP is non-deterministic by EPV-METHOD. epvAccept EP was accepted by EPV-METHOD epvReject EP was rejected by EPV-METHOD. epvExpire EP is expired epvAbort Server *SHOULD* abort the transaction. epvError An error was detected by EPV-METHOD. As far as SMTP is concern, it doesn't really matter how that result was achieved as a blackbox model. So for EPV-CORE-MARID, it fits very nicely like so: connect n/a HELO/EHLO EPV = EPVM-MARID-SPF(CIP,CDN) MAIL FROM EPV = EPVM-MARID-SPF(CIP,TRP,PRA) RCPT TO n/a DATA EPV = EPVM-MARID-SENDERID(TPL) The goal of EPV-CORE is to provide a "plug and play" prior art, open standard model so that the internet mail system is not locked into using a technology that a) may not be suitable for the job, b) has other society oriented concerns. If tomorrow we come with a better solution, like CSV or something else, no one is locked in with deprecated methods. For example, using CSV as a possible replacement: connect HELO/EHLO EPV = EPV-CORE-CSV(EPVD-CSV) MAIL FROM RCPT TO DATA Here is how the current CSV framework can be viewed based on a new EPV-CORE-CSV framework: EPV-CORE-CSV: "EPV-CORE Framework for CSV" by Hector Santos o Summary: The current CSV proposal can be remodeled using EPV-CORE framework as followed: EPV = EPV-CORE-CSV (EPVD-CSV) where EPVD-CSV is a set process or domain elements: CIP Client IP Address CDN Client Domain Name, HELO/EHLO (RFC2821) SRV Domain Name Server Database SRV record DNA Authorization/Reputation Service EPV-CORE-CSV provides an CSV functional model based on the result of two CSV protocols; CSA and DNA: EPV-CSV = EPVM-CSV(EPV-DNA, EPV-CSA) where EPV-CSV is the result of the EPVM-CSV method based on the result of EPVM-DNA and EPVM-CSA methods: EPV-DNA = EPVM-DNA (CIP,CDN,DNA,DNS) EPV-CSA = EPVM-CSA (CIP,CDN,DNS) -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 16:03:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19715 for ; Wed, 21 Jul 2004 16:03:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJn8fw020848; Wed, 21 Jul 2004 12:49:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LJn8xj020847; Wed, 21 Jul 2004 12:49:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJn79r020838 for ; Wed, 21 Jul 2004 12:49:08 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17858; Wed, 21 Jul 2004 15:49:09 -0400 (EDT) Message-Id: <200407211949.PAA17858@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-csv-dna-01.txt Date: Wed, 21 Jul 2004 15:49:09 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Domain Name Accreditation (DNA) Author(s) : D. Crocker, et al. Filename : draft-ietf-marid-csv-dna-01.txt Pages : 10 Date : 2004-7-21 Increased diversity and abuse of access, across the open Internet, mandates additional accountability for sending SMTP clients, in the absence of prior, direct arrangement with receiving SMTP servers. One means for enabling this is by registration with third-party services that vouch for the policies and accountability of SMTP clients accessing SMTP servers. This specification defines a means for an SMTP client to list third-party services that are prepared to vouch for it, and a means for an SMTP server, or its intermediary, to query vouching services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-dna-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-csv-dna-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-csv-dna-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-21153304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-csv-dna-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-csv-dna-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153304.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 16:20:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23087 for ; Wed, 21 Jul 2004 16:20:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJmb5R020791; Wed, 21 Jul 2004 12:48:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LJmbcT020790; Wed, 21 Jul 2004 12:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJmb52020783 for ; Wed, 21 Jul 2004 12:48:37 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17731; Wed, 21 Jul 2004 15:48:39 -0400 (EDT) Message-Id: <200407211948.PAA17731@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-csv-intro-01.txt Date: Wed, 21 Jul 2004 15:48:38 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Client SMTP Validation (CSV) Author(s) : D. Crocker, et al. Filename : draft-ietf-marid-csv-intro-01.txt Pages : 15 Date : 2004-7-21 Internet mail relies on exchanges between systems that have made no prior arrangement with each other. Widespread abuse of the email system has led operators to demand accountability for the email their receiving SMTP servers are being asked to process. Client SMTP Validation (CSV) provides an economical service that permits a receiving SMTP server to decide whether a sending SMTP client is likely to produce well-behaved traffic, or at least to decide whether the client is sufficiently accountable for its actions. CSV provides a small, simple and useful improvement to Internet mail service accountability. It builds upon the existing practice of service providers that accredit the networks from which sending systems are connecting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-intro-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-csv-intro-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-csv-intro-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-21153258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-csv-intro-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-csv-intro-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153258.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 16:48:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19716 for ; Wed, 21 Jul 2004 16:03:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJmG9Q020769; Wed, 21 Jul 2004 12:48:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LJmG0Q020768; Wed, 21 Jul 2004 12:48:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJmFin020762 for ; Wed, 21 Jul 2004 12:48:15 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17705; Wed, 21 Jul 2004 15:48:17 -0400 (EDT) Message-Id: <200407211948.PAA17705@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-csv-csa-01.txt Date: Wed, 21 Jul 2004 15:48:17 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Client SMTP Authorization (CSA) Author(s) : D. Otis, et al. Filename : draft-ietf-marid-csv-csa-01.txt Pages : 12 Date : 2004-7-21 Internet operation has typically required no public mechanism for announcing restriction or permission of particular hosts to operate clients or servers for particular services on behalf of particular domains. What is missing is an open, interoperable means by which a trusted agency can announce authorization for a host to operate a service. The current specification supports this capability for sending SMTP clients. Specifically, is a sending SMTP client permitted to act as a client MTA? Has a separate authority given it permission to perform this service? Client SMTP Authorization (CSA) specifies a DNS-based record that states whether an associated host has permission to operate as a client MTA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-csv-csa-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-csv-csa-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-21153252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-csv-csa-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-csv-csa-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153252.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 19:25:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28991 for ; Wed, 21 Jul 2004 19:25:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LNBGNO039875; Wed, 21 Jul 2004 16:11:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LNBG6o039874; Wed, 21 Jul 2004 16:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LNBCqZ039866 for ; Wed, 21 Jul 2004 16:11:15 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MTAs should do what they're good at Date: Thu, 22 Jul 2004 09:11:16 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7803@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LNBGqZ039869 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed Terje wrote > > > In theory an MTA can server up web pages and wash laundry also. However > it's Dave wrote You know what, MTA's today are good at is transmitting spam. Are you suggesting they just stick to that or, do we make some changes. # None of what I am saying is incompatible with stopping spam. # I never said we should not make changes. Its just some changes are # better than other changes. And why make changes that are not necessary # and that break the layered transport model. It's all very well to let the MUA block it but what if you get 100 spams to every real email. That means your email costs just got multiplied by 100. # If there is a SUBMITTER address and SPF records then the MTA can block the email. # If there is no SUBMITTER address or SPF records then the MUA is smothered anyway. Your are not solving the problem by using MUA filtering. # You are if you also do MTA filtering based on SPF records and the # SUBMITTER address. If there is no SUBMITTER address then nothing changes. And what do you do when the MUA blocks, you can't reject it's too late, so you're going to pester the poor sucker that got joe-jobbed for not publishing spf records. # No you don't pester anybody other than SUBMITTER. And if the MTA accepted # the SUBMITTER address as valid due to SPF checks then it is appropriate to # pester the SUBMITTER. You need to change your thinking from "accept & bounce" to "reject" # I never suggested that the message be bounced. Rejecting can only be done by the MTA. Rejection puts the emphasis onto the sender to prove their authenticity. # Yes but if both the SUBMITTER address and the MAIL FROM address passes # authentication at the MTA level there is no reason to reject. # The only thing for the MUA to do is to display SUBMITTER as the SENDER # instead of displaying FROM as the SENDER. From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 20:22:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08791 for ; Wed, 21 Jul 2004 20:22:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M04dWe044201; Wed, 21 Jul 2004 17:04:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M04d0c044200; Wed, 21 Jul 2004 17:04:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vweb.nass.com.au (vweb.nass.com.au [203.202.24.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M04c28044194 for ; Wed, 21 Jul 2004 17:04:38 -0700 (PDT) (envelope-from davidb@nass.com.au) Received: from localhost (localhost.localdomain [127.0.0.1]) by vweb.nass.com.au (Postfix) with ESMTP id 1AB703C928D; Thu, 22 Jul 2004 10:05:21 +1000 (EST) Received: from vweb.nass.com.au ([127.0.0.1]) by localhost (vweb.nass.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10010-10; Thu, 22 Jul 2004 10:05:21 +1000 (EST) Received: from nass3 (bri0.router.nass.com.au [203.25.102.2]) by vweb.nass.com.au (Postfix) with SMTP id A660F3C8864; Thu, 22 Jul 2004 10:05:20 +1000 (EST) Message-ID: <04ac01c46f7f$870c0c60$034aa8c0@nass3> From: "David Beveridge" To: Cc: "Terje Petersen" References: <3CA474173FC0274799F97F3AB3BD25EE1A7801@ltwd-svr2.lightwood.com.au> Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT Date: Thu, 22 Jul 2004 10:04:58 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at nass.com.au Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tuesday Terje wrote > > Currently the MUA displays the FROM address to the end user as being the > originator of the email. Once the SUBMITTER extension is in use then the > MUA can do one of two things to stop phishing:- > > 1. Instead of displaying the FROM address as the originator it can > display the SUBMITTER address. > > Or > > 2. Dump messages where FROM <> SUBMITTER. > I would pefer that the MUA say From SUBMITTER on behalf of FROM And it should reply to FROM unless there is a "Reply-To:" Header. dave. From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 21:12:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18297 for ; Wed, 21 Jul 2004 21:12:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M0wEUU049110; Wed, 21 Jul 2004 17:58:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M0wECX049109; Wed, 21 Jul 2004 17:58:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M0wDtG049100 for ; Wed, 21 Jul 2004 17:58:13 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT Date: Thu, 22 Jul 2004 10:58:17 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7804@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M0wEtG049103 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Currently the MUA displays the FROM address to the end user as being the > originator of the email. Once the SUBMITTER extension is in use then the > MUA can do one of two things to stop phishing:- > > 1. Instead of displaying the FROM address as the originator it can > display the SUBMITTER address. > > Or > > 2. Dump messages where FROM <> SUBMITTER. > I would pefer that the MUA say From SUBMITTER on behalf of FROM And it should reply to FROM unless there is a "Reply-To:" Header. dave. TP> That's nice but SUBMITTER = FROM unless the content is malformed. TP> And SUBMITTER is verified by the MTA using SPF records. TP> So the reply should go to SUBMITTER as its verified as being the TP> real sender. And if the real sender is sending malformed email TP> then they should get any replies in any case. From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 22:18:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24022 for ; Wed, 21 Jul 2004 22:18:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M24xjM055555; Wed, 21 Jul 2004 19:04:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M24xNc055554; Wed, 21 Jul 2004 19:04:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vweb.nass.com.au (vweb.nass.com.au [203.202.24.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M24wdh055548 for ; Wed, 21 Jul 2004 19:04:58 -0700 (PDT) (envelope-from davidb@nass.com.au) Received: from localhost (localhost.localdomain [127.0.0.1]) by vweb.nass.com.au (Postfix) with ESMTP id 68AD53C9312; Thu, 22 Jul 2004 12:05:42 +1000 (EST) Received: from vweb.nass.com.au ([127.0.0.1]) by localhost (vweb.nass.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13267-01; Thu, 22 Jul 2004 12:05:42 +1000 (EST) Received: from nass3 (bri0.router.nass.com.au [203.25.102.2]) by vweb.nass.com.au (Postfix) with SMTP id E98243C928D; Thu, 22 Jul 2004 12:05:41 +1000 (EST) Message-ID: <04dc01c46f90$5703d820$034aa8c0@nass3> From: "David Beveridge" To: Cc: "Terje Petersen" References: <3CA474173FC0274799F97F3AB3BD25EE1A7804@ltwd-svr2.lightwood.com.au> Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT Date: Thu, 22 Jul 2004 12:05:19 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at nass.com.au Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday Terje wrote: > > TP> That's nice but SUBMITTER = FROM unless the content is malformed. Not always, I host a web page with a payment gateway for my customer. My web server contacts the bank with all the details to process the transaction. Then the bank (SUBMITTER) sends an email on my behalf (FROM ME) to my customer confirming the transaction. > TP> And SUBMITTER is verified by the MTA using SPF records. > TP> So the reply should go to SUBMITTER as its verified as being the > TP> real sender. And if the real sender is sending malformed email > TP> then they should get any replies in any case. I want my customer to reply to me, not the banks computer. dave. From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 22:22:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24212 for ; Wed, 21 Jul 2004 22:22:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M27T6h055691; Wed, 21 Jul 2004 19:07:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M27TNG055690; Wed, 21 Jul 2004 19:07:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M27Slh055633 for ; Wed, 21 Jul 2004 19:07:28 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i6M26nOv030561; Wed, 21 Jul 2004 19:06:50 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Andrew Newton From: Marshall Rose Subject: MARID agenda for IETF60 Date: Wed, 21 Jul 2004 19:06:42 -0700 To: MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Wednesday, August 4 2004 0900-1130 1. Agenda bashing 2. Review and discussion of draft-ietf-marid-submitter-02 3. Review and discussion of draft-ietf-marid-protocol-00 - semantics and backwards-compatibility Wednesday, August 4 2004 1530-1730 4. Intellectual property discussion 5. Review and discussion of draft-ietf-marid-core-02 - PRA algorithm refinement 6. Discuss milestones for CSV series of documents ####### From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 22:52:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26150 for ; Wed, 21 Jul 2004 22:52:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M2cvVp057732; Wed, 21 Jul 2004 19:38:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M2cvxY057731; Wed, 21 Jul 2004 19:38:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M2cubh057725 for ; Wed, 21 Jul 2004 19:38:56 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT Date: Thu, 22 Jul 2004 12:39:01 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7806@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M2cvbh057726 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----Original Message----- From: David Beveridge [mailto:davidb@nass.com.au] Sent: Thursday, 22 July 2004 12:05 PM To: ietf-mxcomp@imc.org Cc: Terje Petersen Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT On Thursday Terje wrote: > > TP> That's nice but SUBMITTER = FROM unless the content is malformed. Not always, I host a web page with a payment gateway for my customer. My web server contacts the bank with all the details to process the transaction. Then the bank (SUBMITTER) sends an email on my behalf (FROM ME) to my customer confirming the transaction. TP# Well the current proposal on the table is that MTAs should reject email TP# if SUBMITTER and FROM are not the same. If you have a beef with that TP# idea then it's much bigger than what I was talking about in relation to TP# what the MUA should be doing. TP# Are you sure you are not thinking of the MAIL FROM address. Certainly TP# the MAIL FROM address can differ from the SUBMITTER address. However TP# MAIL FROM is SPF checked by the MTA. > TP> And SUBMITTER is verified by the MTA using SPF records. > TP> So the reply should go to SUBMITTER as its verified as being the > TP> real sender. And if the real sender is sending malformed email > TP> then they should get any replies in any case. I want my customer to reply to me, not the banks computer. TP# This has nothing to do with whether checking is done by the MTA or TP# or the MUA. TP# It seems you want the bank should put your address as the SUBMITTER. TP# And they should put their address in the MAIL FROM section. TP# Then your SPF records will need to permit them to do this. From owner-ietf-mxcomp@mail.imc.org Wed Jul 21 23:24:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28443 for ; Wed, 21 Jul 2004 23:24:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M3BvYD059747; Wed, 21 Jul 2004 20:11:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M3BvuJ059746; Wed, 21 Jul 2004 20:11:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M3Brb3059727 for ; Wed, 21 Jul 2004 20:11:56 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: I-D ACTION:draft-ietf-marid-submitter-02.txt Date: Thu, 22 Jul 2004 13:11:58 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7807@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M3Bub3059740 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, 21 July 2004 6:16 AM To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org Subject: I-D ACTION:draft-ietf-marid-submitter-02.txt ~~~~~~~ The section of the proposed SUBMITTER standard that I would change is in part 4.2. Currently the last paragraph of that section reads:- Verifying MTAs are strongly urged to validate the SUBMITTER parameter against the RFC 2822 headers; otherwise, an attacker can trivially defeat the algorithm. I would change this text to say:- When a SUBMITTER parameter is provided then receiving MUAs SHOULD display the SUBMITTER parameter as the sender of the email instead of the original FROM address in the RFS 2822 headers; otherwise an attacker can trivially defeat the algorithm by providing a different SUBMITTER and FROM address. This does not prevent people from developing proprietary email gateways that do this level of header checking also. Rejecting email on the basis of malformed content or headers is an existing option for administrators and nothing in the modification I have suggested takes away this local policy option. I just don't want to see MTAs reading the DATA section as a standardised practice. From owner-ietf-mxcomp@mail.imc.org Thu Jul 22 01:10:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04564 for ; Thu, 22 Jul 2004 01:10:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M4s01k066797; Wed, 21 Jul 2004 21:54:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M4s02q066796; Wed, 21 Jul 2004 21:54:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vweb.nass.com.au (vweb.nass.com.au [203.202.24.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M4rtid066786 for ; Wed, 21 Jul 2004 21:53:57 -0700 (PDT) (envelope-from davidb@nass.com.au) Received: from localhost (localhost.localdomain [127.0.0.1]) by vweb.nass.com.au (Postfix) with ESMTP id 5E7433C93E1; Thu, 22 Jul 2004 14:54:41 +1000 (EST) Received: from vweb.nass.com.au ([127.0.0.1]) by localhost (vweb.nass.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15745-10; Thu, 22 Jul 2004 14:54:41 +1000 (EST) Received: from nass3 (bri0.router.nass.com.au [203.25.102.2]) by vweb.nass.com.au (Postfix) with SMTP id F0C803C885D; Thu, 22 Jul 2004 14:54:40 +1000 (EST) Message-ID: <050201c46fa7$f16d24e0$034aa8c0@nass3> From: "David Beveridge" To: Cc: "Terje Petersen" References: <3CA474173FC0274799F97F3AB3BD25EE1A7806@ltwd-svr2.lightwood.com.au> Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT Date: Thu, 22 Jul 2004 14:54:16 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at nass.com.au Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > TP# Are you sure you are not thinking of the MAIL FROM address. > Certainly > TP# the MAIL FROM address can differ from the SUBMITTER address. However > Ah yes, that is what I was thinking. dave From owner-ietf-mxcomp@mail.imc.org Thu Jul 22 05:05:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02037 for ; Thu, 22 Jul 2004 05:05:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M8pVTk055808; Thu, 22 Jul 2004 01:51:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M8pVbd055807; Thu, 22 Jul 2004 01:51:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M8pShD055768 for ; Thu, 22 Jul 2004 01:51:28 -0700 (PDT) (envelope-from roy+dated+1093078284.d774d0@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i6M8pOWE057349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 22 Jul 2004 08:51:25 GMT (envelope-from roy+dated+1093078284.d774d0@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i6M8pOMj064491 for ; Thu, 22 Jul 2004 09:51:24 +0100 (BST) (envelope-from roy+dated+1093078284.d774d0@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i6M8pORa064490 for ietf-mxcomp@imc.org; Thu, 22 Jul 2004 09:51:24 +0100 (BST) (envelope-from roy+dated+1093078284.d774d0@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 22 Jul 2004 09:51:20 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16639.32775.866966.859072@giles.gnomon.org.uk> Date: Thu, 22 Jul 2004 09:51:19 +0100 To: "Terje Petersen" Cc: Subject: RE: I-D ACTION:draft-ietf-marid-submitter-02.txt In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A7807@ltwd-svr2.lightwood.com.au> References: <3CA474173FC0274799F97F3AB3BD25EE1A7807@ltwd-svr2.lightwood.com.au> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Terje" == Terje Petersen writes: Terje> When a SUBMITTER parameter is provided then receiving Terje> MUAs SHOULD display the SUBMITTER parameter as the sender Terje> of the email instead of the original FROM address in the Terje> RFS 2822 headers; otherwise an attacker can trivially Terje> defeat the algorithm by providing a different SUBMITTER and Terje> FROM address. But SUBMITTER is a parameter to an SMTP command. How would the MUA get to see it? -roy From owner-ietf-mxcomp@mail.imc.org Thu Jul 22 08:10:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13697 for ; Thu, 22 Jul 2004 08:10:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MBt5H9004653; Thu, 22 Jul 2004 04:55:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MBt50S004652; Thu, 22 Jul 2004 04:55:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MBt3C2004644 for ; Thu, 22 Jul 2004 04:55:04 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: I-D ACTION:draft-ietf-marid-submitter-02.txt Date: Thu, 22 Jul 2004 21:55:03 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7808@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6MBt5C2004647 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----Original Message----- From: Roy Badami Sent: Thursday, 22 July 2004 6:51 PM To: Terje Petersen Cc: ietf-mxcomp@imc.org Subject: RE: I-D ACTION:draft-ietf-marid-submitter-02.txt >>>>> "Terje" == Terje Petersen writes: Terje> When a SUBMITTER parameter is provided then receiving Terje> MUAs SHOULD display the SUBMITTER parameter as the sender Terje> of the email instead of the original FROM address in the Terje> RFS 2822 headers; otherwise an attacker can trivially Terje> defeat the algorithm by providing a different SUBMITTER and Terje> FROM address. But SUBMITTER is a parameter to an SMTP command. How would the MUA get to see it? -roy ~~~~~~ It would be written in the headers by the most recent MTA to receive the e-mail. Currently if you can send an email with no headers then the receiving MTA will take the MAIL FROM address and add it as a FROM address in the headers so it becomes available to the MUA. The same would be true for the SUBMITTER parameter which is written to the header also. All be it using a slightly different syntax. MUAs already have to grovel in the headers to find the FROM address. Making the MUA grovel for the SUBMITTER address is not really that different. From owner-ietf-mxcomp@mail.imc.org Thu Jul 22 09:33:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19408 for ; Thu, 22 Jul 2004 09:33:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MDHgca012471; Thu, 22 Jul 2004 06:17:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MDHgWM012470; Thu, 22 Jul 2004 06:17:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org ([168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MDHg4a012431 for ; Thu, 22 Jul 2004 06:17:42 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id 404ED41497 for ; Thu, 22 Jul 2004 06:17:14 -0700 (PDT) Received: from 206.165.46.141 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Thu, 22 Jul 2004 06:17:14 -0700 (PDT) Message-ID: <3051.206.165.46.141.1090502234.squirrel@harry.mail-abuse.org> Date: Thu, 22 Jul 2004 06:17:14 -0700 (PDT) Subject: RE: I-D ACTION:draft-ietf-marid-core-02.txt From: "Douglas Otis" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt It would appear information was removed regarding the maximal number of DNS queries allowed and the time limit for these queries. Is there an expectation these limits are to be individual choices? In the security section, should there not be mention of this and likely attack mechanisms, such as risk of DDoS when publishing "open" records with wildcard, etc. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jul 22 11:41:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00187 for ; Thu, 22 Jul 2004 11:41:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFNIlh025444; Thu, 22 Jul 2004 08:23:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MFNIa4025443; Thu, 22 Jul 2004 08:23:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFNIOt025435 for ; Thu, 22 Jul 2004 08:23:18 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id DFDEB40EF for ; Thu, 22 Jul 2004 08:23:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <3051.206.165.46.141.1090502234.squirrel@harry.mail-abuse.org> References: <3051.206.165.46.141.1090502234.squirrel@harry.mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <169D9BA1-DBF3-11D8-896F-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: I-D ACTION:draft-ietf-marid-core-02.txt Date: Thu, 22 Jul 2004 08:23:31 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 22, 2004, at 6:17 AM, Douglas Otis wrote: > It would appear information was removed regarding the maximal number of > DNS queries allowed and the time limit for these queries. Is there an > expectation these limits are to be individual choices? This information was moved to the draft-ietf-marid-protocol-00.txt, which is the draft that deals with making DNS queries. Furthermore, the limits have been reduced from prior drafts we had written. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Thu Jul 22 15:17:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17978 for ; Thu, 22 Jul 2004 15:17:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MJ2oDx043760; Thu, 22 Jul 2004 12:02:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MJ2o7w043759; Thu, 22 Jul 2004 12:02:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MJ2mq5043750 for ; Thu, 22 Jul 2004 12:02:48 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6MJ2mi24690; Thu, 22 Jul 2004 12:02:48 -0700 Date: Thu, 22 Jul 2004 12:02:43 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1054704811.20040722120243@brandenburg.com> To: "Terje Petersen" CC: ietf-mxcomp@imc.org Subject: Re: I-D ACTION:draft-ietf-marid-submitter-02.txt In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A7807@ltwd-svr2.lightwood.com.au> References: <3CA474173FC0274799F97F3AB3BD25EE1A7807@ltwd-svr2.lightwood.com.au> 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 Terje, TP> When a SUBMITTER parameter is provided then receiving MUAs SHOULD TP> display the SUBMITTER parameter as the sender of the email instead TP> of the original FROM address in the RFS 2822 headers; otherwise an TP> attacker can trivially defeat the algorithm by providing a different TP> SUBMITTER and FROM address. SUBMITTER is related to rfc2822.Sender, not rfc2822.From. The concern for display to the user is certainly valid. However bypassing the From field creates more problems than it solves. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jul 22 21:21:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06752 for ; Thu, 22 Jul 2004 21:21:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N17jbK075993; Thu, 22 Jul 2004 18:07:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6N17jQQ075992; Thu, 22 Jul 2004 18:07:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N17fBK075985 for ; Thu, 22 Jul 2004 18:07:44 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: I-D ACTION:draft-ietf-marid-submitter-02.txt Date: Fri, 23 Jul 2004 11:07:45 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7809@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6N17iBK075987 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Friday, 23 July 2004 5:03 AM To: Terje Petersen Cc: ietf-mxcomp@imc.org Subject: Re: I-D ACTION:draft-ietf-marid-submitter-02.txt Terje, TP> When a SUBMITTER parameter is provided then receiving MUAs SHOULD TP> display the SUBMITTER parameter as the sender of the email instead TP> of the original FROM address in the RFS 2822 headers; otherwise an TP> attacker can trivially defeat the algorithm by providing a different TP> SUBMITTER and FROM address. SUBMITTER is related to rfc2822.Sender, not rfc2822.From. The concern for display to the user is certainly valid. However bypassing the From field creates more problems than it solves. Dave Crocker -- -------------------- TP> My understanding is that in all properly formed email the TP> SUBMITTER address MUST equal rfc2822.From. TP> That being the case there should be no problem displaying TP> SUBMITTER as the from address. TP> If they are not equal the email is malformed and displaying TP> SUBMITTER just compensates for the malformed trick that the TP> sender is trying to conduct. From owner-ietf-mxcomp@mail.imc.org Fri Jul 23 00:37:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29574 for ; Fri, 23 Jul 2004 00:37:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N4NbYf094821; Thu, 22 Jul 2004 21:23:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6N4NbMY094820; Thu, 22 Jul 2004 21:23:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6N4NYZE094813 for ; Thu, 22 Jul 2004 21:23:34 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 23 Jul 2004 00:27:42 -0400 Received: from ([65.2.205.223]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 72542376; Fri, 23 Jul 2004 00:27:40 -0400 Message-ID: <00bb01c4706c$b3304340$6401a8c0@hdev1> From: "Hector Santos" To: "Jim Lyon" , "Terje Petersen" , References: <81AC085044D04B429F5FB883D94FA1AF63DE3C@df-fido-msg.exchange.corp.microsoft.com> Subject: Bounce Address MUST BE VERIFIABLE! [Re: MTAs should focus on email TRANSPORT not email CONTENT] Date: Fri, 23 Jul 2004 00:22:40 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jim Lyon" To: "Terje Petersen" ; Sent: Monday, July 19, 2004 9:30 PM Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT > However, MARID's job is to verify the identity of the sender of a > message, and the sender isn't expressed anywhere except in the message > body. That's exactly why the PRA algorithm exists: to determine who > sent the message. But you are not verifying the sender address, only the sender domain. What about the full email address? > The mis-named "MAIL FROM:" doesn't tell you who sent the message, but > who wants to receive the bounce if any. Much confusion would have been > avoided if the 2821 command were spelled "MAIL BOUNCETO:". Many people, > including me, have gone down the path of erroneously trying to use "MAIL > FROM:" for authentication. Are you saying the BOUNCE ADDRESS is not verifiable? That is completely illogical. The problem is the "change of identity." Not that it is "erroneous" for authentication. Look, you can guarantee the SMTP elements will be there: IP HELO MAIL FROM RCPT TO You can NOT GUARANTEE what the PAYLOAD will look like! Regardless of WHO creates the mail, what the PAYLOAD will look like, WHO sends it, it MUST comply with SMTP! Period! You logic is conflictive because the basic reasoning of the PRA in the first place is based on the idea that the user "wants to see who sent" the message. Well, if you are talking about "users" then the 2821 MAIL FROM will typically be user's address and hence where the bounce goes to. The problem is with "change of identity" which your documented illustrates. Nonetheless, the BOUNCE address regardless of who it is, the Author or the Messenger (sender) it *MUST* be valid . Before the USER can get the message, the BOUNCE address must be valid! I truly hope you don't see this as a "bash." No, not at all. But I must say I am extremely disappointing with where this is headed. In my strong assessment, it is an illogical design that will guarantee us more security and performance problems than you care to believe or acknowledge. Microsoft has ignores "ethical programming" in the past by allowing storage and execution of remote code on a local machine in the name of "integration" and look what that got us - major security problems. I see this going down the same path and once the main stream begin seeing this in practice, the booboo will hit the fan. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Fri Jul 23 00:42:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29773 for ; Fri, 23 Jul 2004 00:42:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N4XQ0p095200; Thu, 22 Jul 2004 21:33:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6N4XQJb095199; Thu, 22 Jul 2004 21:33:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6N4XQnn095192 for ; Thu, 22 Jul 2004 21:33:26 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 23 Jul 2004 00:37:44 -0400 Received: from ([65.2.205.223]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 73145236; Fri, 23 Jul 2004 00:37:43 -0400 Message-ID: <00c101c4706e$1a808400$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "Jim Lyon" Cc: References: <81AC085044D04B429F5FB883D94FA1AF63DE3C@df-fido-msg.exchange.corp.microsoft.com> <1679192673.20040719235514@brandenburg.com> Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT Date: Fri, 23 Jul 2004 00:32:43 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Who cares what it means or what the original intent was! It still must be verifiable! If the industry has Time Square neon flashing advertisements saying the "60-80% of the MAIL FROM: address is BAD," it is completely boggles the mind as to why everyone is ignoring it in the name of what the darn user will see!!! Your proposal is based on a verifiable client domain name. Why can't the MAIL FROM be verifier? Even it is a bounce address? Why must one 1 of 2 inputs be valid and not the second? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Dave Crocker" To: "Jim Lyon" Cc: Sent: Tuesday, July 20, 2004 2:55 AM Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT > > Jim, > > JL> The mis-named "MAIL FROM:" doesn't tell you who sent the message, but > JL> who wants to receive the bounce if any. Much confusion would have been > JL> avoided if the 2821 command were spelled "MAIL BOUNCETO:". Many people, > JL> including me, have gone down the path of erroneously trying to use "MAIL > JL> FROM:" for authentication. > > > given that the misnomer dates back to rfc 821, it's rather impressive > that it took more than 20 years for us to notice the error! > > in an odd way, this highlights the difficulty of preventing scaling > problems. > From owner-ietf-mxcomp@mail.imc.org Fri Jul 23 12:14:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05968 for ; Fri, 23 Jul 2004 12:14:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NFxCXn044991; Fri, 23 Jul 2004 08:59:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6NFxCSE044990; Fri, 23 Jul 2004 08:59:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp-mx-02.ti.local (host191180.arnet.net.ar [200.45.191.180] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NFxBcx044962 for ; Fri, 23 Jul 2004 08:59:12 -0700 (PDT) (envelope-from Internet-Drafts@ietf.org) Received: from mail pickup service by smtp-mx-02.ti.local with Microsoft SMTPSVC; Fri, 23 Jul 2004 12:58:50 -0300 Received: from qsmtp-mx-01.arnet.com.ar ([200.45.191.164]) by smtp-mx-02.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jul 2004 21:37:40 -0300 Received: (qmail 28387 invoked from network); 21 Jul 2004 23:22:28 -0000 Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by host191164.arnet.net.ar with SMTP; 21 Jul 2004 23:22:26 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnOwC-0003jR-VZ; Wed, 21 Jul 2004 17:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnN4d-0000k5-Mo for i-d-announce@megatron.ietf.org; Wed, 21 Jul 2004 15:48:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17705; Wed, 21 Jul 2004 15:48:17 -0400 (EDT) Message-Id: <200407211948.PAA17705@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 21 Jul 2004 15:48:17 -0400 Cc: ietf-mxcomp@imc.org Subject: I-D ACTION:draft-ietf-marid-csv-csa-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-OriginalArrivalTime: 22 Jul 2004 00:37:40.0655 (UTC) FILETIME=[1841D3F0:01C46F84] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Client SMTP Authorization (CSA) Author(s) : D. Otis, et al. Filename : draft-ietf-marid-csv-csa-01.txt Pages : 12 Date : 2004-7-21 Internet operation has typically required no public mechanism for announcing restriction or permission of particular hosts to operate clients or servers for particular services on behalf of particular domains. What is missing is an open, interoperable means by which a trusted agency can announce authorization for a host to operate a service. The current specification supports this capability for sending SMTP clients. Specifically, is a sending SMTP client permitted to act as a client MTA? Has a separate authority given it permission to perform this service? Client SMTP Authorization (CSA) specifies a DNS-based record that states whether an associated host has permission to operate as a client MTA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-csv-csa-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-csv-csa-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-21153252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-csv-csa-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-csv-csa-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153252.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ietf-mxcomp@mail.imc.org Fri Jul 23 21:36:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08897 for ; Fri, 23 Jul 2004 21:36:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O1Kjab079841; Fri, 23 Jul 2004 18:20:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6O1Kjl0079840; Fri, 23 Jul 2004 18:20:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O1Ki6N079831 for ; Fri, 23 Jul 2004 18:20:44 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id C4E65414B5; Fri, 23 Jul 2004 18:20:48 -0700 (PDT) Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT From: Douglas Otis To: Hector Santos Cc: Dave Crocker , Jim Lyon , MARID In-Reply-To: <00c101c4706e$1a808400$6401a8c0@hdev1> References: <81AC085044D04B429F5FB883D94FA1AF63DE3C@df-fido-msg.exchange.corp.microsoft.com> <1679192673.20040719235514@brandenburg.com> <00c101c4706e$1a808400$6401a8c0@hdev1> Content-Type: text/plain Message-Id: <1090632047.31696.598.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 23 Jul 2004 18:20:48 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-22 at 21:32, Hector Santos wrote: > Who cares what it means or what the original intent was! It still must be > verifiable! > > If the industry has Time Square neon flashing advertisements saying the > "60-80% of the MAIL FROM: address is BAD," it is completely boggles the > mind as to why everyone is ignoring it in the name of what the darn user > will see!!! > > Your proposal is based on a verifiable client domain name. Why can't the > MAIL FROM be verifier? Even it is a bounce address? Why must one 1 of 2 > inputs be valid and not the second? The RFC 2822 identities being checked are also often not seen by the user. As with with the expression of having two lawyers arriving at three opinions, the definition of who actually sent the mail is not concerned with the question who authored the message either. The return error path is unrelated to the author as is the sender in many cases. The advantage using the RFC 2821 MAIL FROM, is less confusion over what is being checked and what piece of information adds to any assurances. Another important aspect of the RFC 2821 MAIL FROM is that it is used to sneak into the back door of sites that block with IP based accreditation services using those sites that don't. Blocking with name based accreditation, this blocking figure could approach 100% as such could become very aggressive in a safe manner. This accreditation could also declare the age of the domain. To do this, authentication and authorization of the MTA by the controlling domain is vital. The Core specification fails to provide that information. The submitter specification fails to provide that information. These are filtering inputs only. What is important varies depending upon what is being accomplished. If to accredit the polices of the MTA, the HELO domain must be authenticated and authorized. If to close the back door on the bounce traffic, then the RFC 2821 MAIL FROM should be checked. I suspect the BATV proposal could include an option to allow use of the CIDR notation to specify legal Return paths in addition to a signature. If you wish to filter the messages, then the RFC 2822 identities play a role, but filtering is an inherently bad choice to control the problem. Filtering is a cause for the loss of mail integrity. The goal should be to put the burden upon the sender to keep their accreditation high to be accepted, rather than expecting the receiver to filter junk that continues to enter unabated. Desirable mail gets discarded in the filtering process only because it is impossible to recognize spam from desirable mail in many case. Dave Crocker's Bounce Address Tag Validation can solve this back door problem. If done using public key encryption methods, it can be used to block this traffic before being bounced. It can also be used to exclude traffic completely forged. The down side, if you wish to call it that, is that it can be susceptible to 'replay' attacks. By using a time stamp, any replay can be filtered and would only need to be stored in a filter list for the duration of the key life of perhaps 10 days. Sender ID offers a means to continue phishing by playing games with the PRA, which users are likely not to understand, and which there is likely a means to find differences between interpretations of what is being checked and presented, owing to the complexity of the task. Such differences alone will offer ample opportunity to phish. As the user will likely continue to focus on the RFC 2822 From, the ability to confuse the user remains. It is already amusing the SPF records are to be used "as is" which are based upon the RFC 2821 return path. Should there be a desire not to agree to the contract offered by Microsoft, the use of the RFC 2821 MAIL FROM over the same record set is still possible. What is being checked? The error return path? The sender? Does it make a difference, as it is not the author that is being checked and that is what people will likely be looking at. Something like Identified Internet Mail answers the question, is this the author and is this their message? Frankly, other than selling a filtering MUA, I can not see much use for the RFC 2822 checking stuff. -Doug > -- > Hector Santos, Santronics Software, Inc. > http://www.santronics.com > > ----- Original Message ----- > From: "Dave Crocker" > To: "Jim Lyon" > Cc: > Sent: Tuesday, July 20, 2004 2:55 AM > Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT > > > Jim, > > > > JL> The mis-named "MAIL FROM:" doesn't tell you who sent the message, but > > JL> who wants to receive the bounce if any. Much confusion would have been > > JL> avoided if the 2821 command were spelled "MAIL BOUNCETO:". Many people, > > JL> including me, have gone down the path of erroneously trying to use "MAIL > > JL> FROM:" for authentication. > > > > > > given that the misnomer dates back to rfc 821, it's rather impressive > > that it took more than 20 years for us to notice the error! > > > > in an odd way, this highlights the difficulty of preventing scaling > > problems. > > > From owner-ietf-mxcomp@mail.imc.org Fri Jul 23 21:38:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08990 for ; Fri, 23 Jul 2004 21:38:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O1MYAU079933; Fri, 23 Jul 2004 18:22:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6O1MYfw079932; Fri, 23 Jul 2004 18:22:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O1MWqp079925 for ; Fri, 23 Jul 2004 18:22:33 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 2D483132CD1; Fri, 23 Jul 2004 21:22:39 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id AFC1061F; Fri, 23 Jul 2004 21:22:35 -0400 (EDT) Date: Fri, 23 Jul 2004 21:22:35 -0400 From: Meng Weng Wong To: Chris Haynes Cc: IETF MARID WG Subject: Re: Protocol - Support for internationalization? Message-ID: <20040724012235.GG16317@dumbo.pobox.com> References: <128301c46f0e$b67b0f80$0200000a@ringo> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <128301c46f0e$b67b0f80$0200000a@ringo> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, Jul 21, 2004 at 11:37:18AM +0100, Chris Haynes wrote: | | The explanation string is intended to be displayed to legitimate senders in the | form of a short message or URL, via the SMTP receiver. | | I can't see any support for international characters in the draft. Are you saying that the URL encoding scheme with %HH is not sufficient to express international characters? If so, can you suggest some new language that would satisfy you and would be reasonably backward compatible with what is in the draft? If it is good enough we could paste that in. Thank you for bringing the IRI documents to our attention. If we were to use that as a normative reference we would need to wait for it to become an RFC. thanks. | There has been a lot of W3C work recently on Internationalised Resource | Identifiers (IRI): | http://www.w3.org/International/iri-edit/draft-duerst-iri-09.txt | | Using IRI syntax, if Mike Dürst wanted to put his name into the DNS TXT | explanation (the ü has an umlaut) he would encode it in UTF-8 using the % URL | escaping as | "Mike D%C3%BCrst". From owner-ietf-mxcomp@mail.imc.org Sat Jul 24 14:31:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03603 for ; Sat, 24 Jul 2004 14:31:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OIIpmb045834; Sat, 24 Jul 2004 11:18:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6OIIpKR045833; Sat, 24 Jul 2004 11:18:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp-mx-05.ti.local (host191180.arnet.net.ar [200.45.191.180] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OIIngq045808 for ; Sat, 24 Jul 2004 11:18:50 -0700 (PDT) (envelope-from Internet-Drafts@ietf.org) Received: from smtp-mx-04.ti.local ([192.168.220.23]) by smtp-mx-05.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Jul 2004 15:18:21 -0300 Received: from mail pickup service by smtp-mx-04.ti.local with Microsoft SMTPSVC; Sat, 24 Jul 2004 15:18:19 -0300 Received: from qsmtp-mx-04.arnet.com.ar ([200.45.191.167]) by smtp-mx-04.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jul 2004 20:45:48 -0300 Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by host191167.arnet.net.ar with SMTP; 21 Jul 2004 23:43:12 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnOwH-0003kD-MJ; Wed, 21 Jul 2004 17:47:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnN5U-00014k-1v for i-d-announce@megatron.ietf.org; Wed, 21 Jul 2004 15:49:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17858; Wed, 21 Jul 2004 15:49:09 -0400 (EDT) Message-Id: <200407211949.PAA17858@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 21 Jul 2004 15:49:09 -0400 Cc: ietf-mxcomp@imc.org Subject: I-D ACTION:draft-ietf-marid-csv-dna-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-OriginalArrivalTime: 21 Jul 2004 23:45:48.0867 (UTC) FILETIME=[D97CA930:01C46F7C] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Domain Name Accreditation (DNA) Author(s) : D. Crocker, et al. Filename : draft-ietf-marid-csv-dna-01.txt Pages : 10 Date : 2004-7-21 Increased diversity and abuse of access, across the open Internet, mandates additional accountability for sending SMTP clients, in the absence of prior, direct arrangement with receiving SMTP servers. One means for enabling this is by registration with third-party services that vouch for the policies and accountability of SMTP clients accessing SMTP servers. This specification defines a means for an SMTP client to list third-party services that are prepared to vouch for it, and a means for an SMTP server, or its intermediary, to query vouching services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-dna-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-csv-dna-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-csv-dna-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-21153304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-csv-dna-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-csv-dna-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153304.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ietf-mxcomp@mail.imc.org Sat Jul 24 15:56:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08587 for ; Sat, 24 Jul 2004 15:56:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJhLDp051106; Sat, 24 Jul 2004 12:43:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6OJhL1C051105; Sat, 24 Jul 2004 12:43:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJhKYo051090 for ; Sat, 24 Jul 2004 12:43:20 -0700 (PDT) (envelope-from rms@gnu.org) Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BoSQT-0001A9-D5; Sat, 24 Jul 2004 15:43:21 -0400 From: Richard Stallman To: Michel Bouissou To: "IETF MARID WG" cc: team@fsfeurope.org Subject: Sender-ID and free software Reply-to: rms@gnu.org Message-Id: Date: Sat, 24 Jul 2004 15:43:21 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (Michel, I am not a member of this list, so would you please forward my message if it does not go through?) Microsoft's Sender-ID license is directly incompatible with free software regardless of which free software license is used. Free software means users are free to run it, study and modify the source, and to redistribute it with or without changes. Free to do so means there is no requirement to ask or tell anyone that you are doing so. The Microsoft license for Sender-ID directly forbids release of software with all these freedoms, so it is impossible for any program to be free software under Microsoft's regime. I've been expecting to see something like this ever since Gates started talking about spam. This license is an example of Microsoft's strategy for killing off free software as an alternative to Windows. Microsoft first patents something, then incorporates it into a format or protocol, then tries to make it de rigueur while excluding those it wishes to exclude. In the absence of resistance, Microsoft has a good chance of imposing whatever standards it likes. Let us, therefore, resist it here and now. From owner-ietf-mxcomp@mail.imc.org Sat Jul 24 17:35:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13065 for ; Sat, 24 Jul 2004 17:35:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OLNtU0057994; Sat, 24 Jul 2004 14:23:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6OLNtvb057993; Sat, 24 Jul 2004 14:23:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OLNsJd057986 for ; Sat, 24 Jul 2004 14:23:54 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id 240B141497; Sat, 24 Jul 2004 14:23:54 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 24 Jul 2004 14:23:54 -0700 (PDT) Message-ID: <3861.64.142.13.68.1090704234.squirrel@harry.mail-abuse.org> In-Reply-To: References: Date: Sat, 24 Jul 2004 14:23:54 -0700 (PDT) Subject: Re: Sender-ID and free software From: "Douglas Otis" To: rms@gnu.org Cc: "IETF MARID WG" , team@fsfeurope.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > (Michel, I am not a member of this list, so would you please > forward my message if it does not go through?) > > Microsoft's Sender-ID license is directly incompatible with free > software regardless of which free software license is used. Free > software means users are free to run it, study and modify the source, > and to redistribute it with or without changes. Free to do so means > there is no requirement to ask or tell anyone that you are doing so. > > The Microsoft license for Sender-ID directly forbids release of > software with all these freedoms, so it is impossible for any program > to be free software under Microsoft's regime. > > I've been expecting to see something like this ever since Gates > started talking about spam. This license is an example of Microsoft's > strategy for killing off free software as an alternative to Windows. > Microsoft first patents something, then incorporates it into a format > or protocol, then tries to make it de rigueur while excluding those it > wishes to exclude. In the absence of resistance, Microsoft has a good > chance of imposing whatever standards it likes. Let us, therefore, > resist it here and now. Richard, In the case of the PRA proposal, proponents have difficultly explaining why this concept is better. PRA ensures there is NO relief with respect to network overhead, even if messages are rejected. PRA ignores the primary motivation for which identity is being spoofed, being a means to avoid accreditation filtering, the RFC 2821 MAIL FROM. If accreditation is allowed to become more effective with CSV, this oversight is significant. A rather weakly supported claim is this will end phising. Support for PRA checks overlooks the identity significant to the user, and that many techniques still exist to allow phising, some without the need to publish DNS records by the entity committing the fraud. There is also a potential for network instability caused by early termination of a series of DNS queries, that both allow accumulation of outstanding UDP traffic and necessitate the resending of the messages. A serious flaw made far worse with PRA. As PRA has been isolated, envision rejection of both the Submitter and PRA draft. Take the BATV draft of Dave Crocker and add a mode using an address based technique to include the SPF record sets. This would allow Forwarding and List Servers for the most part to continue working, without the use of Submitter. (EzMLM may be an exception for signatures, but would still work with the SPF mode.) Submitter and PRA should be rejected as being highly disruptive. Combine SPF with BATV. Submitter and PRA fail to provide the most basic goal of the MARID charter. That is to authenticate (and authorize) the MTA domain (responsible for policy as implied with DNS), as compared to CSV that ignores filtering objectives of messages, but accomplishes the basic goal of the charter. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Jul 24 18:00:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14189 for ; Sat, 24 Jul 2004 18:00:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OLrF8K059999; Sat, 24 Jul 2004 14:53:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6OLrF5K059998; Sat, 24 Jul 2004 14:53:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OLrEJ9059990 for ; Sat, 24 Jul 2004 14:53:14 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id E070F280B1 for ; Sat, 24 Jul 2004 23:53:11 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16124-03 for ; Sat, 24 Jul 2004 23:53:09 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 22E5A280BA; Sat, 24 Jul 2004 23:53:08 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Sender-ID and free software Date: Sat, 24 Jul 2004 23:53:08 +0200 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407242353.08671@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Le samedi 24 Juillet 2004 21:43, Richard Stallman wrote : > > Microsoft's Sender-ID license is directly incompatible with free > software regardless of which free software license is used. [...] > Let us, therefore, resist it here and now. Thus He Spoke. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Sat Jul 24 22:06:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25484 for ; Sat, 24 Jul 2004 22:06:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P1rAhS073948; Sat, 24 Jul 2004 18:53:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6P1rABE073947; Sat, 24 Jul 2004 18:53:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P1r8iJ073941 for ; Sat, 24 Jul 2004 18:53:09 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52770) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1BoYCN-0007xH-7Z for ietf-mxcomp@imc.org; Sun, 25 Jul 2004 02:53:11 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BoYCM-0002UA-T8 for ietf-mxcomp@imc.org; Sun, 25 Jul 2004 02:53:10 +0100 Date: Sun, 25 Jul 2004 02:53:10 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: draft-ietf-marid-core-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The abstract states: The specification is carefully tailored to ensure that the overwhelming majority of legitimate emailers, remailers and mailing list operators are already compliant. Has anyone published a survey on this topic? Implementations that I know are not compliant include: Sendmail (.forward and /etc/aliases) Exim (ditto) Cyrus (Sieve redirect) Postfix and qmail typically add Delivered-To headers in the process of alias-forwarding a message; however these are no longer part of the PRA algorithm and can't be added without conflicting with the RFC 822 semantics of Resent- header fields. The Introduction suggests: "an MDA might discard a message rather than placing it into a mailbox". Recommending the silent discarding of email that is likely to be legitimate is irresponsible. Section 2.1 says "The mechanism of this document also seeks to authenticate the mailbox associated with the MOST RECENT introduction of a message into the mail delivery system." This protocol claims to authenticate domains not mailboxes. It goes on to say "However, in the case of a third-party mailer, a forwarder or a mailing list server, the address being authenticated is that of the third party, the forwarder or the mailing list." The terminology here is rather imprecise. The document as a whole needs to be much clearer about the difference between encapsulation-forwarding (for which one might use the MIME type message/rfc822), alias-forwarding (via the Sieve redirect command or the Unix /etc/aliases or .forward mechanisms), and re-sending (which is similar in use to encapsulation- forwarding except that the message is not encapsulated; it is what Resent- header fields are for). Section 4. 6. The message is ill-formed, and it is impossible to determine a Purported Responsible Address. MTAs performing the Sender ID check as part of receiving a message SHOULD reject that message with "550 5.1.7 Missing Purported Responsible Address". I recently performed a practical experiment to check for well-formed Sender: and/or From: header fields in messages passing through the University of Cambridge's email system. It was rather short-lived because of the large number of hopelessly malformed legitimate messages. Large email systems will not be able to enforce RFC 2822 syntax as the above paragraph suggests they should. Section 7.2. The recommendation in this section conflicts with the semantics for Resent-From: defined in RFC 2822. In addition, this recommendation forces email systems to de-optimise the delivery of messages with multiple recipients that alias-forward on to the same external site, since it requires that each alias-forwarding address adds a different header to the message. This multiple copies of the message are sent on to the external site instead of just one as at present. Finally, I note that a typical academic site will have thousands of users (on the order of 10% of the population) who alias-forward email to or from an off-site email system. These users and their sites will be seriously inconvenienced by the widespread implementation of this protocol. The compatibility problems of are serious and still unresolved after getting on for a year of concerted effort. Tony. -- f.a.n.finch http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR. GOOD. SLIGHT OR SMOOTH. From owner-ietf-mxcomp@mail.imc.org Sat Jul 24 22:22:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26282 for ; Sat, 24 Jul 2004 22:22:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P26lGt074759; Sat, 24 Jul 2004 19:06:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6P26lOq074758; Sat, 24 Jul 2004 19:06:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P26kRH074752 for ; Sat, 24 Jul 2004 19:06:47 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52842) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1BoYPa-0007OL-Ph for ietf-mxcomp@imc.org; Sun, 25 Jul 2004 03:06:50 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BoYPa-0002pG-Nk for ietf-mxcomp@imc.org; Sun, 25 Jul 2004 03:06:50 +0100 Date: Sun, 25 Jul 2004 03:06:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: draft-ietf-marid-submitter-02.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 25 Jul 2004, Tony Finch wrote Re: draft-ietf-marid-core-02.txt > > The recommendation in this section conflicts with the semantics for > Resent-From: defined in RFC 2822. In addition, this recommendation forces > email systems to de-optimise the delivery of messages with multiple > recipients that alias-forward on to the same external site, since it > requires that each alias-forwarding address adds a different header to the > message. This multiple copies of the message are sent on to the external > site instead of just one as at present. This also applies to section 5.2 of the SUBMITTER specification. In addition, the suggested use of Resent-From: in section 5.4 is even further from the RFC 2822 semantics. Tony. -- f.a.n.finch http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR. GOOD. SLIGHT OR SMOOTH. From owner-ietf-mxcomp@mail.imc.org Sat Jul 24 22:46:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27028 for ; Sat, 24 Jul 2004 22:46:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P2P075075757; Sat, 24 Jul 2004 19:25:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6P2P0l6075756; Sat, 24 Jul 2004 19:25:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P2P07i075747 for ; Sat, 24 Jul 2004 19:25:00 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52922) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1BoYhF-0000R0-0d for ietf-mxcomp@imc.org; Sun, 25 Jul 2004 03:25:05 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BoYh4-0003I0-Qg for ietf-mxcomp@imc.org; Sun, 25 Jul 2004 03:24:54 +0100 Date: Sun, 25 Jul 2004 03:24:54 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: draft-ietf-marid-protocol-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some trivial comments: There's some poor phrasing in the second paragraph of the introduction. The third paragraph is redundant. Section 2 should explain how SPF TXT records coexist with existing TXT records. Section 3.4.1 suggests that they cannot coexist. Tony. -- f.a.n.finch http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR. GOOD. SLIGHT OR SMOOTH. From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 09:26:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08710 for ; Sun, 25 Jul 2004 09:26:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PDD7tU020437; Sun, 25 Jul 2004 06:13:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PDD7V3020436; Sun, 25 Jul 2004 06:13:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cmail.yandex.ru (cmail.yandex.ru [213.180.193.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PDD1mj020415 for ; Sun, 25 Jul 2004 06:13:05 -0700 (PDT) (envelope-from motto@yandex-team.ru) Received: from exchange.yandex.ru (exchange.yandex.ru [213.180.193.135]) by cmail.yandex.ru (8.12.11/8.12.11) with ESMTP id i6PDCkSY038609; Sun, 25 Jul 2004 17:12:46 +0400 (MSD) (envelope-from motto@yandex-team.ru) Received: by exchange.yandex.ru with Internet Mail Service (5.5.2653.19) id ; Sun, 25 Jul 2004 17:12:38 +0400 Message-ID: <6F80EF10E8C3D611825C00D0B774502901EB6110@exchange.yandex.ru> From: Pavel Zavyalov To: "'Harry Katz'" , "'ietf-mxcomp@imc.org'" Cc: "'eric@sendmail.com'" Subject: SUBMITTER extra information Date: Sun, 25 Jul 2004 17:12:38 +0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Received-SPF: pass (cmail.yandex.ru: domain of yandex-team.ru designates 213.180.193.135 as permitted sender) client-ip=213.180.193.135; envelope-from=motto@yandex-team.ru; helo=exchange.yandex.ru; X-Spam-Ystatus: hits=-44.0 VIRUS_SUBJ ALLTRUSTEDIP MANY_BIG_WORDS_COTINUES NEWBAYES_099 CWORDS_100 OUR_MESSAGEID LINK_IN_TEXT X-Spam-Flag: NO Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some (re-) submitting system may want to notify receiving system some extra information about precedence / priority of messages. Examples * Forwarders may run spam filters and know submitting message is suspicious * Postcards/'Send-link-to-friends services may know submitting user is anonymous or may be forged * Something else Extension like MAIL FROM: SUBMITTER: EXTRA="junk" will be (imho) useful in this case List of available must be reserved (may be JUNK, LIST, SUSPICIOUS, ANONYMOUS, FIRST-CLASS), usage of extra info may be unspecified, receiving server can interpret extra info by his own rules and/or reputation services. Thank you, Pavel -- Pavel A. Zavyalov Yandex Mail project manager Yandex http://mail.yandex.ru http://yandex.ru From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 11:35:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14381 for ; Sun, 25 Jul 2004 11:35:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PFN9mI032712; Sun, 25 Jul 2004 08:23:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PFN9FE032711; Sun, 25 Jul 2004 08:23:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PFN8DD032701 for ; Sun, 25 Jul 2004 08:23:08 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i6PFMpGN017274; Sun, 25 Jul 2004 08:22:51 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 25 Jul 2004 08:22:51 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'rms@gnu.org'" , Michel Bouissou , IETF MARID WG Cc: team@fsfeurope.org Subject: RE: Sender-ID and free software Date: Sun, 25 Jul 2004 08:22:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Richard, I would rather resist YOU here and now. How DARE you come into this group and make this type of accusation without the slightest concern or interest in what the group is trying to achieve? You have made no effort to understand the situation before launching your attack. Microsoft has been told the license terms it must satisfy for the Sumbitter proposal to be a part of the MARID standard and the time by which they must provide the necessary assurances. These can only come from the Microsoft legal department. Please go and find yourself another platform for your political ideology. Phill > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Richard Stallman > Sent: Saturday, July 24, 2004 3:43 PM > To: Michel Bouissou; IETF MARID WG > Cc: team@fsfeurope.org > Subject: Sender-ID and free software > > > > (Michel, I am not a member of this list, so would you please > forward my message if it does not go through?) > > Microsoft's Sender-ID license is directly incompatible with free > software regardless of which free software license is used. Free > software means users are free to run it, study and modify the source, > and to redistribute it with or without changes. Free to do so means > there is no requirement to ask or tell anyone that you are doing so. > > The Microsoft license for Sender-ID directly forbids release of > software with all these freedoms, so it is impossible for any program > to be free software under Microsoft's regime. > > I've been expecting to see something like this ever since Gates > started talking about spam. This license is an example of Microsoft's > strategy for killing off free software as an alternative to Windows. > Microsoft first patents something, then incorporates it into a format > or protocol, then tries to make it de rigueur while excluding those it > wishes to exclude. In the absence of resistance, Microsoft has a good > chance of imposing whatever standards it likes. Let us, therefore, > resist it here and now. > From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 12:58:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17459 for ; Sun, 25 Jul 2004 12:58:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PGjqwt039643; Sun, 25 Jul 2004 09:45:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PGjqZx039642; Sun, 25 Jul 2004 09:45:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PGjqVQ039636 for ; Sun, 25 Jul 2004 09:45:52 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id B8CF341497; Sun, 25 Jul 2004 09:45:38 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sun, 25 Jul 2004 09:45:38 -0700 (PDT) Message-ID: <4168.64.142.13.68.1090773938.squirrel@harry.mail-abuse.org> In-Reply-To: <6F80EF10E8C3D611825C00D0B774502901EB6110@exchange.yandex.ru> References: <6F80EF10E8C3D611825C00D0B774502901EB6110@exchange.yandex.ru> Date: Sun, 25 Jul 2004 09:45:38 -0700 (PDT) Subject: Re: SUBMITTER extra information From: "Douglas Otis" To: "Pavel Zavyalov" Cc: "'Harry Katz'" , "'ietf-mxcomp@imc.org'" , "'eric@sendmail.com'" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Some (re-) submitting system may want to notify receiving system some > extra > information about precedence / priority of messages. > > Examples > * Forwarders may run spam filters and know submitting message is > suspicious > * Postcards/'Send-link-to-friends services may know submitting user is > anonymous or may be forged > * Something else > > Extension like > MAIL FROM: SUBMITTER: > EXTRA="junk" > will be (imho) useful in this case > List of available must be reserved (may be JUNK, LIST, SUSPICIOUS, > ANONYMOUS, FIRST-CLASS), usage of extra info may be unspecified, receiving > server can interpret extra info by his own rules and/or reputation > services. A merger of BATV/SPF to protect the RFC 2821 MAIL FROM will not expose an additional mailbox address as will SUBMITTER. This is important as SENDER-ID et al will not reduce the amount of spam. In addition, there will be no means to accredit abuse with SUBMITTER. Unlike a merger of BATV and SPF, much less of the mail system is damaged as with SUBMITTER. In general, SUBMITTER is unfriendly. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 14:22:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20230 for ; Sun, 25 Jul 2004 14:22:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PICeCr046479; Sun, 25 Jul 2004 11:12:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PICeDX046478; Sun, 25 Jul 2004 11:12:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PICd9C046471 for ; Sun, 25 Jul 2004 11:12:40 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 3F9C528096 for ; Sun, 25 Jul 2004 20:12:43 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10574-04 for ; Sun, 25 Jul 2004 20:12:39 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 1DA22280BC; Sun, 25 Jul 2004 20:12:38 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Sender-ID and free software Date: Sun, 25 Jul 2004 20:12:38 +0200 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407252012.38630@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le dimanche 25 Juillet 2004 17:22, Hallam-Baker, Phillip a écrit : > Richard, > > I would rather resist YOU here and now. > > How DARE you come into this group [...] [...] > Please go and find yourself another platform for your political > ideology. Welcome to my .autoplonk file, Phillip. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 16:31:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26681 for ; Sun, 25 Jul 2004 16:31:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PKJg6x057319; Sun, 25 Jul 2004 13:19:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PKJgJd057318; Sun, 25 Jul 2004 13:19:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PKJfu8057312 for ; Sun, 25 Jul 2004 13:19:41 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (verisign.com [65.205.251.33] (may be forged)) by pigeon.verisign.com (8.12.10/) with ESMTP id i6PKJb8S029925; Sun, 25 Jul 2004 13:19:37 -0700 Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <38A0KSNF>; Sun, 25 Jul 2004 13:19:37 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Michel Bouissou'" , IETF MARID WG Cc: "'Richard Stallman'" Subject: RE: Sender-ID and free software Date: Sun, 25 Jul 2004 13:19:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6PKJfu8057313 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Interesting that you should find it necessary to delete this part of the quote: "make this type of accusation without the slightest concern or interest in what the group is trying to achieve?" The Area Director has already stated that the attacks claiming Microsoft is acting in bad faith are unacceptable. Instead of stopping these attacks you decided to take them into the public arena. I don't know if you told Richard that the Microsoft employees have already agreed to work with their lawyers to try to obtain an acceptable license, his answer suggests that either you did not or Richard did not listen. Either way Richard is still at fault for weighing in on a situation before bothering to find out what the situation is. This type of behavior is very damaging both to the group and to the IETF. It makes it much harder to achieve an acceptable license. All it takes is a Microsoft manager to decide that they do not want it to appear that they are being dictated to and it is game over. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Michel Bouissou > Sent: Sunday, July 25, 2004 2:13 PM > To: IETF MARID WG > Subject: Re: Sender-ID and free software > > > > Le dimanche 25 Juillet 2004 17:22, Hallam-Baker, Phillip a écrit : > > Richard, > > > > I would rather resist YOU here and now. > > > > How DARE you come into this group [...] > [...] > > Please go and find yourself another platform for your political > > ideology. > > Welcome to my .autoplonk file, Phillip. > > -- > Michel Bouissou OpenPGP ID 0xDDE8AC6E > From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 19:21:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03236 for ; Sun, 25 Jul 2004 19:21:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PN876f068965; Sun, 25 Jul 2004 16:08:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PN87CO068964; Sun, 25 Jul 2004 16:08:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PN85E7068958 for ; Sun, 25 Jul 2004 16:08:07 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Sun, 25 Jul 2004 19:08:09 -0400 id 000DFBA0.41043D59.00002776 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7CC4CE26-DE8F-11D8-B79D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Marshall Rose , IETF MARID WG From: Andrew Newton Subject: Re: Sender-ID and free software Date: Sun, 25 Jul 2004 19:08:06 -0400 To: rms@gnu.org X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit First, I do not think this message says anything that has not already been stated on this list already. In fact, there have been messages on this list with a far better description of the legal nature of this issue than this one. While on the subject of things stated previously on this list: On Jul 24, 2004, at 3:43 PM, Richard Stallman wrote: > I've been expecting to see something like this ever since Gates > started talking about spam. This license is an example of Microsoft's > strategy for killing off free software as an alternative to Windows. > Microsoft first patents something, then incorporates it into a format > or protocol, then tries to make it de rigueur while excluding those it > wishes to exclude. In the absence of resistance, Microsoft has a good > chance of imposing whatever standards it likes. Let us, therefore, > resist it here and now. We have asked repeatedly that this type of behavior be stopped. See http://www.imc.org/ietf-mxcomp/mail-archive/msg02079.html You are no exception to the rule. Do not do it again. -andy From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 20:03:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAB05121 for ; Sun, 25 Jul 2004 20:03:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PNm22E071781; Sun, 25 Jul 2004 16:48:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PNm2qm071780; Sun, 25 Jul 2004 16:48:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PNm0dg071772 for ; Sun, 25 Jul 2004 16:48:01 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 34D4528096; Mon, 26 Jul 2004 01:48:03 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20296-07; Mon, 26 Jul 2004 01:47:59 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 1C578280BD; Mon, 26 Jul 2004 01:47:59 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Sender-ID and free software Date: Mon, 26 Jul 2004 01:47:58 +0200 User-Agent: KMail/1.6.1 References: <7CC4CE26-DE8F-11D8-B79D-000A95B3BA44@hxr.us> In-Reply-To: <7CC4CE26-DE8F-11D8-B79D-000A95B3BA44@hxr.us> Cc: rms@gnu.org, Marshall Rose MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407260147.58609@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Andy, Please let me respectfully reply in regard to your message to RMS. Le lundi 26 Juillet 2004 01:08, Andrew Newton a écrit : > First, I do not think this message says anything that has not already > been stated on this list already. In fact, there have been messages on > this list with a far better description of the legal nature of this > issue than this one. Richard's message was rather short, to concentrate on the main aspects of the issue, and give his conclusions, without entering again in the technical and legal details that have, as you state, already been exposed in detail on this list. However, Richard's opinion on the matter is highly respected and weights for a number of people, me included, he being the leader of the Free Sofware Community. I think he was completely in his rights expressing here the general views of this community regarding the licensing issue of the Sender-ID proposal. I don't expect Richard to express himself often on this list, much less to pollute it. So please let him express once for all the valid concerns of the Free Software Community. > While on the subject of things stated previously on this list: > > On Jul 24, 2004, at 3:43 PM, Richard Stallman wrote: > > I've been expecting to see something like this ever since Gates > > started talking about spam. This license is an example of Microsoft's > > strategy for killing off free software as an alternative to Windows. > > Microsoft first patents something, then incorporates it into a format > > or protocol, then tries to make it de rigueur while excluding those it > > wishes to exclude. In the absence of resistance, Microsoft has a good > > chance of imposing whatever standards it likes. Let us, therefore, > > resist it here and now. > > We have asked repeatedly that this type of behavior be stopped. > > See http://www.imc.org/ietf-mxcomp/mail-archive/msg02079.html > > You are no exception to the rule. Do not do it again. I suppose that you refer to this extract of the archive message (from yourself) that your refer to: <<< > * Because all the participants are individuals and represent no corporation, > government or other type of organization, intimations and message subtext > regarding the motives and/or hidden agendas of other participants will no > longer be tolerated. >>> I perfectly understand this and wish to conform. Nevertheless, it is to be noticed that the licence imposed on Sender-ID is not the property of any "individual" participating in the works of this group, but the alledged property of a (rather big) corporation. This being, the attitude of this corporation and its intentions regarding the license it wishes to impose are perfectly relevant subjects as they influence much of the global availability and usability of the concerned technology. Please note that Richard didn't make any statement regarding the motives and/or hidden agendas of members of this working group, as, per your own definition, the concerned corporation is not, as such, a member of this group. Furthermore, let me citate anoter extract from your mail of June, 17: <<< > * Above all else, participants should concentrate their energies on creating > an interoperable standard. >>> I strongly believe that the license issue is one of the major roadblocks towards "creating an interoperable standard", and this opinion seems to be shared by many others. Thus, in my humble opinion, the remarks that Richard made on this subject were perfectly relevant. Respectfully. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 20:37:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06372 for ; Sun, 25 Jul 2004 20:37:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q0R44h074854; Sun, 25 Jul 2004 17:27:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q0R4Jg074853; Sun, 25 Jul 2004 17:27:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q0R0Sa074845 for ; Sun, 25 Jul 2004 17:27:03 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: SUBMITTER extra information Date: Mon, 26 Jul 2004 10:27:03 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7810@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: "Pavel Zavyalov" , "Harry Katz" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6Q0R3Sa074847 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Some (re-) submitting system may want to notify receiving system some extra information about precedence / priority of messages. Examples * Forwarders may run spam filters and know submitting message is suspicious * Postcards/'Send-link-to-friends services may know submitting user is anonymous or may be forged * Something else Extension like MAIL FROM: SUBMITTER: EXTRA="junk" will be (imho) useful in this case List of available must be reserved (may be JUNK, LIST, SUSPICIOUS, ANONYMOUS, FIRST-CLASS), usage of extra info may be unspecified, receiving server can interpret extra info by his own rules and/or reputation services. Thank you, Pavel -- Pavel A. Zavyalov ~~~~~~~~~~~~~~~~~ Isn't this beyond the scope of MARID. There is a danger in trying to solve every problem at once. MARID should focus on solving spoofing and phishing using authentication of the sender (or the senders domain at least). I can also think of lots of cool extras that it would be nice to introduce into the mail standards. However I don't believe that this is the forum in which to do it. Forwarders today have no formal mechanism to do what you are suggesting. SUBMITTER does not break anything. It seems that you are just trying to piggy back some new functionality on top of an already complex proposal. I apologise if this is an incorrect reading however it is what it appears to be. I suspect that you are introducing MISSION CREEP into the objectives of MARID. Tell me if I am wrong. Regards, Terje Petersen. From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 21:13:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07759 for ; Sun, 25 Jul 2004 21:13:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q15Qu3077539; Sun, 25 Jul 2004 18:05:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q15QDa077538; Sun, 25 Jul 2004 18:05:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q15OOA077521 for ; Sun, 25 Jul 2004 18:05:24 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: alternate submitter syntax Date: Mon, 26 Jul 2004 11:05:29 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7811@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6Q15POA077533 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I know that this is cosmetic. However the standards are forever. And words seem to cause so much confusion that getting the cosmetics of terminology correct makes a huge difference. This proposal may be too far down the road to wind back the clock. However I will offer my two bob worth. The term SUBMITTER is getting confused even by smart people. SUBMITTER is merely the reply address. The parameter would have been a lot less confusing if it was simply called REPLYTO. The RFC.2822 FROM address is supposed to be identical to this parameter. If it is not then the RFC.2822 header is malformed. We would say that we use an SPF test to check a servers authority to instruct a specific REPLYTO address. But we would not imagine that the parameter referred to the actual real author or originator of the email. In dialogue people seem to often mentally infer that SUBMITTER relates to the address from which the email entered the system. Even people who have read and understood the standards. People easily flip back into thinking in common english terms. Your servers need authority (granted through SPF) to specify either. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MAIL FROM address = BOUNCETO address SUBMITTER address = REPLYTO address MAIL FROM: SUBMITTER: MAIL FROM: REPLYTO: SPF checks the authority of a server to specify a given BOUNCETO address. SPF checks the authority of a server to specify a given REPLYTO address. From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 21:38:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08787 for ; Sun, 25 Jul 2004 21:38:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q1SlP8080377; Sun, 25 Jul 2004 18:28:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q1SlU8080376; Sun, 25 Jul 2004 18:28:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q1SkDu080365 for ; Sun, 25 Jul 2004 18:28:46 -0700 (PDT) (envelope-from rms@gnu.org) Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BouIL-0001CV-K1; Sun, 25 Jul 2004 21:28:49 -0400 From: Richard Stallman To: "Hallam-Baker, Phillip" CC: michel@bouissou.net, ietf-mxcomp@imc.org In-reply-to: (pbaker@verisign.com) Subject: Re: Sender-ID and free software Reply-to: rms@gnu.org References: Message-Id: Date: Sun, 25 Jul 2004 21:28:49 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would rather resist YOU here and now. Since I have no power, there's nothing to resist. All I can do is present arguments and hope they will persuade people. If you don't find them persuasive, they cannot do anything to you. A mere shrug is sufficient to resist them. By contrast, Microsoft, with its software patents, has real power, and is a real danger. You can't remain safe from Microsoft by ignoring it: it can sue you for that. If a standards committee ignores that danger, it could mean big trouble for the whole Internet for a decade or more. How DARE you come into this group and make this type of accusation without the slightest concern or interest in what the group is trying to achieve? The danger that an important standard feature may be off limits to the whole free software world is what I'm concerned about. My understanding is that this group can make decisions that either allow that to happen or prevent it from happening. Even the potential for such a threat calls for an alarm, so that a terrible mistake is not made. If people have already taken the necessary steps to prevent this danger, I am glad to hear it; however, other messages suggest that this is not the case, so it is just as well to make double sure. Microsoft has been told the license terms it must satisfy for the Sumbitter proposal to be a part of the MARID standard and the time by which they must provide the necessary assurances. Would the provision of these assurances involve changes in the Microsoft license such that implementations undr some kind of free software license would be permitted? If so, that would solve the problem. Thank you very much, if you have insisted on this already. From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 22:38:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10797 for ; Sun, 25 Jul 2004 22:38:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q2NDZd085372; Sun, 25 Jul 2004 19:23:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q2NDGP085371; Sun, 25 Jul 2004 19:23:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q2NDU2085363 for ; Sun, 25 Jul 2004 19:23:13 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i6Q2Mqi5013708; Sun, 25 Jul 2004 19:22:53 -0700 In-Reply-To: <200407260147.58609@totor.bouissou.net> References: <7CC4CE26-DE8F-11D8-B79D-000A95B3BA44@hxr.us> <200407260147.58609@totor.bouissou.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "IETF MARID WG" , rms@gnu.org From: Marshall Rose Subject: Re: Sender-ID and free software Date: Sun, 25 Jul 2004 19:22:44 -0700 To: Michel Bouissou X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit michel - the plain fact is that the contents of rms' posting, specifically the last paragraph, is directly contrary to the admonition, repeatedly given by the co-chairs, with respect to the content of messages sent to the list. he has been given a warning. if he continues to misbehave, then the chairs will invoke bcp83 and ask the iesg to ban him from the mailing list. there is an expression in western society that goes like this "rule of law, not rule of men". the rules apply equally to everyone, and so i simply don't care who we're talking about. if some-other-important-person sends a similarly offending message, then he too will get a warning, and if he does it a second time, he too will get at bcp83 timeout. if you feel this unfair, unappreciative or otherwise unhelpful then i suggest you straight to the iesg right now. andrew and i have been tasked to chair this working group according to the charter approved by the iesg and consistent with the ietf process. one of the more distasteful aspects of that is having to remind people of the admonition cited earlier. /mtr From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 23:44:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13061 for ; Sun, 25 Jul 2004 23:44:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q3S7VK090866; Sun, 25 Jul 2004 20:28:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q3S7YC090865; Sun, 25 Jul 2004 20:28:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q3S7Hn090858 for ; Sun, 25 Jul 2004 20:28:07 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 4540A132CD1; Sun, 25 Jul 2004 23:28:39 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id A5D0F628; Sun, 25 Jul 2004 23:28:12 -0400 (EDT) Date: Sun, 25 Jul 2004 23:28:12 -0400 From: Meng Weng Wong To: Terje Petersen Cc: ietf-mxcomp@imc.org Subject: Re: alternate submitter syntax Message-ID: <20040726032812.GJ16317@dumbo.pobox.com> References: <3CA474173FC0274799F97F3AB3BD25EE1A7811@ltwd-svr2.lightwood.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A7811@ltwd-svr2.lightwood.com.au> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jul 26, 2004 at 11:05:29AM +1000, Terje Petersen wrote: | | The term SUBMITTER is getting confused even by smart people. | | SUBMITTER is merely the reply address. The parameter would have been | a lot less confusing if it was simply called REPLYTO. | | The RFC.2822 FROM address is supposed to be identical to this parameter. In the forwarding case, where a@a.com sends mail to b@b.com b@b.com forwards to c@c.com, When c.com receives the message, it sees MAIL FROM: SUBMITTER= Due to the nature of the forwarding relationship, b@b.com and c@c.com can be said to represent the same entity. In this case, SUBMITTER is not the reply address, and it is not identical to the 2822.From header. SUBMITTER identifies the entity responsible for the most recent logical insertion of the message into the mailstream. a@a.com -> b@b.com is one logical delivery. b@b.com -> c@c.com is another logical delivery. A logical delivery may consist of more than one physical SMTP transaction due to the presence of smarthosts and intramural relaying. From owner-ietf-mxcomp@mail.imc.org Sun Jul 25 23:50:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13286 for ; Sun, 25 Jul 2004 23:50:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q3Nsjc090629; Sun, 25 Jul 2004 20:23:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q3NseQ090628; Sun, 25 Jul 2004 20:23:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q3NswL090620 for ; Sun, 25 Jul 2004 20:23:54 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 0CFC8132CD6; Sun, 25 Jul 2004 23:24:24 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id AB250628; Sun, 25 Jul 2004 23:23:57 -0400 (EDT) Date: Sun, 25 Jul 2004 23:23:57 -0400 From: Meng Weng Wong To: "'Harry Katz'" , "'ietf-mxcomp@imc.org'" Subject: ESMTP "X-*" parameters Message-ID: <20040726032357.GI16317@dumbo.pobox.com> References: <6F80EF10E8C3D611825C00D0B774502901EB6110@exchange.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F80EF10E8C3D611825C00D0B774502901EB6110@exchange.yandex.ru> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Jul 25, 2004 at 05:12:38PM +0400, Pavel Zavyalov wrote: | | Extension like | MAIL FROM: SUBMITTER: | EXTRA="junk" | will be (imho) useful in this case | List of available must be reserved (may be JUNK, LIST, SUSPICIOUS, | ANONYMOUS, FIRST-CLASS), usage of extra info may be unspecified, receiving | server can interpret extra info by his own rules and/or reputation services. I agree that a relatively freeform "extra" field type is desirable; with such a field type, it will be easier to experiment with future extensions before standardization. To ensure that this field doesn't become the "TXT" of ESMTP, perhaps we should define a namespace under which all extensions not recognized should be ignored. That would allow "de facto" extensions to quickly achieve critical mass through Darwinian processes without bureaucratic overhead. MAIL FROM: X-WHATEVER=... If an ESMTP receiver has "X-" support, it could advertise that fact in the EHLO response. The WHATEVER namespace could be the subject of an IANA registry. Examples: MAIL FROM: X-foo=foo MAIL FROM: X-bar=bar X-baz=baz We're getting kind of off topic, maybe this conversation could move into the WG responsible for the next ESMTP RFC. From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 00:24:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14724 for ; Mon, 26 Jul 2004 00:24:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q4AbnC093508; Sun, 25 Jul 2004 21:10:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q4Ab4I093507; Sun, 25 Jul 2004 21:10:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q4AZCL093498 for ; Sun, 25 Jul 2004 21:10:35 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bowov-00051S-00 for ; Mon, 26 Jul 2004 06:10:37 +0200 Received: from du-001-151.access.de.clara.net ([212.82.227.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Jul 2004 06:10:37 +0200 Received: from nobody by du-001-151.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Jul 2004 06:10:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: MARID compatibility with SPF records Date: Mon, 26 Jul 2004 05:46:39 +0200 Organization: Lines: 58 Message-ID: <41047E9F.45C1@xyzzy.claranet.de> References: <16632.28935.611895.708064@giles.gnomon.org.uk> 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-151.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > To recap -- > 1) There is concern that since the proposed use of SPF format records > is changing from envelope MAIL FROM checking to PRA checking, that the > difference in semantics might cause problems for some domains: Older > implementations of SPF will use records intended for PRA against > envelope MAIL FROM; Newer implementations will use older records > intended for envelope MAIL FROM against PRA. > 2) The 'null' mechanism is a very simple and clean solution to the > first of these to problems. > 3) While one can construct cases that show the technical difference in > the semantics, I still cannot find one that demonstrates a practical > need for distinguishing a host between them. Maybe I've found a case where this is very important: me ;-) At the moment I use From: nobody@xyzzy.claranet.de everywhere. Including the trivial case where I submit my mail at clara.net with a corresponding MAIL FROM: Please note that xyzzy.claranet.de is a vanity host, it has a simple "v=spf1 redirect=claranet.de" sender policy, and I'm not in the position to modify this (wildcard) policy. I also use other providers with the same From: address. In fact I and my MUA don't know which MSA I'll use at the moment when I write a message. The outbound mail waits in a file "outbound" until I start "send now". And then my MUA uses a MAIL FROM corresponding to the selected provider, but it does _not_ add a Sender: header. Actually my 2nd SMTP provider insists on a correct MAIL FROM: like any well behaved MSA. It won't modify my message in any way, it does _not_ add a Sender:. Now if I've understood [Sender-Id] correctly the recipient tries to find a Sender: in step 3, and a From: in step 4, and this results in From: nobody@xyzzy.claranet.de with an IP of 2nd.provider.example => Sender-Id FAIL. In theory you could say that my MUA or the MSA should add a Sender: header reflecting MAIL FROM:. But in practice this won't happen (my MUA is old, and the MSA isn't interested in MARID oddities, it's already good enough that it enforces a MAIL FROM matching the identified user). Why is the PRA determined by the 2822 From: address in step 4 instead of the existing and valid MAIL FROM ? For recipients trying to be compatible with classic SPF and RfC 2476 that could be an obvious solution, use MAIL FROM as default Sender: Bye, Frank From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 00:41:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15243 for ; Mon, 26 Jul 2004 00:41:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q4UCnv094914; Sun, 25 Jul 2004 21:30:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q4UC5w094913; Sun, 25 Jul 2004 21:30:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q4UAhb094903 for ; Sun, 25 Jul 2004 21:30:11 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: alternate submitter syntax Date: Mon, 26 Jul 2004 14:30:17 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7813@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6Q4UChb094907 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----Original Message----- From: Meng Weng Wong [mailto:mengwong@dumbo.pobox.com] Sent: Monday, 26 July 2004 1:28 PM To: Terje Petersen Cc: ietf-mxcomp@imc.org Subject: Re: alternate submitter syntax On Mon, Jul 26, 2004 at 11:05:29AM +1000, Terje Petersen wrote: | | The term SUBMITTER is getting confused even by smart people. | | SUBMITTER is merely the reply address. The parameter would have been | a lot less confusing if it was simply called REPLYTO. | | The RFC.2822 FROM address is supposed to be identical to this parameter. In the forwarding case, where a@a.com sends mail to b@b.com b@b.com forwards to c@c.com, When c.com receives the message, it sees MAIL FROM: SUBMITTER= Due to the nature of the forwarding relationship, b@b.com and c@c.com can be said to represent the same entity. In this case, SUBMITTER is not the reply address, and it is not identical to the 2822.From header. SUBMITTER identifies the entity responsible for the most recent logical insertion of the message into the mailstream. a@a.com -> b@b.com is one logical delivery. b@b.com -> c@c.com is another logical delivery. A logical delivery may consist of more than one physical SMTP transaction due to the presence of smarthosts and intramural relaying. ==== reply from TERJE below =============================== Thankyou Meng for the example. I am not sure that you got the sequence correct in your example however as an MTA/MUA/USER sitting at "C" this is how I would expect to interpret it. Your example says that sitting at "C" I receive:- MAIL FROM: SUBMITTER= RFC.2822.FROM not equal to If I am C@C.COM then when I hit REPLY in MS-Outlook or any other MUA I would expect my email to be sent to B@B.COM. After all they are the nominated responsible sender in your example. When I hit reply I expect to be corresponding with the PRA. The text of the proposed SUBMITTER standard says:- " Furthermore, SMTP clients MUST, if necessary, insert such RFC 2822 headers as defined in section 4 of [SENDER-ID] in order to ensure that the purported responsible address determined from the RFC 2822 headers by the receiving SMTP server will match the SUBMITTER address. " QUESTION1: Are you suggesting that when C@C.COM presses the reply button the email should be directed to somebody other than the PRA. QUESTION2: If the example you detail is correct then what are the RFC.2822 headers that should match SUBMITTER as per the above quote from the proposed standard. And if the reply address is different then should it not also be SPF checked. From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 04:26:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08656 for ; Mon, 26 Jul 2004 04:26:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q8944A067362; Mon, 26 Jul 2004 01:09:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q894Qv067361; Mon, 26 Jul 2004 01:09:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q893UM067351 for ; Mon, 26 Jul 2004 01:09:03 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6Q88aN07403; Mon, 26 Jul 2004 01:08:36 -0700 Date: Mon, 26 Jul 2004 01:08:32 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <621051756.20040726010832@brandenburg.com> To: Meng Weng Wong CC: "'Harry Katz'" , "'ietf-mxcomp@imc.org'" Subject: Re: ESMTP "X-*" parameters In-Reply-To: <20040726032357.GI16317@dumbo.pobox.com> References: <6F80EF10E8C3D611825C00D0B774502901EB6110@exchange.yandex.ru> <20040726032357.GI16317@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng, MWW> I agree that a relatively freeform "extra" field type is MWW> desirable; with such a field type, it will be easier to MWW> experiment with future extensions before standardization. The history of x- fields from RFC733/RFC822 shows the flaw in that approach: If the field is of any use, then it gets popular. It is extremely rare that folks then migrate from the original header to a header with a different name. MWW> To ensure that this field doesn't become the "TXT" of ESMTP, MWW> perhaps we should define a namespace under which all MWW> extensions not recognized should be ignored. In other words, you want to standardize the experimental field, by creating a new administrative effort. It would be far simpler to just use the existing administrative effort. This has the benefit of requiring no future transition for the installed base. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 05:30:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10902 for ; Mon, 26 Jul 2004 05:30:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9CmrC088187; Mon, 26 Jul 2004 02:12:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q9CmkF088186; Mon, 26 Jul 2004 02:12:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9ClIh088130 for ; Mon, 26 Jul 2004 02:12:47 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i6Q9CVxS1140088; Mon, 26 Jul 2004 11:12:31 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 547481111B; Mon, 26 Jul 2004 11:12:31 +0200 (CEST) Date: Mon, 26 Jul 2004 11:12:31 +0200 From: Stephane Bortzmeyer To: Andrew Newton Cc: rms@gnu.org, Marshall Rose , IETF MARID WG Subject: Re: Sender-ID and free software Message-ID: <20040726091231.GA4693@nic.fr> References: <7CC4CE26-DE8F-11D8-B79D-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7CC4CE26-DE8F-11D8-B79D-000A95B3BA44@hxr.us> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Jul 25, 2004 at 07:08:06PM -0400, Andrew Newton wrote a message of 25 lines which said: > We have asked repeatedly that this type of behavior be stopped. Excuse me but it seems that legal or political issues should be openly discussed *before* the standard is cast in stone. Otherwise, the fine RFC writers would have work for nothing if the resulting technology is so patent-encumbered that it cannot be implemented or distributed. I've already seen that sort of behavior at IETF: dismissing in a few sentences any legal or political issues because "we are a technical body" and "we should not get involved in non-technical issues". Very often, the dismissed issue just come back later and time and effort were wasted. It happened with NSEC zone walking in DNSsec, for instance, when the worries about invasion of privacy were not taking into account, forcing the issue to pop up again during the last call. So, because MARID records are useful only if *many* sites use them, deciding in advance to be blind to patent issues is a bad decision. And using personal remarks against the persons who happen to raise these issues will not help, either. [Woh, I managed not to mention Microsoft once :-)] From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 05:33:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11091 for ; Mon, 26 Jul 2004 05:33:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9LIQN091316; Mon, 26 Jul 2004 02:21:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q9LIAc091314; Mon, 26 Jul 2004 02:21:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9LHVW091302 for ; Mon, 26 Jul 2004 02:21:17 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i6Q9LDxS1392264; Mon, 26 Jul 2004 11:21:13 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 38F831111B; Mon, 26 Jul 2004 11:21:13 +0200 (CEST) Date: Mon, 26 Jul 2004 11:21:13 +0200 From: Stephane Bortzmeyer To: Marshall Rose Cc: Michel Bouissou , IETF MARID WG , rms@gnu.org Subject: Re: Sender-ID and free software Message-ID: <20040726092113.GB4693@nic.fr> References: <7CC4CE26-DE8F-11D8-B79D-000A95B3BA44@hxr.us> <200407260147.58609@totor.bouissou.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Jul 25, 2004 at 07:22:44PM -0700, Marshall Rose wrote a message of 26 lines which said: > he has been given a warning. if he continues to misbehave, then the > chairs will invoke bcp83 and ask the iesg to ban him from the > mailing list. The RFC 3683 was discussed mostly to deal with people like Jim Fleming who are clearly engaged in "what amounts to a "denial-of-service" attack to disrupt the consensus-driven process. Typically, these attacks are made by repeatedly posting messages that are off-topic, inflammatory, or otherwise counter-productive." Pure trolls are easy to spot. I presume (but you probably know it better than me :-) that it is the reason why the BCP 83 talks more about "A Practice for Revoking Posting Rights" (procedure, delay, etc) than about a precise definition of the reasons for being revoked. Using RFC 3683 to stop someone to express unpopular views or to raise annoying issues is a bad move, IMHO. I specially wonder what rule could be applied to rms' posting. The only one I see is "unprofessional commentary" which is never defined. > if some-other-important-person sends a similarly offending message, > then he too will get a warning, and if he does it a second time, he > too will get at bcp83 timeout. I'm not important so I assume the risk :-) From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 05:45:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11465 for ; Mon, 26 Jul 2004 05:45:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9XaFt095196; Mon, 26 Jul 2004 02:33:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q9XakP095195; Mon, 26 Jul 2004 02:33:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9XZCO095184 for ; Mon, 26 Jul 2004 02:33:36 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i6Q9XYxS1394892; Mon, 26 Jul 2004 11:33:34 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 3FD981111B; Mon, 26 Jul 2004 11:33:34 +0200 (CEST) Date: Mon, 26 Jul 2004 11:33:34 +0200 From: Stephane Bortzmeyer To: "Hallam-Baker, Phillip" Cc: "'Michel Bouissou'" , IETF MARID WG , "'Richard Stallman'" Subject: Re: Sender-ID and free software Message-ID: <20040726093334.GC4693@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Jul 25, 2004 at 01:19:36PM -0700, Hallam-Baker, Phillip wrote a message of 50 lines which said: > The Area Director has already stated that the attacks claiming > Microsoft is acting in bad faith are unacceptable. What I've seen at postings like http://www.imc.org/ietf-mxcomp/mail-archive/msg02079.html is a recall of the old IETF legend that people suddenly forget the company they work for when they post on an IETF mailing list. So, telling you "You say this because you work for evil Verisign and therefore we should not listen to you" is unacceptable according to the above statement. But is does not and should not prevent people from discussing the activities or the statements of Microsoft, Cisco, Verisign or AFNIC, the organizations, at least when it has a direct consequence on a current IETF activity. It is interesting to see that the discussion on the same issue (rms' statement) has been much more professionnal (nobody was threatened to be kicked off) on the private SPF mailing list (http://archives.listbox.com/spf-discuss@v2.listbox.com/200407/0814.html) than on the consensus-driven IETF MARID mailing list. > This type of behavior is very damaging both to the group and to the > IETF. It makes it much harder to achieve an acceptable license. All > it takes is a Microsoft manager to decide that they do not want it > to appear that they are being dictated to and it is game over. I thought that the already mentioned legend "all the participants are individuals and represent no corporation, government or other type of organization" was issued to avoid political discussions to distract people from actual work on the standard. And then, you say that we should adopt such or such viewpoint purely for tactical reasons? If you drag the discussion on this ground, I would say that I'm skeptical: Microsoft seems to be very eager to have an official IETF endorsment for Sender-ID. See, for instance, http://www.microsoft.com/presspass/press/2004/jun04/06-24SIDSpecIETFPR.asp. From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 06:04:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12158 for ; Mon, 26 Jul 2004 06:04:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9pApY001249; Mon, 26 Jul 2004 02:51:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q9pA0r001248; Mon, 26 Jul 2004 02:51:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9p9Ic001235 for ; Mon, 26 Jul 2004 02:51:09 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id A48512807B for ; Mon, 26 Jul 2004 11:51:09 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08718-05 for ; Mon, 26 Jul 2004 11:51:02 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id DB8CF28096; Mon, 26 Jul 2004 11:51:02 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Sender-ID and free software Date: Mon, 26 Jul 2004 11:51:02 +0200 User-Agent: KMail/1.6.1 References: <20040726093334.GC4693@nic.fr> In-Reply-To: <20040726093334.GC4693@nic.fr> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407261151.02352@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le lundi 26 Juillet 2004 11:33, Stephane Bortzmeyer a écrit : > > What I've seen at postings like > http://www.imc.org/ietf-mxcomp/mail-archive/msg02079.html is a recall > of the old IETF legend that people suddenly forget the company they > work for when they post on an IETF mailing list. Furthermore, http://www.imc.org/ietf-mxcomp/mail-archive/msg02079.html specifically says: <<< > Because all the participants are individuals and represent no corporation, > government or other type of organization [...] >>> But as soon as one of the participants talks in terms such as : <> or something sounding like this, then it becomes blatantly evident that such individuals don't have anymore the role of "individuals", but act as an interface between their company and this WG, and as representatives of their company in this WG. Trying to stick to the point of view that they are just "individuals" is then pure fiction, isn't it ? -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 08:41:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19885 for ; Mon, 26 Jul 2004 08:41:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QCU2hO032942; Mon, 26 Jul 2004 05:30:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QCU2bl032941; Mon, 26 Jul 2004 05:30:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QCTreO032927 for ; Mon, 26 Jul 2004 05:29:53 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 26 Jul 2004 08:29:52 -0400 id 000DFC1A.4104F940.00006A22 In-Reply-To: <20040726091231.GA4693@nic.fr> References: <7CC4CE26-DE8F-11D8-B79D-000A95B3BA44@hxr.us> <20040726091231.GA4693@nic.fr> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7CE08B36-DEFF-11D8-B79D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Marshall Rose , rms@gnu.org, IETF MARID WG From: Andrew Newton Subject: Re: Sender-ID and free software Date: Mon, 26 Jul 2004 08:29:50 -0400 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 26, 2004, at 5:12 AM, Stephane Bortzmeyer wrote: > Excuse me but it seems that legal or political issues should be openly > discussed *before* the standard is cast in stone. Otherwise, the fine > RFC writers would have work for nothing if the resulting technology is > so patent-encumbered that it cannot be implemented or distributed. The IETF is not a policy-making body nor a political party. If it were, its technical work would be held as partisan and in far less regard. So politics have little to do with the IETF. > I've already seen that sort of behavior at IETF: dismissing in a few > sentences any legal or political issues because "we are a technical > body" and "we should not get involved in non-technical issues". Very > often, the dismissed issue just come back later and time and effort > were wasted. It happened with NSEC zone walking in DNSsec, for > instance, when the worries about invasion of privacy were not taking > into account, forcing the issue to pop up again during the last call. The NSEC issue is a case of ignoring requirements not making policy or political statements. There is a large difference between saying "it is a requirement of MARID to adopt license X" vs. "Microsoft is using MARID to stop all free software the world over." -andy From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 08:52:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20632 for ; Mon, 26 Jul 2004 08:52:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QCfjOR034163; Mon, 26 Jul 2004 05:41:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QCfjBg034162; Mon, 26 Jul 2004 05:41:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QCfiLD034152 for ; Mon, 26 Jul 2004 05:41:45 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: (from hadmut@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) id i6QCfdYf008884 for ietf-mxcomp@imc.org; Mon, 26 Jul 2004 14:41:39 +0200 From: Hadmut Danisch Date: Mon, 26 Jul 2004 14:41:39 +0200 To: ietf-mxcomp@imc.org Subject: Reading list for IETF meeting? Message-ID: <20040726124139.GA8853@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, is there a list of all documents to read for preparing for the IETF meeting? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 09:51:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26788 for ; Mon, 26 Jul 2004 09:51:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QDVTl5040542; Mon, 26 Jul 2004 06:31:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QDVTr0040541; Mon, 26 Jul 2004 06:31:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QDVTOU040534 for ; Mon, 26 Jul 2004 06:31:29 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id i6QDVK8S003312; Mon, 26 Jul 2004 06:31:20 -0700 Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <3Y80S0WW>; Mon, 26 Jul 2004 06:31:20 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Stephane Bortzmeyer'" , "Hallam-Baker, Phillip" Cc: "'Michel Bouissou'" , IETF MARID WG , "'Richard Stallman'" Subject: RE: Sender-ID and free software Date: Mon, 26 Jul 2004 06:31:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > What I've seen at postings like > http://www.imc.org/ietf-mxcomp/mail-archive/msg02079.html is a recall > of the old IETF legend that people suddenly forget the company they > work for when they post on an IETF mailing list. So, telling you "You > say this because you work for evil Verisign and therefore we should > not listen to you" is unacceptable according to the above statement. It is a fiction with an important purpose. Without it I would have to get every post OK'd by my management. I am a press spokesperson for VeriSign, without the fiction I would have to worry about each post being reported in the Press as an official VeriSign position and clear each one through our PR office. Also many of the suggestions I make have absolutely nothing to do with the interests of VeriSign. If someone proposes a problem that should be addressed I may suggest a solution even though there is no VeriSign interest at stake. I may even be suggesting something that might not be in the direct interests of VeriSign as a means of arriving at a better overall spec. So to call them a VeriSign position would be innaccurate. > But is does not and should not prevent people from discussing the > activities or the statements of Microsoft, Cisco, Verisign or AFNIC, > the organizations, at least when it has a direct consequence on a > current IETF activity. That is something different, that is called decorum. Accusing people of acting in bad faith is not polite. You do not have any idea who is acting in bad faith here. Accusing people of being dishonest because of who they work for is not acceptable. >If you drag the discussion on this ground, I would say that I'm >skeptical: Microsoft seems to be very eager to have an official IETF >endorsment for Sender-ID. See, for instance, >http://www.microsoft.com/presspass/press/2004/jun04/06-24SIDSpecIETFPR.asp. Don't confuse being keen to have an endorsement by a standards body with being keen to get an endorsement by the IETF in particular. >Using RFC 3683 to stop someone to express unpopular views or to raise >annoying issues is a bad move, IMHO. I specially wonder what rule >could be applied to rms' posting. The only one I see is >"unprofessional commentary" which is never defined. Making accusations of bad faith is considered unprofessional. As is raising an issue repeatedly when it is not possible to deal with it. Microsoft has been told that they need to adjust the license terms if the technology is to stay in. The chairs have given a specific date for providing the statement from the lawyers. Ergo there is nothing to be done until either we hear from the lawyers or the deadline expires. There seems to already be consensus that the license terms are not acceptable as is. From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 09:53:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27043 for ; Mon, 26 Jul 2004 09:53:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QDZ0UI040981; Mon, 26 Jul 2004 06:35:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QDZ0Ba040980; Mon, 26 Jul 2004 06:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QDYxnY040972 for ; Mon, 26 Jul 2004 06:34:59 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 65EF9132CD1; Mon, 26 Jul 2004 09:35:32 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id A99215F0; Mon, 26 Jul 2004 09:35:00 -0400 (EDT) Date: Mon, 26 Jul 2004 09:35:00 -0400 From: Meng Weng Wong To: Terje Petersen Cc: ietf-mxcomp@imc.org Subject: Re: alternate submitter syntax Message-ID: <20040726133500.GK16317@dumbo.pobox.com> References: <3CA474173FC0274799F97F3AB3BD25EE1A7813@ltwd-svr2.lightwood.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A7813@ltwd-svr2.lightwood.com.au> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jul 26, 2004 at 02:30:17PM +1000, Terje Petersen wrote: | | When I hit reply I expect to be corresponding with the PRA. | That would be funny, because the PRA should be b@b.com, which is yourself! | | The text of the proposed SUBMITTER standard says:- | | " | Furthermore, SMTP clients MUST, if necessary, insert such RFC 2822 | headers as defined in section 4 of [SENDER-ID] in order to ensure | that the purported responsible address determined from the RFC 2822 | headers by the receiving SMTP server will match the SUBMITTER | address. | " | | | | | QUESTION1: Are you suggesting that when C@C.COM presses the reply button | the email should be directed to somebody other than the PRA. The email should be directed to whoever's in the Reply-To or From headers, just as things work today. | QUESTION2: If the example you detail is correct then what are the | RFC.2822 headers that should match SUBMITTER as per the above quote | from the proposed standard. And if the reply address is different then | should it not also be SPF checked. Resent-From, I think. See the latest marid-core spec, which describes PRA. From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 10:58:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08226 for ; Mon, 26 Jul 2004 10:58:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QEUNTV049478; Mon, 26 Jul 2004 07:30:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QEUN0R049475; Mon, 26 Jul 2004 07:30:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QEUMKp049465 for ; Mon, 26 Jul 2004 07:30:22 -0700 (PDT) (envelope-from rms@gnu.org) Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Bp6Ui-00019Q-9A; Mon, 26 Jul 2004 10:30:24 -0400 From: Richard Stallman To: Marshall Rose CC: michel@bouissou.net, ietf-mxcomp@imc.org In-reply-to: (message from Marshall Rose on Sun, 25 Jul 2004 19:22:44 -0700) Subject: Re: Sender-ID and free software Reply-to: rms@gnu.org References: <7CC4CE26-DE8F-11D8-B79D-000A95B3BA44@hxr.us> <200407260147.58609@totor.bouissou.net> Message-Id: Date: Mon, 26 Jul 2004 10:30:24 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The important issue here, the one that people's attention must focus on, is to thwart the attempt to exclude free software operating systems from full participation in email. "Rule of law" is an admirable concept; it means that governments' actions towards the public are limited by laws. Would that the US government followed this principle. It is not applicable to the present situation, both because we are not talking about limiting the actions of a government, and because mere rules are not laws. Since you mention laws, please note that even laws carry no automatic moral authority; they have to earn it. It is often morally justified for individuals to break laws. It wasn't wrong to get an abortion in 1960, or to flee to evade the draft, even though both were illegal in the US. It wasn't wrong for mixed-race couples to marry, or live together, even though that was illegal too in some states. Even the law recognizes that breaking laws is justified, when necessary to prevent something worse from happening. If we were to misapply the standards of laws to mere rules, this would be such a case if ever there was one. The members of the IETF surely cannot want petty matters to preclude the thorough and proper consideration a potential serious problem that would affect all of society. Most of the technical questions a standards committee deals with are purely technical; they make systems function better or worse in various cases. Finding the right decision in those questions is purely a technical matter. Not every technical question is purely technical in its consequences. Some have social implications. One of the lessons society learned after some bad experiences in the 40s and 50s was that scientists and engineers must take account of the social consequences of their work. To bury one's head in engineering and ignore its impact is socially irresponsible. Surely no one will advocate that the IETF make its decisions in such a manner. Let us therefore make sure that this standard is not restricted. From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 11:46:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18515 for ; Mon, 26 Jul 2004 11:46:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QFIUhx065253; Mon, 26 Jul 2004 08:18:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QFIUIn065252; Mon, 26 Jul 2004 08:18:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QFIUWl065226 for ; Mon, 26 Jul 2004 08:18:30 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 26 Jul 2004 11:18:31 -0400 id 000DFC5F.410520C7.00007B57 In-Reply-To: <20040726124139.GA8853@danisch.de> References: <20040726124139.GA8853@danisch.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0C9C2613-DF17-11D8-B79D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: Andrew Newton Subject: Re: Reading list for IETF meeting? Date: Mon, 26 Jul 2004 11:18:29 -0400 To: Hadmut Danisch X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 26, 2004, at 8:41 AM, Hadmut Danisch wrote: > is there a list of all documents to read for preparing for > the IETF meeting? > good question. You can find all the drafts on the charter page: http://www.ietf.org/html.charters/marid-charter.html (note, the first marid-protocol link seems to be in error, but the second is good). We intend the meeting to cover the Sender-ID drafts: http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-02.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-00.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-rationale-00.txt However, reading the CSV docs is also a good thing to do: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-intro-01.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-01.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-dna-01.txt -andy From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 14:44:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23630 for ; Mon, 26 Jul 2004 14:44:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QITWY3059988; Mon, 26 Jul 2004 11:29:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QITWsr059987; Mon, 26 Jul 2004 11:29:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QITVPd059970 for ; Mon, 26 Jul 2004 11:29:32 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i6QITYbY030461 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 26 Jul 2004 14:29:35 -0400 Date: Mon, 26 Jul 2004 14:29:34 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: ietf-mxcomp@imc.org Subject: How is SPF different from RMX? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: How is MARID different from RMX? Let me be more specific. RMX was a non-starter because many people send email using services outsourced from several different companies. For example, Av8 Internet relays email from @earthlink (and others) because the customer gets IP connectivity from Av8 Internet, but gets email from earthlink. Earthlink doesn't provide relay service for these users; Av8 Internet does. Under RMX, Earthlink would presumably charge Av8 Internet for the RMX record (and similarly for SPF record). Alternately, Earthlink could impose its connectivity services on the customer be refusing to accept records for other providers, preventing outsourcing. RMX couldn't overcome this limitation. How does SPF work in this scenario? It was pointed out that RMX doesn't prevent spam, since the spammer always has a domain which they can use: either 1) the domain of the ISP of the (usually hijacked) connection, or 2) a disposable domain. How does SPF deal with disposable domains and abusive use of a valid domain? One thing that has become apparent since the passage of CAN-SPAM is that we don't have a "bulk commercial email" problem: 90 something percent of the commercial emailers were partially compliant with CAN-SPAM in January, and 57% were _fully_ compliant. If you define spam as "unsolicited bulk commercial email", then we don't have a _spam_ problem at all. A very small number of non-compliant emailers are being dealt with according to CAN-SPAM. However, they don't represent even a tiny dent in the volume of "junk" mail. Instead, we have a problem with abuse email, which is completely different from a problem of "commercial bulk email". With the preceding in mind, how does SPF prevent a virus-infected, hijacked computer from sending abuse email? RMX didn't do any of these things, but just created different "hoops" that the abusers could jump through, which creating significant impediments for legitimate email outsourcing. Is SPF just a scheme to prevent outsourcing (or extort money from outsourced email service providers)? Dean Anderson Av8 Internet, Inc P.S. In reviewing the archives, I was also disturbed by the misconceptions being flung about with respect to the ECPA. I am something of an expert on the subject, having read nearly all the case law on the subject, as well as the congressional reports on the ECPA, the Wiretap Act, the Right to Financial Privacy Act and other related legislation and congressional reports. I've also been in conflict with other ISPs (lawyer to lawyer conferences) involving potential ECPA violations. I can say with some certainty and generality that nothing I have seen so far in either SPF or RMX that would universally violate the ECPA: One can certainly get permission. The ECPA is principally about permission: If you have permission, you can do those things that you have permission to do. If you don't have permission, you have a problem. The "problem" can be both civil and/or criminal. There were several things in particular: 1) The USA PATRIOT Act altered the ECPA and the Wiretap Act with respect to Law Enforcement access. If you are not a law enforcement officer, then the USA PATRIOT Act didn't change anything, (unless of course, you have to give law enforcement access.) 2) The ECPA doesn't make exception for employers. Rather, the employer's have permission to tap your phone, and read your email, as specified in employment policies: Its the employer's communications. The employee is only an agent. Even so, the employer still has to respect personal communications unless that is itself a violation of the employment policy. The ECPA violations are practically always a case where someone did something they didn't have permission to do. In my personal experiences, they have involved blocking non-spam email. Most ISPs have permission to block spam (though there are some that don't). No ISP's (that I have found anyway) have permission to block non-spam email. Merely having a password or "ownership of equipment" does not mean you have the customer's permission to access/block/alter their email. In each of my personal experiences, once the appropriate arguments were made to the other ISPs lawyers, they assured us they won't violate the ECPA, and didn't block non-spam email. A case that did go to court on the subject of using a password beyond what it was meant for is Konop V. Hawaiian Airlines. A pilot created a password protected website, and each person receiving a password agreed not to share the password with others. One fellow pilot was persuaded to give his password to a manager. The manager used this password to access the communications on the web site. The court found that this access was not authorized and violated the ECPA. The Councilman case also created quite a bit of mis-information: Having reviewd the documents at http://www.ca1.uscourts.gov/pdf.opinions/03-1383-01A.pdf It found that: Count 1: Conspiracy to violate 18 USC 2511. Court dismissed this count on the grounds that email is in "electronic storage", and cannot be "intercepted" under the meaning of '2511. I agree completely. But this does not mean that a violation of 18 USC 2701 has not occurred. As I suspected, the defendant was not charged with a violation of 18 USC 2701. The defendant argues that his acts were lawful under the ECPA but the Court does not address this argument, noting on page 16: "Defendant's argument takes us beyond the charges in the Indictment. Therefore, we need not stray beyond the text of the Wiretap Act into the Stored Communications Act because the government sought to indict defendant only for conspiracy to violate Title I, 18 U.S.C. S 2511(a)" Further, Councilman is consistent with and references Konop V. Hawaiian Airlines, where violation of both the Wiretap Act and the ECPA was alleged. The Court in Konop held that the Wiretap Act was not violated, but the ECPA was violated. There is every reason to think that if the defendent had been charged with a violation of the ECPA, that given Konop and other cases, they would have been found guilty. There is no reason to think that one can lawfully read email without authorization or that the privacy of email is at risk. The dissenting argument, while persuasive that justice was not served by allowing Councilman to get off scot-free, was not persuasive that unlawful access of stored communications should be prosecuted under the Wiretap Act. Congress moved to make such access unlawful when it passed the ECPA. ECPA compliance for SPF is conceptually simple: A provider implementing SPF would have to obtain permission from its customers and notify them that their service will no longer accept email from non-SPF sites, and that most of or much of the internet is expected not to use SPF, and that they can no longer receive email from anyone on the internet, as their service descriptions previously read. Having made the customers fully aware of the changes and the implications for the customers service in a timely fashion so that the customer can change their service provider, then continued use indicates that the customer accepts the change. One only gets in trouble when customers are left expecting that their email shouldn't be blocked, and that email was blocked without their permsission. From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 15:19:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29245 for ; Mon, 26 Jul 2004 15:19:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QJ8E7X066869; Mon, 26 Jul 2004 12:08:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QJ8EDV066868; Mon, 26 Jul 2004 12:08:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QJ8DxU066859 for ; Mon, 26 Jul 2004 12:08:14 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id A59FE1D651; Mon, 26 Jul 2004 12:08:15 -0700 (PDT) Subject: Re: PRA algorithm and use of non-standard header fields From: Greg Connor To: Margaret Olson Cc: IETF MARID WG In-Reply-To: References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1090868894.525.75.camel@dhcp-163-154-36-247.corp.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 26 Jul 2004 12:08:15 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-07-20 at 09:36, Margaret Olson wrote: > Evaluating the PRA based on records published for SPF-classic is not > valid. SPF-classic publication is itself a non-representative > subsection of the net, and on top of that SPF classic records are not > Sender ID records - the semantics are different - so "pass" and "fail" > does not mean anything. > Actually, this is exactly what SenderID proposal is based on -- the assumption is that published SPF records will be effective when used against the PRA. The proposal depends on this, so it's good that it's actually getting tested. I see PRA as a first step of possibly several in our quest to determine what identity to check. Eventually, if Submitter becomes widely used, we will reach a point where SUBMITTER is either there, or we fall back to MAIL FROM, and then we will be close to where SPF Classic would be if we had continued down the SRS path. From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 15:33:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00912 for ; Mon, 26 Jul 2004 15:33:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QJL20f068875; Mon, 26 Jul 2004 12:21:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QJL23C068874; Mon, 26 Jul 2004 12:21:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QJL12r068868 for ; Mon, 26 Jul 2004 12:21:01 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id D5266280A3 for ; Mon, 26 Jul 2004 21:21:04 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15262-01 for ; Mon, 26 Jul 2004 21:21:01 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id A4AD4280A9; Mon, 26 Jul 2004 21:21:01 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: PRA algorithm and use of non-standard header fields Date: Mon, 26 Jul 2004 21:21:01 +0200 User-Agent: KMail/1.6.1 References: <16631.11634.627247.402238@giles.gnomon.org.uk> <1090868894.525.75.camel@dhcp-163-154-36-247.corp.sgi.com> In-Reply-To: <1090868894.525.75.camel@dhcp-163-154-36-247.corp.sgi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407262121.01225@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le lundi 26 Juillet 2004 21:08, Greg Connor a écrit : > >  Eventually, if Submitter becomes widely used, > we will reach a point where SUBMITTER is either there, or we fall back > to MAIL FROM, and then we will be close to where SPF Classic would be if > we had continued down the SRS path. Is there actually a technical reason why we shouldn't continue down the Classic-SPF + SRS path ? SRS makes sense to me, much more that SUBMITTER and PRA which interest is yet very unclear in my mind (but the complication it introduces is ;-) -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 16:01:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05694 for ; Mon, 26 Jul 2004 16:01:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QJlNWn072860; Mon, 26 Jul 2004 12:47:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QJlNPw072858; Mon, 26 Jul 2004 12:47:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QJlM7r072841 for ; Mon, 26 Jul 2004 12:47:22 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id EF82D4149B; Mon, 26 Jul 2004 12:47:24 -0700 (PDT) Subject: Re: PRA algorithm and use of non-standard header fields From: Douglas Otis To: Greg Connor Cc: Margaret Olson , IETF MARID WG In-Reply-To: <1090868894.525.75.camel@dhcp-163-154-36-247.corp.sgi.com> References: <16631.11634.627247.402238@giles.gnomon.org.uk> <85725BC7-D99E-11D8-BD4A-000A95B3BA44@hxr.us> <1090868894.525.75.camel@dhcp-163-154-36-247.corp.sgi.com> Content-Type: text/plain Message-Id: <1090871244.31696.871.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 26 Jul 2004 12:47:24 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-07-26 at 12:08, Greg Connor wrote: > On Tue, 2004-07-20 at 09:36, Margaret Olson wrote: > > Evaluating the PRA based on records published for SPF-classic is not > > valid. SPF-classic publication is itself a non-representative > > subsection of the net, and on top of that SPF classic records are not > > Sender ID records - the semantics are different - so "pass" and "fail" > > does not mean anything. > > Actually, this is exactly what SenderID proposal is based on -- the > assumption is that published SPF records will be effective when used > against the PRA. The proposal depends on this, so it's good that it's > actually getting tested. > > I see PRA as a first step of possibly several in our quest to determine > what identity to check. Eventually, if Submitter becomes widely used, > we will reach a point where SUBMITTER is either there, or we fall back > to MAIL FROM, and then we will be close to where SPF Classic would be if > we had continued down the SRS path. A typical technique used by spammers is to forge the RFC 2821 MAIL FROM as a "back door" means to submit messages into a domain that would have prohibited direct assess. With focus moved from a useful check of the RFC 2821 MAIL FROM to some RFC 2822 sender identity, how does this ensure this "back door" remains closed? The sender identity could point to any random open SPF record or to one specifically designed to gain full approval from a PRA evaluation. PRA rather than Classic SPF ensures the "back door" may never be closed. Classic SPF can be made much better by including BATV. I would prefer to see the BATV be used in conjunction with the SPF record. If the SPF record were closed, then this could over-ride the BATV signature. The BATV signature would not require a full listing of all domains, but could serve as a useful means to list just the domain's outbound SMTP clients irrespective of other domains that carry their mail. This could become the preferred method, if a DomainKey technique allows verification of the RFC 2821 MAIL FROM. A 'replay' of this bounce address could be easily caught and keeps the "back door" closed. MAIL FROM addresses that do not use the BATV signature and have a SPF record could then apply the matching address requirement as a means of thwarting spoofed MAIL FROM addresses. Looking at address records to sort mail based upon RFC 2822 identities into different folders supports filtering and little else. Filtering in general will only lower the integrity of the mail system. This seems to be a bad direction to take, if there is a means to actually stop abuse before it enters the mail stream. A CSV accreditation by name used in conjunction with strong checks on the RFC 2821 MAIL FROM have the ability to close the door on abuse. I would not expect SPF records to be comprehensive enough in all cases, where a signature scheme could take over in those cases as with BATV. A signature method would also provide a solution to many of the problems seen just using addresses alone. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 16:06:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06163 for ; Mon, 26 Jul 2004 16:06:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QJvtpQ074153; Mon, 26 Jul 2004 12:57:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QJvtDK074152; Mon, 26 Jul 2004 12:57:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QJvsoq074146 for ; Mon, 26 Jul 2004 12:57:54 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 2C48F4149D; Mon, 26 Jul 2004 12:57:59 -0700 (PDT) Subject: Re: PRA algorithm and use of non-standard header fields From: Douglas Otis To: Michel Bouissou Cc: IETF MARID WG In-Reply-To: <200407262121.01225@totor.bouissou.net> References: <16631.11634.627247.402238@giles.gnomon.org.uk> <1090868894.525.75.camel@dhcp-163-154-36-247.corp.sgi.com> <200407262121.01225@totor.bouissou.net> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1090871878.31696.894.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 26 Jul 2004 12:57:58 -0700 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 2004-07-26 at 12:21, Michel Bouissou wrote: > Le lundi 26 Juillet 2004 21:08, Greg Connor a écrit : > > > > Eventually, if Submitter becomes widely used, > > we will reach a point where SUBMITTER is either there, or we fall back > > to MAIL FROM, and then we will be close to where SPF Classic would be if > > we had continued down the SRS path. > > Is there actually a technical reason why we shouldn't continue down the > Classic-SPF + SRS path ? SRS makes sense to me, much more that SUBMITTER and > PRA which interest is yet very unclear in my mind (but the complication it > introduces is ;-) I agree. I would hope this could be the direction taken. I would see SRS being transformed into incorporating BATV or perhaps the other way around. Either way, I see NO use for the PRA or Submitter scheme unless the goal is to break mail and have messages go missing. ;^) -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 16:15:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07125 for ; Mon, 26 Jul 2004 16:15:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QK265R074609; Mon, 26 Jul 2004 13:02:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QK26Zm074608; Mon, 26 Jul 2004 13:02:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QK25fg074601 for ; Mon, 26 Jul 2004 13:02:05 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 564C71D651; Mon, 26 Jul 2004 13:02:09 -0700 (PDT) Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT From: Greg Connor To: Terje Petersen Cc: ietf-mxcomp@imc.org In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> References: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> Content-Type: text/plain Message-Id: <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 26 Jul 2004 13:02:09 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-07-19 at 17:44, Terje Petersen wrote: ... > A mismatch between the SUBMITTER address and the FROM address is a content problem not a transport problem. > > MTAs should deal with transport. > MUAs should deal with content. I think the assumption hidden here is that 2821 defines transport data, and never content, and 2822 defines content, and never transport. Perhaps this is true, but there was LONG discussion during the first phase of MARID about "Choice of identity to operate on" and it was decided at the outset that we want to be able to validate BOTH 2821 and 2822 identities. In my opinion, if you want to define 2821 as Transport and 2822 as Content, that is fine, but there are still cases where you need to sync up the two. How do you solve this puzzle? If the MTA only has access to 2821 identities, and the MUA can only see 2822 identities, then neither of these can validate consistency without stepping out of its assumed boundaries. You mentioned spam filters and virus filters that are already blurring the lines. There is good reason for that. Users want to REJECT bad mail, not accept it and deliver it to an MUA which has no choice but to file it in another folder. Administrators want to reject it during the first conversation so that they don't have to generate a bounce message later (commonly referred to as "blowback") Also, RFC2476 defines the concept of an MSA (Submit server) which fills all the functions of an MTA, but also does some content checking. For example, it says that an MSA should check all of return path, Sender:, Message-Id, and more). So the idea of checking both 2821 and 2822 identities in the same place is not new (RFC2476 is 5.5 years old, though big ISPs and corporations still routinely skirt it). Another way of looking at this is: MARID doesn't require implementation at the MTA level. SUBMITTER is a helper-function, but not a requirement, and it is completely possible to implement MARID within the spec by an MUA or an MUA-like filter like SpamAssassin. The spec itself doesn't say "It must be in your MTA". But, if users are free to implement it at whatever stage they choose, they are guaranteed to start phoning Sendmail and asking for a MARID implementation :) From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 17:19:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10701 for ; Mon, 26 Jul 2004 17:19:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QL1ePr081812; Mon, 26 Jul 2004 14:01:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QL1euV081811; Mon, 26 Jul 2004 14:01:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QL1bXc081804 for ; Mon, 26 Jul 2004 14:01:37 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 704A5414B7; Mon, 26 Jul 2004 14:01:42 -0700 (PDT) Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT From: Douglas Otis To: Greg Connor Cc: Terje Petersen , MARID In-Reply-To: <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> References: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> Content-Type: text/plain Message-Id: <1090875701.31696.999.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 26 Jul 2004 14:01:41 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-07-26 at 13:02, Greg Connor wrote: > On Mon, 2004-07-19 at 17:44, Terje Petersen wrote: > ... > > A mismatch between the SUBMITTER address and the FROM address is a content problem not a transport problem. > > > > MTAs should deal with transport. > > MUAs should deal with content. > > > I think the assumption hidden here is that 2821 defines transport data, > and never content, and 2822 defines content, and never transport. > Perhaps this is true, but there was LONG discussion during the first > phase of MARID about "Choice of identity to operate on" and it was > decided at the outset that we want to be able to validate BOTH 2821 and > 2822 identities. Subjugation of RFC 2821 MAIL FROM to PRA was "announced" more than "discussed." This took place when Ming announcing "he" decided to relinquish SPF to C-ID. It has been a hard road to pushing back the changes this entailed. From XML syntax to now the RFC 2822 sender identities. I see little justification for either of these changes and may reasons for not allowing such changes. > In my opinion, if you want to define 2821 as Transport and 2822 as > Content, that is fine, but there are still cases where you need to sync > up the two. How do you solve this puzzle? If the MTA only has access > to 2821 identities, and the MUA can only see 2822 identities, then > neither of these can validate consistency without stepping out of its > assumed boundaries. There are several proposals that handle RFC 2822 identities in a manner they SHOULD be handled. Sender-ID will continue Phishing and "back door" entry practices. Something like "DomainKey" or "Identified Internet Mail" does exactly what a user would expect. Tell them WHO sent the mail, or provide STRONG assurances of the domain. PRA can not clearly define which identity should be checked, displayed, or how this relates to the author of the message. > You mentioned spam filters and virus filters that are already blurring > the lines. There is good reason for that. Users want to REJECT bad > mail, not accept it and deliver it to an MUA which has no choice but to > file it in another folder. Administrators want to reject it during the > first conversation so that they don't have to generate a bounce message > later (commonly referred to as "blowback") The large number of records required for this check and the need to read the message ensures there is no savings with respect to the incoming network load. Closing the "back door" or preventing "blowback" is best done with RFC 2821 MAIL FROM checks. Allowing a different identity only allows a means to side step any protections desired. > Also, RFC2476 defines the concept of an MSA (Submit server) which fills > all the functions of an MTA, but also does some content checking. For > example, it says that an MSA should check all of return path, Sender:, > Message-Id, and more). So the idea of checking both 2821 and 2822 > identities in the same place is not new (RFC2476 is 5.5 years old, > though big ISPs and corporations still routinely skirt it). RFC 2476: MSA Unfinished messages need to be completed to ensure they conform to [MESSAGE-FORMAT], and later requirements. For example, the message may lack a proper 'Date' header field, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished messages (for example, it might not know its time zone). Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are in general considered to be outside the province of standardized MTA functionality. There is specific wording regarding checking the RFC 2821 return path but only that compliance to RFC 822 be done to ensure "local only" paths have the domain added, etc. I would not describe that as advice to "check" that these RFC 822 paths are valid, only that they conform to syntax requirements. > Another way of looking at this is: MARID doesn't require implementation > at the MTA level. SUBMITTER is a helper-function, but not a > requirement, and it is completely possible to implement MARID within the > spec by an MUA or an MUA-like filter like SpamAssassin. The spec itself > doesn't say "It must be in your MTA". But, if users are free to > implement it at whatever stage they choose, they are guaranteed to start > phoning Sendmail and asking for a MARID implementation :) How easy would it be to spoof, if not done at the MTA? I did not think the charter was to aid message filtering. By making the authorization based upon the message (RFC 2822), rather than the MTA (RFC 2821), the overly broad nature of this task removes a clear definition of the identity being checked. In addition, the permission sets for this RFC 2822 check obscures which domain is administratively accountable for the messages being emitted. At least, when done for the RFC 2821 MAIL FROM, this had the benefit of directly blocking the "blowback". Checking the RFC 2822 identity ensures an ability to continue the practice of using RFC 2821 MAIL FROM spoofing. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 18:02:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13523 for ; Mon, 26 Jul 2004 18:02:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QLnHvJ087599; Mon, 26 Jul 2004 14:49:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QLnHf9087598; Mon, 26 Jul 2004 14:49:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QLnFu5087592 for ; Mon, 26 Jul 2004 14:49:15 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id C9C68280A3 for ; Mon, 26 Jul 2004 23:49:19 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17203-04 for ; Mon, 26 Jul 2004 23:49:15 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id C755E280A9; Mon, 26 Jul 2004 23:49:15 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT Date: Mon, 26 Jul 2004 23:49:15 +0200 User-Agent: KMail/1.6.1 References: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> In-Reply-To: <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407262349.15344@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le lundi 26 Juillet 2004 22:02, Greg Connor a écrit : > > In my opinion, if you want to define 2821 as Transport and 2822 as > Content, that is fine, but there are still cases where you need to sync > up the two.  How do you solve this puzzle?  If the MTA only has access > to 2821 identities, and the MUA can only see 2822 identities, then > neither of these can validate consistency without stepping out of its > assumed boundaries. I don't really understand this necessity of "syncing" envelope with contents, unless I missed an essential part of the goals of MARID. The major problem we have to face today regarding this is the huge quantity of spam/viruses that comes from zombie or exploited machines around the world, that pick-up a random e-mail address, connect directly to the destination MX and say: HELO destination-domain.com (or whatever) MAIL FROM: We aren't out to prevent the user from sending from work a mail which headers state "From: , we are out to prevent the massive disruption of e-mail that all these zombie and trojaned machines cause. And this can perfectly be achived without having to "sync" envelopes and contents, or even to worry about contents at MTA level. It would be enough to use SPF + SRS plus maybe some specifics for bounces, AND enforcing readily available state-of-the-art techniques. If you publish a RFC saying: 1/ A machine that wants to send mail out MUST HELO using its FQDN, and the given FQDN MUST resolve in DNS to its actual IP address, otherwise receiving side SHOULD reject the connection. 2/ The machine that wants to send mail SHOULD be listed in SPF as a legitimate mail sender for the HELO it gave. i.e. MAIL FROM: SPF check SHOULD give "pass" and MAY give "neutral" or "none" (in these 2 last cases, the receiving side policy MAY decide to refuse the connection), but MUST NOT give "fail", "softfail", "error" or "unknown" otherwise the receving side SHOULD reject the connection with a 4xx temporary error. 4/ The given MAIL FROM: MUST be replyable (its right-hand part must resolve in DNS either to an A or a valid MX record) otherwise the mail SHOULD be rejected (most MTAs already implement this check); but in case of a DSN (MAIL FROM: <>), then we should make the check using the given HELO. 3/ The given MAIL FROM: SPF check SHOULD give "pass" and MAY give "neutral" or "none" or "softfail" (in these 3 cases the receiveing domain policy MAY decide to reject the message or submit it to further checks), and with an SPF "fail" the receiving side SHOULD reject the message with a 5xx permanent error. Now, with this, you are already sure that you will only accept mail from machines that HELO properly with their real name, that are authorized mail sender for their domain (receivers can push towards SPF adoption by deciding massively to reject connexions for domains that have no SPF record). Then the SPF check on the MAIL FROM permits checking that the sender is actually allowed to send from this machine, and SRS solves the forwarding issue. At this step, you know that all e-mail you accept to receive comes from a MAIL FROM and a sending MTA that are mutually coherent, and authorized. At this step, all e-mail from forging zombies is eliminated, and this is the main result we want to achieve. Then, we could simply recommend that MUAs SHOULD display the as well as the "From: " header field, and simply educate users in telling them that, when they differ, and if in doubt about the authenticity of a given message, the is credible where the "From: " may not be. We already have almost all the needed tools for achieving all this (and they already prove usable and efficient), without having to invent a very COMPLEX system such as PRA + SUBMITTER that doesn't give any true assurance that it can perform any better than what we already have readily available. The PRA + SUBMITTER system really looks to me like a kludge on a kludge on a kludge, and if I'm not sure it will perform any better than a much simpler system such as what I suggest. In France, we have a Shadok joke that says "Why do simple, when we can do much more complicated ?" And that's exactly what PRA + SUBMITTER evokes to me. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 18:09:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14571 for ; Mon, 26 Jul 2004 18:09:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QLu6pA088530; Mon, 26 Jul 2004 14:56:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QLu6vV088529; Mon, 26 Jul 2004 14:56:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QLu5sa088522 for ; Mon, 26 Jul 2004 14:56:06 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 30851280A3 for ; Mon, 26 Jul 2004 23:56:07 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17203-05 for ; Mon, 26 Jul 2004 23:56:03 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 198C2280A9; Mon, 26 Jul 2004 23:56:03 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT Date: Mon, 26 Jul 2004 23:56:02 +0200 User-Agent: KMail/1.6.1 References: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> <1090875701.31696.999.camel@ddev.mail-abuse.org> In-Reply-To: <1090875701.31696.999.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407262356.02633@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le lundi 26 Juillet 2004 23:01, Douglas Otis a écrit : > > By making the authorization > based upon the message (RFC 2822), rather than the MTA (RFC 2821), the > overly broad nature of this task removes a clear definition of the > identity being checked. Absolutely. At 2821 stage, we currently have ONE un-ambiguous sender identity, which is MAIL FROM. It is obvious to common sense that we should base our controls upon the provided identity that is given to us, rather than having to reinvent, dig out from the 2822 headers thru complex circonvolutions or whatever, another supposedly "better" identity that we would like to check instead of the one that has been given to us in the first place. Shadok's word in french: "Pourquoi faire simple quand on peut faire compliqué ?" ;-) -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 21:33:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25675 for ; Mon, 26 Jul 2004 21:33:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R1OtMN010869; Mon, 26 Jul 2004 18:24:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6R1OthY010868; Mon, 26 Jul 2004 18:24:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R1OtrP010862 for ; Mon, 26 Jul 2004 18:24:55 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 7BA714149B; Mon, 26 Jul 2004 18:24:58 -0700 (PDT) Subject: Re: I-D ACTION:draft-ietf-marid-core-02.txt From: Douglas Otis To: Mark Lentczner Cc: IETF MARID WG In-Reply-To: <169D9BA1-DBF3-11D8-896F-000393A56BB6@glyphic.com> References: <3051.206.165.46.141.1090502234.squirrel@harry.mail-abuse.org> <169D9BA1-DBF3-11D8-896F-000393A56BB6@glyphic.com> Content-Type: text/plain Message-Id: <1090891497.31696.1411.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 26 Jul 2004 18:24:57 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-22 at 08:23, Mark Lentczner wrote: > On Jul 22, 2004, at 6:17 AM, Douglas Otis wrote: > > > It would appear information was removed regarding the maximal number of > > DNS queries allowed and the time limit for these queries. Is there an > > expectation these limits are to be individual choices? > > This information was moved to the draft-ietf-marid-protocol-00.txt, > which is the draft that deals with making DNS queries. Furthermore, > the limits have been reduced from prior drafts we had written. The following are draft references marked with -------. Notes are indicated with -*-*- ------- Core version 01 definition of processing limits: 9.5 MTA Implementers MTAs that are acting as SMTP servers SHOULD implement the checks described in this document. An MTA SHOULD limit the number of DNS lookups (or the time spent performing the lookup) that it will perform in the process of checking a message. Such a limit SHOULD permit at least 20 DNS lookups. ------- Protocol version 00 processing limits: 6.2 Processing Limits During processing, an check_host() may require additional evaluations of check_host() due to the Include mechanism and/or the Redirect modifier. Implementations must be prepared to handle records that are set up incorrectly or maliciously. Implementations MUST perform loop detection, limit additional evaluations, or both. If an implementation chooses to limit additional evaluations, then at least a total of 10 evaluations of check_host() for a single query MUST be supported. (This number should be enough for even the most complicated configurations.) If a loop is detected, or evaluation limit of an implementation is reached, check_host() MUST abort processing and return the result "PermError". MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authentication SHOULD be "TempError". -*-*- Although this may appear to represent a smaller number of DNS lookups, as this does not refer specifically to a DNS lookup, the number of lookups contained within a check_host() is undefined but may include a dozen such lookups without invoking a redirection modifier as specified within the draft. -*-*- The check_host() function fetches published records, parses them, and interprets them to evaluate if a particular host is or is not permitted to send mail in a given context. ... 4.2 "include" include = "include" ":" domain-spec The "include" mechanism triggers a recursive evaluation of check_host(). The domain-spec is expanded as per section 7. Then check_host() is evaluated with the resulting string as the . The and arguments remain the same as current evaluation of check_host(). "Include" makes it possible for one domain to designate multiple administratively independent domains. These DNS lookups are contained within a check_host() lookup. 4.3 "a" This mechanism matches if is one of the 's IP addresses. A = "a" [ ":" domain-spec ] [ dual-cidr-length ] The is compared to the IP address(es) of the . If any address matches, the mechanism matches. 4.4 "mx" This mechanism matches if is one of the MX hosts for a domain name. MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] check_host() first performs an MX lookup on the . Then perform an A lookup on each MX name returned, in order of MX priority. The is compared to each returned IP address. If any address matches, the mechanism matches. Note Regarding Implicit MXes: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A lookup on the directly. This behavior breaks with the legacy "implicit MX" rule. See [RFC 2821] Section 5. If such behavior is desired, the publisher should specify an "a" directive. 4.5 "ptr" This mechanism tests if 's name is within a particular domain. PTR = "ptr" [ ":" domain-spec ] First the 's name is looked up using this procedure: perform a PTR lookup against . For each record returned, validate the host name by looking up its IP address. If is among the returned IP addresses, then that host name is validated. In pseudocode: sending-host_names := ptr_lookup(sending-host_IP); for each name in (sending-host_names) { IP_addresses := a_lookup(name); if the sending-host_IP is one of the IP_addresses { validated_sending-host_names += name; } } Check all validated hostnames to see if they end in the domain. If any do, this mechanism matches. If no validated hostname can be found, or if none of the validated hostnames end in the , this mechanism fails to match. Pseudocode: for each name in (validated_sending-host_names) { if name ends in , return match. if name is , return match. } return no-match. This mechanism matches if the is an ancestor of the name of , or if the and the name of are the same. For example: "mail.example.com" is within the domain "example.com", but "mail.bad-example.com" is not. If a validated hostname is the , a match results. Note: This mechanism represents a burden on the reverse DNS tree. Therefore, it should be used only as a last resort, if domain policy cannot be expressed using alternative mechanisms. If a domain decides to use it, it should ensure it has the proper PTR records in place for its hosts. -*-*- Due to address sorting and long lists, A, AAAA, and MX records may not provide a complete list of addresses and may be useless as a means of authentication. Another concern is that PTR records could be used to poison the DNS cache. (MX and SRV records do not allow use of an aliased name.) Network integrity is significantly reduced, as the typical timeout defaults to 5 seconds for unknown DNS server, a 20 second timeout could be tripped by two packets lost out of an untold number. If there is 10 RR references per SPF RR accessed by the Check_Host() function, then the amount of DNS traffic is not reduced by this specification, but could exceed more than 100 DNS queries! It would appear by specifying a limit in this manner, the effect is to greatly increase the possible DNS queries required to support this scheme. This is not a reduction as you suggest. DNS is not HTTP. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jul 26 21:35:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25728 for ; Mon, 26 Jul 2004 21:35:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R1HZZW010330; Mon, 26 Jul 2004 18:17:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6R1HZG0010329; Mon, 26 Jul 2004 18:17:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R1HZNF010321 for ; Mon, 26 Jul 2004 18:17:35 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i6R1HUGN009756; Mon, 26 Jul 2004 18:17:30 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Jul 2004 18:17:30 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Michel Bouissou'" , IETF MARID WG Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT Date: Mon, 26 Jul 2004 18:17:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Procedural note, each time I reply to a mail from this individual he has a robot send me spam. If he is serious about stopping spam he will shut his robot up. > Absolutely. At 2821 stage, we currently have ONE un-ambiguous > sender identity, which is MAIL FROM. As has been explained at length in this forum, MAIL FROM is not un-ambiguous. In fact the real semantics of the field as defined by the protocol are that it is the bounce address. > It is obvious to common sense that we should base our > controls upon the > provided identity that is given to us, rather than having to > reinvent, dig > out from the 2822 headers thru complex circonvolutions or > whatever, another It seems obvious to me that a mail authentication mechanism should try to authenticate the mechanism that is seen by the user, accepting that we may need to get MUAs to act in a more coherent manner. The RFC 2821 / RFC 2822 distinction is really not relevant to this, the message format and the transport have numerous interactions and in any case we would be breaking the model of total separation of concerns between layers by introducing an interaction between IP layer transport and the application layer. From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 00:19:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02422 for ; Tue, 27 Jul 2004 00:19:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R42Lxs027401; Mon, 26 Jul 2004 21:02:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6R42LUk027400; Mon, 26 Jul 2004 21:02:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R42Hwm027381 for ; Mon, 26 Jul 2004 21:02:20 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: alternate submitter syntax Date: Tue, 27 Jul 2004 14:02:23 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE0C537B@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6R42Lwm027394 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit TP> When I hit reply I expect to be corresponding with the PRA. MW> That would be funny, because the PRA should be b@b.com, MW> which is yourself! TP> No! According to your example I am C@C.com. TP> You have not addressed the issue. From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 00:41:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03631 for ; Tue, 27 Jul 2004 00:41:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R4Vxpb030194; Mon, 26 Jul 2004 21:31:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6R4VxPw030193; Mon, 26 Jul 2004 21:31:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R4Vwaa030187 for ; Mon, 26 Jul 2004 21:31:58 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id E1F3A132CD1; Tue, 27 Jul 2004 00:32:39 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 1E24E6CB; Tue, 27 Jul 2004 00:32:01 -0400 (EDT) Date: Tue, 27 Jul 2004 00:32:01 -0400 From: Meng Weng Wong To: Terje Petersen Cc: IETF MARID WG Subject: Re: alternate submitter syntax Message-ID: <20040727043201.GL16317@dumbo.pobox.com> References: <3CA474173FC0274799F97F3AB3BD25EE0C537B@ltwd-svr2.lightwood.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE0C537B@ltwd-svr2.lightwood.com.au> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jul 27, 2004 at 02:02:23PM +1000, Terje Petersen wrote: | | TP> When I hit reply I expect to be corresponding with the PRA. | | | MW> That would be funny, because the PRA should be b@b.com, | MW> which is yourself! | | | TP> No! According to your example I am C@C.com. | TP> You have not addressed the issue. | OK, then, if you are c@c.com, who is b@b.com? I originally said: In the forwarding case, where a@a.com sends mail to b@b.com b@b.com forwards to c@c.com, When c.com receives the message, it sees MAIL FROM: SUBMITTER= Due to the nature of the forwarding relationship, b@b.com and c@c.com can be said to represent the same entity. From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 01:12:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04967 for ; Tue, 27 Jul 2004 01:12:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R4wJSs032690; Mon, 26 Jul 2004 21:58:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6R4wJGe032689; Mon, 26 Jul 2004 21:58:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R4wI8L032677 for ; Mon, 26 Jul 2004 21:58:19 -0700 (PDT) (envelope-from rbarclay@comcast.net) Received: from [127.0.0.1] (unknown[67.176.72.175]) by comcast.net (sccrmhc13) with ESMTP id <2004072704582001600okfl0e> (Authid: rbarclay); Tue, 27 Jul 2004 04:58:20 +0000 Message-ID: <4105E0E6.1010507@comcast.net> Date: Mon, 26 Jul 2004 22:58:14 -0600 From: Robert Barclay User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: alternate submitter syntax References: <3CA474173FC0274799F97F3AB3BD25EE0C537B@ltwd-svr2.lightwood.com.au> In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE0C537B@ltwd-svr2.lightwood.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Terje Petersen wrote: > > > TP> When I hit reply I expect to be corresponding with the PRA. > > > MW> That would be funny, because the PRA should be b@b.com, > MW> which is yourself! > > > TP> No! According to your example I am C@C.com. > TP> You have not addressed the issue. > > In the original example b@b.com and c@c.com are the same person. b@b.com is an address that only exists to forward mail on to c@c.com. If you, as c@c.com sent a reply there, it would just get forwarded back to you. This case is I would guess the main reason why the Sender and Resent- headers exist. There are a number of identities in an email. In 2822 there are From, Reply-to, Sender, and Resent-From to name a few. In 2821 there is currently the, HELO domain, the MAIL FROM and now the proposed SUBMITTER. The reason for all of these is that there are legitimate cases where these identities will differ. (SUBMITTER actually must be the same as one of the 2822 headers chosen via the PRA algorithm, but it is not gauranteed to always equal any one of them). The debate in this group has not been about whether it should be possible to represent the fact that lots of people may touch and claim some level of responsibility for an email between the end points. It has been about which of those identities to check and how. Robert From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 01:53:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07381 for ; Tue, 27 Jul 2004 01:53:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R5gmZ1052849; Mon, 26 Jul 2004 22:42:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6R5gmQa052847; Mon, 26 Jul 2004 22:42:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R5gkl5052818 for ; Mon, 26 Jul 2004 22:42:47 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: alternate submitter syntax Date: Tue, 27 Jul 2004 15:42:53 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7814@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" Cc: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6R5gll5052836 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit | | TP> When I hit reply I expect to be corresponding with the PRA. | | | MW> That would be funny, because the PRA should be b@b.com, | MW> which is yourself! | | | TP> No! According to your example I am C@C.com. | TP> You have not addressed the issue. | OK, then, if you are c@c.com, who is b@b.com? I originally said: In the forwarding case, where a@a.com sends mail to b@b.com b@b.com forwards to c@c.com, When c.com receives the message, it sees MAIL FROM: SUBMITTER= Due to the nature of the forwarding relationship, b@b.com and c@c.com can be said to represent the same entity. ================================== === RESPONSE FROM TERJE BELOW ==== ================================== Okay so let's see if I understand you correctly. a represents friend@ hotmail b represents bob @ work c represents bob @ home And the MTA at B talks to the MTA at C as such:- Eg MAIL FROM: SUBMITTER= Eg MAIL FROM: SUBMITTER= Given that a@a.com is unlikely to have published SPF records that authorise the MTA at B to make this claim to the MTA at C then its only going to work if the MTA at C has some rule to bypass SPF checking for email from the MTA at B. Otherwise such an SPF test would fail to pass the bounce address. The MTA at C can do this if it trusts that B has already made the relevant checks already and is itself trustworthy. In effect the MTA at C must whitelist email from the MTA at B. However we could instead constructed a command sequence such as:- Eg MAIL FROM: SUBMITTER= Eg MAIL FROM: SUBMITTER= Which would seem altogether more reasonable and logical to me. And in this case a@a.com is the reply address. Ie REPLYTO. Am I missing something? From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 02:46:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23266 for ; Tue, 27 Jul 2004 02:46:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R6ZbsK076508; Mon, 26 Jul 2004 23:35:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6R6ZblR076507; Mon, 26 Jul 2004 23:35:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R6ZXkx076477 for ; Mon, 26 Jul 2004 23:35:36 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT Date: Tue, 27 Jul 2004 16:35:32 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7816@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6R6Zbkx076499 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----Original Message----- From: Roy Badami [mailto:roy@] Sent: Wednesday, 21 July 2004 5:15 AM To: Terje Petersen Cc: ietf-mxcomp@imc.org Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT >>>>> "Terje" == Terje Petersen writes: Terje> 2. Dump messages where FROM <> SUBMITTER. But an MTA can reject the message at the MTA level. Quietly dumping messages anywhere is a bad thing, and it violates the spirit of the reliable mail delivery prinicple, even if perhaps not the letter. -roy ================================= === RESPONSE FROM TERJE BELOW === ================================= Having thought about this some more it is now even more obvious to me that the MUA can easily handle this job without "dumping" email silently. The MTA receives a command such as:- MAIL FROM: SUBMITTER: Now even before we look at content both email addresses MUST pass an SPF check and be authorised (and arguably confirmed correct). So if the MUA subsequently finds that the email content is malformed because it does not have the correctly matching headers then the email can be safely bounced by the MUA back to fred. After all that address was authenticated previously by the MTA. And whether the MUA bounces the message or the MTA bounces the message the entire content had to be received first up anyway. And at the risk of flogging a dead horse I will just say once again there is nothing stopping proprietary solutions from incorporating MUA checks into mail gateways. It just that the standards should regard it as an MUA function. From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 09:54:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13837 for ; Tue, 27 Jul 2004 09:54:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RDb71Z035391; Tue, 27 Jul 2004 06:37:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RDb7DM035390; Tue, 27 Jul 2004 06:37:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RDb4E5035381 for ; Tue, 27 Jul 2004 06:37:04 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 21791132CD1; Tue, 27 Jul 2004 09:37:47 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 1DE6E885; Tue, 27 Jul 2004 09:37:05 -0400 (EDT) Date: Tue, 27 Jul 2004 09:37:05 -0400 From: Meng Weng Wong To: Terje Petersen Cc: IETF MARID WG Subject: Re: alternate submitter syntax Message-ID: <20040727133705.GM16317@dumbo.pobox.com> References: <3CA474173FC0274799F97F3AB3BD25EE1A7814@ltwd-svr2.lightwood.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A7814@ltwd-svr2.lightwood.com.au> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jul 27, 2004 at 03:42:53PM +1000, Terje Petersen wrote: | | Okay so let's see if I understand you correctly. | | a represents friend@ hotmail | b represents bob @ work | c represents bob @ home | | And the MTA at B talks to the MTA at C as such:- | | Eg MAIL FROM: SUBMITTER= | | Eg MAIL FROM: SUBMITTER= | Yes, that is the intent of SUBMITTER. | | Given that a@a.com is unlikely to have published SPF records | that authorise the MTA at B to make this claim to the MTA at C | then its only going to work if the MTA at C has some rule to bypass | SPF checking for email from the MTA at B. Otherwise such an SPF test | would fail to pass the bounce address. | | The MTA at C can do this if it trusts that B has already made the | relevant checks already and is itself trustworthy. | | In effect the MTA at C must whitelist email from the MTA at B. | If receivers are explicitly aware of their expected forwarding, abuse of SUBMITTER can be strongly limited. In other words, any SUBMITTER not whitelisted can be rejected, if receiver MTAs know what forwarding relationships to expect. | | However we could instead constructed a command sequence | such as:- | | Eg MAIL FROM: SUBMITTER= | | Eg MAIL FROM: SUBMITTER= | | Which would seem altogether more reasonable and logical to me. | | And in this case a@a.com is the reply address. Ie REPLYTO. | OK, can you explain how this is better than the current SUBMITTER proposal? Also, I hope you are clear about the difference between the envelope address used for bounces, and the header address used to tell an MUA where to reply. From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 18:24:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18002 for ; Tue, 27 Jul 2004 18:24:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RMB79Y051181; Tue, 27 Jul 2004 15:11:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RMB6h0051180; Tue, 27 Jul 2004 15:11:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RMAt5p051121 for ; Tue, 27 Jul 2004 15:11:00 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 4794816E17 for ; Tue, 27 Jul 2004 18:18:35 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? In-Reply-To: Your message of "Mon, 26 Jul 2004 14:29:34 EDT." Date: Tue, 27 Jul 2004 18:18:35 -0400 Message-Id: <20040727221835.4794816E17@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > RMX didn't do any of these things, but just created different "hoops" that > the abusers could jump through, .. to send mail from domains that they legitimately have access to. This isn't news. > which creating significant impediments for legitimate email > outsourcing. Which is why great care must be taken in its design and implementation. > With the preceding in mind, how does SPF prevent a virus-infected, > hijacked computer from sending abuse email? It doesn't. It DOES, however, make them accountable to either the domain used by the owner of the infected machine, or by a throw-away spammer domain. IMHO, MARID (RMX, etc) is about closing a hole in SMTP, which says "messages MUST be accepted for delivery or bounced", but it makes no provisions for ensuring that the message CAN be bounced. One intention behind all of these related ideas is to provably have an accountable entity which will accept responsibility for messages, including bounces. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 19:19:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20055 for ; Tue, 27 Jul 2004 19:19:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RN4Osj062167; Tue, 27 Jul 2004 16:04:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RN4OkR062166; Tue, 27 Jul 2004 16:04:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RN4N9j062152 for ; Tue, 27 Jul 2004 16:04:23 -0700 (PDT) (envelope-from larry@larryseltzer.com) Message-Id: <200407272304.i6RN4N9j062152@above.proper.com> Received: (qmail 5957 invoked from network); 27 Jul 2004 23:04:26 -0000 Received: from dsl081-214-187.nyc2.dsl.speakeasy.net (HELO elliot) (lseltzer@[64.81.214.187]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Jul 2004 23:04:25 -0000 From: "Larry Seltzer" To: Subject: RE: How is SPF different from RMX? Date: Tue, 27 Jul 2004 19:04:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcR0KICzTxgoKkGYSTaJi07o1P3ZswABNb/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2149 In-Reply-To: <20040727221835.4794816E17@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>> With the preceding in mind, how does SPF prevent a virus-infected, >>> hijacked computer from sending abuse email? > It doesn't. It DOES, however, make them accountable to either the domain used by the owner of the infected machine, or by a throw-away spammer domain. It's worth pointing out, unless I'm mistaken, that the entire endemic population of mail worms would fail under SPF. None of them would authenticate because they all pick MAIL FROM addresses essentially at random and then use built-in MTAs, none of which will be registered in any DNS. It would also be much harder to write one that would be successful, and the messages would actually come from where they purport to come from, making it easier to shut down the worm. For instance, if there is a throwaway domain involved it would be quickly shut down. From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 19:45:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20970 for ; Tue, 27 Jul 2004 19:45:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RNQgLo067328; Tue, 27 Jul 2004 16:26:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RNQged067327; Tue, 27 Jul 2004 16:26:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RNQg92067321 for ; Tue, 27 Jul 2004 16:26:42 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id BF8934149D for ; Tue, 27 Jul 2004 16:26:47 -0700 (PDT) Subject: Is the back door open? From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1090970806.11296.441.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 27 Jul 2004 16:26:47 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit With the latest increase in the number of DNS lookups required to support construction of the Sender-ID record matrix, and time allotted being more than 3 minutes per message, the ability to defend from DDoS attacks may prove intractable. The number of DNS queries could be hundreds per message, as an attack intended to disable channel checks. Sender-ID employs existing SPF records intended to qualify the RFC 2821 MAIL FROM, but then fully ignores the RFC 2821 MAIL FROM. Sender-ID introduces "Purported Responsible Address" (PRA) from the RFC 2822 headers, where differing types trump more recent headers. Dropping the MAIL FROM strategy of ASRG to adopt this complex and proprietary scheme, this ensures bounce mail and phishing continues. : ( Establishing accountability of sent mail and validity of the return path is ignored by Sender-ID. If an MTA is not checking users as messages are received, perhaps found when selecting low preference MX records, machines of backup MTAs, or relay providers, then these MTAs can be used to send mail to an intended target via the return path. (There is little advice how to handling multi-parts or malformed partitions for PRA determination. This and header trumping could prove fertile soil for abuse.) The back door remains open. MAIL FROM: (never checked per core draft) RCPT TO: (could be local user, but is not) Resent-From: (any open record or not checked) From: (don't care per core draft) To: Subject: Secret ... The bounce becomes: PRA = known@dup.com (validated) MAIL FROM: (bounce not compliant) RCPT TO: Subject: Undelivered Mail ... Resent-From: From: To: ... From: ... Would this be validated as originating from known@dup.com and sent to the inbox. If recognized as a bounce, what would the following variant do? MAIL FROM: (never checked per core draft) RCPT TO: (could be local user, but is not) Resent-From: (any open records or not checked) From: (don't care per the core draft) To: Subject: Secret ... The bounce becomes: PRA = (validated) MAIL FROM: <> (compliant) RCPT TO: Subject: Undelivered Mail Returned to Sender ... From: To: Subject: Secret Resent-From: ... From: Phishing continues: PRA=<796.44.4556@big-bank.cc> (a personal number you may recognize) MAIL FROM: (never checked per core draft) RCPT TO: (could be local user, but is not) Resent-From: <796.44.4556@big-bank.cc> (validates) From: (don't care per core draft) To: Subject: Bogus Claim ... Headers that trump more recent headers should prove to be a difficult item to assess and equally difficult to sort. Would a mail sorting rule ignore the From if the Resent-From does not match? As this Sender-ID mechanism is primarily intended to assist filtering, how mail is sorted as a result, if done differently between MUAs, could also allow an area for confusion and fraud. Could this be done using a DNS cache poisoning technique to even hide real name of the PRA? The extensive set of tools available with SPF makes this possibility greater. CSV can close the front door for spam and Trojans. SPF or BATV can close the back door. What feature does Sender-ID bring to the table, other than support for folders? -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 20:12:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22696 for ; Tue, 27 Jul 2004 20:12:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RNwGWZ074354; Tue, 27 Jul 2004 16:58:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RNwGLD074353; Tue, 27 Jul 2004 16:58:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RNwGoG074336 for ; Tue, 27 Jul 2004 16:58:16 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 27 Jul 2004 19:58:19 -0400 id 000DFD0F.4106EC1B.00003F5B In-Reply-To: <1090970806.11296.441.camel@ddev.mail-abuse.org> References: <1090970806.11296.441.camel@ddev.mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: MARID From: Andrew Newton Subject: Re: Is the back door open? Date: Tue, 27 Jul 2004 19:58:15 -0400 To: Douglas Otis X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 27, 2004, at 7:26 PM, Douglas Otis wrote: > The back door remains open. > > MAIL FROM: (never checked per core draft) > RCPT TO: (could be local user, but is not) > Resent-From: (any open record or not checked) > From: (don't care per core draft) > To: > Subject: Secret > ... > > The bounce becomes: > PRA = known@dup.com (validated) > MAIL FROM: (bounce not compliant) > RCPT TO: > Subject: Undelivered Mail You lost me right here. 2 qs: Why is From "don't care per core draft"? Why is there a bounce? -andy From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 21:19:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26305 for ; Tue, 27 Jul 2004 21:19:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S15jWQ089660; Tue, 27 Jul 2004 18:05:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S15jZP089658; Tue, 27 Jul 2004 18:05:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S15jSf089650 for ; Tue, 27 Jul 2004 18:05:45 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 8CC264149D; Tue, 27 Jul 2004 18:05:51 -0700 (PDT) Subject: Re: Is the back door open? From: Douglas Otis To: Andrew Newton Cc: MARID In-Reply-To: References: <1090970806.11296.441.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1090976750.11296.591.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 27 Jul 2004 18:05:51 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-07-27 at 16:58, Andrew Newton wrote: > On Jul 27, 2004, at 7:26 PM, Douglas Otis wrote: > > The back door remains open. > > > > MAIL FROM: (never checked per core draft) > > RCPT TO: (could be local user, but is not) > > Resent-From: (any open record or not checked) > > From: (don't care per core draft) > > To: > > Subject: Secret > > ... draft-ietf-marid-core-02.txt: 4. Determining the Purported Responsible Address ... 2. Locate the first non-empty Resent-From header in the message. If a Resent-From header is found, proceed to step 5. Otherwise, continue with step 3. This jump to step 5 omits checks for From headers in the message. There is a caution that differing PRA headers should be visible at the MUA, but offers no action. I noted that as a don't care. PRA header trumping order (unrelated to being most recent): 1) If first Resent-Sender go to 5 2) If first Resent-From go to 5 3) If any and all Sender go to 5 4) If any and all From go to 5 5) If single header done. 6) Else 550 Missing PRA. (Must be a single address, not a list) > > The bounce becomes: > > PRA = known@dup.com (validated) > > MAIL FROM: (bounce not compliant) > > RCPT TO: > > Subject: Undelivered Mail The random-1@dup.com could have been a local user, (it had the right domain), but when relayed to a MTA with a list of valid users, the mail was rejected as the local part 'random-1' was not valid. The MTA second to last in the chain, then bounces the message. This may allow filtering, or if done by a backup MTA, the knowledgeable server is expected to be out of service. > You lost me right here. 2 qs: > Why is From "don't care per core draft"? > Why is there a bounce? -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 21:30:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26765 for ; Tue, 27 Jul 2004 21:30:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S1MIUi092723; Tue, 27 Jul 2004 18:22:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S1MIR6092722; Tue, 27 Jul 2004 18:22:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S1MGpR092698 for ; Tue, 27 Jul 2004 18:22:16 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: alternate submitter syntax Date: Wed, 28 Jul 2004 11:22:14 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A7817@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6S1MHpR092717 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----Original Message----- From: Meng Weng Wong [mailto:mengwong@dumbo.pobox.com] Sent: Tuesday, 27 July 2004 11:37 PM To: Terje Petersen Cc: IETF MARID WG Subject: Re: alternate submitter syntax On Tue, Jul 27, 2004 at 03:42:53PM +1000, Terje Petersen wrote: | | Okay so let's see if I understand you correctly. | | a represents friend@ hotmail | b represents bob @ work | c represents bob @ home | | And the MTA at B talks to the MTA at C as such:- | | Eg MAIL FROM: SUBMITTER= | | Eg MAIL FROM: SUBMITTER= | Yes, that is the intent of SUBMITTER. | | Given that a@a.com is unlikely to have published SPF records | that authorise the MTA at B to make this claim to the MTA at C | then its only going to work if the MTA at C has some rule to bypass | SPF checking for email from the MTA at B. Otherwise such an SPF test | would fail to pass the bounce address. | | The MTA at C can do this if it trusts that B has already made the | relevant checks already and is itself trustworthy. | | In effect the MTA at C must whitelist email from the MTA at B. | If receivers are explicitly aware of their expected forwarding, abuse of SUBMITTER can be strongly limited. In other words, any SUBMITTER not whitelisted can be rejected, if receiver MTAs know what forwarding relationships to expect. | | However we could instead constructed a command sequence | such as:- | | Eg MAIL FROM: SUBMITTER= | | Eg MAIL FROM: SUBMITTER= | | Which would seem altogether more reasonable and logical to me. | | And in this case a@a.com is the reply address. Ie REPLYTO. | OK, can you explain how this is better than the current SUBMITTER proposal? Also, I hope you are clear about the difference between the envelope address used for bounces, and the header address used to tell an MUA where to reply. ================================================= === Terje's Detailed Responds Below === ================================================= I believe that I am clear on the difference between the bounce address and the header address used for reply. What your example suggests to me is that you want SUBMITTER to work differently to what I understand. It seems to me that you want the MAIL FROM parameter to be the bounce address only if there is no SUBMITTER parameter. If there is a SUBMITTER parameter then the bounce address is specified by SUBMITTER. You want the meaning of MAIL FROM to change to being equivalent to the RFC.2822 FROM address. So we have two scenarios:- SCENERIO-A: SUBMITTER parameter NOT supported. MAIL FROM -> BOUNCE ADDRESS SUBMITTER -> NOT APPLICABLE RFC.2822.FROM -> REPLY ADDRESS SCENERIO-B: SUBMITTER parameter IS supported. MAIL FROM -> must equal RFC.2822 SUBMITTER -> BOUNCE ADDRESS RFC.2822.FROM -> REPLY ADDRESS In other words the location of the BOUNCE ADDRESS moves in the syntax. And we could have had a parameter called BOUNCETO instead of SUBMITTER. Eg MAIL FROM: BOUNCETO= Is this a correct interpretation of what you are suggesting? From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 21:34:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26851 for ; Tue, 27 Jul 2004 21:34:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S1QUaD093494; Tue, 27 Jul 2004 18:26:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S1QUmi093493; Tue, 27 Jul 2004 18:26:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S1QULp093487 for ; Tue, 27 Jul 2004 18:26:30 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 27 Jul 2004 21:26:31 -0400 id 000DFD0C.410700C7.0000481B In-Reply-To: <1090976750.11296.591.camel@ddev.mail-abuse.org> References: <1090970806.11296.441.camel@ddev.mail-abuse.org> <1090976750.11296.591.camel@ddev.mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <26248864-E035-11D8-B79D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: MARID From: Andrew Newton Subject: Re: Is the back door open? Date: Tue, 27 Jul 2004 21:26:28 -0400 To: Douglas Otis X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 27, 2004, at 9:05 PM, Douglas Otis wrote: > This jump to step 5 omits checks for From headers in the message. Right. My eyes missed the Resent-From. Sorry. > The random-1@dup.com could have been a local user, (it had the right > domain), but when relayed to a MTA with a list of valid users, the mail > was rejected as the local part 'random-1' was not valid. The MTA > second > to last in the chain, then bounces the message. This may allow > filtering, or if done by a backup MTA, the knowledgeable server is > expected to be out of service. Why would the first MTA receiving for dup.com not just reject the message? -andy From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 21:58:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27721 for ; Tue, 27 Jul 2004 21:58:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S1oO8O099069; Tue, 27 Jul 2004 18:50:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S1oOiv099066; Tue, 27 Jul 2004 18:50:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S1oNif099038 for ; Tue, 27 Jul 2004 18:50:23 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id E26CE4149D; Tue, 27 Jul 2004 18:50:24 -0700 (PDT) Subject: Re: Is the back door open? From: Douglas Otis To: Andrew Newton Cc: MARID In-Reply-To: <26248864-E035-11D8-B79D-000A95B3BA44@hxr.us> References: <1090970806.11296.441.camel@ddev.mail-abuse.org> <1090976750.11296.591.camel@ddev.mail-abuse.org> <26248864-E035-11D8-B79D-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1090979424.11296.627.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 27 Jul 2004 18:50:24 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-07-27 at 18:26, Andrew Newton wrote: > On Jul 27, 2004, at 9:05 PM, Douglas Otis wrote: > > This jump to step 5 omits checks for From headers in the message. > > Right. My eyes missed the Resent-From. Sorry. > > > The random-1@dup.com could have been a local user, (it had the right > > domain), but when relayed to a MTA with a list of valid users, the mail > > was rejected as the local part 'random-1' was not valid. The MTA > > second > > to last in the chain, then bounces the message. This may allow > > filtering, or if done by a backup MTA, the knowledgeable server is > > expected to be out of service. > > Why would the first MTA receiving for dup.com not just reject the > message? > > -andy It could if the MTA either had a valid list of users, or attempted to deliver down stream to ascertain if the user was valid before completing the session. The MTA only knows it will relay for a domain. In the case of the backup MTA service, this 'knowledgeable' server is expected to be down. As a shortcut for administration or out of reluctance, lists of valid users may not be shared with some MTAs relying messages. These become a boon for those looking for a back door. This also becomes a valid reason for sticking with the ASRG ground work and dropping PRA. Contrary to moving away from the channel, the opposite is needed. There are several _really_ good methods for strongly ensuring the author when needed. Much better than the PRA stuff. In addition, PRA can never protect the network. Abating abuse should be the goal and not filtering where there will be a loss of integrity by design. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jul 27 22:10:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28326 for ; Tue, 27 Jul 2004 22:10:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S20Iql001182; Tue, 27 Jul 2004 19:00:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S20I9t001181; Tue, 27 Jul 2004 19:00:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S20H5h001174 for ; Tue, 27 Jul 2004 19:00:17 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i6S20NGN013161; Tue, 27 Jul 2004 19:00:23 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <3Z4Y72M3>; Tue, 27 Jul 2004 19:00:23 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Larry Seltzer'" , "'ietf-mxcomp@imc.org'" Subject: RE: How is SPF different from RMX? Date: Tue, 27 Jul 2004 19:00:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Larry makes the right point here, sure there are countermeasures, but the coutermeasures have costs and are vulnerable to coubter countermeasures. Senderid was chosen because of all the available measures it looked the most promising. I have seen no idea that appears to offer more and even if such an idea was proposed now the boats are burned. We cannot embark on a new course until this project is completed. -----Original Message----- From: Larry Seltzer [mailto:larry@larryseltzer.com] Sent: Tue Jul 27 16:28:38 2004 To: ietf-mxcomp@imc.org Subject: RE: How is SPF different from RMX? >>> With the preceding in mind, how does SPF prevent a virus-infected, >>> hijacked computer from sending abuse email? > It doesn't. It DOES, however, make them accountable to either the domain used by the owner of the infected machine, or by a throw-away spammer domain. It's worth pointing out, unless I'm mistaken, that the entire endemic population of mail worms would fail under SPF. None of them would authenticate because they all pick MAIL FROM addresses essentially at random and then use built-in MTAs, none of which will be registered in any DNS. It would also be much harder to write one that would be successful, and the messages would actually come from where they purport to come from, making it easier to shut down the worm. For instance, if there is a throwaway domain involved it would be quickly shut down. From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 00:21:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03591 for ; Wed, 28 Jul 2004 00:21:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S4A6ax028930; Tue, 27 Jul 2004 21:10:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S4A6Lt028929; Tue, 27 Jul 2004 21:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S4A5Qq028915 for ; Tue, 27 Jul 2004 21:10:05 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BpflW-0001NI-9z for ietf-mxcomp@imc.org; Tue, 27 Jul 2004 23:10:12 -0500 To: "IETF MARID WG" References: <20040726124139.GA8853@danisch.de> <0C9C2613-DF17-11D8-B79D-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 27 Jul 2004 23:10:06 -0500 In-Reply-To: <0C9C2613-DF17-11D8-B79D-000A95B3BA44@hxr.us> (Andrew Newton's message of "Mon, 26 Jul 2004 11:18:29 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Reading list for IETF meeting? Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.5 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <0C9C2613-DF17-11D8-B79D-000A95B3BA44@hxr.us> Andrew Newton writes: > On Jul 26, 2004, at 8:41 AM, Hadmut Danisch wrote: > >> is there a list of all documents to read for preparing for >> the IETF meeting? >> > > good question. > > You can find all the drafts on the charter page: > http://www.ietf.org/html.charters/marid-charter.html Speaking of stuff that I've been intending to read for a while now, and would really like to read it before the IETF-60, are there ever going to be minutes of the interim meeting published? To the best of my knowledge, there were draft minutes published on the list a couple of times, but I can't find any final minutes on the MARID charter page or on the mailing list archive. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 00:24:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03741 for ; Wed, 28 Jul 2004 00:24:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S47nu9028528; Tue, 27 Jul 2004 21:07:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S47nXH028527; Tue, 27 Jul 2004 21:07:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S47mFI028519 for ; Tue, 27 Jul 2004 21:07:48 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BpfjJ-0001M2-CF for ietf-mxcomp@imc.org; Tue, 27 Jul 2004 23:07:54 -0500 To: "IETF MARID WG" References: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 27 Jul 2004 23:07:49 -0500 In-Reply-To: <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> (Greg Connor's message of "Mon, 26 Jul 2004 13:02:09 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.5 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> Greg Connor writes: > I think the assumption hidden here is that 2821 defines transport data, > and never content, and 2822 defines content, and never transport. > Perhaps this is true, but there was LONG discussion during the first > phase of MARID about "Choice of identity to operate on" and it was > decided at the outset that we want to be able to validate BOTH 2821 and > 2822 identities. No, it was decided that we would validate the RFC2821 identities first, and then go on to the 2822 identities. Yes, I know, the last time I brought this up (see http://www.imc.org/ietf-mxcomp/mail-archive/msg02598.html ), both PHB and you said that you didn't see who identities were important. That doesn't change the MARID charter and that doesn't change the co-chairs ruling that 2822 identities would be considered after 2821 identities. I dunno. Maybe rulings by co-chairs aren't important and can be ignored. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 01:51:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07661 for ; Wed, 28 Jul 2004 01:51:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S5ZDZk056779; Tue, 27 Jul 2004 22:35:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S5ZDlg056778; Tue, 27 Jul 2004 22:35:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S5ZAAX056676 for ; Tue, 27 Jul 2004 22:35:10 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 235FA132CF8; Wed, 28 Jul 2004 01:36:00 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 77B2F605; Wed, 28 Jul 2004 01:35:10 -0400 (EDT) Date: Wed, 28 Jul 2004 01:35:10 -0400 From: Meng Weng Wong To: Terje Petersen Cc: IETF MARID WG Subject: Re: alternate submitter syntax Message-ID: <20040728053510.GN16317@dumbo.pobox.com> References: <3CA474173FC0274799F97F3AB3BD25EE1A7817@ltwd-svr2.lightwood.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A7817@ltwd-svr2.lightwood.com.au> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jul 28, 2004 at 11:22:14AM +1000, Terje Petersen wrote: | | What your example suggests to me is that you want SUBMITTER to work | differently to what I understand. | | It seems to me that you want the MAIL FROM parameter to be the bounce | address only if there is no SUBMITTER parameter. If there is a SUBMITTER | parameter then the bounce address is specified by SUBMITTER. No, I expect the bounce address to always be MAIL FROM. I expect the subject of SPF checking to be SUBMITTER if it is present, and MAIL FROM if it is not. | You want the meaning of MAIL FROM to change to being equivalent to the | RFC.2822 FROM address. No, I don't. From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 02:41:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08059 for ; Wed, 28 Jul 2004 02:41:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S6NEZ2086231; Tue, 27 Jul 2004 23:23:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S6NEl8086230; Tue, 27 Jul 2004 23:23:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S6NCHG086210 for ; Tue, 27 Jul 2004 23:23:13 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: alternate submitter syntax Date: Wed, 28 Jul 2004 16:23:11 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A781A@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6S6NEHG086222 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, Jul 28, 2004 at 11:22:14AM +1000, Terje Petersen wrote: | | What your example suggests to me is that you want SUBMITTER to work | differently to what I understand. | | It seems to me that you want the MAIL FROM parameter to be the bounce | address only if there is no SUBMITTER parameter. If there is a SUBMITTER | parameter then the bounce address is specified by SUBMITTER. No, I expect the bounce address to always be MAIL FROM. I expect the subject of SPF checking to be SUBMITTER if it is present, and MAIL FROM if it is not. | You want the meaning of MAIL FROM to change to being equivalent to the | RFC.2822 FROM address. No, I don't. =================================== === TERJE RESPONDS BELOW ===== =================================== Okay. Well that does take the whole thing a very long way from where I understood it to be. So if we can summarise what you are saying we have this:- SCENERIO-A: SUBMITTER parameter NOT supported on MTA. MAIL FROM = BOUNCE ADDRESS (SPF TESTED) SUBMITTER = NOT APPLICABLE RFC.2822.FROM = REPLY ADDRESS (NOT SPF TESTED) SCENERIO-B: SUBMITTER parameter IS supported on MTA. MAIL FROM = BOUNCE ADDRESS (NOT SPF TESTED) SUBMITTER = OTHER ADDRESS (SPF TESTED) RFC.2822.FROM = REPLY ADDRESS (NOT SPF TESTED) And in this second scenario I think you are saying that the addresses can all be different. Which does not seem to solve the phishing problem. So what am I missing here? I've read the proposed standard, however what your saying sounds very different to what I understood. Based on what I now think you are saying I am left asking myself what is the point of SUBMITTER. I can no longer see any reason for its existence. And if when there is a SUBMITTER parameter you no longer test the validity of the BOUNCE address then isn't that just another loophole to allow denial of service attacks. For instance a virus sends itself as follows:- MAIL FROM: SUBMITTER= RCPT TO: The SUBMITTER address may pass the SPF check but down the track all the non deliverable mail all bounces back to poor old bill. You seem to be giving up one of the prime benefits of SPF classic. From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 02:46:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08461 for ; Wed, 28 Jul 2004 02:46:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S6WlrD090984; Tue, 27 Jul 2004 23:32:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S6WlFZ090982; Tue, 27 Jul 2004 23:32:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S6WhDp090942 for ; Tue, 27 Jul 2004 23:32:43 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BphzW-00013P-00 for ; Wed, 28 Jul 2004 08:32:42 +0200 Received: from 212.82.251.4 ([212.82.251.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Jul 2004 08:32:42 +0200 Received: from nobody by 212.82.251.4 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Jul 2004 08:32:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT Date: Wed, 28 Jul 2004 08:24:28 +0200 Organization: Lines: 14 Message-ID: <4107469C.1A56@xyzzy.claranet.de> References: <3CA474173FC0274799F97F3AB3BD25EE1A77FF@ltwd-svr2.lightwood.com.au> <1090872128.525.91.camel@dhcp-163-154-36-247.corp.sgi.com> <200407262349.15344@totor.bouissou.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.4 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Michel Bouissou wrote: > we could simply recommend that MUAs SHOULD display the > as well as the "From: " header field Yes, I like this. I'd recommend to treat MAIL FROM != From _without_ Sender like MAIL FROM == Sender. This would solve a SPF classic / Sender-Id incompatibility for legacy software. For "MAIL FROM" read "address minus old routing stuff", for "!= From" read "does not match any From address", and for "== Sender" read "matches the Sender address". Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 08:13:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24954 for ; Wed, 28 Jul 2004 08:13:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SBuPAN048332; Wed, 28 Jul 2004 04:56:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SBuPOV048331; Wed, 28 Jul 2004 04:56:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SBuPwB048322 for ; Wed, 28 Jul 2004 04:56:25 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 28 Jul 2004 07:56:22 -0400 id 000DFCEB.41079468.000012B6 In-Reply-To: <1090979424.11296.627.camel@ddev.mail-abuse.org> References: <1090970806.11296.441.camel@ddev.mail-abuse.org> <1090976750.11296.591.camel@ddev.mail-abuse.org> <26248864-E035-11D8-B79D-000A95B3BA44@hxr.us> <1090979424.11296.627.camel@ddev.mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <228025AC-E08D-11D8-B79D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: MARID From: Andrew Newton Subject: Re: Is the back door open? Date: Wed, 28 Jul 2004 07:56:18 -0400 To: Douglas Otis X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 27, 2004, at 9:50 PM, Douglas Otis wrote: > It could if the MTA either had a valid list of users, or attempted to > deliver down stream to ascertain if the user was valid before > completing > the session. The MTA only knows it will relay for a domain. In the > case of the backup MTA service, this 'knowledgeable' server is expected > to be down. As a shortcut for administration or out of reluctance, > lists of valid users may not be shared with some MTAs relying messages. Why do you need a list of valid users to do a Sender-ID check? -andy From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 08:13:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25006 for ; Wed, 28 Jul 2004 08:13:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SC2aWN050450; Wed, 28 Jul 2004 05:02:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SC2auL050449; Wed, 28 Jul 2004 05:02:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts20-srv.bellnexxia.net (tomts20.bellnexxia.net [209.226.175.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SC2Zj2050443 for ; Wed, 28 Jul 2004 05:02:35 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.206.18]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040728120235.BLEN26030.tomts20-srv.bellnexxia.net@ibmrkydk2ufvdd>; Wed, 28 Jul 2004 08:02:35 -0400 From: "John Glube" To: "'Andrew Newton'" , "'Terje Petersen'" , "'Douglas Otis'" , "'Meng Weng Wong'" Cc: "'MARID'" Subject: Back doors and syntax Date: Wed, 28 Jul 2004 08:02:18 -0400 Message-ID: <000001c4749a$bb9fbc90$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <1090979424.11296.627.camel@ddev.mail-abuse.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6SC2aj2050444 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit With the recent issues raised by Douglas Otis concerning the PRA algorithm: http://www.imc.org/ietf-mxcomp/mail-archive/msg02865.html and Terje Petersen concerning Submitter: http://www.imc.org/ietf-mxcomp/mail-archive/msg02828.html have the MARID proponents: * Sought out senior IETF review of Marid core and Submitter proposals from "security and operations geeks?" See the urgent suggestion of Dave Crocker on July 19, "with one candidate source for reviewers being http://graybeards.net/sirs/index.html." http://www.imc.org/ietf-mxcomp/mail-archive/msg02751.html * Considered putting forward a panel of reviewers for consideration by the WG Chairs and Technical Advisors as per a suggestion in the same thread. http://www.imc.org/ietf-mxcomp/mail-archive/msg02771.html * Or otherwise are the WG Chairs aware of any steps being taken by the MARID proponents to have such a review carried out and if so, do we have any idea when this review would be available for the benefit of the WG? I ask because to the best of my knowledge there has been no large scale field testing of MARID core or SUBMITTER to verify the proposals and therefore the WG may benefit from such a review. On a separate note, in reading the SPF "help mailing list," it is becoming apparent one implementation issue is going to be mis-configured DNS set ups. This seems to be happening with "mom and pop" shops all the way up to and including large corporations with huge networks and IT departments. Would it be helpful if there was a statement in the MARID protocol suggesting that implementers for senders should endeavour to ensure DNS set ups are in compliance with the appropriate RFC's, prior to publishing an SPF record to avoid problems? I appreciate this may be a statement of the obvious, but ... many folks are going to want to publish a record either on their own and this might help with implementation. John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004 From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 12:13:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10780 for ; Wed, 28 Jul 2004 12:13:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SG1u8S019891; Wed, 28 Jul 2004 09:01:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SG1u2v019890; Wed, 28 Jul 2004 09:01:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SG1lhA019854 for ; Wed, 28 Jul 2004 09:01:47 -0700 (PDT) (envelope-from rms@gnu.org) Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BpqsH-0004ra-Ly; Wed, 28 Jul 2004 12:01:49 -0400 From: Richard Stallman To: "Hallam-Baker, Phillip" CC: bortzmeyer@nic.fr, pbaker@verisign.com, michel@bouissou.net, ietf-mxcomp@imc.org In-reply-to: (pbaker@verisign.com) Subject: Re: Sender-ID and free software Reply-to: rms@gnu.org References: Message-Id: Date: Wed, 28 Jul 2004 12:01:49 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You do not have any idea who is acting in bad faith here. Accusing people of being dishonest because of who they work for is not acceptable. I am not sure who that was meant to refer to, but I don't believe I have accused anyone of being dishonest. Microsoft's internal documents (the Halloween documents) said years ago that they would try to use patents to hold back their free software competition. If I understand correctly, that's precisely what they have proposed to do here. (If I am factually mistaken about part of this, please show me.) I made a small surmise that Gates had planned to put that general approach into effect on the spam issue. I acknowledge I have no proof of that; if you prefer, we can suppose that Microsoft stumbled blindly across the opportunity. Either way, the danger is the same. A previous message on this list alluded to the idea of linking free programs with a non-free library that would carry out Microsoft's sender-id proposal. This would not solve the problem of exclusion of free operating systems, because this is a non-free solution. Free operating systems cannot come with, or recommend the user install, such a library. (Such linking would also violate the GNU GPL if done with a GPL-covered mailer.) Freedom-lovers, caught between the Microsoft license and the specification, would have to try to break out in whichever direction offered the best chance of escaping with freedom intact. However, since Microsoft's aim (as stated in those documents) is to hold back the competition from "Linux" rather than to attack freedom as such, this loophole could make the plan ineffective for Microsoft. That argument may carry weight for convincing Microsoft it is not worth while to insist on that license. From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 12:13:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10806 for ; Wed, 28 Jul 2004 12:13:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SG2PqI020015; Wed, 28 Jul 2004 09:02:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SG2PDw020014; Wed, 28 Jul 2004 09:02:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SG2OKH020008 for ; Wed, 28 Jul 2004 09:02:24 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 28 Jul 2004 12:02:23 -0400 id 000D8186.4107CE0F.0000366F In-Reply-To: References: <20040726124139.GA8853@danisch.de> <0C9C2613-DF17-11D8-B79D-000A95B3BA44@hxr.us> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81DB1E68-E0AF-11D8-B79D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: Reading list for IETF meeting? Date: Wed, 28 Jul 2004 12:02:20 -0400 To: wayne Schlitt X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 28, 2004, at 12:10 AM, wayne wrote: > To the best of my knowledge, there were draft minutes published on the > list a couple of times, but I can't find any final minutes on the > MARID charter page or on the mailing list archive. To the best of my knowledge, the secretariat never posts minutes to the charter page of a working group (at least, I've never seen it). I've also been rooting around the IETF webpage trying to figure out where interim meeting minutes are posted and can't seem to find that (the minutes for plenary meeting sessions do have a webpage, btw). I'll send a request to have the minutes posted to the charter page if that is possible. In the meantime, here they are: Minutes of the MARID Interim Meeting - May 19 & 20, 2004 Chairs: Andy Newton Marshall Rose Scribe: Marshall Rose Jabber Logs: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-05-19.html http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-05-20.html Room Hums: From item 4: support for being able separately express legitimate, illegitimate, and unknown IP addresses. From item 5: support for a hint regarding a reputation/accreditation service. From item 9: positive feedback on the merged SPF/Caller-ID plan. From item 11: support for a "wildcard-like" function. Item 1: Agenda Bashing Andy put forward the following draft agenda: agenda bashing, notes from the chair, semantics with subitems of bounce address tag validation and the 30% solution, DNS record type discussion, and syntax. The expectation was that the first day was to cover up to the semantics, and the second day would lead off with a DNS discussion. Andy also noted that the agenda would be fluid and would probably change as the meeting progressed. Dave Crocker asked for time for a discussion on regarding the problems being solved by the each proposal by decomposing the mechanisms used in the proposals. Based on the sense of the room, Andy asked for that topic to be covered after the DNS topic. Item 2: Chair notes Andy simply asked the room to be courteous and professional and remember that all participants should be in the room for the purpose of working toward consensus. Item 3: Bounce Address Tag Validation - Dave Crocker presenting The main concept on this item is that the bounce address (2821.MAILFROM) is to be signed. The syntax would be: as = "/" "/" The local part is opaque to the Internet, and is only meaningful to the domain specified by the domain part. This concept has two modes based on the sig-type: the first mode uses a secret symmetric key so validation is only done by the domain in the domain-part of the address, and the second mode uses a public key so that receivers may verify the address with public key management being done via domain keys. Many participants questioned the need for standardization since it could be done unilaterally (without coordination of the rest of the Internet). Dave noted that even in the first mode, there may be multiple software components using this validation. He also noted that the first mode stops joe-jobs at the destination while the second mode stops joe-jobs at the source (of injection). Concerns about replay attacks were mentioned. Dave suggested that a timestamp or some other data in the hash may solve the problem. Many comparisons with other bounce prevention/protection schemes were raised. One participant mentioned that Dave's proposal sounded similar to an old version of the SES proposal. It was also suggested that this could best be handled via a BCP rather than a standard. Item 4: 30% Solution Semantics - Pete Resnick presenting Pete presented the "30% Solution": receiving server takes "claimed" domain name to lookup MARID records describing IP addresses and flags containing the source (mail-from, ehlo, etc...), flags for legitimacy, resolution type. Jim Lyon compared this solution to SPF and Caller-ID, and noted the similarities. The group discussed sets of IP addresses as either legitimate, illegitimate, or unknown. Subtopics covered deriving the set of unknown and/or illegitimate from the set of legitimate using set subtraction, explicit definition of the sets, etc... Andy asked for a hum on the need for independently expressing the three sets; there was a loud hum for it. Item 5: 40% Solution Semantics - Pete Resnick presenting Pete presented his interpretation of the "40% Solution": receiving server queries type for legitimate, illegitimate, and unknown status with "claimed" domain, with subsequent lookups on other types if no data is found. Many of the participants expressed concern over the multiple lookups and perceived serial chaining of lookups with respect to latency. Many participants did not understand the nature of the second query with respect to the first. The group then undertook a discussion on reputation services. There was debate about these services being about reputation or accreditation. Concern was expressed that the group did not possess the needed understanding of either reputation or accreditation services to adequately define either. The group then discussed the necessity to provide a hint to the reputation service. It was noted that a receiver would not outright trust any reputation hint from a sender, with the counter argument being that it allows receivers to only make a single reputation/accreditation inquiry if the hinted service is in the list of used services by the receiver (thus eliminating queries to multiple services). A hum was called on the ability to specify a hint which gives a domain that gives further information with respect to accreditation (and could be a second record). A loud hum was heard. Item 6: CAA Semantics - Douglas Otis presenting Doug presented his CAA proposal using SRV records, with follow-on discussion by the group. In summary, the input to the process is EHLO, with outputs being IP addresses, and a bridge mechanism for 2821.MAILFROM if EHLO does not match. Item 7: CSV Semantics - Dave Crocker presenting Dave presented the CSV proposals. The group discussed his assertion that HELO/EHLO is "channel-based" while MAIL FROM is "content-based" (in that it is tied to the sender). He also briefly discussed "vouching services". Item 8: Tagged Addressing - Sam Silberman presenting Sam presented issues around tagged addressing. The group discussed replay attacks and the affects of a MARID/LMAP solution on forwarding. Sam suggested that all forwarding be based on an opt-in relationship. The group then discussed problems with forwarding and LMAP/MARID solutions. The presentation ended with Ted Hardie noting that this working group does not have a charter allowing the breakage of core email functionality, and that the working group needs to produce an applicability statement on the problems being solved. Item 9: Caller-ID and SPF Converged - Jim Lyon presenting Jim presented a plan for convergence of SPF and Caller-ID. This convergence would merge the differences between 2821 and 2822 identity checking by using the 2822 header selection algorithm in Caller-ID and by promoting it back to a 2821 identity through a proposed SMTP extension called "RFROM" (responsible from). It was noted that 2821.MAILFROM is currently overloaded and RFROM would provide clarity while allowing the check to occur before the SMTP DATA command. There was some discussion over spammers adapting to RFROM, but Jim dismissed the concern. The new proposal would encompass the SPF semantics while using the XML encoding of Caller-ID. Jim gave several examples of how this would work. There was then some discussion on extension mechanisms and the necessity to get the semantics for it right. There was also concern that the proposal may be too complex and may contain features that are interesting but not necessary. Finally, a concern was raised regarding the number of recursive queries. Andy asked the room if they found the converged plan valuable and wise use of time and received a loud hum. During revision of the minutes, two participants expressed confusion regarding this hum. The confusion centers around the chairs asking the room if the merged SPF/Caller-ID proposal was a move in the right direction vs. asking the room the merged SPF/Caller-ID proposal was to be the direction of the working group. The chairs note that it was not their intention to ask at that time for committal to this merged proposal being the sole proposal to move forward in the working group. Additionally , during the revision of the minutes a participant (one of the two above) also recalls a failed hum for concurrent work on this merged proposal and other 2821 proposals and passed hum for to revisit other 2821 proposals at a later time (no such hums were recorded in the raw minutes of either the chairs or the Jabber sessions). Item 10: CSV Semantics Continued - Dave Crocker presenting Link - http://brandenburg.com/presentations/CSV-Summary.ppt //TODO: update Dave Crocker continued his presentation from the previous day on CSV, and explained the cut between the various CSV drafts. Dave's main point is that CSV is orthogonal to the SPF and Caller-ID solutions, and that CSV is inherently transitive unlike checks of MAIL FROM. A concerned was raised about multiple independent mechanisms. The group finished up the discussion with a comparison of the semantics of CSV with TLS and dial-back schemes. Item 11: DNS Considerations - Ed Lewis presenting Link - http://homepage.mac.com/resnick/copy_MARID-DNS.ppt //TODO: update Ed presented various issues with extending DNS based on past attempts. The group compared the advice to not use naming conventions with the popular use of SRV records. Many concluded that if SRV were to be defined today using this advice, it would not be feasible. Discussion also centered around adding a new RR type to DNS. Ed noted that the DNS community had previously been very uneasy in defining new record types for fear of depleting the namespace, but that fear no longer existed and new record types were considered the appropriate device for extending DNS. Many in the room were convince that adding a new record type to DNS would take 5 years or longer. The group undertook a long discussion regarding client DNS support. Some in the room felt that the issue should not sway the adoption of a new record type because it was relatively simple to write and deploy UDP DNS clients (one participant pointed out that most malware has its own simple code for this function). However, most of the participants in the room felt that current DNS library client support was lacking. One participant pointed to a vendor solution that used RPC instead of DNS in certain situations. Ted proposed a dual record type approach, whereby TXT records would be used in environments where a new record type could not be defined. The participants then discussed wildcards. It was noted that the "name hack" excluded the use of wildcards without new DNS server code. Using SOA records to determine zone cuts for the purposes of tree-walking was also discussed. Ed questioned the viability of such an algorithm. Andy asked for a hum of the room regarding the desire for a "wildcard-like" function and received a hum in favor of it. Item 12: Utility of Bounce Addresses - Pete Resnick presenting Pete started a discussion on bounces being tossed on the Internet by convention. This brought back many points for earlier discussions such as comparison of proposals using the EHLO banner for checking and the themes around tagged bounce address validation. Item 13: Action Items - Marshall Rose presiding Action 1 - Harry Katz, Jim Lyon and Meng Wong are to develop a schedule for the output of the SPF/Caller-ID converged drafts and send it to the list. Action 2 - All parties are to review IPR disclosures with respect to their proposal. Action 3 - Dave Crocker and Doug Otis are to develop a schedule for the output of CSV/CAA/SRV related drafts. Action 4 - Daniel Quinlan to write a draft to standardize the Received header format, and mention RFROM. From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 12:13:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10834 for ; Wed, 28 Jul 2004 12:13:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SG1Lca019734; Wed, 28 Jul 2004 09:01:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SG1Lxv019733; Wed, 28 Jul 2004 09:01:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SG1JQm019727 for ; Wed, 28 Jul 2004 09:01:19 -0700 (PDT) (envelope-from rms@gnu.org) Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Bpqro-0004nD-DO; Wed, 28 Jul 2004 12:01:20 -0400 From: Richard Stallman To: Nathaniel Borenstein CC: mrose@dbc.mtview.ca.us, michel@bouissou.net, ietf-mxcomp@imc.org In-reply-to: <8856E163-DFD9-11D8-B16C-000A9571873E@us.ibm.com> (message from Nathaniel Borenstein on Tue, 27 Jul 2004 10:30:39 -0400) Subject: Re: Sender-ID and free software Reply-to: rms@gnu.org References: <8856E163-DFD9-11D8-B16C-000A9571873E@us.ibm.com> Message-Id: Date: Wed, 28 Jul 2004 12:01:20 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: With respect, you're flat-out wrong in this context. For the community having this discussion, *the* important issue is stopping spam, which tops all surveys as the scourge of the Internet age. We often set out to solve one particular problem, but doing this properly implicitly means not replacing it with another problem. If you propose a solution that free software operating systems are not allowed to use, the price of using that solution would be our freedom. Some will choose your solution and give up their freedom; some of us will uphold our freedom and not support the solution. The issues you raise are serious ones, and I respect their importance. But they are only *slightly* more relevant to this mailing list than the relative merits of Levitra and Viagra as spam-enabling technologies. The question is whether your solution to one problem brings with it another problem. You have no control over Levitra and Viagra, but you do have an important say in this. Thanks in part to that history, I am confident that the IESG and IAB will not permit the emergence of a standard that excludes *anyone* from "full participation in email." I hope you are right. From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 12:25:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13046 for ; Wed, 28 Jul 2004 12:25:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SGBXj8022190; Wed, 28 Jul 2004 09:11:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SGBXw7022189; Wed, 28 Jul 2004 09:11:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.once.com (mail.once.com [207.162.212.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SGBWll022150 for ; Wed, 28 Jul 2004 09:11:32 -0700 (PDT) (envelope-from rordway@once.com) Received: from exchange2.once.com (exchange2.once.com [192.168.0.5]) by mail.once.com (8.12.8/8.12.8) with ESMTP id i6SGBMek012044; Wed, 28 Jul 2004 09:11:22 -0700 (PDT) Received: by exchange2.once.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Jul 2004 09:11:22 -0700 Message-ID: From: Ryan Ordway To: "'Andrew Newton'" , Douglas Otis Cc: MARID Subject: RE: Is the back door open? Date: Wed, 28 Jul 2004 09:11:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-100.2, required 5, AWL 0.00, QUOTED_EMAIL_TEXT -0.48, USER_IN_WHITELIST -100.00) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: Andrew Newton [mailto:andy@hxr.us] > Why do you need a list of valid users to do a Sender-ID check? Without a valid list of users, a mail gateway cannot simply reject a message to domains it is responsible for. For example: fleeblebur.org, let's say, has 3 MX hosts, ralph.fleeblebur.org with a priority of 0, fred.fleeblebur.org and bob.fleeblebur.org both with a priority of 10. ralph may have a valid user list, being the primary MX host which will handle the majority of mail. fred and bob may not, being simply configured to spool mail until ralph is back online. In this scenario, now that a given message is coming from trusted hosts, will Sender-ID be effective? Ryan -- Ryan Ordway Sr. Unix Systems Administrator @Once, Corp. Email: rordway@once.com From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 13:26:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18857 for ; Wed, 28 Jul 2004 13:25:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHBQZf037124; Wed, 28 Jul 2004 10:11:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SHBQLC037123; Wed, 28 Jul 2004 10:11:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHBQ4x037116 for ; Wed, 28 Jul 2004 10:11:26 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 28 Jul 2004 13:11:27 -0400 id 000D8180.4107DE3F.00003DCA In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: MARID , Douglas Otis From: Andrew Newton Subject: Re: Is the back door open? Date: Wed, 28 Jul 2004 13:11:24 -0400 To: Ryan Ordway X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 28, 2004, at 12:11 PM, Ryan Ordway wrote: > fleeblebur.org, let's say, has 3 MX hosts, > ralph.fleeblebur.org with a priority of 0, fred.fleeblebur.org and > bob.fleeblebur.org both with a priority of 10. ralph > may have a valid user list, being the primary MX host > which will handle the majority of mail. fred and bob > may not, being simply configured to spool mail until > ralph is back online. > > In this scenario, now that a given message is > coming from trusted hosts, will Sender-ID be effective? Are you saying that ralph cannot trust the data coming from fred and bob? If so, then there is a larger problem here. CSV could help this, but its utility here is allowing ralph to convert its IP-based whitelist to a domain-based whitelist. I assume that CSV is being designed for inter-domain MTA authentication/authorization because intra-domain problems can be solved in other ways (some that need no standards work and others that are already standardized). Regardless, what is stopping ralph, fred, and bob from doing Sender-ID or SPF checks? -andy From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 13:31:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19601 for ; Wed, 28 Jul 2004 13:31:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHOaGp040693; Wed, 28 Jul 2004 10:24:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SHOaqM040692; Wed, 28 Jul 2004 10:24:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHOZYu040658 for ; Wed, 28 Jul 2004 10:24:35 -0700 (PDT) (envelope-from daryl.odnert@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v6.0.0)); Wed, 28 Jul 2004 10:23:54 -0700 X-Server-Uuid: 2FF20946-3D64-4888-885C-250F7FE4E04F Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Wed, 28 Jul 2004 10:24:22 -0700 Message-ID: From: "Daryl Odnert" To: "'Terje Petersen'" , "IETF MARID WG" Subject: RE: alternate submitter syntax Date: Wed, 28 Jul 2004 10:24:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D193EA02X49299057-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C474C7.5A165228" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C474C7.5A165228 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit > SCENERIO-B: SUBMITTER parameter IS supported on MTA. > > MAIL FROM = BOUNCE ADDRESS (NOT SPF TESTED) > SUBMITTER = OTHER ADDRESS (SPF TESTED) > RFC.2822.FROM = REPLY ADDRESS (NOT SPF TESTED) > > > And in this second scenario I think you are saying that the addresses > can all be different. Which does not seem to solve the phishing problem. > So what am I missing here? I think what you're missing is this, from draft-ietf-marid-submitter-02.txt: If the receiving SMTP server allows the connecting SMTP client to transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message headers as described in [SENDER-ID]. If this purported responsible address does not match the address appearing in the SUBMITTER parameter, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter does not match header." Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C474C7.5A165228 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: alternate submitter syntax

> SCENERIO-B:   SUBMITTER parameter IS = supported on MTA.
>
>       MAIL = FROM     =3D   BOUNCE ADDRESS  (NOT = SPF TESTED)
>       = SUBMITTER     =3D   OTHER = ADDRESS   (SPF TESTED)
>     RFC.2822.FROM = =3D   REPLY ADDRESS   (NOT SPF TESTED)
>
>
> And in this second scenario I think you are = saying that the addresses
> can all be different. Which does not seem to = solve the phishing problem.
> So what am I missing here?

I think what you're missing is this, from = draft-ietf-marid-submitter-02.txt:

   If the receiving SMTP server allows the = connecting SMTP client to
   transmit message data, then the server = SHOULD determine the purported
   responsible address of the message by = examining the RFC 2822 message
   headers as described in = [SENDER-ID].  If this purported responsible
   address does not match the address = appearing in the SUBMITTER
   parameter, the receiving SMTP server = SHOULD reject the message and
   when rejecting MUST use "550 5.7.1 = Submitter does not match header."

Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C474C7.5A165228-- From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 13:54:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21118 for ; Wed, 28 Jul 2004 13:54:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHhGRx045664; Wed, 28 Jul 2004 10:43:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SHhGN2045661; Wed, 28 Jul 2004 10:43:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHhFDp045652 for ; Wed, 28 Jul 2004 10:43:15 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 61C244149B; Wed, 28 Jul 2004 10:43:19 -0700 (PDT) Subject: Re: Is the back door open? From: Douglas Otis To: Andrew Newton Cc: MARID In-Reply-To: <228025AC-E08D-11D8-B79D-000A95B3BA44@hxr.us> References: <1090970806.11296.441.camel@ddev.mail-abuse.org> <1090976750.11296.591.camel@ddev.mail-abuse.org> <26248864-E035-11D8-B79D-000A95B3BA44@hxr.us> <1090979424.11296.627.camel@ddev.mail-abuse.org> <228025AC-E08D-11D8-B79D-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1091036598.11296.731.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 28 Jul 2004 10:43:18 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-07-28 at 04:56, Andrew Newton wrote: > On Jul 27, 2004, at 9:50 PM, Douglas Otis wrote: > > > It could if the MTA either had a valid list of users, or attempted to > > deliver down stream to ascertain if the user was valid before > > completing the session. The MTA only knows it will relay for a > > domain. In the case of the backup MTA service, this 'knowledgeable' > > server is expected to be down. As a shortcut for administration or > > out of reluctance, lists of valid users may not be shared with some > > MTAs relying messages. > > Why do you need a list of valid users to do a Sender-ID check? This could done using a domain with no records, open records, or to a relay MTA that opts to turn off Sender-ID channel checks. Sender-ID is not always 100%, due to its extremely large scope. With the expense of DNS wrenches, as a defensive posture, such checks could be postponed until it is at least determined the mail is for a valid user. Owning to the overhead involved, it would seem a poor assumption every point in the MTA path enables these checks. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 14:07:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22064 for ; Wed, 28 Jul 2004 14:07:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHwqDB048829; Wed, 28 Jul 2004 10:58:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SHwqP1048828; Wed, 28 Jul 2004 10:58:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHwpMc048813 for ; Wed, 28 Jul 2004 10:58:51 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id AF9AE4149D; Wed, 28 Jul 2004 10:58:52 -0700 (PDT) Subject: Re: Is the back door open? From: Douglas Otis To: Andrew Newton Cc: Ryan Ordway , MARID In-Reply-To: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> References: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1091037531.11296.762.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 28 Jul 2004 10:58:52 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-07-28 at 10:11, Andrew Newton wrote: > On Jul 28, 2004, at 12:11 PM, Ryan Ordway wrote: > > fleeblebur.org, let's say, has 3 MX hosts, > > ralph.fleeblebur.org with a priority of 0, fred.fleeblebur.org and > > bob.fleeblebur.org both with a priority of 10. ralph > > may have a valid user list, being the primary MX host > > which will handle the majority of mail. fred and bob > > may not, being simply configured to spool mail until > > ralph is back online. > > > > In this scenario, now that a given message is > > coming from trusted hosts, will Sender-ID be effective? > > Are you saying that ralph cannot trust the data coming from fred and > bob? If so, then there is a larger problem here. Only that messages are stored and then forwarded. > CSV could help this, but its utility here is allowing ralph to convert > its IP-based whitelist to a domain-based whitelist. I assume that CSV > is being designed for inter-domain MTA authentication/authorization > because intra-domain problems can be solved in other ways (some that > need no standards work and others that are already standardized). Although CSV could help make these intra-domain configurations safer, the problem was about how a resulting bounce is handled. Remember, Sender-ID ignores the RFC 2821 MAIL FROM. The defense against the bounce that once justified publishing these records has been removed by the PRA algorithm. > Regardless, what is stopping ralph, fred, and bob from doing Sender-ID > or SPF checks? If these checks are not done as messages are received, or where the sender is spoofing a domain with an open list or no records, then even with the checks, the mail is accepted and then bounced. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 14:36:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24055 for ; Wed, 28 Jul 2004 14:36:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SIMJNc055855; Wed, 28 Jul 2004 11:22:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SIMJq5055854; Wed, 28 Jul 2004 11:22:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SIMJ3V055833 for ; Wed, 28 Jul 2004 11:22:19 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i6SIMKUt030123 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Jul 2004 11:22:20 -0700 Date: Wed, 28 Jul 2004 11:22:20 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Douglas Otis cc: Andrew Newton , Ryan Ordway , MARID Subject: Re: Is the back door open? In-Reply-To: <1091037531.11296.762.camel@ddev.mail-abuse.org> Message-ID: References: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> <1091037531.11296.762.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 28 Jul 2004, Douglas Otis wrote: > Although CSV could help make these intra-domain configurations safer, > the problem was about how a resulting bounce is handled. Remember, > Sender-ID ignores the RFC 2821 MAIL FROM. The defense against the > bounce that once justified publishing these records has been removed by > the PRA algorithm. Doesn't protection against the bounce using SPF-Classic require 100% adoption to make it work? Wouldn't BATV or some other site-local protection against joe-jobbing have a more direct impact on this problem (which, I will note, is not necessarily the problem this group was chartered to address). -Rand From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 16:05:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01221 for ; Wed, 28 Jul 2004 16:05:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SJjWCI073984; Wed, 28 Jul 2004 12:45:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SJjWP2073983; Wed, 28 Jul 2004 12:45:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SJjVlB073962 for ; Wed, 28 Jul 2004 12:45:31 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id B8D81132CD1; Wed, 28 Jul 2004 15:46:31 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 874D0628; Wed, 28 Jul 2004 15:45:34 -0400 (EDT) Date: Wed, 28 Jul 2004 15:45:34 -0400 From: Meng Weng Wong To: Terje Petersen Cc: IETF MARID WG Subject: Re: alternate submitter syntax Message-ID: <20040728194534.GO16317@dumbo.pobox.com> References: <3CA474173FC0274799F97F3AB3BD25EE1A781A@ltwd-svr2.lightwood.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A781A@ltwd-svr2.lightwood.com.au> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jul 28, 2004 at 04:23:11PM +1000, Terje Petersen wrote: | | And if when there is a SUBMITTER parameter you no longer test the | validity of the BOUNCE address then isn't that just another loophole to | allow denial of service attacks. | | For instance a virus sends itself as follows:- | | MAIL FROM: | SUBMITTER= | RCPT TO: | | The SUBMITTER address may pass the SPF check but down the track all the | non deliverable mail all bounces back to poor old bill. | | You seem to be giving up one of the prime benefits of SPF classic. | If SUBMITTER appears on your whitelist, then you are infectedsucker@xyz.com, and can presumably do something about it. If SUBMITTER does not appear on your whitelist, then you can reject the message even if the SPF check passes. From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 16:21:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02158 for ; Wed, 28 Jul 2004 16:21:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SK4Gr1079708; Wed, 28 Jul 2004 13:04:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SK4Gar079707; Wed, 28 Jul 2004 13:04:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6SK4EWQ079664 for ; Wed, 28 Jul 2004 13:04:15 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 68311 invoked by uid 1013); 28 Jul 2004 20:04:07 -0000 Date: Wed, 28 Jul 2004 22:04:07 +0200 From: Markus Stumpf To: Larry Seltzer Cc: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? Message-ID: <20040728200407.GI65482@Space.Net> References: <20040727221835.4794816E17@mail.nitros9.org> <200407272304.i6RN4N9j062152@above.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407272304.i6RN4N9j062152@above.proper.com> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jul 27, 2004 at 07:04:18PM -0400, Larry Seltzer wrote: > It's worth pointing out, unless I'm mistaken, that the entire endemic > population of mail worms would fail under SPF. None of them would > authenticate because they all pick MAIL FROM addresses essentially at > random and then use built-in MTAs, none of which will be registered in > any DNS. People have domains and use them. Modern viruses contruct new sender/receiver address pairs by randomly mixing user and domain parts of addresses they find anywhere on the infected host. Only the DE zone has as of now 7,788,391 second level domains. Today (21:52 GMT+2) there were 2038 new registrations. Do you really seriously think that the mechanisms developed by this group during the last five months will be deployed by a significant part of the existing domains within the next 5 years? I think it will take a really long time before the first virus or worm will be rejected at SMTP level because of SPF or any similar method and if it can't be caught before the DATA command it doesn't make a difference, because then the message will be received and it is probably cheaper to let the virus scanner catch it instead of cruising the DNS, collect records and feed all this to a spam filter for evaluation that classifies it then to a "maybe spam" folder, IF the sender domain has deployed SPF or similar methods at all. But as Phillip wrote the train is on the way and we'll see how many will jump on it and how many will jump off and how many won't simply care at all. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 17:49:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08831 for ; Wed, 28 Jul 2004 17:49:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SLZX8L002142; Wed, 28 Jul 2004 14:35:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SLZXK2002141; Wed, 28 Jul 2004 14:35:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SLZTrx002111 for ; Wed, 28 Jul 2004 14:35:29 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id BE02D132CD1; Wed, 28 Jul 2004 17:36:28 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id BBC7B628; Wed, 28 Jul 2004 17:35:30 -0400 (EDT) Date: Wed, 28 Jul 2004 17:35:30 -0400 From: Meng Weng Wong To: Markus Stumpf Cc: Larry Seltzer , ietf-mxcomp@imc.org Subject: an excerpt from my SPF rejection logs Message-ID: <20040728213530.GP16317@dumbo.pobox.com> References: <20040727221835.4794816E17@mail.nitros9.org> <200407272304.i6RN4N9j062152@above.proper.com> <20040728200407.GI65482@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040728200407.GI65482@Space.Net> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jul 28, 2004 at 10:04:07PM +0200, Markus Stumpf wrote: | | I think it will take a really long time before the first virus or | worm will be rejected at SMTP level because of SPF or any similar | method and if it can't be caught before the DATA command it doesn't | make a difference, because then the message will be received and it 2004-07-27 18:13:07 : SPF fail: sender=qgcyvotmbd%40topmail.de&ip=69.166.143.181, domain of qgcyvotmbd@topmail.de does not designate 69.166.143.181 as permitted sender 2004-07-27 18:15:48 : SPF neutral: sender=mhtuuldnvh%40hotmail.com&ip=207.8.226.3, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-27 18:52:38 : SPF neutral: sender=bernardcallaway%40hotmail.com&ip=24.218.254.106, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-27 19:42:14 : SPF neutral: sender=gkskeocnfdfd%40hotmail.com&ip=218.155.37.165, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-27 21:23:50 : SPF neutral: sender=vgrove_ay%40aol.com&ip=208.58.1.194, 208.58.1.194 is neither permitted nor denied by domain of vgrove_ay@aol.com 2004-07-27 22:14:09 : SPF fail: sender=khathi%40yahoo.com&ip=208.210.124.70, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-27 22:33:49 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=207.93.212.56, domain of noreply@dumbo.pobox.com does not designate 207.93.212.56 as permitted sender 2004-07-27 22:33:49 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=207.93.212.56, domain of noreply@dumbo.pobox.com does not designate 207.93.212.56 as permitted sender 2004-07-27 22:33:57 : SPF neutral: sender=ub6s3au%40hotmail.com&ip=207.8.226.2, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-27 23:22:31 : SPF fail: sender=obzipbvs%40yahoo.com&ip=208.210.124.73, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-27 23:50:13 : SPF neutral: sender=kmobley_qo%40aol.com&ip=208.210.124.70, 208.210.124.70 is neither permitted nor denied by domain of kmobley_qo@aol.com 2004-07-27 23:57:47 : SPF fail: sender=lkling146%40yahoo.com&ip=208.58.1.198, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-27 23:57:47 : SPF fail: sender=mandynsl%40yahoo.com&ip=208.58.1.198, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-27 23:58:05 : SPF neutral: sender=soonyee_wong%40hotmail.com&ip=219.94.101.106, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 00:44:12 : SPF fail: sender=spf-discuss%40v2.listbox.com&ip=82.77.64.5, domain of spf-discuss@v2.listbox.com does not designate 82.77.64.5 as permitted sender 2004-07-28 00:51:26 : SPF fail: sender=ffwypcwtsu%40uol.com.br&ip=222.99.96.24, domain of ffwypcwtsu@uol.com.br does not designate 222.99.96.24 as permitted sender 2004-07-28 00:56:32 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=166.153.177.169, domain of postmaster@dumbo.pobox.com does not designate 166.153.177.169 as permitted sender 2004-07-28 00:56:34 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=166.153.177.169, domain of postmaster@dumbo.pobox.com does not designate 166.153.177.169 as permitted sender 2004-07-28 01:11:24 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=193.96.40.29, domain of noreply@dumbo.pobox.com does not designate 193.96.40.29 as permitted sender 2004-07-28 01:11:24 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=193.96.40.29, domain of noreply@dumbo.pobox.com does not designate 193.96.40.29 as permitted sender 2004-07-28 01:23:36 : SPF fail: sender=caminul_1%40yahoo.com&ip=82.137.16.154, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 01:25:46 : SPF neutral: sender=ryan_hue%40hotmail.com&ip=219.94.101.106, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 01:34:41 : SPF fail: sender=ham_yu%40yahoo.com&ip=219.94.101.106, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 01:56:25 : SPF neutral: sender=irene_lhl%40hotmail.com&ip=208.58.1.198, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 02:07:07 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=217.226.127.165, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 217.226.127.165 as permitted sender 2004-07-28 02:07:08 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=217.226.127.165, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 217.226.127.165 as permitted sender 2004-07-28 02:08:24 : SPF neutral: sender=kinetik_ang%40hotmail.com&ip=219.94.101.106, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 02:20:52 : SPF neutral: sender=CEFYZJXBS%40hotmail.com&ip=207.8.226.3, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 02:42:16 : SPF fail: sender=nsjptr%40yahoo.com&ip=222.117.216.227, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 02:45:51 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=217.165.80.205, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 217.165.80.205 as permitted sender 2004-07-28 02:45:53 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=217.165.80.205, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 217.165.80.205 as permitted sender 2004-07-28 03:06:13 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=166.180.38.10, domain of noreply@dumbo.pobox.com does not designate 166.180.38.10 as permitted sender 2004-07-28 03:06:22 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=166.180.38.10, domain of noreply@dumbo.pobox.com does not designate 166.180.38.10 as permitted sender 2004-07-28 03:15:01 : SPF fail: sender=maxdu_de_varos%40yahoo.com&ip=219.94.101.106, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 03:33:09 : SPF neutral: sender=melody_holliday_gl%40hotmail.com&ip=208.58.1.193, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 03:38:41 : SPF neutral: sender=dkghs%40hotmail.com&ip=61.248.94.112, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 03:38:44 : SPF neutral: sender=dkghs%40hotmail.com&ip=61.248.94.112, 61.248.94.112 is neither permitted nor denied by domain of dkghs@hotmail.com 2004-07-28 03:57:31 : SPF neutral: sender=leison%40hotmail.com&ip=211.172.109.21, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 03:57:39 : SPF fail: sender=alexandr%40cedex.net&ip=211.178.13.133, domain of alexandr@cedex.net does not designate 211.178.13.133 as permitted sender 2004-07-28 04:01:25 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=203.200.26.134, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 203.200.26.134 as permitted sender 2004-07-28 04:01:59 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=203.200.26.134, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 203.200.26.134 as permitted sender 2004-07-28 04:02:19 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=209.157.48.1, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 209.157.48.1 as permitted sender 2004-07-28 04:18:22 : SPF fail: sender=ogdnx%40yahoo.com&ip=207.8.226.6, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 04:32:51 : SPF neutral: sender=nicoleycy%40hotmail.com&ip=208.58.1.193, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 04:33:03 : SPF neutral: sender=taifei%40hotmail.com&ip=219.94.101.106, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 04:50:56 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.171.135.222, domain of postmaster@dumbo.pobox.com does not designate 195.171.135.222 as permitted sender 2004-07-28 04:50:57 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.171.135.222, domain of postmaster@dumbo.pobox.com does not designate 195.171.135.222 as permitted sender 2004-07-28 04:58:53 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=80.90.7.24, domain of postmaster@dumbo.pobox.com does not designate 80.90.7.24 as permitted sender 2004-07-28 04:58:54 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=80.90.7.24, domain of postmaster@dumbo.pobox.com does not designate 80.90.7.24 as permitted sender 2004-07-28 04:59:05 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=193.41.195.11, domain of postmaster@dumbo.pobox.com does not designate 193.41.195.11 as permitted sender 2004-07-28 05:13:24 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=213.218.232.88, domain of noreply@dumbo.pobox.com does not designate 213.218.232.88 as permitted sender 2004-07-28 05:13:27 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=213.218.232.88, domain of noreply@dumbo.pobox.com does not designate 213.218.232.88 as permitted sender 2004-07-28 05:13:30 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=81.6.232.50, domain of noreply@dumbo.pobox.com does not designate 81.6.232.50 as permitted sender 2004-07-28 05:34:20 : SPF fail: sender=xyfxinqcygh%40yahoo.com&ip=207.8.226.2, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 05:42:12 : SPF neutral: sender=jmorvw%40aol.com&ip=208.210.124.70, 208.210.124.70 is neither permitted nor denied by domain of jmorvw@aol.com 2004-07-28 06:11:39 : SPF neutral: sender=lfchiow%40hotmail.com&ip=208.58.1.194, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 06:11:45 : SPF fail: sender=shiauchyn%40yahoo.com&ip=219.94.101.106, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 06:25:19 : SPF fail: sender=fcyeo2002%40yahoo.com&ip=219.94.101.106, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 06:37:19 : SPF neutral: sender=wmxalgfhixfe%40aol.com&ip=208.58.1.193, 208.58.1.193 is neither permitted nor denied by domain of wmxalgfhixfe@aol.com 2004-07-28 06:58:13 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=130.89.66.133, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 130.89.66.133 as permitted sender 2004-07-28 06:58:13 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=130.89.66.133, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 130.89.66.133 as permitted sender 2004-07-28 07:25:54 : SPF fail: sender=cjvvzmbsapss%40yahoo.com&ip=208.210.124.73, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 07:25:54 : SPF fail: sender=cjvvzmbsapss%40yahoo.com&ip=208.210.124.73, domain of cjvvzmbsapss@yahoo.com does not designate 208.210.124.73 as permitted sender 2004-07-28 08:05:14 : SPF fail: sender=andrei0241%40yahoo.com&ip=82.137.38.58, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 08:07:22 : SPF fail: sender=traschke%40yahoo.com&ip=200.183.75.132, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 08:10:08 : SPF softfail: sender=www%40mail.com&ip=80.178.80.244, transitioning domain of www@mail.com does not designate 80.178.80.244 as permitted sender 2004-07-28 08:22:39 : SPF fail: sender=202231%40dumbo.pobox.com&ip=61.31.145.12, domain of 202231@dumbo.pobox.com does not designate 61.31.145.12 as permitted sender 2004-07-28 08:22:40 : SPF fail: sender=202231%40vw.mailzone.com&ip=61.31.145.12, domain of 202231@vw.mailzone.com does not designate 61.31.145.12 as permitted sender 2004-07-28 08:28:51 : SPF fail: sender=adah%40yahoo.com&ip=207.8.226.3, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 09:03:37 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=199.172.212.254, domain of postmaster@dumbo.pobox.com does not designate 199.172.212.254 as permitted sender 2004-07-28 09:03:38 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=199.172.212.254, domain of postmaster@dumbo.pobox.com does not designate 199.172.212.254 as permitted sender 2004-07-28 09:03:41 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=199.172.192.5, domain of postmaster@dumbo.pobox.com does not designate 199.172.192.5 as permitted sender : SPF fail: sender=zpbad%40yahoo.com&ip=208.58.1.198, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 10:09:59 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=82.228.46.41, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 82.228.46.41 as permitted sender 2004-07-28 10:10:01 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=82.228.46.41, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 82.228.46.41 as permitted sender 2004-07-28 10:11:33 : SPF neutral: sender=utkvdmqhyamqh79598%40hotmail.com&ip=207.8.226.3, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 10:16:18 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=149.225.94.152, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 149.225.94.152 as permitted sender 2004-07-28 10:16:37 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=149.225.94.152, domain of MAILER-DAEMON@dumbo.pobox.com does not designate 149.225.94.152 as permitted sender 2004-07-28 10:35:46 : SPF softfail: sender=ncqddyaodfzpxf%40bk.ru&ip=66.214.251.32, transitioning domain of ncqddyaodfzpxf@bk.ru does not designate 66.214.251.32 as permitted sender 2004-07-28 10:41:30 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=216.68.162.139, domain of postmaster@dumbo.pobox.com does not designate 216.68.162.139 as permitted sender 2004-07-28 10:41:30 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=216.68.162.139, domain of postmaster@dumbo.pobox.com does not designate 216.68.162.139 as permitted sender 2004-07-28 10:41:51 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=192.128.134.71, domain of noreply@dumbo.pobox.com does not designate 192.128.134.71 as permitted sender 2004-07-28 11:15:03 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.208.209.117, domain of postmaster@dumbo.pobox.com does not designate 195.208.209.117 as permitted sender 2004-07-28 11:15:04 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.208.209.117, domain of postmaster@dumbo.pobox.com does not designate 195.208.209.117 as permitted sender 2004-07-28 11:15:08 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.208.208.19, domain of postmaster@dumbo.pobox.com does not designate 195.208.208.19 as permitted sender 2004-07-28 11:23:58 : SPF softfail: sender=ingmar%40seznam.cz&ip=207.8.226.3, transitioning domain of ingmar@seznam.cz does not designate 207.8.226.3 as permitted sender 2004-07-28 12:02:06 : SPF neutral: sender=mollyoconnell_pf%40bankkadr.com.pl&ip=211.115.216.225, 211.115.216.225 is neither permitted nor denied by domain of mollyoconnell_pf@bankkadr.com.pl 2004-07-28 13:28:10 : SPF fail: sender=nlwrs%40yahoo.com&ip=208.58.1.198, explicit fallback found: yahoo.com defines v=spf1 ptr -all 2004-07-28 13:52:07 : SPF neutral: sender=velasquezmario%40hotmail.com&ip=24.218.254.106, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 13:53:16 : SPF neutral: sender=fantastic34%40hotmail.com&ip=24.218.254.106, Microsoft Caller-ID for Email record at _ep.hotmail.com 2004-07-28 14:14:47 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=146.9.22.127, domain of postmaster@dumbo.pobox.com does not designate 146.9.22.127 as permitted sender 2004-07-28 14:14:54 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=146.9.22.127, domain of postmaster@dumbo.pobox.com does not designate 146.9.22.127 as permitted sender From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 17:50:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08904 for ; Wed, 28 Jul 2004 17:50:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SLdato003098; Wed, 28 Jul 2004 14:39:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SLda6j003096; Wed, 28 Jul 2004 14:39:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SLdZ49003089 for ; Wed, 28 Jul 2004 14:39:36 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 8C67C16E17 for ; Wed, 28 Jul 2004 17:47:28 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Is the back door open? In-Reply-To: Your message of "Wed, 28 Jul 2004 13:11:24 EDT." <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> Date: Wed, 28 Jul 2004 17:47:28 -0400 Message-Id: <20040728214728.8C67C16E17@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton wrote: > Are you saying that ralph cannot trust the data coming from fred and > bob? If so, then there is a larger problem here. I think Doug's point is more that information necessary for the MX to implement Sender-ID isn't distributed, but the incoming mail is. I won't get into issues of Sender-Id, but I haven't run an off-site secondary MX for "striker.ottawa.on.ca" for about 5 years. It was too difficult for me to distribute & maintain my anti-spam rules to the secondaries, so I just stopped using secondaries. From what I can see, many other domains have the same problem. Most of the mailing lists I run have messages which sit in the outgoing queues for days, because the destination MX is flaky. Over time, the number of such messages has been increasing. One of the benefits of any MARID approach *should* be that secondary MX's may now query & cache the MARID rules, which means that they can apply those rules themselves... which means secondary MX's may become more useful. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 18:03:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09665 for ; Wed, 28 Jul 2004 18:03:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SLmwAT005399; Wed, 28 Jul 2004 14:48:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SLmwj7005397; Wed, 28 Jul 2004 14:48:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SLmvnb005388 for ; Wed, 28 Jul 2004 14:48:58 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id EF04616E17 for ; Wed, 28 Jul 2004 17:56:50 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? In-Reply-To: Your message of "Wed, 28 Jul 2004 22:04:07 +0200." <20040728200407.GI65482@Space.Net> Date: Wed, 28 Jul 2004 17:56:50 -0400 Message-Id: <20040728215650.EF04616E17@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Markus Stumpf wrote: > Do you really seriously think that the mechanisms developed by this > group during the last five months will be deployed by a significant > part of the existing domains within the next 5 years? Are there any methods that *will* be deployed by a significant part of the existing domains within the next 5 years? If so, what are they? If not, what should we do instead of MARID? Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 18:22:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11721 for ; Wed, 28 Jul 2004 18:22:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SM6J1r010511; Wed, 28 Jul 2004 15:06:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SM6JsP010510; Wed, 28 Jul 2004 15:06:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SM6Jq5010482 for ; Wed, 28 Jul 2004 15:06:19 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 647A7414B5; Wed, 28 Jul 2004 15:06:19 -0700 (PDT) Subject: Re: Is the back door open? From: Douglas Otis To: Rand Wacker Cc: Andrew Newton , Ryan Ordway , MARID In-Reply-To: References: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> <1091037531.11296.762.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1091052378.11296.1160.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 28 Jul 2004 15:06:18 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-07-28 at 11:22, Rand Wacker wrote: > On Wed, 28 Jul 2004, Douglas Otis wrote: > > > Although CSV could help make these intra-domain configurations safer, > > the problem was about how a resulting bounce is handled. Remember, > > Sender-ID ignores the RFC 2821 MAIL FROM. The defense against the > > bounce that once justified publishing these records has been removed by > > the PRA algorithm. > > Doesn't protection against the bounce using SPF-Classic require 100% > adoption to make it work? Wouldn't BATV or some other site-local > protection against joe-jobbing have a more direct impact on this problem > (which, I will note, is not necessarily the problem this group was > chartered to address). > > -Rand SPF offered some relief, if the MTA creating the bounce checked the destination domain records for valid sources of the message. This is lost with Sender-ID. A solution for this problem could be found through a combination of SPF and BATV, where BATV is less disruptive. SPF accommodates an address based white-list, but such a list would be of less use, with CSV offering names. Should end-users or the MTA make accept/reject decisions? The forward/reverse model for MX records is not symmetrical. Some 'forward path' is visible, but this view is not comprehensive. Rejection based against a sending domain's 'reverse path' is daunting, but must be comprehensive. Rejection based upon a sending host-name falls within an achievable realm for DNS, and ideally accomplished with a single query, as with CSV. The host-name relationship broadens to the sending domain within the realm of accreditation. The quest for a 'reverse path' still does not permit a decision of whether to reject the message, if to avoid abuse. A quest to examine content only weakens a decision process with complexity. The decision whether to reject the message is best based upon RFC 2821 information. The result should not be a rating for an end-user disposition of messages. It would be hard to twist the charter to arrive at that goal. A standard method to sign RFC 2821 MAIL FROM paths, as with BATV, would end schemes used by rogue mailers to skirt accreditation. This skirting takes advantage of MTAs that do not employ history, and a reason for many spoofed addresses. If the sending domain has a history, acceptance is based upon the sending domain's demonstration of policy. If the sending domain does not have a history, then mail could be constrained. For economies of scale, the burden must be placed upon the sender. This burden would result from their history of behavior. If the sending domain is rejected as a result of their accumulated history, then it becomes their burden as the sender. It must not be seen as a problem for the end-user to sort, filter, and delete. Grading makes mail unreliable and eventually useless. History based accreditation is best done with a known name of the sending domain responsible for policy. This is the specific aim of CSV. To stop spam or viruses, the question remains, what is the history of the domain? Construction of a partial 'reverse path' or examination of content for filtering does little to abate abuse. The quest for 'reverse path' based grading begs for restrictions upon end-users to a limited choice of a mailbox, or forces exposure of an additional mailbox, while breaking many programs. Freedoms offered by mail can be preserved, rather than sacrificed for new folders in a mailer program. These introduced identities resemble a shell game, where the end-user guesses the significance of different headers, most unrelated to the author of message. There are straight forward and strong means to identify the author that do not break mail. Sender-ID does not identify which domain allowed introduction of abusive mail. There can be no solution without this information. If a domain demonstrates a history of neglect, then a growing number of rejected messages will make economic sense for polices to be repaired. Sender-ID is useless in this regard. Put the burden upon the sender, and not the recipient. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 18:24:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11802 for ; Wed, 28 Jul 2004 18:24:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SMDsaA012603; Wed, 28 Jul 2004 15:13:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SMDs4L012602; Wed, 28 Jul 2004 15:13:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SMDs3i012591 for ; Wed, 28 Jul 2004 15:13:54 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 28 Jul 2004 18:13:57 -0400 id 0002C2C3.41082525.00005E3B In-Reply-To: <20040728214728.8C67C16E17@mail.nitros9.org> References: <20040728214728.8C67C16E17@mail.nitros9.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: Andrew Newton Subject: Re: Is the back door open? Date: Wed, 28 Jul 2004 18:13:55 -0400 To: "Alan DeKok" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 28, 2004, at 5:47 PM, Alan DeKok wrote: > I think Doug's point is more that information necessary for the MX > to implement Sender-ID isn't distributed, but the incoming mail is. I understand this point. I just don't think it is valid because it assumes that the "To:" identity (either 2821 or 2822) is part of the Sender-ID (or SPF) equation. Why does an MTA need to know the "To" in order to check the "From"? > I won't get into issues of Sender-Id, but I haven't run an off-site > secondary MX for "striker.ottawa.on.ca" for about 5 years. It was too > difficult for me to distribute & maintain my anti-spam rules to the > secondaries, so I just stopped using secondaries. This is my experience as well. > One of the benefits of any MARID approach *should* be that secondary > MX's may now query & cache the MARID rules, which means that they can > apply those rules themselves... which means secondary MX's may become > more useful. I agree. -andy From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 19:04:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13699 for ; Wed, 28 Jul 2004 19:04:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SMrUY0023026; Wed, 28 Jul 2004 15:53:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SMrU5M023025; Wed, 28 Jul 2004 15:53:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SMrSTv022983 for ; Wed, 28 Jul 2004 15:53:29 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id C3F7B28272 for ; Thu, 29 Jul 2004 00:53:24 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03133-03 for ; Thu, 29 Jul 2004 00:53:13 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id EE6A52829C; Thu, 29 Jul 2004 00:53:12 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: an excerpt from my SPF rejection logs Date: Thu, 29 Jul 2004 00:53:12 +0200 User-Agent: KMail/1.6.1 References: <20040727221835.4794816E17@mail.nitros9.org> <20040728200407.GI65482@Space.Net> <20040728213530.GP16317@dumbo.pobox.com> In-Reply-To: <20040728213530.GP16317@dumbo.pobox.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407290053.12479@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le mercredi 28 Juillet 2004 23:35, Meng Weng Wong a écrit : > On Wed, Jul 28, 2004 at 10:04:07PM +0200, Markus Stumpf wrote: > | I think it will take a really long time before the first virus or > | worm will be rejected at SMTP level because of SPF or any similar > | method and if it can't be caught before the DATA command it doesn't > | make a difference, because then the message will be received and it > > 2004-07-27 18:13:07 : SPF fail: > sender=qgcyvotmbd%40topmail.de&ip=69.166.143.181, domain of > qgcyvotmbd@topmail.de does not designate 69.166.143.181 as permitted sender I have a couple as well on my humble little machine ;-) and keeps getting more everyday : the damned thing works :-)) Plain ole' good classic SPF ;-) Résultats SPF sur totor.bouissou.net le Jul 27 : Jul 27 04:02:42 totor postfix/smtpd[30484]: NOQUEUE: reject: RCPT from unknown[211.139.120.2]: 550 : Sender address rejected: Violation SPF: Mail de alien@12inch.com doit etre transmis depuis serveur approuve pour domaine 12inch.com. Contactez administrateur de 12inch.com pour plus d'info, ou voyez http://spf.pobox.com/why.html?sender=alien%4012inch.com&ip=211.139.120.2&receiver=totor.bouissou.net; from= to= proto=ESMTP helo= Jul 27 05:53:14 totor postfix/smtpd[8932]: NOQUEUE: reject: RCPT from unknown[200.37.86.106]: 550 : Sender address rejected: Violation SPF: Mail de dude@bouissou.net doit etre transmis depuis serveur approuve pour domaine bouissou.net. Contactez administrateur de bouissou.net pour plus d'info, ou voyez http://spf.pobox.com/why.html?sender=dude%40bouissou.net&ip=200.37.86.106&receiver=totor.bouissou.net; from= to= proto=SMTP helo= Jul 27 22:49:46 totor postfix/smtpd[22624]: NOQUEUE: reject: RCPT from lns-vlq-8-82-254-216-91.adsl.proxad.net[82.254.216.91]: 550 : Sender address rejected: Violation SPF: Mail de support@irislink.com doit etre transmis depuis serveur approuve pour domaine irislink.com. Contactez administrateur de irislink.com pour plus d'info, ou voyez http://spf.pobox.com/why.html?sender=support%40irislink.com&ip=82.254.216.91&receiver=totor.bouissou.net; from= to= proto=ESMTP helo= Résultats SPF sur totor.bouissou.net le Jul 26 : Jul 26 05:46:43 totor postfix/smtpd[5465]: NOQUEUE: reject: RCPT from pD9EB514A.dip0.t-ipconnect.de[217.235.81.74]: 550 : Sender address rejected: Violation SPF: Mail de tnorsrvrgvui@email.ro doit etre transmis depuis serveur approuve pour domaine email.ro. Contactez administrateur de email.ro pour plus d'info, ou voyez http://spf.pobox.com/why.html?sender=tnorsrvrgvui%40email.ro&ip=217.235.81.74&receiver=totor.bouissou.net; from= to= proto=SMTP helo= Jul 26 17:22:44 totor postfix/smtpd[6960]: NOQUEUE: reject: RCPT from unknown[195.121.4.119]: 550 : Sender address rejected: Violation SPF: Mail de MAILER-DAEMON@arboi.fr.eu.org doit etre transmis depuis serveur approuve pour domaine arboi.fr.eu.org. Contactez administrateur de arboi.fr.eu.org pour plus d'info, ou voyez http://spf.pobox.com/why.html?sender=MAILER-DAEMON%40arboi.fr.eu.org&ip=195.121.4.119&receiver=totor.bouissou.net; from= to= proto=ESMTP helo= -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 20:31:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17049 for ; Wed, 28 Jul 2004 20:31:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0BXd2040687; Wed, 28 Jul 2004 17:11:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6T0BXhC040686; Wed, 28 Jul 2004 17:11:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0BRe2040677 for ; Wed, 28 Jul 2004 17:11:27 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6T0BPN02098; Wed, 28 Jul 2004 17:11:25 -0700 Date: Wed, 28 Jul 2004 17:11:21 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1145525893.20040728171121@brandenburg.com> To: Andrew Newton CC: "Alan DeKok" , ietf-mxcomp@imc.org Subject: Re: Is the back door open? In-Reply-To: <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> References: <20040728214728.8C67C16E17@mail.nitros9.org> <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew, AN> I understand this point. I just don't think it is valid because it AN> assumes that the "To:" identity (either 2821 or 2822) is part of the There is no such thing as an RFC2821.TO identity. So, what are you referring...to? >> One of the benefits of any MARID approach *should* be that secondary >> MX's may now query & cache the MARID rules, which means that they can >> apply those rules themselves... which means secondary MX's may become >> more useful. Seems to me there should be a discussion about the implications of having distributed rule-processing engines. For example, where do we have related experience, such that we can understand the dynamics and administration, and have any hope of expecting this stuff to scale? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Jul 28 22:26:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23687 for ; Wed, 28 Jul 2004 22:26:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T27rqn065507; Wed, 28 Jul 2004 19:07:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6T27rJT065506; Wed, 28 Jul 2004 19:07:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T27mcU065467 for ; Wed, 28 Jul 2004 19:07:51 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47510.DBADA337" Subject: RE: alternate submitter syntax Date: Thu, 29 Jul 2004 12:07:53 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A781B@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: "IETF MARID WG" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C47510.DBADA337 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yes, =20 However Meng seems to be saying that SUBMITTER does not need to match the header in RFC.2822 that is presented to the end users MUA as the FROM address. He is quite adamant that the SUBMITTER address need not be the address that the end user is presented with.=20 =20 And there is no direct SPF checking of RFC.2822 headers. =20 So how does this stop phishing.=20 =20 Regards, Terje. =20 =20 =20 _____ =20 From: Daryl Odnert [mailto:daryl.odnert@tumbleweed.com]=20 Sent: Thursday, 29 July 2004 3:24 AM To: Terje Petersen; IETF MARID WG Subject: RE: alternate submitter syntax =20 > SCENERIO-B: SUBMITTER parameter IS supported on MTA.=20 >=20 > MAIL FROM =3D BOUNCE ADDRESS (NOT SPF TESTED)=20 > SUBMITTER =3D OTHER ADDRESS (SPF TESTED)=20 > RFC.2822.FROM =3D REPLY ADDRESS (NOT SPF TESTED)=20 >=20 >=20 > And in this second scenario I think you are saying that the addresses=20 > can all be different. Which does not seem to solve the phishing problem.=20 > So what am I missing here?=20 I think what you're missing is this, from draft-ietf-marid-submitter-02.txt:=20 If the receiving SMTP server allows the connecting SMTP client to=20 transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message=20 headers as described in [SENDER-ID]. If this purported responsible=20 address does not match the address appearing in the SUBMITTER=20 parameter, the receiving SMTP server SHOULD reject the message and=20 when rejecting MUST use "550 5.7.1 Submitter does not match header."=20 Daryl Odnert=20 Tumbleweed Communications=20 Redwood City, California=20 ------_=_NextPart_001_01C47510.DBADA337 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: alternate submitter syntax

Yes,

 

However Meng seems to be saying = that SUBMITTER does not need to match the header in RFC.2822 that is presented to the = end users MUA as the FROM address. He is quite adamant that the SUBMITTER = address need not be the address that the end user is presented with. =

 

And there is no direct SPF checking = of RFC.2822 headers.

 

So how does this stop phishing. =

 

Regards,

Terje.

 

 

 

From: Daryl Odnert [mailto:daryl.odnert@tumbleweed.com]
Sent: Thursday, 29 July = 2004 3:24 AM
To: Terje Petersen; IETF = MARID WG
Subject: RE: alternate = submitter syntax

 

> SCENERIO-B:   SUBMITTER parameter IS supported on = MTA.
>
>       MAIL FROM     =3D   BOUNCE ADDRESS  = (NOT SPF TESTED)
>       SUBMITTER     =3D   OTHER = ADDRESS   (SPF TESTED)
>     RFC.2822.FROM =3D   REPLY ADDRESS   (NOT SPF = TESTED)
>
>
> And in this second = scenario I think you are saying that the addresses
> can all be = different. Which does not seem to solve the phishing problem.
> So what am I = missing here?

I think what you're missing is this, from = draft-ietf-marid-submitter-02.txt:

   If the receiving SMTP server allows the connecting SMTP client = to
   transmit = message data, then the server SHOULD determine the purported
   responsible = address of the message by examining the RFC 2822 message
   headers as = described in [SENDER-ID].  If this purported responsible
   address = does not match the address appearing in the SUBMITTER
   parameter, = the receiving SMTP server SHOULD reject the message and
   when = rejecting MUST use "550 5.7.1 Submitter does not match header." =

Daryl Odnert
Tumbleweed = Communications
Redwood City, California

------_=_NextPart_001_01C47510.DBADA337-- From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 01:43:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02144 for ; Thu, 29 Jul 2004 01:43:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T5MdTf020053; Wed, 28 Jul 2004 22:22:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6T5MdjX020052; Wed, 28 Jul 2004 22:22:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T5MZui020013 for ; Wed, 28 Jul 2004 22:22:36 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 303E1132CD6; Thu, 29 Jul 2004 01:23:43 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 898966D4; Thu, 29 Jul 2004 01:22:41 -0400 (EDT) Date: Thu, 29 Jul 2004 01:22:41 -0400 From: Meng Weng Wong To: Terje Petersen Cc: IETF MARID WG Subject: Re: alternate submitter syntax Message-ID: <20040729052241.GQ16317@dumbo.pobox.com> References: <3CA474173FC0274799F97F3AB3BD25EE1A781B@ltwd-svr2.lightwood.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA474173FC0274799F97F3AB3BD25EE1A781B@ltwd-svr2.lightwood.com.au> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jul 29, 2004 at 12:07:53PM +1000, Terje Petersen wrote: | | However Meng seems to be saying that SUBMITTER does not need to match | the header in RFC.2822 that is presented to the end users MUA as the | FROM address. He is quite adamant that the SUBMITTER address need not be | the address that the end user is presented with. | Yes, if you read the core spec that describes PRA you will see this. Perhaps the slideshow which starts at http://spf.pobox.com/slides/thenewspf/0010.html will be more informative. I apologize for the naming, but the slideshow was drawn before the name Sender ID was chosen. From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 02:38:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19113 for ; Thu, 29 Jul 2004 02:38:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T6MH9q056387; Wed, 28 Jul 2004 23:22:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6T6MHq1056386; Wed, 28 Jul 2004 23:22:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ltwd-svr2.lightwood.com.au ([202.92.90.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T6MFpu056364 for ; Wed, 28 Jul 2004 23:22:16 -0700 (PDT) (envelope-from terje@excelan.com.au) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: alternate submitter syntax Date: Thu, 29 Jul 2004 16:22:14 +1000 Message-ID: <3CA474173FC0274799F97F3AB3BD25EE1A781C@ltwd-svr2.lightwood.com.au> From: "Terje Petersen" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6T6MGpu056379 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Meng etc, I have reviewed the slide show before. However it was good revision to read it again so thanks for suggesting it. With the understanding I now have under my belt I can happily concede that SUBMITTER is appropriately named given the intent (although I do think the draft standard on SUBMITTER is unclear in so far as it presumes prior understanding of too much). In any case I still have issues. Let me see if I can summarise the standard correctly in my own words. The PRA ADDRESS is one of the following. RFC.2822.RESENT-FROM or RFC.2822.SENDER or RFC.2822.FROM In that order of preference. QUESTION 1: Is it always the PRA address that is displayed in MUAs as being the FROM or REPLY ADDRESS? Are some MUAs compliant and others not compliant? QUESTION 2: If the answer to the first question is NO then how is this going to solve PHISHING? With the above definition for PRA the following would apply. SCENERIO-A: SUBMITTER parameter NOT supported on MTA. MAIL FROM = BOUNCE ADDRESS (SPF TESTED??) SUBMITTER = NOT APPLICABLE PRA ADDRESS = MUA REPLY ADDRESS?? (SPF TESTED) SCENERIO-B: SUBMITTER parameter IS supported on MTA. MAIL FROM = BOUNCE ADDRESS (NOT SPF TESTED??) SUBMITTER = OTHER ADDR (SPF TESTED) PRA ADDRESS = MUA REPLY ADDRESS?? (NOT DIRECTLY SPF TESTED) PRA ADDRESS = SUBMITTER (TESTED) QUESTION 3: Why is the bounce address not also SPF tested in this second scenerio? Assuming that the bounce address is not also tested it still leaves the ability to write viruses that send email from the infected parties machine (as an SPF authorised address of the infected party) with a false bounce address. This means that some third party owner of the bounce address could be victimised. When the virus is successful in sending itself then the infection spreads. When the virus email is bounced by antivirus gateways it annoys the hell out of some innocent party. Surely this is a security loophole even if not as big as the current SMTP security loophole. QUESTION 4. If the bounce address was always SPF checked and confirmed valid then could we not leave the confirmation that RFC.2822.PRA = SUBMITTER as an MUA function? Regards, Terje. -----Original Message----- From: Meng Weng Wong [mailto:mengwong@dumbo.pobox.com] Sent: Thursday, 29 July 2004 3:23 PM To: Terje Petersen Cc: IETF MARID WG Subject: Re: alternate submitter syntax On Thu, Jul 29, 2004 at 12:07:53PM +1000, Terje Petersen wrote: | | However Meng seems to be saying that SUBMITTER does not need to match | the header in RFC.2822 that is presented to the end users MUA as the | FROM address. He is quite adamant that the SUBMITTER address need not be | the address that the end user is presented with. | Yes, if you read the core spec that describes PRA you will see this. Perhaps the slideshow which starts at http://spf.pobox.com/slides/thenewspf/0010.html will be more informative. I apologize for the naming, but the slideshow was drawn before the name Sender ID was chosen. From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 03:37:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23051 for ; Thu, 29 Jul 2004 03:37:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T7JWnR084006; Thu, 29 Jul 2004 00:19:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6T7JWAq084005; Thu, 29 Jul 2004 00:19:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T7JW7q083998 for ; Thu, 29 Jul 2004 00:19:32 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i6T7JVeD011150; Thu, 29 Jul 2004 00:19:31 -0700 Subject: Re: Is the back door open? From: Douglas Otis To: Andrew Newton Cc: Alan DeKok , MARID In-Reply-To: <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> References: <20040728214728.8C67C16E17@mail.nitros9.org> <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1091085571.2659.102.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 29 Jul 2004 00:19:31 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-07-28 at 15:13, Andrew Newton wrote: > On Jul 28, 2004, at 5:47 PM, Alan DeKok wrote: > > I think Doug's point is more that information necessary for the MX > > to implement Sender-ID isn't distributed, but the incoming mail is. > > I understand this point. I just don't think it is valid because it > assumes that the "To:" identity (either 2821 or 2822) is part of the > Sender-ID (or SPF) equation. Why does an MTA need to know the "To" in > order to check the "From"? Sender-ID checks the Purported Responsible Address (PRA) and may not include the RFC 2822 From. Sender-ID does not check the RFC 2821 RCPT TO or the RFC 2822 To. Such checks are done independently. The scenario described was to illustrate a generation of a bounce (resending of the message to the RFC 2821 MAIL FROM) rather than an immediate message rejection with a 5xx error. The bounce occurs, in this case, when the mail is being relayed by an MTA that does not have a list of valid users, but is only checking the right hand side of the RFC 2821 RCPT TO address. If the message is initially accepted and then the user is later discovered not valid, the message becomes bounced. Acceptance does not require a full rating from Sender-ID, and may not include a full set of other checks at that time. Sender-ID acceptance could be achieved using a domain with either none, open, owned, or borrowed records. A relay MTA may also opt to turn off Sender-ID channel checks. The bounce can emerge with a high Sender-ID rating however. If just the RFC 2822 From is used in the spoof, then the bouncer becomes the PRA. If the RFC 2821 is not null in the bounce, then this would appear to originate from the bouncer. (Some virus filters seemingly want to advertise their post acceptance detection and put something in RFC 2821 MAIL FROM bounce. Bet such companies will use 'open' records. Often the virus reported is listed on their website as known to spoof the RFC 2821 MAIL FROM, and so they pass it along, like a cat showing their prey.) The 'reverse path' declarations needed for Sender-ID are not always comprehensive, due to the extremely large scope involved. There will remain a population of 'open' records. With the expense of DNS wrenches, as a defensive posture, such Sender-ID checks could be postponed until it is determined the mail is for a valid user. Owing to the overhead involved, Sender-ID checks could be reserved to benefit just local users. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 10:45:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16252 for ; Thu, 29 Jul 2004 10:45:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TEP1WK033185; Thu, 29 Jul 2004 07:25:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TEP1LH033184; Thu, 29 Jul 2004 07:25:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TEOwiD033159 for ; Thu, 29 Jul 2004 07:25:01 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id A798516E17 for ; Thu, 29 Jul 2004 10:32:47 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Is the back door open? In-Reply-To: Your message of "Wed, 28 Jul 2004 17:11:21 PDT." <1145525893.20040728171121@brandenburg.com> Date: Thu, 29 Jul 2004 10:32:47 -0400 Message-Id: <20040729143247.A798516E17@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > Seems to me there should be a discussion about the implications of > having distributed rule-processing engines. For example, where do we > have related experience, such that we can understand the dynamics and > administration, and have any hope of expecting this stuff to scale? We know DNS works, and scales. I don't think anyone's arguing that systems can maintain & publish their own MARID records. So to the rest of the net, those records in DNS look much like any other records in DNS. The main differences between MARID and other kinds of data in DNS are size and how much work the receipient puts into interpreting them. These issues have been discussed for recipients, but not for MX secondaries, because the topic of MX secondaries interpreting MARID records hasn't come up. It should be discussed in further detail. Hmm.. other than the "RCPT TO" issue Douglas Otis brought up, MX secondaries aren't that different from any recipient SMTP server so far as MARID goes. The main difference is that it's more critical for the MX secondaries to obtain the MARID information for a domain. As a related point, I've been part of a system which implements a kind of distributed "pobox" via hesiod. Each site publishes a list of users@common-domain (which maps to a local email address), and each site is listed as an MX for that domain. They all do cross-queries for hesiod information, so they all have the complete user list & forwarding table. Mail can then get queued on any site that's up, and forwarded to the final destination by whoever received it. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 10:48:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16446 for ; Thu, 29 Jul 2004 10:48:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TEZMaB036009; Thu, 29 Jul 2004 07:35:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TEZMIb036008; Thu, 29 Jul 2004 07:35:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TEZLui035983 for ; Thu, 29 Jul 2004 07:35:21 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from righton.sendmail.com (ns.sendmail.com [209.246.26.10]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i6TEZIaU020251 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 29 Jul 2004 07:35:18 -0700 Received: from [192.168.36.36] (echoes.singletrack.org [66.93.133.212]) (authenticated bits=0) by righton.sendmail.com (8.12.11/8.12.11) with ESMTP id i6TEZGax026034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2004 07:35:17 -0700 (PDT) (envelope-from rand@sendmail.com) Message-ID: <41090B4D.5060104@sendmail.com> Date: Thu, 29 Jul 2004 07:35:57 -0700 From: Rand Wacker User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis CC: Andrew Newton , Ryan Ordway , MARID Subject: Re: Is the back door open? References: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> <1091037531.11296.762.camel@ddev.mail-abuse.org> <1091052378.11296.1160.camel@ddev.mail-abuse.org> In-Reply-To: <1091052378.11296.1160.camel@ddev.mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > On Wed, 2004-07-28 at 11:22, Rand Wacker wrote: > >>Doesn't protection against the bounce using SPF-Classic require 100% >>adoption to make it work? Wouldn't BATV or some other site-local >>protection against joe-jobbing have a more direct impact on this problem >>(which, I will note, is not necessarily the problem this group was >>chartered to address). > > SPF offered some relief, if the MTA creating the bounce checked the > destination domain records for valid sources of the message. Again though, this requires *every* MTA that might generate a bounce to deploy SPF checking, *everywhere*. > This is lost with Sender-ID. This wasn't the goal of Sender ID. > A solution for this problem could be found through > a combination of SPF and BATV, where BATV is less disruptive. If an individual sending site deployed BATV wouldn't that let them determine what bounces were genuine and which were forged from the outside? Why would they need SPF *at all* in that case? > SPF accommodates an address based white-list, but such a list would be of > less use, with CSV offering names. Doesn't Sender ID accomodate an address-based white-list as well? Specifically, addresses that users see/can see more readily than the Envelope From? > Should end-users or the MTA make accept/reject decisions? This question seems out of place. But decisions should be made by some automated system, probably near the gateway, operating on behalf of the wishes of the admins/users. > A quest to examine content only weakens a decision process with > complexity. The decision whether to reject the message is best based > upon RFC 2821 information. For what technical reason is it best based on the 2821 address? > A standard method to sign RFC 2821 MAIL FROM paths, as with BATV, would > end schemes used by rogue mailers to skirt accreditation. This skirting > takes advantage of MTAs that do not employ history, and a reason for > many spoofed addresses. If the sending domain has a history, acceptance > is based upon the sending domain's demonstration of policy. If the > sending domain does not have a history, then mail could be constrained. Agreed. > For economies of scale, the burden must be placed upon the sender. This > burden would result from their history of behavior. If the sending > domain is rejected as a result of their accumulated history, then it > becomes their burden as the sender. It must not be seen as a problem > for the end-user to sort, filter, and delete. Grading makes mail > unreliable and eventually useless. History based accreditation is best > done with a known name of the sending domain responsible for policy. > This is the specific aim of CSV. To stop spam or viruses, the question > remains, what is the history of the domain? OK, I agree with everything you say here as well. Doesn't almost every proposal put forth here (including Sender ID and DomainKeys) give you a verifiable domain to check the history of? > Sender-ID does not identify which domain allowed introduction of abusive > mail. Without 100% publication of DNS records for sending domains, *none* of these solutions will be able to identify where all mail came from. > There can be no solution without this information. We may be looking for solutions to different problems then. > If a domain > demonstrates a history of neglect, then a growing number of rejected > messages will make economic sense for polices to be repaired. Sender-ID > is useless in this regard. Put the burden upon the sender, and not the > recipient. Agree with the latter, disagree with the former. Sender-ID can be used to verify the sending domain for purposes of reputation checks just like you say. Is your concern with it the use of Resent-Sender and Resent-From And, FWIW, neither SPF nor Sender-ID will ever be able to tell you any more than the most recent domain to forward a message to you, so in the case of messages that go through multiple hops to your gateway, you're going to be checking the reputation of any service that may be forwarding to you. -Rand From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 12:08:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21132 for ; Thu, 29 Jul 2004 12:08:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TFr4sY050696; Thu, 29 Jul 2004 08:53:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TFr4LN050695; Thu, 29 Jul 2004 08:53:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TFr4Ya050665 for ; Thu, 29 Jul 2004 08:53:04 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 29 Jul 2004 11:53:04 -0400 id 0002C2BD.41091D61.000052ED Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <1145525893.20040728171121@brandenburg.com> References: <20040728214728.8C67C16E17@mail.nitros9.org> <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> <1145525893.20040728171121@brandenburg.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5E6DBCD8-E177-11D8-B79D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: Is the back door open? Date: Thu, 29 Jul 2004 11:53:00 -0400 To: MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 28, 2004, at 8:11 PM, Dave Crocker wrote: > There is no such thing as an RFC2821.TO identity. Then we needn't worry about using a valid list of users when doing Sender-ID or SPF checks then. :) On Jul 28, 2004, at 6:06 PM, Douglas Otis wrote: > SPF offered some relief, if the MTA creating the bounce checked the > destination domain records for valid sources of the message. This is > lost with Sender-ID. A solution for this problem could be found > through > a combination of SPF and BATV, where BATV is less disruptive. SPF > accommodates an address based white-list, but such a list would be of > less use, with CSV offering names. I was under the assumption that BATV was a much better fit with domain keys than with SPF. Actually, I have no idea what it has to do with SPF at all. BATV is an interesting idea. On Jul 29, 2004, at 3:19 AM, Douglas Otis wrote: > Sender-ID checks the Purported Responsible Address (PRA) and may not > include the RFC 2822 From. Sender-ID does not check the RFC 2821 RCPT > TO or the RFC 2822 To. Such checks are done independently. I'm glad there's agreement on this. :) > The scenario described was to illustrate a generation of a bounce > (resending of the message to the RFC 2821 MAIL FROM) rather than an > immediate message rejection with a 5xx error. The bounce occurs, in > this case, when the mail is being relayed by an MTA that does not have > a > list of valid users, but is only checking the right hand side of the > RFC > 2821 RCPT TO address. If the message is initially accepted and then > the > user is later discovered not valid, the message becomes bounced. I understand the scenario. And I keep asking, "why not just do a Sender-ID (or SPF) check and REJECTION at the first MTA"? And you keep saying, "It doesn't have the list of valid users." And I keep asking, "what does a list of valid users have to do with a Sender-ID or SPF check?" > Acceptance does not require a full rating from Sender-ID, and may not > include a full set of other checks at that time. Sender-ID acceptance > could be achieved using a domain with either none, open, owned, or > borrowed records. huh? what? > A relay MTA may also opt to turn off Sender-ID > channel checks. Well, that is between you and the people you list in the target of your MX. A relay MTA may also opt to block 0/0, but that's no fault of Sender-ID or SPF. Are you trying to say that Sender-ID checks will only be one part of a spam-filter evaluation that can only take place on the delivery MTA? If so, isn't this your responsibility to handle properly since step 6 of the PRA says "SHOULD" reject (meaning, if you didn't, you really ought to know what you are doing). -andy From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 13:03:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25084 for ; Thu, 29 Jul 2004 13:03:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TGlUIh061558; Thu, 29 Jul 2004 09:47:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TGlUIH061557; Thu, 29 Jul 2004 09:47:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TGlUJg061550 for ; Thu, 29 Jul 2004 09:47:30 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2004 09:48:02 +0000 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6TGkO8H023283; Thu, 29 Jul 2004 09:46:24 -0700 (PDT) Received: from fenton-w2k01.cisco.com (dhcp-128-107-163-194.cisco.com [128.107.163.194]) (authenticated bits=0) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i6THF6kZ028407; Thu, 29 Jul 2004 10:15:07 -0700 Message-Id: <4.3.2.7.2.20040729080558.04a87218@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jul 2004 08:10:50 -0700 To: Markus Stumpf , Larry Seltzer From: Jim Fenton Subject: Re: How is SPF different from RMX? Cc: ietf-mxcomp@imc.org In-Reply-To: <20040728200407.GI65482@Space.Net> References: <200407272304.i6RN4N9j062152@above.proper.com> <20040727221835.4794816E17@mail.nitros9.org> <200407272304.i6RN4N9j062152@above.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-IMAIL-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1091121307.830347"; x:"432000"; a:"rsa-sha1"; b:"0:1000"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"SycbYfatzGbGnNfSNspJtHCngbQ8Iew0iHWMkpK9Q/FRxPNkGZW5Yr5IgHrRd" "rceY74yIDI1PzhL9Qp7t/KABBLNHAO0YdnBLDzjC3dIvwu+Bu+6m1wQAGj2ha" "VY1v/ZYiY7+gff/wFqVd5RU3Z151Hpx5ykCAigRHBCEI8H2SE="; c:"Date: Thu, 29 Jul 2004 08:10:50 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: How is SPF different from RMX?" X-IMAIL-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:04 PM 7/28/2004 +0200, Markus Stumpf wrote: >I think it will take a really long time before the first virus or >worm will be rejected at SMTP level because of SPF or any similar >method and if it can't be caught before the DATA command it doesn't >make a difference, because then the message will be received and it >is probably cheaper to let the virus scanner catch it instead of >cruising the DNS, collect records and feed all this to a spam filter >for evaluation that classifies it then to a "maybe spam" folder, IF >the sender domain has deployed SPF or similar methods at all. The message isn't accepted until the DATA command is accepted, at the end of the message. While the receiving domain has to provide bandwidth to receive at least part of the message, it can still reject the message (and doesn't have to provide storage for it) any time before the "OK". It can, potentially, tear down the TCP connection after receiving the relevant headers if it wants. -Jim From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 13:37:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27236 for ; Thu, 29 Jul 2004 13:37:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6THOln8069192; Thu, 29 Jul 2004 10:24:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6THOl3B069191; Thu, 29 Jul 2004 10:24:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange2003.ad.skymv.com (mail.skymv.com [66.120.210.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6THOlrB069185 for ; Thu, 29 Jul 2004 10:24:47 -0700 (PDT) (envelope-from csg@habeas.com) Received: from [10.4.1.84] ([10.4.1.84]) by exchange2003.ad.skymv.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jul 2004 10:23:09 -0700 Message-ID: <410932E1.3070609@habeas.com> Date: Thu, 29 Jul 2004 10:24:49 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Request to move PRA to its own draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2004 17:23:09.0984 (UTC) FILETIME=[B83B2200:01C47590] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The Perported Responsible Address algorithm has utility and scope well beyond its use in Sender-ID, including areas where Sender-ID isn't applicable. It's really filling in an omission in the base mail header specifications. I'd like to suggest to the chairs that PRA be made into its own draft and published as an update to RFC 2822, rather than a part of the Sender-ID suite of specs. This would facilitate future RFCs that wish to reference the PRA without having to dislaim a dependency on the rest of Sender-ID. From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 13:55:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28052 for ; Thu, 29 Jul 2004 13:55:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6THe1pb071670; Thu, 29 Jul 2004 10:40:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6THe1Am071669; Thu, 29 Jul 2004 10:40:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6THe0HT071647 for ; Thu, 29 Jul 2004 10:40:00 -0700 (PDT) (envelope-from nborenst@us.ibm.com) Received: from [169.229.200.85] [169.229.200.85] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id A0968B701A8; Thu, 29 Jul 2004 10:15:02 -0700 Mime-Version: 1.0 (Apple Message framework v618) To: ietf-mxcomp@imc.org Message-Id: <5A700302-E186-11D8-B16C-000A9571873E@us.ibm.com> Content-Type: multipart/alternative; boundary=Apple-Mail-25--1001016632 From: Nathaniel Borenstein Subject: Re: Sender-ID and free software Date: Thu, 29 Jul 2004 13:40:16 -0400 X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-25--1001016632 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Note: This is a message I sent a few days ago, but my address was blocked; you've already seen Richard's reply, but here's the message he was replying to. -- Nathaniel Begin forwarded message: > From: Nathaniel Borenstein > Date: July 27, 2004 10:30:39 AM EDT > To: Richard Stallman > Cc: Marshall Rose , michel@bouissou.net, > ietf-mxcomp@imc.org > Subject: Sender-ID and free software > > On Jul 26, 2004, at 10:30 AM, Richard Stallman wrote: > >> The important issue here, the one that people's attention must focus >> on, is to thwart the attempt to exclude free software operating >> systems from full participation in email. > > With respect, you're flat-out wrong in this context. For the > community having this discussion, *the* important issue is stopping > spam, which tops all surveys as the scourge of the Internet age. But > even that's not the right issue for this particular mailing list, > which has a very specific task. Here, the most important issue is > resolving the details of a specific family of protocol proposals > related to IP-based authentication of email. > > The issues you raise are serious ones, and I respect their importance. > But they are only *slightly* more relevant to this mailing list than > the relative merits of Levitra and Viagra as spam-enabling > technologies. > >> The members of the IETF surely cannot want petty matters to preclude >> the thorough and proper consideration a potential serious problem that >> would affect all of society. > > The members of the IETF range from survivalist gun nuts to committed > communists. Not surprisingly, there is a significant subset of the > IETF community that regularly engages in extended debate on subjects > like the one you raise, and they have over time helped to evolve the > IETF's intellectual property policy, among other things. Thanks in > part to that history, I am confident that the IESG and IAB will not > permit the emergence of a standard that excludes *anyone* from "full > participation in email." > >> Not every technical question is purely technical in its consequences. >> Some have social implications. One of the lessons society learned >> after some bad experiences in the 40s and 50s was that scientists and >> engineers must take account of the social consequences of their work. >> To bury one's head in engineering and ignore its impact is socially >> irresponsible. > > I certainly share your concern that technologists must weigh our > social responsibilities, and the larger consequences of our work. > Many of us devote a great deal of time to these issues. However, most > of us choose not to interfere with well-focused technical discussions > in order to advance our own (highly controversial) interpretations of > our social responsibilities. > > Finally, wearing my IBM hat, let me assure everyone on this mailing > list that the legal terms of the Sender-ID license are receiving close > scrutiny from many directions. It is very important to IBM that every > Linux user have the ability to make use of Sender-ID. We also welcome > Microsoft's participation in and contribution to this standard, and > the cooperative spirit they have shown so far. -- Nathaniel > > --- > Nathaniel S. Borenstein, Ph.D. > Distinguished Engineer, IBM Lotus Division > --Apple-Mail-25--1001016632 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Note: This is a message I sent a few days ago, but my address was blocked; you've already seen Richard's reply, but here's the message he was replying to. -- Nathaniel Begin forwarded message: Helvetica0000,0000,0000From: HelveticaNathaniel Borenstein < 0000,0000,0000Date: July 27, 2004 10:30:39 AM EDT 0000,0000,0000To: Richard Stallman < 0000,0000,0000Cc: Marshall Rose <, michel@bouissou.net, ietf-mxcomp@imc.org 0000,0000,0000Subject: Sender-ID and free software On Jul 26, 2004, at 10:30 AM, Richard Stallman wrote: The important issue here, the one that people's attention must focus on, is to thwart the attempt to exclude free software operating systems from full participation in email. With respect, you're flat-out wrong in this context. For the community having this discussion, *the* important issue is stopping spam, which tops all surveys as the scourge of the Internet age. But even that's not the right issue for this particular mailing list, which has a very specific task. Here, the most important issue is resolving the details of a specific family of protocol proposals related to IP-based authentication of email. The issues you raise are serious ones, and I respect their importance. But they are only *slightly* more relevant to this mailing list than the relative merits of Levitra and Viagra as spam-enabling technologies. The members of the IETF surely cannot want petty matters to preclude the thorough and proper consideration a potential serious problem that would affect all of society. The members of the IETF range from survivalist gun nuts to committed communists. Not surprisingly, there is a significant subset of the IETF community that regularly engages in extended debate on subjects like the one you raise, and they have over time helped to evolve the IETF's intellectual property policy, among other things. Thanks in part to that history, I am confident that the IESG and IAB will not permit the emergence of a standard that excludes *anyone* from "full participation in email." Not every technical question is purely technical in its consequences. Some have social implications. One of the lessons society learned after some bad experiences in the 40s and 50s was that scientists and engineers must take account of the social consequences of their work. To bury one's head in engineering and ignore its impact is socially irresponsible. I certainly share your concern that technologists must weigh our social responsibilities, and the larger consequences of our work. Many of us devote a great deal of time to these issues. However, most of us choose not to interfere with well-focused technical discussions in order to advance our own (highly controversial) interpretations of our social responsibilities. Finally, wearing my IBM hat, let me assure everyone on this mailing list that the legal terms of the Sender-ID license are receiving close scrutiny from many directions. It is very important to IBM that every Linux user have the ability to make use of Sender-ID. We also welcome Microsoft's participation in and contribution to this standard, and the cooperative spirit they have shown so far. -- Nathaniel --- Nathaniel S. Borenstein, Ph.D. < Distinguished Engineer, IBM Lotus Division --Apple-Mail-25--1001016632-- From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 13:56:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28140 for ; Thu, 29 Jul 2004 13:56:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6THlGlY072774; Thu, 29 Jul 2004 10:47:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6THlGXZ072773; Thu, 29 Jul 2004 10:47:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6THlGBs072767 for ; Thu, 29 Jul 2004 10:47:16 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i6THlHGN007857; Thu, 29 Jul 2004 10:47:17 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Jul 2004 10:47:17 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Andrew Newton'" , "'MARID WG'" Subject: Re: Is the back door open? Date: Thu, 29 Jul 2004 10:47:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I am at black hat. The guy on stage is demonstrating voice over dns. It caches everywhere... I think that the problems of people using reasonable uses of the dns that might possibly be subverted are far less worrying than the likely total abuses. -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Thu Jul 29 09:32:35 2004 To: MARID WG Subject: Re: Is the back door open? On Jul 28, 2004, at 8:11 PM, Dave Crocker wrote: > There is no such thing as an RFC2821.TO identity. Then we needn't worry about using a valid list of users when doing Sender-ID or SPF checks then. :) On Jul 28, 2004, at 6:06 PM, Douglas Otis wrote: > SPF offered some relief, if the MTA creating the bounce checked the > destination domain records for valid sources of the message. This is > lost with Sender-ID. A solution for this problem could be found > through > a combination of SPF and BATV, where BATV is less disruptive. SPF > accommodates an address based white-list, but such a list would be of > less use, with CSV offering names. I was under the assumption that BATV was a much better fit with domain keys than with SPF. Actually, I have no idea what it has to do with SPF at all. BATV is an interesting idea. On Jul 29, 2004, at 3:19 AM, Douglas Otis wrote: > Sender-ID checks the Purported Responsible Address (PRA) and may not > include the RFC 2822 From. Sender-ID does not check the RFC 2821 RCPT > TO or the RFC 2822 To. Such checks are done independently. I'm glad there's agreement on this. :) > The scenario described was to illustrate a generation of a bounce > (resending of the message to the RFC 2821 MAIL FROM) rather than an > immediate message rejection with a 5xx error. The bounce occurs, in > this case, when the mail is being relayed by an MTA that does not have > a > list of valid users, but is only checking the right hand side of the > RFC > 2821 RCPT TO address. If the message is initially accepted and then > the > user is later discovered not valid, the message becomes bounced. I understand the scenario. And I keep asking, "why not just do a Sender-ID (or SPF) check and REJECTION at the first MTA"? And you keep saying, "It doesn't have the list of valid users." And I keep asking, "what does a list of valid users have to do with a Sender-ID or SPF check?" > Acceptance does not require a full rating from Sender-ID, and may not > include a full set of other checks at that time. Sender-ID acceptance > could be achieved using a domain with either none, open, owned, or > borrowed records. huh? what? > A relay MTA may also opt to turn off Sender-ID > channel checks. Well, that is between you and the people you list in the target of your MX. A relay MTA may also opt to block 0/0, but that's no fault of Sender-ID or SPF. Are you trying to say that Sender-ID checks will only be one part of a spam-filter evaluation that can only take place on the delivery MTA? If so, isn't this your responsibility to handle properly since step 6 of the PRA says "SHOULD" reject (meaning, if you didn't, you really ought to know what you are doing). -andy From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 14:18:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29266 for ; Thu, 29 Jul 2004 14:18:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TI7juD076859; Thu, 29 Jul 2004 11:07:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TI7inH076858; Thu, 29 Jul 2004 11:07:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange2003.ad.skymv.com (mail.skymv.com [66.120.210.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TI7i2N076852 for ; Thu, 29 Jul 2004 11:07:44 -0700 (PDT) (envelope-from csg@habeas.com) Received: from [10.4.1.84] ([10.4.1.84]) by exchange2003.ad.skymv.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jul 2004 11:06:07 -0700 Message-ID: <41093CF3.2000900@habeas.com> Date: Thu, 29 Jul 2004 11:07:47 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Fenton CC: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? References: <200407272304.i6RN4N9j062152@above.proper.com> <20040727221835.4794816E17@mail.nitros9.org> <200407272304.i6RN4N9j062152@above.proper.com> <4.3.2.7.2.20040729080558.04a87218@mira-sjc5-1.cisco.com> In-Reply-To: <4.3.2.7.2.20040729080558.04a87218@mira-sjc5-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2004 18:06:07.0578 (UTC) FILETIME=[B898C3A0:01C47596] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jim Fenton wrote: > The message isn't accepted until the DATA command is accepted, at the > end of the message. While the receiving domain has to provide > bandwidth to receive at least part of the message, it can still reject > the message (and doesn't have to provide storage for it) any time > before the "OK". It can, potentially, tear down the TCP connection > after receiving the relevant headers if it wants. Just splitting hairs here: If the server simply tears down the connection, the client MTA will handle it the same as a 421 error, and resend the message (and resend it, and resend it... for three days). If you really want to reject a message after a 354 response, then you'll have to swallow the whole message and send a 55x code in response to the dot. Then you'll have to hope that the client MTA does the Right Thing when it receives a 55x at that point -- some don't. From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 15:29:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04111 for ; Thu, 29 Jul 2004 15:29:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJGIVi089948; Thu, 29 Jul 2004 12:16:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TJGIxf089945; Thu, 29 Jul 2004 12:16:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJGHvU089927 for ; Thu, 29 Jul 2004 12:16:17 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.206.18]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040729191613.UVYS6357.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 29 Jul 2004 15:16:13 -0400 From: "John Glube" To: "'Carl S. Gutekunst'" , "'IETF MARID WG'" Subject: RE: Request to move PRA to its own draft Date: Thu, 29 Jul 2004 15:15:51 -0400 Message-ID: <00bc01c475a0$766cde80$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <410932E1.3070609@habeas.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6TJGHvU089936 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Carl S. Gutekunst Sent: July 29, 2004 1:25 PM To: IETF MARID WG Subject: Request to move PRA to its own draft Carl Gutekunst wrote, "The Purported Responsible Address algorithm has utility and scope well beyond its use in Sender-ID, including areas where Sender-ID isn't applicable. It's really filling in an omission in the base mail header specifications. I'd like to suggest to the chairs that PRA be made into its own draft and published as an update to RFC 2822, rather than a part of the Sender-ID suite of specs. This would facilitate future RFCs that wish to reference the PRA without having to disclaim a dependency on the rest of Sender-ID." To the best of my knowledge there has been no follow up concerning the suggestion put on 19.07.04 to have an outside review of the PRA algorithm carried out by one or more graybeards. Although I appreciate such a review may or may not be required, given the experimental nature of the PRA algorithm, along with the import of the MARID protocol to the Internet infrastructure, without such a review being carried out and this WG being satisfied the PRA algorithm will in fact add value, without undue cost to the stated charter objective, I am obliged to second this suggestion. I appreciate the earlier tenor of the group was to fold the PRA algorithm and Submitter into Sender ID. However, I believe circumstances have sufficiently changed so that this decision should be revisited, especially given the absence of any published results from large scale field testing and an outside review by graybeards. John Glube Toronto, Canada http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004 From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 16:02:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05708 for ; Thu, 29 Jul 2004 16:02:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJqxes096411; Thu, 29 Jul 2004 12:52:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TJqxcJ096410; Thu, 29 Jul 2004 12:52:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TJqx4a096384 for ; Thu, 29 Jul 2004 12:52:59 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id DF27F414BC; Thu, 29 Jul 2004 12:52:59 -0700 (PDT) Subject: Re: Is the back door open? From: Douglas Otis To: Andrew Newton Cc: MARID WG In-Reply-To: <5E6DBCD8-E177-11D8-B79D-000A95B3BA44@hxr.us> References: <20040728214728.8C67C16E17@mail.nitros9.org> <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> <1145525893.20040728171121@brandenburg.com> <5E6DBCD8-E177-11D8-B79D-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1091130779.11296.1285.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 29 Jul 2004 12:52:59 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-29 at 08:53, Andrew Newton wrote: > On Jul 28, 2004, at 8:11 PM, Dave Crocker wrote: > > There is no such thing as an RFC2821.TO identity. > > Then we needn't worry about using a valid list of users when doing > Sender-ID or SPF checks then. :) > > On Jul 28, 2004, at 6:06 PM, Douglas Otis wrote: > > > SPF offered some relief, if the MTA creating the bounce checked the > > destination domain records for valid sources of the message. This is > > lost with Sender-ID. A solution for this problem could be found > > through a combination of SPF and BATV, where BATV is less > > disruptive. SPF accommodates an address based white-list, but such > > a list would be of less use, with CSV offering names. > > I was under the assumption that BATV was a much better fit with domain > keys than with SPF. Actually, I have no idea what it has to do with > SPF at all. BATV is an interesting idea. BATV uses DNS DomainKeys for a method that could allow the bounce to be prevented in much the same manner as SPF would have done. The difference between SPF and BATV would be the method used to authenticate the originating domain. SPF would use a number of DNS TXT records to compile a "comprehensive" or "closed" list of addresses of all outbound SMTP servers sending messages using the domain of RFC 2821 MAIL FROM to prevent the bounce. BATV could authenticate the domain using a DNS DomainKey to prevent the bounce. BATV provides no assurance of the RFC 2822 From, nor does SPF. > On Jul 29, 2004, at 3:19 AM, Douglas Otis wrote: > > > Sender-ID checks the Purported Responsible Address (PRA) and may not > > include the RFC 2822 From. Sender-ID does not check the RFC 2821 RCPT > > TO or the RFC 2822 To. Such checks are done independently. > > I'm glad there's agreement on this. :) > > > The scenario described was to illustrate a generation of a bounce > > (resending of the message to the RFC 2821 MAIL FROM) rather than an > > immediate message rejection with a 5xx error. The bounce occurs, in > > this case, when the mail is being relayed by an MTA that does not have > > a list of valid users, but is only checking the right hand side of > > the RFC 2821 RCPT TO address. If the message is initially accepted > > and then the user is later discovered not valid, the message becomes > > bounced. > > I understand the scenario. And I keep asking, "why not just do a > Sender-ID (or SPF) check and REJECTION at the first MTA"? And you keep > saying, "It doesn't have the list of valid users." And I keep asking, > "what does a list of valid users have to do with a Sender-ID or SPF > check?" I attempted to explain this in the following two sentences. > > Acceptance does not require a full rating from Sender-ID, and may not > > include a full set of other checks at that time. Sender-ID acceptance > > could be achieved using a domain with either none, open, owned, or > > borrowed records. The spammer only needs to have the message accepted by the Sender-ID check. The rating for the check does not matter, provided the message is accepted. This could mean the domain claimed by the PRA which would be: First RFC 2822.Resent-Sender else First RFC 2822.Resent-From else Singular RFC 2822.Sender else Singular RFC 2822.From and receives a Sender-ID rating: Pass (+) Neutral (?) SoftFail (~ may accept messages) TempError (transient DNS or format error, may accept messages) PermError (unrecoverable format error, may accept messages) None (no records) Those publishing records may include "+all" or "?all" as a method allow their record set to be less than comprehensive. Creating a comprehensive record set could be daunting, with a limit of just 100 or so DNS lookups with just 10 calls to Check_Host(). : ) If the bouncer has published their SPF record, then the bounce may receive a Pass(+) rating. : ( > huh? what? > > > A relay MTA may also opt to turn off Sender-ID > > channel checks. > > Well, that is between you and the people you list in the target of your > MX. A relay MTA may also opt to block 0/0, but that's no fault of > Sender-ID or SPF. No. Bounce traffic is from a third-party beyond the control of the MTA receiving the bounce. This is not between related parties. > Are you trying to say that Sender-ID checks will only be one part of a > spam-filter evaluation that can only take place on the delivery MTA? No. The Sender-ID rating system directs mail into different folders (rat-holes), and leaves to the end-user the task of sorting and deleting. The goal should be to have the message either rejected outright or placed into the inbox. If there is a problem, it can be discovered and resolved, at the expense of the sender. The Sender-ID approach seriously degrades reliability of mail in a systemic fashion, and puts a much greater burden onto the recipient. It does not really stop phishing, bounces, or spoofing. It does not identify the domain responsible for the introduction of the abuse. It does not allow a means to control such introduction. It does break forwarding. It does break mail "exploders". It does cause users to change their mail address. It does cause users to expose more of the mail addresses. It does put mail and DNS at risk. > If so, isn't this your responsibility to handle properly since step 6 > of the PRA says "SHOULD" reject (meaning, if you didn't, you really > ought to know what you are doing). That would be for resolving the PRA. If a spammer can't get past the test of creating a valid header, then it should be rejected. I would not expect the learning curve to be all that steep however, for this test to stop that much abuse. Imagine how credit cards would be handled, if there were no means to authenticate the identity of the person presenting the card. Imagine the amount of fraud there would be, if were no accreditation system. Why dream up methods to sort fraud? Stop it! Verify the name of the sending domain. Remember that domain if there was fraud. Take action based upon the history of that name. An accreditation service could make this process simple, but an MTA being administered with strict policies can make a significant reduction in this mess by just creating a history based upon names. No name or no history, offer only constrained service to limit damage. If there was damage, remember it or report it to the accreditation system. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 17:08:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09652 for ; Thu, 29 Jul 2004 17:08:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKtNCR008463; Thu, 29 Jul 2004 13:55:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TKtN1i008462; Thu, 29 Jul 2004 13:55:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKtJjK008437 for ; Thu, 29 Jul 2004 13:55:20 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BqHvr-0003av-00 for ; Thu, 29 Jul 2004 22:55:19 +0200 Received: from 212.82.251.212 ([212.82.251.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Jul 2004 22:55:19 +0200 Received: from nobody by 212.82.251.212 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Jul 2004 22:55:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: alternate submitter syntax Date: Thu, 29 Jul 2004 22:49:12 +0200 Organization: Lines: 54 Message-ID: <410962C8.2E98@xyzzy.claranet.de> References: <3CA474173FC0274799F97F3AB3BD25EE1A7817@ltwd-svr2.lightwood.com.au> <20040728053510.GN16317@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.212 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng Weng Wong wrote: > No, I expect the bounce address to always be MAIL FROM. > I expect the subject of SPF checking to be SUBMITTER if it > is present, and MAIL FROM if it is not. Let's see, I'm a spammer and have several hundreds of cheap domains and thousands of spamcast zombies. Today I would point one of my domains to the IP where I host redirections to my spamvertized pages, and then let my zombies send spam MAIL FROM: From: Subject: Viagra With classic SPF this will FAIL, no spamcast IP is allowed to use a forged@xyzzy address. Therefore I'm forced to use other addresses. With Sender-Id I'd also use one of my cheap domains per spam run (to be burnt with SURBL) _and_ add a sender policy for it: cast.example TXT "v=spf1 +exists:{ir}.cast.blackholes.us -all" Then I let my spamcast zombies fire: MAIL FROM: SUBMITTER=spam@cast.example From: forged@xyzzy Sender: spam@cast.example Subject: Viagra Sent from any spamcast zombie this should pass a Sender-Id test, and therefore it's not necessarily rejected immediately by the MX of the recipient. If it's bounced later it would go to forged@xyzzy. In <3CA474173FC0274799F97F3AB3BD25EE1A781A@ltwd-svr2.lightwood.com.au> Terje wrote: | You seem to be giving up one of the prime benefits of SPF | classic That's also my impression. You answered in <20040728194534.GO16317@dumbo.pobox.com>: | If SUBMITTER does not appear on your whitelist, then you can | reject the message even if the SPF check passes. What's this "whitelist" used with a SUBMITTER ? In my example the throw-away domain cast.example isn't on any "whitelist", it only exists for a single spam run of 10 million spam mails, the same idea as today with spamvertized domains. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 20:30:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20656 for ; Thu, 29 Jul 2004 20:30:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U09oJg043382; Thu, 29 Jul 2004 17:09:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6U09oVi043381; Thu, 29 Jul 2004 17:09:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U09o1D043372 for ; Thu, 29 Jul 2004 17:09:50 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id AE31D414BD; Thu, 29 Jul 2004 17:09:55 -0700 (PDT) Subject: Re: Is the back door open? From: Douglas Otis To: Rand Wacker Cc: Andrew Newton , Ryan Ordway , MARID In-Reply-To: <41090B4D.5060104@sendmail.com> References: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> <1091037531.11296.762.camel@ddev.mail-abuse.org> <1091052378.11296.1160.camel@ddev.mail-abuse.org> <41090B4D.5060104@sendmail.com> Content-Type: text/plain Message-Id: <1091146194.11296.1435.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 29 Jul 2004 17:09:55 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-29 at 07:35, Rand Wacker wrote: > Douglas Otis wrote: > > > On Wed, 2004-07-28 at 11:22, Rand Wacker wrote: > > > >>Doesn't protection against the bounce using SPF-Classic require 100% > >>adoption to make it work? Wouldn't BATV or some other site-local > >>protection against joe-jobbing have a more direct impact on this problem > >>(which, I will note, is not necessarily the problem this group was > >>chartered to address). > > > > SPF offered some relief, if the MTA creating the bounce checked the > > destination domain records for valid sources of the message. > > Again though, this requires *every* MTA that might generate a bounce to > deploy SPF checking, *everywhere*. I did say some. BATV would allow more immediate benefits as it could be acted upon by either end. It would be more effective at the sender, however. > > This is lost with Sender-ID. > > This wasn't the goal of Sender ID. We agree Sender-ID does not stop the bounce. I'll bite, what is the goal of Sender-ID? > > A solution for this problem could be found through > > a combination of SPF and BATV, where BATV is less disruptive. > > If an individual sending site deployed BATV wouldn't that let them > determine what bounces were genuine and which were forged from the > outside? Why would they need SPF *at all* in that case? Not everyone uses a null RFC 2821 MAIL FROM when they bounce. Determining a bounce then requires RFC 2822 checks of the From or Subject headers. This is not a solid basis for rejecting a message however. The act of the bounce is best known by the sender, in this case. > > SPF accommodates an address based white-list, but such a list would be of > > less use, with CSV offering names. > > Doesn't Sender ID accommodate an address-based white-list as well? > Specifically, addresses that users see/can see more readily than the > Envelope From? Is the PRA the same as the RFC 2821 MAIL FROM? Of course not. The check needs to be based upon an assertion made by the list. A goal to block the bounce, if the return path is spoofed, can not rely upon a list intended for a different purpose. > > Should end-users or the MTA make accept/reject decisions? > > This question seems out of place. But decisions should be made by some > automated system, probably near the gateway, operating on behalf of the > wishes of the admins/users. How are the results of this decision reported to the sender? Will mail simply go missing, if placed in a folder flooded with other junk? > > A quest to examine content only weakens a decision process with > > complexity. The decision whether to reject the message is best based > > upon RFC 2821 information. > > For what technical reason is it best based on the 2821 address? The EHLO domain allows for a stronger level of authentication and authorization, than an RFC 2822 identity allows (without the aid of digital signatures) as the EHLO domain can be authenticated directly against the remote address of the current connection. Rejection based upon RFC 2821 identities can also conserve network resources. RFC 2822 identity checks will never conserve network resources. Killing the connection is not a suitable solution as some advocate when rejection is based upon an RFC 2822 identity. The RFC 2821 MAIL FROM path is often spoofed as a means to skirt accreditation checks based upon the remote IP address or, with CSV, the name of the EHLO domain. There is a need to curtail this practice. BATV could do this very quickly, but SPF did have merit in this respect. Sender-ID does not, as we agree. > > A standard method to sign RFC 2821 MAIL FROM paths, as with BATV, would > > end schemes used by rogue mailers to skirt accreditation. This skirting > > takes advantage of MTAs that do not employ history, and a reason for > > many spoofed addresses. If the sending domain has a history, acceptance > > is based upon the sending domain's demonstration of policy. If the > > sending domain does not have a history, then mail could be constrained. > > Agreed. > > > For economies of scale, the burden must be placed upon the sender. This > > burden would result from their history of behavior. If the sending > > domain is rejected as a result of their accumulated history, then it > > becomes their burden as the sender. It must not be seen as a problem > > for the end-user to sort, filter, and delete. Grading makes mail > > unreliable and eventually useless. History based accreditation is best > > done with a known name of the sending domain responsible for policy. > > This is the specific aim of CSV. To stop spam or viruses, the question > > remains, what is the history of the domain? > > OK, I agree with everything you say here as well. Doesn't almost every > proposal put forth here (including Sender ID and DomainKeys) give you a > verifiable domain to check the history of? Sender-ID does not indicate the domain accountable for permitting access to the mail channel. Sender-ID can not check against the source of a message, if introduced inside an administrative network or region of MTAs. As such, it would be impossible to attribute any domain as being accountable, as this presumes an unverifiable assumption of security. Also, as shown by a Sender-ID bounce technique, the wrong domain could be credited for sending the message. It is also very likely, the domain assertion would be nebulous. What does ~, ?, +all, TempError, or 0.0.0.0/32 mean with respect to accrediting a domain? In the case of the BATV and a DomainKey, that is missing is a nounce. A short term blacklist of timestamps with BATV would exclude a 'replay' attack, but could not be used to accredit the domain. The Yahoo DomainKey or Cisco Identified Internet Mail signatures of the message would be strong enough to accredit the domain. These schemes would still benefit from a lightweight check of the sending domain however. Sender-ID itself may also need lightweight protections. > > Sender-ID does not identify which domain allowed introduction of abusive > > mail. > > Without 100% publication of DNS records for sending domains, *none* of > these solutions will be able to identify where all mail came from. Those systems that use CSV, will identify themselves as a source. If an MTA wishes to enjoy name accreditation, perhaps to bypass filtering or Sender-ID checks, there would be motivation for publishing the SRV record that enables this method. A name based accreditation could be beneficial without 100% participation. CSV-CSA is simple and does not add a single DNS query beyond the current SMTP protocol. CSV could eventually amend RFC 2821 as a means to repair the current defect preventing SMTP client authentication (with authorization added as a means to thwart Trojans). > > There can be no solution without this information. > > We may be looking for solutions to different problems then. I'll wait to see if I can understand the goal of Sender-ID first. > > If a domain demonstrates a history of neglect, then a growing number > > of rejected messages will make economic sense for polices to be > > repaired. Sender-ID is useless in this regard. Put the burden upon > > the sender, and not the recipient. > > Agree with the latter, disagree with the former. Sender-ID can be used > to verify the sending domain for purposes of reputation checks just like > you say. Is your concern with it the use of Resent-Sender and Resent-From? It would be a nightmare attempting to make sense of Sender-ID domains from an accreditation perspective. There are many ways Sender-ID itself can be spoofed, not to mention many nebulous levels of Sender-ID assurances about the domain. I see problems with an algorithm that ignores which header type was most recently applied. I doubt anyone has given this much consideration. Spammers will be quick to exploit exceptions and learn intra-domain relationships published in this records. Accreditation is about controlling access at the domain level. Sender-ID is about grading mail ignoring the channel granted access. These concepts are incompatible. Would you allow a retailer to complain about a bad credit card, if they never checked the identity of the card holder? > And, FWIW, neither SPF nor Sender-ID will ever be able to tell you any > more than the most recent domain to forward a message to you, so in the > case of messages that go through multiple hops to your gateway, you're > going to be checking the reputation of any service that may be > forwarding to you. I see name accreditation or history as a means of establishing a chain of trust. A retailer not only trusts a credit card, they are trusting the holder of the card. In general, they are trusting the system represented by the card. Only administrators of domains permitting access will be able to curtail high levels of abuse as seen today. Just as accreditation allows access to a credit card, the same approach can work for mail. Those domains that allow abuse, will themselves loose access. Showing little history could mean little access. This is a model that works. If there is a crime, there is also an authenticated and authorized domain name holding the logs with CSV. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 20:58:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22240 for ; Thu, 29 Jul 2004 20:58:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U0jmN8050404; Thu, 29 Jul 2004 17:45:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6U0jm72050403; Thu, 29 Jul 2004 17:45:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U0jl6Z050397 for ; Thu, 29 Jul 2004 17:45:47 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i6U0jqpA006722 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Jul 2004 17:45:52 -0700 Date: Thu, 29 Jul 2004 17:45:52 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Douglas Otis cc: Andrew Newton , Ryan Ordway , MARID Subject: Re: Is the back door open? In-Reply-To: <1091146194.11296.1435.camel@ddev.mail-abuse.org> Message-ID: References: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> <1091037531.11296.762.camel@ddev.mail-abuse.org> <1091052378.11296.1160.camel@ddev.mail-abuse.org> <41090B4D.5060104@sendmail.com> <1091146194.11296.1435.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jul 2004, Douglas Otis wrote: > > Again though, this requires *every* MTA that might generate a bounce to > > deploy SPF checking, *everywhere*. > > I did say some. BATV would allow more immediate benefits as it could be > acted upon by either end. It would be more effective at the sender, > however. Right, so it seems that BATV could be a *much* better solution to the joe-jobbing solution in the short term than SPF, precisely because BATV requires adoption by exactly *one* site, the sender that wants to discard bounces to them of forgeries. To completely solve joe-jobbing for any one site, SPF requires 100% adoption across the entire Internet. (This is not to say that SPF may have other good properties, I'm just hearing a lot of "its all about stopping joe-jobbing" comments) > We agree Sender-ID does not stop the bounce. I'll bite, what is the > goal of Sender-ID? I refer you to the MARID charter and the marid-core draft. > > For what technical reason is it best based on the 2821 address? > > The EHLO domain allows for a stronger level of authentication and > authorization, than an RFC 2822 identity allows (without the aid of > digital signatures) The RFC 2822 identity in a message is *exactly* the same regardless of whether it is authenticated by a crypto-based solution, an IP-based solution, or not authenticated at all. We are definitly talking about two different goals, as I want to authenticate the sender of a message, you want to authenticate the owner of a channel. > Sender-ID does not indicate the domain accountable for permitting access > to the mail channel. True. But again, that is not its goal. > Sender-ID can not check against the source of a message The *original* source of a message. It can check against the *most recent* source of the message, to exactly the same level of assuredness as SPF or any other IP-based system. > > Agree with the latter, disagree with the former. Sender-ID can be used > > to verify the sending domain for purposes of reputation checks just like > > you say. Is your concern with it the use of Resent-Sender and Resent-From? > > It would be a nightmare attempting to make sense of Sender-ID domains > from an accreditation perspective. When I say "accreditation and reputation checks" I am referring specifically to querying a network service to ask about historical behaviour of the particular sending domain. Based on previous comments I think you may be using accreditation to mean something different. > I see name accreditation or history as a means of establishing a chain > of trust. A retailer not only trusts a credit card, they are trusting > the holder of the card. In general, they are trusting the system > represented by the card. Only administrators of domains permitting > access will be able to curtail high levels of abuse as seen today. Just > as accreditation allows access to a credit card, the same approach can > work for mail. Those domains that allow abuse, will themselves loose > access. Showing little history could mean little access. This is a > model that works. If there is a crime, there is also an authenticated > and authorized domain name holding the logs with CSV. I still think we are using the term "accreditation" differently, but I believe we agree on one thing here, making domains more accountable for the mail they send. I *think* that you want to do this by authenticating the channel the domain used to inject a message in to the system. I want to do this by authenticating the user-visible address purports to be from. To be blunt, I think everyone who has actively participated in this group understands that *any* IP-based solution applied at *any* level can *only* give you assurance of the most recent hop that a message took. This applies to CSV, SPF, and Sender ID. This has implications for any message that takes more than one hop from the original sending domain to the final receiving domain. All the proponents of these IP-based solutions understand this and are moving forward knowing full well that they are not able to authenticate the original sending MTA, domain, or author. -Rand From owner-ietf-mxcomp@mail.imc.org Thu Jul 29 21:40:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23963 for ; Thu, 29 Jul 2004 21:40:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U1PDG8058000; Thu, 29 Jul 2004 18:25:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6U1PD8t057998; Thu, 29 Jul 2004 18:25:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U1PCP0057989 for ; Thu, 29 Jul 2004 18:25:12 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 29 Jul 2004 21:25:12 -0400 id 000DFB2B.4109A379.000014EB In-Reply-To: <1091130779.11296.1285.camel@ddev.mail-abuse.org> References: <20040728214728.8C67C16E17@mail.nitros9.org> <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> <1145525893.20040728171121@brandenburg.com> <5E6DBCD8-E177-11D8-B79D-000A95B3BA44@hxr.us> <1091130779.11296.1285.camel@ddev.mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4AD26A08-E1C7-11D8-BB8D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: MARID WG From: Andrew Newton Subject: Re: Is the back door open? Date: Thu, 29 Jul 2004 21:25:07 -0400 To: Douglas Otis X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 29, 2004, at 3:52 PM, Douglas Otis wrote: > If the bouncer has published their SPF record, then the bounce may > receive a Pass(+) rating. : ( This is getting repetitive. Why is it bouncing and not rejecting? > No. Bounce traffic is from a third-party beyond the control of the MTA > receiving the bounce. This is not between related parties. And this is NOT the ralph, fred, bob scenario you started with. So now we are back to receiving a bounce out of the wild, blue yonder? > No. The Sender-ID rating system directs mail into different folders > (rat-holes), and leaves to the end-user the task of sorting and > deleting. It does? I'll admit that I'm juggling multiple working groups and umpteen various drafts between them, so I could have missed it. But where is that written? > The goal should be to have the message either rejected > outright or placed into the inbox. If there is a problem, it can be > discovered and resolved, at the expense of the sender. So where does Step 6 fail on this? > The Sender-ID approach seriously degrades reliability of mail in a > systemic fashion, and puts a much greater burden onto the recipient. This is an unproven statement. Repeating it doesn't make it come true. > It > does not really stop phishing, bounces, or spoofing. What new data do you have on this that can be added to past discussions of what some MUA's do and do not display to the users? > It does not > identify the domain responsible for the introduction of the abuse. No, it identifies the domain which will undergo a forgery check, just like CSV and SPF. In the abusive case, all 3 do not identify the domain responsible for the introduction of the abuse. A spammer need not have purchased a domain to forge another. > It > does not allow a means to control such introduction. What about SUBMITTER? > It does break > forwarding. It does break mail "exploders". In some cases, yes. So does SPF. CSV doesn't. > It does cause users to > change their mail address. What? > It does cause users to expose more of the > mail addresses. What? > It does put mail and DNS at risk. This is another unproven statement. -andy From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 00:28:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02013 for ; Fri, 30 Jul 2004 00:28:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U4DUHF089342; Thu, 29 Jul 2004 21:13:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6U4DUSM089341; Thu, 29 Jul 2004 21:13:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U4DTfT089323 for ; Thu, 29 Jul 2004 21:13:29 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id AB358414B5; Thu, 29 Jul 2004 21:13:29 -0700 (PDT) Subject: Re: Is the back door open? From: Douglas Otis To: Rand Wacker Cc: Andrew Newton , Ryan Ordway , MARID In-Reply-To: References: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> <1091037531.11296.762.camel@ddev.mail-abuse.org> <1091052378.11296.1160.camel@ddev.mail-abuse.org> <41090B4D.5060104@sendmail.com> <1091146194.11296.1435.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1091160808.11296.1642.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 29 Jul 2004 21:13:28 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-29 at 17:45, Rand Wacker wrote: > On Thu, 29 Jul 2004, Douglas Otis wrote: > > > > Again though, this requires *every* MTA that might generate a bounce to > > > deploy SPF checking, *everywhere*. > > > > I did say some. BATV would allow more immediate benefits as it could be > > acted upon by either end. It would be more effective at the sender, > > however. > > Right, so it seems that BATV could be a *much* better solution to the > joe-jobbing solution in the short term than SPF, precisely because BATV > requires adoption by exactly *one* site, the sender that wants to discard > bounces to them of forgeries. To completely solve joe-jobbing for any one > site, SPF requires 100% adoption across the entire Internet. > > (This is not to say that SPF may have other good properties, I'm just > hearing a lot of "its all about stopping joe-jobbing" comments) > > > We agree Sender-ID does not stop the bounce. I'll bite, what is the > > goal of Sender-ID? > > I refer you to the MARID charter and the marid-core draft. The core-02 abstract: Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means the address is used without the permission of the domain owner. This document describes the following: mechanisms by which a domain owner can publish its set of outgoing MTAs, mechanisms by which SMTP servers can determine what email address is allegedly responsible for most proximately introducing a message into the Internet mail system, and whether that introduction is authorized by the owner of the domain contained in that email address. The specification is carefully tailored to ensure that the overwhelming majority of legitimate emailers, remailers and mailing list operators are already compliant. CSV publishes outgoing SMTP servers. A "spoofed" address for most would include the RFC 2821 MAIL FROM, but yet this address is ignored. CSV and BATV meets the goal of finding prior compliance far better than Sender-ID. Now here is an interesting sentence fragment. mechanisms by which SMTP servers can determine what email address is allegedly responsible for most proximately introducing a message into the Internet mail system, and whether that introduction is authorized by the owner of the domain contained in that email address. Clearly, in the case of a bounce containing Resent-Sender, Resent-From, or Sender, this proximal goal is missed. Also, can Sender-ID claim to have met this goal, if the rating is other than Pass or Fail? No, and yet there are many rating levels? Sender-ID allows mail to traverse or be emitted by many differing domains of those referenced by the PRA. It would be an over statement to suggest permissions of the PRA can be verified with any certitude. SMTP is simply not secure enough to make this assertion, especially when the specific SMTP server domain is ignored. There are methods that can safely reach to the RFC 2822 From. Methods like Identified Internet Mail can accomplish this goal, with the requisite certainty. Sender-ID can not. > > > For what technical reason is it best based on the 2821 address? > > > > The EHLO domain allows for a stronger level of authentication and > > authorization, than an RFC 2822 identity allows (without the aid of > > digital signatures) > > The RFC 2822 identity in a message is *exactly* the same regardless of > whether it is authenticated by a crypto-based solution, an IP-based > solution, or not authenticated at all. An RFC 2822 identity may relate to an IP address of an SMTP server, but at far greater distances, if compared to the EHLO domain. This is important in both the immense scale required for such a relationship, the complexity deriving the relationship, and the assumption of security needed to assert the relationship. Any claims of having verified or validated the RFC 2822 From would be irresponsible, in my opinion. The PRA is not limited to just this From header, nor should the channel be considered secure enough to make such claim. > We are definitly talking about two different goals, as I want to > authenticate the sender of a message, you want to authenticate the owner > of a channel. > > > Sender-ID does not indicate the domain accountable for permitting access > > to the mail channel. > > True. But again, that is not its goal. I would expect an ISP response to the complexity of Sender-ID, would be to add Resent-From to all outgoing mail. This would allow customers to continue normal habits. To arrive at a point where a message can be rejected or accredited, barriers must be removed that would prevent certitude in that process. A greater distance between the the associations being verified, reduces this certainty. Evidence of this reduced certainty is documented by the many gradations that may result with Sender-ID. If the goal is to validate the RFC 2822 From, then do this in a reasonable fashion. The scope of any simple validation should not extended beyond the most immediate, being the MTA in this case. This is the charter, is it not? > > Sender-ID can not check against the source of a message > > The *original* source of a message. It can check against the *most > recent* source of the message, to exactly the same level of assuredness as > SPF or any other IP-based system. I do not agree with that statement. By not going beyond the host being authenticated and authorized, there is a significant difference between the quality of the assurance from CSV versus Sender-ID, if to establish accountability of the entity granted access. Access is the commodity of accreditation and the tool to enforcement. > > > Agree with the latter, disagree with the former. Sender-ID can be used > > > to verify the sending domain for purposes of reputation checks just like > > > you say. Is your concern with it the use of Resent-Sender and Resent-From? > > > > It would be a nightmare attempting to make sense of Sender-ID domains > > from an accreditation perspective. > > When I say "accreditation and reputation checks" I am referring > specifically to querying a network service to ask about historical > behavior of the particular sending domain. Based on previous comments I > think you may be using accreditation to mean something different. With Sender-ID, I see a complex record set that may include many different domains. To suggest that I should accredit the domain seen in the PRA misses the purpose of accreditation. Accreditation needs to assess the policies of the domain granting access to the mail channel. The scale of this task is great, but resolving to the user would be overwhelming. There is a cost associated with a domain, there is virtually none for a user. The scope of the accreditation must end at the domain, and only relate to their access policies. With Sender-ID, these messages could be "granted permission" by any number of domains. > > I see name accreditation or history as a means of establishing a chain > > of trust. A retailer not only trusts a credit card, they are trusting > > the holder of the card. In general, they are trusting the system > > represented by the card. Only administrators of domains permitting > > access will be able to curtail high levels of abuse as seen today. Just > > as accreditation allows access to a credit card, the same approach can > > work for mail. Those domains that allow abuse, will themselves loose > > access. Showing little history could mean little access. This is a > > model that works. If there is a crime, there is also an authenticated > > and authorized domain name holding the logs with CSV. > > I still think we are using the term "accreditation" differently, but I > believe we agree on one thing here, making domains more accountable for > the mail they send. I *think* that you want to do this by authenticating > the channel the domain used to inject a message in to the system. I want > to do this by authenticating the user-visible address purports to be from. The PRA is not always the user-visible address. By looking to the user-visible address, you miss what needs accreditation. What domain is negligent in their access polices? Do their policies control access in a manner that abates abuse? Looking to the user-visible address makes this assessment far more difficult. Looking to the user-visible address makes this assessment far less accurate. Sender-ID does not offer the tools needed to tackle the problem, as its assertions are too weak and too vague to be acted upon. It may be just fine, if the goal is to select a folder. That goal seriously erodes the integrity of the mail system however. It also places a greater burden upon the recipient. It does not protect the network. It does not abate the abuse, because accreditation has become even more difficult. > To be blunt, I think everyone who has actively participated in this group > understands that *any* IP-based solution applied at *any* level can *only* > give you assurance of the most recent hop that a message took. This > applies to CSV, SPF, and Sender ID. This has implications for any message > that takes more than one hop from the original sending domain to the final > receiving domain. All the proponents of these IP-based solutions > understand this and are moving forward knowing full well that they are not > able to authenticate the original sending MTA, domain, or author. To fully understand the scope of the problem, work only on what can be assured. Limit the reach to the most immediate with simple measures and stop trying to indirectly authenticate the user. SMTP was never intended to preform this function. BATV and CSV can make a dramatic change without breaking mail, and can be put into play quickly. We can make a real difference, if to recognize what is within our grasp, and what is not. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 02:51:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21038 for ; Fri, 30 Jul 2004 02:51:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U6ZCHc047279; Thu, 29 Jul 2004 23:35:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6U6ZCZH047278; Thu, 29 Jul 2004 23:35:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U6ZC9G047271 for ; Thu, 29 Jul 2004 23:35:12 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id 735C44149D; Thu, 29 Jul 2004 23:35:12 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Thu, 29 Jul 2004 23:35:12 -0700 (PDT) Message-ID: <1069.64.142.13.68.1091169312.squirrel@harry.mail-abuse.org> In-Reply-To: <4AD26A08-E1C7-11D8-BB8D-000A95B3BA44@hxr.us> References: <20040728214728.8C67C16E17@mail.nitros9.org> <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> <1145525893.20040728171121@brandenburg.com> <5E6DBCD8-E177-11D8-B79D-000A95B3BA44@hxr.us> <1091130779.11296.1285.camel@ddev.mail-abuse.org> <4AD26A08-E1C7-11D8-BB8D-000A95B3BA44@hxr.us> Date: Thu, 29 Jul 2004 23:35:12 -0700 (PDT) Subject: Re: Is the back door open? From: "Douglas Otis" To: "Andrew Newton" Cc: "MARID WG" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > On Jul 29, 2004, at 3:52 PM, Douglas Otis wrote: >> If the bouncer has published their SPF record, then the bounce may >> receive a Pass(+) rating. : ( > > This is getting repetitive. Why is it bouncing and not rejecting? The message is accepted by the Sender-ID check with some rating other than Fail, but a more complete check of the local part of the address is done subsequent to acceptance. This name check fails, as intended, and the message is bounced. The same could happen with a virus. >> No. Bounce traffic is from a third-party beyond the control of the MTA >> receiving the bounce. This is not between related parties. > > And this is NOT the ralph, fred, bob scenario you started with. So now > we are back to receiving a bounce out of the wild, blue yonder? I had never used these names? Sender-ID never checks the RFC 2821 MAIL FROM. The bounced message will use this unchecked address to return the message. This return path could point anywhere and thus the message would appear out of the blue, as you would say, sporting a high rating. With headers able to trump the bounce From, a filter may have greater diffculty, as the PRA local part could be anything. >> No. The Sender-ID rating system directs mail into different folders >> (rat-holes), and leaves to the end-user the task of sorting and >> deleting. > > It does? I'll admit that I'm juggling multiple working groups and > umpteen various drafts between them, so I could have missed it. But > where is that written? When asked at the Open Group forum at Boston, during a presentation by Microsoft, they claimed the only result of the Sender-ID check was to sort mail into differing folders with their new Outlook. It does explain their lack of concern about reusing a list not intended for this function, or the lack of security of the channel. It does not abate the abuse, it simply tries to sort it into folders. >> The goal should be to have the message either rejected >> outright or placed into the inbox. If there is a problem, it can be >> discovered and resolved, at the expense of the sender. > > So where does Step 6 fail on this? You are referring to a process that selects the PRA? Sorry, but I fail to see that as having much to do with the rejection of messages. >> The Sender-ID approach seriously degrades reliability of mail in a >> systemic fashion, and puts a much greater burden onto the recipient. > > This is an unproven statement. Repeating it doesn't make it come true. Filtering in general degrades the reliability of mail. If you have experienced a failure of the mail reaching its destination without notice, then you are likely the victim of a filter. This happens and I have been forced to ask many times for an examination of the spam folder. Perhaps I become sensitve to this problem. I don't see Sender-ID as a solution for many reasons, but especially when it encorporates filtering, without addressing the source of abuse. >> It does not really stop phishing, bounces, or spoofing. > > What new data do you have on this that can be added to past discussions > of what some MUA's do and do not display to the users? It is not just a matter of what is displayed. There are areas where any shared MTA becomes an ample opportunity. Any ISP that transparently intercepts mail, will then place all their clients at risk of this phishing or spoofing. These clients may also lose mail, if they are unaware of this practice and close their lists. This intercept technique does abate spam. As Sender-ID does not, don't ask to have this practice stopped to allow a weak phishing claim. The bounce problem has nothing to do with the display. I would much rather see something like Identified Internet mail rather than Sender-ID for this type of function. There will be fewer victims of fraud then. >> It does not identify the domain responsible for the introduction of the >> abuse. > > No, it identifies the domain which will undergo a forgery check, just > like CSV and SPF. There is a difference. CSV uniquely identifies the sending domain granting access. Sender-ID or SPF may identify a set of domains that may have granted access. This is significant, when accreditation is considered. > In the abusive case, all 3 do not identify the domain responsible for the > introduction of the abuse. A spammer need not have purchased a domain to > forge another. How does a spammer forge the hostname with CSV? How does CSV not identify the domain? >> It does not allow a means to control such introduction. > > What about SUBMITTER? Submitter is about the same as PRA, assuming PRA gets checked. >> It does break forwarding. It does break mail "exploders". > > In some cases, yes. So does SPF. CSV doesn't. > >> It does cause users to change their mail address. > > What? In cases where the user does not control the DNS, there may be no choice but to change their RFC 2822 From to be accepted. >> It does cause users to expose more of the mail addresses. > > What? In the case of Submitter, the user may expose two addresses to accomplish this feat. >> It does put mail and DNS at risk. > > This is another unproven statement. Yes, I have not proved this statement. I can do the calculations that raise concerns. I call that risk. I have not seen any counter studies either. "That would be bad" does not suggest this matter has been reviewed to any degree. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 03:53:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22939 for ; Fri, 30 Jul 2004 03:53:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U7dkfW075409; Fri, 30 Jul 2004 00:39:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6U7dkOV075407; Fri, 30 Jul 2004 00:39:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U7djc6075393 for ; Fri, 30 Jul 2004 00:39:45 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id B33DA283E0 for ; Fri, 30 Jul 2004 09:39:44 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08975-01-3 for ; Fri, 30 Jul 2004 09:39:32 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id BAF1D283DD; Fri, 30 Jul 2004 09:39:32 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: The forged bounce question Date: Fri, 30 Jul 2004 09:39:32 +0200 User-Agent: KMail/1.6.1 References: <41090B4D.5060104@sendmail.com> <1091146194.11296.1435.camel@ddev.mail-abuse.org> In-Reply-To: <1091146194.11296.1435.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407300939.32283@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le vendredi 30 Juillet 2004 02:09, Douglas Otis a écrit : > > Not everyone uses a null RFC 2821 MAIL FROM when they bounce. > Determining a bounce then requires RFC 2822 checks of the From or > Subject headers. This is not a solid basis for rejecting a message > however.  The act of the bounce is best known by the sender, in this > case. What about the following idea : - Suppose that our outgoing SMTP servers encode _all_ of their outgoing MAIL FROM with SRS, whether or not the message is a forward, and whether or not it initially comes from our own domain. - Now we can reject all "bounces" (MAIL FROM: <>) that we would receive, which RCPT TO: wouldn't be a valid SRS address. Because if this were a legit bounce, then it would be a reply to one of our own messages, and would thus go to a valid SRS address. Looks simple, but what do you think ? -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 03:53:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22961 for ; Fri, 30 Jul 2004 03:53:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U7fSOQ076101; Fri, 30 Jul 2004 00:41:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6U7fSfD076100; Fri, 30 Jul 2004 00:41:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from puzzle.pobox.com (puzzle.sasl.smtp.pobox.com [207.8.226.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U7fSIo076073 for ; Fri, 30 Jul 2004 00:41:28 -0700 (PDT) (envelope-from McQuilWP@pobox.com) Received: from localhost.localdomain (localhost [127.0.0.1]) by puzzle.pobox.com (Postfix) with ESMTP id 069151391AE; Fri, 30 Jul 2004 03:40:16 -0400 (EDT) Received: from MCQWP2 (ip68-7-159-196.sd.sd.cox.net [68.7.159.196]) by puzzle.pobox.com (Postfix) with ESMTP id 99ED2139185; Fri, 30 Jul 2004 03:40:14 -0400 (EDT) Date: Fri, 30 Jul 2004 00:41:14 -0700 From: Bill McQuillan X-Mailer: The Bat! (v2.11) Personal X-Priority: 3 (Normal) Message-ID: <1507862623.20040730004114@pobox.com> To: MARID Subject: Re: Is the back door open? In-Reply-To: References: <27B826F8-E0B9-11D8-B79D-000A95B3BA44@hxr.us> <1091037531.11296.762.camel@ddev.mail-abuse.org> <1091052378.11296.1160.camel@ddev.mail-abuse.org> <41090B4D.5060104@sendmail.com> <1091146194.11296.1435.camel@ddev.mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-07-29 at 17:45:52, Rand Wacker wrote: > We are definitly talking about two different goals, as I want to > authenticate the sender of a message, you want to authenticate the owner > of a channel. But isn't Sender-Id trying to authenticate the sender of the message against the IP-address of the most recent SMTP client? Doesn't the IP-address represent a channel? -- Bill McQuillan From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 08:25:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02306 for ; Fri, 30 Jul 2004 08:25:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UC9MVJ056258; Fri, 30 Jul 2004 05:09:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UC9M7t056257; Fri, 30 Jul 2004 05:09:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UC9Kdg056249 for ; Fri, 30 Jul 2004 05:09:21 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48828) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1BqWCG-0002yV-G2 for ietf-mxcomp@imc.org; Fri, 30 Jul 2004 13:09:12 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BqWCG-0005t5-3q; Fri, 30 Jul 2004 13:09:12 +0100 Date: Fri, 30 Jul 2004 13:09:12 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Michel Bouissou cc: IETF MARID WG Subject: Re: The forged bounce question In-Reply-To: <200407300939.32283@totor.bouissou.net> Message-ID: References: <41090B4D.5060104@sendmail.com> <1091146194.11296.1435.camel@ddev.mail-abuse.org> <200407300939.32283@totor.bouissou.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 30 Jul 2004, Michel Bouissou wrote: > > Looks simple, but what do you think ? This is what BATV/SES/pick-your-name is about. Tony. -- f.a.n.finch http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR. GOOD. SLIGHT OR SMOOTH. From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 09:36:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05104 for ; Fri, 30 Jul 2004 09:36:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UDOOVA061678; Fri, 30 Jul 2004 06:24:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UDOOXK061677; Fri, 30 Jul 2004 06:24:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UDONMe061665 for ; Fri, 30 Jul 2004 06:24:23 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id E953E4149D; Fri, 30 Jul 2004 06:24:20 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Fri, 30 Jul 2004 06:24:20 -0700 (PDT) Message-ID: <1215.64.142.13.68.1091193860.squirrel@harry.mail-abuse.org> Date: Fri, 30 Jul 2004 06:24:20 -0700 (PDT) Subject: Re: The forged bounce question From: "Douglas Otis" To: "Michel Bouissou" Cc: "IETF MARID WG" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal References: <41090B4D.5060104@sendmail.com> <1091146194.11296.1435.camel@ddev.mail-abuse.org> <200407300939.32283@totor.bouissou.net> In-Reply-To: <200407300939.32283@totor.bouissou.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Le vendredi 30 Juillet 2004 02:09, Douglas Otis a écrit : >> >> Not everyone uses a null RFC 2821 MAIL FROM when they bounce. >> Determining a bounce then requires RFC 2822 checks of the From or Subject >> headers. This is not a solid basis for rejecting a message however. The >> act of the bounce is best known by the sender, in this case. > > What about the following idea : > > - Suppose that our outgoing SMTP servers encode _all_ of their outgoing > MAIL FROM with SRS, whether or not the message is a forward, and whether > or not it initially comes from our own domain. As SRS replaces the domain to match the forwarding SPF environment, the return path attempts to colapse to two steps of this process. If a forwarding process does not perform this function, then the message is rejected, as now the SPF environment is wrong. Rather than rewriting the return path, the concept is to use a public key found with DNS of the originating domain. If verified to be of that domain by the receiver, then the SPF environment check is not needed to validate the return path before a bounce. If the encoding is recognized, such a check could be used to discard a bounce by the receiver. This would not allow a rejection of a replay message by the receiver however, but then would not require 100% compliance for this to work through other hops. > - Now we can reject all "bounces" (MAIL FROM: <>) that we would receive, > which RCPT TO: wouldn't be a valid SRS address. > > Because if this were a legit bounce, then it would be a reply to one of > our own messages, and would thus go to a valid SRS address. BATV always allowed that. There are virus filtering programs and other noncompliant applications that attempt to "bounce" with a non-null return path. If there were an encoding of the return path that could be recognized and checked before the bounce were allowed, the sending side would then be helpful getting rid of that class of traffic. Not overly fond of SPF restricting user domains, I would rather see a comment tag added to a resent-from header that validated the forwarding domain using the same technique, if to reestablish the SPF environment. This would be done, rather than placing this forwarding domain into either the domain or localpart of the return path. This would forgive domains not publishing SPF records or adding SRS, unlike SRS. As often said, I think something like Identified Internet Mail would be a better choice for identifying the user. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 10:13:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08129 for ; Fri, 30 Jul 2004 10:13:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UE2adc065825; Fri, 30 Jul 2004 07:02:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UE2ajn065824; Fri, 30 Jul 2004 07:02:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UE2ZJG065805 for ; Fri, 30 Jul 2004 07:02:35 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 30 Jul 2004 10:02:35 -0400 id 000DF954.410A54FB.000066BC In-Reply-To: <1069.64.142.13.68.1091169312.squirrel@harry.mail-abuse.org> References: <20040728214728.8C67C16E17@mail.nitros9.org> <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> <1145525893.20040728171121@brandenburg.com> <5E6DBCD8-E177-11D8-B79D-000A95B3BA44@hxr.us> <1091130779.11296.1285.camel@ddev.mail-abuse.org> <4AD26A08-E1C7-11D8-BB8D-000A95B3BA44@hxr.us> <1069.64.142.13.68.1091169312.squirrel@harry.mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <19DE6FFE-E231-11D8-BB8D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: "MARID WG" From: Andrew Newton Subject: Re: Is the back door open? Date: Fri, 30 Jul 2004 10:02:32 -0400 To: "Douglas Otis" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 30, 2004, at 2:35 AM, Douglas Otis wrote: > The message is accepted by the Sender-ID check with some rating other > than > Fail, but a more complete check of the local part of the address is > done > subsequent to acceptance. This name check fails, as intended, and the > message is bounced. The same could happen with a virus. So you are explaining that a bounce occurs because something other than Sender-ID has happened, and therefore that is a problem with Sender-ID? >> And this is NOT the ralph, fred, bob scenario you started with. So >> now >> we are back to receiving a bounce out of the wild, blue yonder? > > I had never used these names? Sender-ID never checks the RFC 2821 MAIL > FROM. Ryan came up with the names after you backed into the use case when I asked why it was there was a bounce in the first place. You said there was a bounce because the mail was relayed to an MTA with the list of valid users. Now you are back to the first use case saying that the bounce just happens for some mystical reason. Ok fine. But then that is not a flaw in Sender-ID, which is where this thread started. On Jul 30, 2004, at 12:13 AM, Douglas Otis wrote: > To fully understand the scope of the problem, work only on what can be > assured. Limit the reach to the most immediate with simple measures > and > stop trying to indirectly authenticate the user. SMTP was never > intended to preform this function. BATV and CSV can make a dramatic > change without breaking mail, and can be put into play quickly. We can > make a real difference, if to recognize what is within our grasp, and > what is not. When you started this thread, I thought you were suggesting you had found a flaw in the PRA algorithm. That is why I engaged in discussion. Instead, this thread seems to have backed into the relative comparisons of CSV vs. SPF vs. Sender-ID, ground this working group has been over many, many times. It is nothing new to find out that one proposal deals with forwarding better, one proposal deals with bounces better, and one proposal deal with phishing better. -andy From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 10:32:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10197 for ; Fri, 30 Jul 2004 10:32:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UEJf2o067195; Fri, 30 Jul 2004 07:19:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UEJfTJ067194; Fri, 30 Jul 2004 07:19:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from oe-im2.bizmailsrvcs.net (oe-im2pub.managedmail.com [206.46.164.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UEJeST067183 for ; Fri, 30 Jul 2004 07:19:40 -0700 (PDT) (envelope-from sam_silberman+marid@openwave.com) Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040730141937.WHZT21050.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net>; Fri, 30 Jul 2004 09:19:37 -0500 Received: from silbermans ([12.25.200.134]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040730141937.WFOU21446.mm-ismta4.bizmailsrvcs.net@silbermans>; Fri, 30 Jul 2004 09:19:37 -0500 Message-ID: <008d01c47640$3e4154f0$0700a8c0@myopwv.com> Reply-To: "Sam Silberman" From: "Sam Silberman" To: "Michel Bouissou" , "IETF MARID WG" References: <41090B4D.5060104@sendmail.com> <1091146194.11296.1435.camel@ddev.mail-abuse.org> <200407300939.32283@totor.bouissou.net> Subject: Re: The forged bounce question Date: Fri, 30 Jul 2004 10:19:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Michel Bouissou" To: "IETF MARID WG" Sent: Friday, July 30, 2004 3:39 AM Subject: Re: The forged bounce question > What about the following idea : > > - Suppose that our outgoing SMTP servers encode _all_ of their outgoing MAIL > FROM with SRS, The trick is to encode SOMETHING into the 2821.MAILFROM. MUA/MTAs that don't know the 'secret' can't forge the MAILFROM. Take your pick of encodings BATV/SES/SRS/whatever. This argument is orthogonal to 2822 identity checking. Those method do not need to use the LHS of the 2821.MAILFROM. Both methods should work fine in tandom. -Sam From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 10:43:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11436 for ; Fri, 30 Jul 2004 10:43:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UEUbbc067738; Fri, 30 Jul 2004 07:30:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UEUbc7067737; Fri, 30 Jul 2004 07:30:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UEUaI5067731 for ; Fri, 30 Jul 2004 07:30:36 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 5FA9C28623 for ; Fri, 30 Jul 2004 16:30:38 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15743-03 for ; Fri, 30 Jul 2004 16:30:26 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id F0A6528617; Fri, 30 Jul 2004 16:30:25 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: The forged bounce question Date: Fri, 30 Jul 2004 16:30:25 +0200 User-Agent: KMail/1.6.1 References: <200407300939.32283@totor.bouissou.net> <1215.64.142.13.68.1091193860.squirrel@harry.mail-abuse.org> In-Reply-To: <1215.64.142.13.68.1091193860.squirrel@harry.mail-abuse.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407301630.25505@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le vendredi 30 Juillet 2004 15:24, Douglas Otis a écrit : > > > > What about the following idea : > > > > - Suppose that our outgoing SMTP servers encode _all_ of their outgoing > > MAIL FROM with SRS, whether or not the message is a forward, and whether > > or not it initially comes from our own domain. > > As SRS replaces the domain to match the forwarding SPF environment, the > return path attempts to colapse to two steps of this process. If a > forwarding process does not perform this function, then the message is > rejected, as now the SPF environment is wrong. I don't quite understand your point, as you are mixing SRS and SPF. I was discussing SRS as a way to detect forged bounces, and this can work completely independently from SPF. > Rather than rewriting the return path, the concept is to use a public key Which concept ? There is quite a number of concepts discussed here ;-) > > - Now we can reject all "bounces" (MAIL FROM: <>) that we would receive, > > which RCPT TO: wouldn't be a valid SRS address. > > > > Because if this were a legit bounce, then it would be a reply to one of > > our own messages, and would thus go to a valid SRS address. > > BATV always allowed that. As far as I understood (but correct me if I'm mistaken), a BATV address is replayable if it doesn't have a validity duration limit, which the draft I saw doesn't very clearly specify. On the other hand, SRS addresses have only a limited validity in time, so they are replayable only for a short period, which would make them of no interest harvesting for spammers. And bounce validity checking using SRS wouldn't need any public key to be published in DNS, nor any cooperation from the "bouncing side", it can be implemented by the "side receiving the bounce" alone, without any impact. i.e. If I decide tomorrow to patch my MTA so that _any_ outgoing mail from my domain has an SRS , and then that I will reject any DSN directed to any address other than a valid SRS address, then I can close the door to any spam ou virus disguised as a DSN, as it wouldn't have a valid destination. > There are virus filtering programs and other > noncompliant applications that attempt to "bounce" with a non-null return > path. If there were an encoding of the return path that could be > recognized and checked before the bounce were allowed, the sending side > would then be helpful getting rid of that class of traffic. I have read this paragraph 5 times and don't get your meaning at all ;-) Regards. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 12:01:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16014 for ; Fri, 30 Jul 2004 12:01:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UFkpWZ074273; Fri, 30 Jul 2004 08:46:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UFkpQZ074272; Fri, 30 Jul 2004 08:46:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UFkp8e074266 for ; Fri, 30 Jul 2004 08:46:51 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id 498CF4149D; Fri, 30 Jul 2004 08:46:49 -0700 (PDT) Received: from 207.46.121.10 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Fri, 30 Jul 2004 08:46:49 -0700 (PDT) Message-ID: <16773.207.46.121.10.1091202409.squirrel@harry.mail-abuse.org> Date: Fri, 30 Jul 2004 08:46:49 -0700 (PDT) Subject: Re: Is the back door open? From: "Douglas Otis" To: "Andrew Newton" Cc: "Douglas Otis" , "MARID WG" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > On Jul 30, 2004, at 2:35 AM, Douglas Otis wrote: >> The message is accepted by the Sender-ID check with some rating other >> than Fail, but a more complete check of the local part of the address is >> done subsequent to acceptance. This name check fails, as intended, and >> the message is bounced. The same could happen with a virus. > > So you are explaining that a bounce occurs because something other than > Sender-ID has happened, and therefore that is a problem with Sender-ID? Yes. >>> And this is NOT the ralph, fred, bob scenario you started with. So >>> now we are back to receiving a bounce out of the wild, blue yonder? >> >> I had never used these names? Sender-ID never checks the RFC 2821 MAIL >> FROM. > > Ryan came up with the names after you backed into the use case when I > asked why it was there was a bounce in the first place. You said there > was a bounce because the mail was relayed to an MTA with the list of > valid users. Now you are back to the first use case saying that the > bounce just happens for some mystical reason. Ok fine. But then that > is not a flaw in Sender-ID, which is where this thread started. This must have been a conversation off this list. The bounce does not happen for some mystical reason. The flaw, if you wish to call it that, is that Sender-ID does not prevent the bounce spam/virus traffic as did SPF. I strongly feel the motivation for publishing SPF was to find relief from this bounce traffic. That relief is not available with Sender-ID. The situation that creates the bounce is not uncommon. If mail is being relayed, it is often the relay only checks the right hand side of the recipient address. At some hop later, the local part of the recipient address is checked. At this point, the message may get bounced. Spammers are proficient at finding these configurations and using them in the manner descibed. It is also common for a virus check to happen after the message had been accepted, with a similar result. > On Jul 30, 2004, at 12:13 AM, Douglas Otis wrote: > >> To fully understand the scope of the problem, work only on what can be >> assured. Limit the reach to the most immediate with simple measures >> and stop trying to indirectly authenticate the user. SMTP was never >> intended to preform this function. BATV and CSV can make a dramatic >> change without breaking mail, and can be put into play quickly. We can >> make a real difference, if to recognize what is within our grasp, and >> what is not. > > When you started this thread, I thought you were suggesting you had > found a flaw in the PRA algorithm. That is why I engaged in > discussion. Instead, this thread seems to have backed into the > relative comparisons of CSV vs. SPF vs. Sender-ID, ground this working > group has been over many, many times. It is nothing new to find out > that one proposal deals with forwarding better, one proposal deals with > bounces better, and one proposal deal with phishing better. Sorry, I found Rand Wacker able to understand these concerns and continued to express what seems to be philosophical differences separating what appears to be rather common agreement on most issues. This statement does not dismiss the initial concern, as you appear to have concluded. Sorry, I'll restrain myself to smaller aspects of these details. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 14:43:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23992 for ; Fri, 30 Jul 2004 14:43:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UIRY8L085216; Fri, 30 Jul 2004 11:27:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UIRY0A085215; Fri, 30 Jul 2004 11:27:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UIRXLs085205 for ; Fri, 30 Jul 2004 11:27:33 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id AEF68414B7; Fri, 30 Jul 2004 11:27:32 -0700 (PDT) Received: from 207.46.112.37 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Fri, 30 Jul 2004 11:27:32 -0700 (PDT) Message-ID: <3038.207.46.112.37.1091212052.squirrel@harry.mail-abuse.org> In-Reply-To: <200407301630.25505@totor.bouissou.net> References: <200407300939.32283@totor.bouissou.net> <1215.64.142.13.68.1091193860.squirrel@harry.mail-abuse.org> <200407301630.25505@totor.bouissou.net> Date: Fri, 30 Jul 2004 11:27:32 -0700 (PDT) Subject: Re: The forged bounce question From: "Douglas Otis" To: "Michel Bouissou" Cc: "IETF MARID WG" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Le vendredi 30 Juillet 2004 15:24, Douglas Otis a écrit : >> > >> > What about the following idea : >> > >> > - Suppose that our outgoing SMTP servers encode _all_ of their >> > outgoing MAIL FROM with SRS, whether or not the message is a forward, >> > and whether or not it initially comes from our own domain. >> >> As SRS replaces the domain to match the forwarding SPF environment, the >> return path attempts to colapse to two steps of this process. If a >> forwarding process does not perform this function, then the message is >> rejected, as now the SPF environment is wrong. > > I don't quite understand your point, as you are mixing SRS and SPF. I was > discussing SRS as a way to detect forged bounces, and this can work > completely independently from SPF. > >> Rather than rewriting the return path, the concept is to use a public >> key > > Which concept ? There is quite a number of concepts discussed here ;-) Validation is not limited to just the sending domain. >> > - Now we can reject all "bounces" (MAIL FROM: <>) that we would >> > receive, which RCPT TO: wouldn't be a valid SRS address. >> > >> > Because if this were a legit bounce, then it would be a reply to one >> > of our own messages, and would thus go to a valid SRS address. >> >> BATV always allowed that. > > As far as I understood (but correct me if I'm mistaken), a BATV address is > replayable if it doesn't have a validity duration limit, which the draft I > saw doesn't very clearly specify. BATV did include a timestamp. I admit, the draft is just an outline. There are several otheres working to make this draft more complete. > On the other hand, SRS addresses have only a limited validity in time, so > they are replayable only for a short period, which would make them of no > interest harvesting for spammers. It would prevent the return path being used to avoid accreditation. It would not prevent a replay attack to different MTAs spoofing as the original message. This would be assuming the return path was being validated as part of the acceptance process. That is not required for this be useful. > And bounce validity checking using SRS wouldn't need any public key to be > published in DNS, nor any cooperation from the "bouncing side", it can be > implemented by the "side receiving the bounce" alone, without any impact. If the sending side could know when a return path was being used, that would be good, if only to ensure the return path on the bounce messages was null. > i.e. If I decide tomorrow to patch my MTA so that _any_ outgoing mail from > my domain has an SRS , and then that I will reject any DSN > directed to any address other than a valid SRS address, then I can close > the door to any spam or virus disguised as a DSN, as it wouldn't have a > valid destination. You will still be struggling with some of this traffic. It will be reduced. As I said, not all of this traffic uses a null return. >> There are virus filtering programs and other noncompliant applications >> that attempt to "bounce" with a non-null return path. If there were an >> encoding of the return path that could be recognized and checked before >> the bounce were allowed, the sending side would then be helpful getting >> rid of that class of traffic. If there were a recognizeable encoding of a return path (that would indicate it to be a return path), then the sending side could help ensure the message sent using this return path, would itself ensure this message contained a null (MAIL FROM: <>) return path as a means to acknowledge it was sending a bounce. This concern is with respect to preventing double bounces. If the encoding is understood, and can be validated by the sender, and this is discovered to be not valid, then the bounce can be dropped. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 15:40:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27392 for ; Fri, 30 Jul 2004 15:40:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UJR9bm088366; Fri, 30 Jul 2004 12:27:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UJR9j1088365; Fri, 30 Jul 2004 12:27:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.once.com (mail.once.com [207.162.212.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UJR8Tg088359 for ; Fri, 30 Jul 2004 12:27:08 -0700 (PDT) (envelope-from rordway@once.com) Received: from exchange2.once.com (exchange2.once.com [192.168.0.5]) by mail.once.com (8.12.8/8.12.8) with ESMTP id i6UJQRB1022052; Fri, 30 Jul 2004 12:26:28 -0700 (PDT) Received: from [192.168.0.23] (rordway-g4.once.com [192.168.0.23]) by exchange2.once.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P8042GMQ; Fri, 30 Jul 2004 12:26:27 -0700 In-Reply-To: <19DE6FFE-E231-11D8-BB8D-000A95B3BA44@hxr.us> References: <20040728214728.8C67C16E17@mail.nitros9.org> <6A7219EE-E0E3-11D8-B79D-000A95B3BA44@hxr.us> <1145525893.20040728171121@brandenburg.com> <5E6DBCD8-E177-11D8-B79D-000A95B3BA44@hxr.us> <1091130779.11296.1285.camel@ddev.mail-abuse.org> <4AD26A08-E1C7-11D8-BB8D-000A95B3BA44@hxr.us> <1069.64.142.13.68.1091169312.squirrel@harry.mail-abuse.org> <19DE6FFE-E231-11D8-BB8D-000A95B3BA44@hxr.us> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <59D337C2-E25E-11D8-9258-00306571677A@once.com> Content-Transfer-Encoding: 7bit Cc: "Douglas Otis" , "MARID WG" From: Ryan Ordway Subject: Re: Is the back door open? Date: Fri, 30 Jul 2004 12:26:26 -0700 To: Andrew Newton X-Mailer: Apple Mail (2.618) X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-101.2, required 5, AWL 0.00, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.50, QUOTED_EMAIL_TEXT -0.48, REFERENCES -0.50, REPLY_WITH_QUOTES -0.50, USER_AGENT_APPLEMAIL 0.00, USER_IN_WHITELIST -100.00) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 30, 2004, at 7:02 AM, Andrew Newton wrote: >>> And this is NOT the ralph, fred, bob scenario you started with. So >>> now >>> we are back to receiving a bounce out of the wild, blue yonder? >> >> I had never used these names? Sender-ID never checks the RFC 2821 >> MAIL >> FROM. > > Ryan came up with the names after you backed into the use case when I > asked why it was there was a bounce in the first place. You said > there was a bounce because the mail was relayed to an MTA with the > list of valid users. Now you are back to the first use case saying > that the bounce just happens for some mystical reason. Ok fine. But > then that is not a flaw in Sender-ID, which is where this thread > started. > > > On Jul 30, 2004, at 12:13 AM, Douglas Otis wrote: > >> To fully understand the scope of the problem, work only on what can be >> assured. Limit the reach to the most immediate with simple measures >> and >> stop trying to indirectly authenticate the user. SMTP was never >> intended to preform this function. BATV and CSV can make a dramatic >> change without breaking mail, and can be put into play quickly. We >> can >> make a real difference, if to recognize what is within our grasp, and >> what is not. > > When you started this thread, I thought you were suggesting you had > found a flaw in the PRA algorithm. That is why I engaged in > discussion. Instead, this thread seems to have backed into the > relative comparisons of CSV vs. SPF vs. Sender-ID, ground this working > group has been over many, many times. It is nothing new to find out > that one proposal deals with forwarding better, one proposal deals > with bounces better, and one proposal deal with phishing better. Do we not want a solution that deals with each of these problems? I would rather spend a few more months having to wait for an adequate solution, rather than roll out a flawed solution and hope for the best. What would be the problem with addressing these issues now? And that is not a rhetorical question, I really want to know. Thanks, Ryan -- Ryan Ordway Sr. Unix Systems Administrator rordway@once.com From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 17:57:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03377 for ; Fri, 30 Jul 2004 17:57:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ULicIk098442; Fri, 30 Jul 2004 14:44:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6ULic2D098441; Fri, 30 Jul 2004 14:44:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ULiaOV098434 for ; Fri, 30 Jul 2004 14:44:38 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [66.80.0.10] (dhcp-10.danastreet.live.com [66.80.0.10]) by mail.glyphic.com (Postfix) with ESMTP id 085F640DA for ; Fri, 30 Jul 2004 14:44:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <1090970806.11296.441.camel@ddev.mail-abuse.org> References: <1090970806.11296.441.camel@ddev.mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: Is the back door open? Date: Fri, 30 Jul 2004 14:45:03 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It has taken me a few days to digest and understand the broad range of concerns with Sender-ID that Doug has raised. Most of the specific points already have clear responses by others in this thread. I hope to respond to grander concepts implicit in Doug's statements. Picking an Identity ------------------- This group has agreed up front that a piece of the spam puzzle hinges on being able to check that the sending MTA's IP address is authorized by the domain of some identity associated with the e-mail message. By holding that domain responsible, and staking it's reputation on the actions of the MTAs it authorizes, the scheme enables systems that result in a reduction of spam. For better or worse, RFC 2821 and RFC 2822 are not concerned with this kind of identity. Due to both the design of the standards, and deployed current practices, none of the identities: not the HELO domain, not the MAIL FROM, nor any of the headers, presents a clear identity of the form we need. The schemes discussed in this group, CSV, original SPF, and Sender-ID each pick an identity from the RFC 2821/RFC 2822 set and imbue it with the meaning we need. We expect that upon adoption of such a scheme, by virtue of being checked by receiving MTAs, it will acquire this new meaning. However, by doing so, the new scheme will be at odds with some segment of current practice, and cause some entities to change their processes. Picking an identity is a matter of weighing pluses and minuses - there is no clear choice. Picking PRA ----------- Originally, SPF was based on the 2821 MAIL FROM identity. Briefly, it is a convenient identity to check, and it had the additional advantage of directly confronting bounce-back attacks ("joe-jobs"). However, downsides were that it requires some significant changes for some MTAs (in the form of SRS) and that this identity isn't generally connected with anything the recipient sees. Picking an identity based on the 2822 headers is closer to what recipient thinks of as the identity and can require fewer and simpler changes for MTAs that need them (in the form of SUBMITTER). The current form of the PRA algorithm (in core-02) is neither heuristic nor proprietary nor arcane: It is a direct embodiment of the 2822 concept of the mailbox that sent or resent the message. The priorities and orderings of the headers checked is follow directly from the 2822 definition of the headers. I'm sure the description in core-02 could be more clear in this regard. One minor related issue: Multi-part messages have no bearing on PRA, since the MIME multi-part construct, including the headers of any included messages, is all part of the body of the outer message. Such attached headers are never involved. DNS DDoS and Other Attacks -------------------------- The number of DNS queries has been grossly overstated in this discussion. As for DDoS attacks based on SPF records designed to cause large number of DNS queries, or through excessive querying of legitimate SPF records, this is discussed in the protocol draft. In short, while conceivable, the possible DDoS attacks are harder to mount and have less impact that other, existing mail based DDoS attacks. It seems to me that ALL schemes discussed in MARID are subject to DNS poising schemes. Indeed, we talk about it clearly in the protocol draft. This is nothing new. The notion that SPF computation is so high that that sites will postpone the Sender-ID check until the receiver is a known good user does not hold up to scrutiny. Large volume mail receivers routinely apply checks that are far more resource expensive than Sender-ID. The vulnerability of sending via backup MXs is there in EVERY scheme - and exists today -- no one can really use backup MXs that aren't under their administrative control, and aren't configured to support the identical local mail policy. The era of reciprocal friendly back-up MXs is gone. However, deploying secondary and backup MXs within an organization, with common administrative control and policy still works in the face of Sender-ID. And yes, the Sender-ID check needs to be done at the border, as do any checks that are checking the authorization of the sending MTA. Yes - Sender-ID no longer directly combats bounce attacks. But it does insofar as the only bounced mail is mail that doesn't fail a Sender-ID check (as that mail would be rejected at the 2821 layer.) Of course, the reputation of the domain in a message that passes Sender-ID stakes its reputation on the message and hence if the bounces are joe jobs, it would suffer. Does this mean that anyone launching a bounce attack will use a domain without a published SPF record? Yes - but no scheme proposed on MARID purports to break the status quo. And, when I discuss my work with anyone, bounce attacks are at the bottom of the pile of spam concerns. Lastly, neither Sender-ID, CSV, nor original SPF will stop phishing directly: Once a phisher catches own, they will have domains set up correctly. Only the addition of reputation can fix this, and then only if MUAs present the information in a way that users can understand. "big-bank.cc" is going to be forever confused with "big-bank.com". Sender-ID however helps the most: Since it is based on the reputation of a domain the user will see, and we can only hope the "big-bank.cc"s of the world will get a bad reputation quickly. I hope this helps further our group understanding. - Mark From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 18:51:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06879 for ; Fri, 30 Jul 2004 18:50:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UMZPRp002612; Fri, 30 Jul 2004 15:35:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UMZPCl002611; Fri, 30 Jul 2004 15:35:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from messagelevel.com ([208.253.112.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UMZNfr002603 for ; Fri, 30 Jul 2004 15:35:25 -0700 (PDT) (envelope-from bill.mcinnis@messagelevel.com) Received: from BILL [64.83.63.84] by messagelevel.com with ESMTP (SMTPD32-8.05) id AD191E3E0058; Fri, 30 Jul 2004 18:35:05 -0400 From: "Bill McInnis" To: "IETF MARID WG" Subject: How would SPF or Sender Id caught this one? Date: Fri, 30 Jul 2004 18:34:52 -0400 Message-ID: <7DF9D69B5FC4BB449AEFA3B1CCF7BF3525FFA1@exchange.rdcim.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Declude-Sender: bill.mcinnis@messagelevel.com [64.83.63.84] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I sent this to the ASRG list as well so I apologize if you got it twice. Last weekend a phishing attack took place against US Bank. The phisher spoofed and connected with the appropriate IP for US Bank, 170.135.72.63. How would SPF or Sender ID have managed to catch that attack? Thanks, Bill McInnis MessageLevel.com ---- This outgoing message is guaranteed to be authentic by MessageLevel users. Guarantee the authenticity of your email @ http://www.messagelevel.com. From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 19:28:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08172 for ; Fri, 30 Jul 2004 19:28:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UNICeZ005755; Fri, 30 Jul 2004 16:18:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UNIC5b005754; Fri, 30 Jul 2004 16:18:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UNIBLc005746 for ; Fri, 30 Jul 2004 16:18:11 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i6UNIBrf004286 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 30 Jul 2004 19:18:12 -0400 Date: Fri, 30 Jul 2004 19:18:11 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? In-Reply-To: <20040727221835.4794816E17@mail.nitros9.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 27 Jul 2004, Alan DeKok wrote: > > > With the preceding in mind, how does SPF prevent a virus-infected, > > hijacked computer from sending abuse email? > > It doesn't. It DOES, however, make them accountable to either the > domain used by the owner of the infected machine, or by a throw-away > spammer domain. Which does what? AOL and MSN and other large domain operators already have tens of thousands of virus infected machines sending junk. Mostly, those machines are connecting directly. It wouldn't make any difference if they send mail through AOL's mail servers instead, using a forged (or accurate) @aol.com From: address. Major residential providers have already blocked outgoing SMTP, which forces the clients to the providers relays. This hasn't stopped abuse. Essentially, all SPF is a way to force everyone to block outbound SMTP except from their relays. But that won't stop abuse either. > IMHO, MARID (RMX, etc) is about closing a hole in SMTP, which says > "messages MUST be accepted for delivery or bounced", but it makes no > provisions for ensuring that the message CAN be bounced. Ahh. Still trying to contact the abuser. Well, forget it. There is no way to do that. You aren't dealing with a commerical operator practically any of the time. You are dealing with a one-way, virus-operated mail client whose purpose is not two-way communication but sending one-way abuse. "Bounce" has no meaning to such a client, and there is no point in trying to "bounce" anything to them. > One intention behind all of these related ideas is to provably have an > accountable entity which will accept responsibility for messages, > including bounces. This is impossible. You already have an accountable entity: the IP address delegate. Evidently, they either aren't responsible enough or aren't responsive enough to halt abuse. They are often the same entity as the domain delegate: AOL owns the IP address, AOL owns the aol.com domain. You haven't "proven" anyone's accountability. Information theory demonstrates conclusively that that you can't stop abuse by protocol. There is an abuse problem: More specifically, there is a Virus problem. The virus operator doesn't care about the domain owner any more than they care about the machine owner, or the IP address owner. The domain owner has no more control over the infected machine than the IP address owner. That being so, sender verification is pointless. It costs us millions, perhaps billions of dollars to go through these gyrations. There are millions of domains, for which tens or hundreds of records will have to be added to DNS. That expands the distributed DNS database by tens or hundreds of millions of records. Operations like register.com and DNS operators have to alter their applications to store and update the records. Millions of dollars are spent doing this. The virus operator has to add a couple lines of code to his program to use the infected machines legitimate email address, and use psyBNC to distibute this to his virus stable. Time to implement: few days. Cost: 0. I am sorry to be critical, but this was why the DNSEXT group rejected RMX. One has to wonder why it was brought up again without more critical analysis. If you want to stop abuse, then forget about SPF, and work on viruses. Thats the problem and unless you address that problem, you are just playing with playdoh: Squeezing it just changes the shape, but not the mass. It doesn't go away, it just morphs. But making it change shape costs the good guys money and the bad guys nothing. --Dean From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 19:55:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09330 for ; Fri, 30 Jul 2004 19:55:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UNiYng007373; Fri, 30 Jul 2004 16:44:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UNiYZm007372; Fri, 30 Jul 2004 16:44:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UNiY19007361 for ; Fri, 30 Jul 2004 16:44:34 -0700 (PDT) (envelope-from daryl.odnert@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v6.0.0)); Fri, 30 Jul 2004 16:44:12 -0700 X-Server-Uuid: 2FF20946-3D64-4888-885C-250F7FE4E04F Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Fri, 30 Jul 2004 16:44:29 -0700 Message-ID: From: "Daryl Odnert" To: "'Bill McInnis'" , "IETF MARID WG" Subject: RE: How would SPF or Sender Id caught this one? Date: Fri, 30 Jul 2004 16:44:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D1402C62X49696625-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4768F.27384824" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4768F.27384824 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit > How would SPF or Sender ID have managed to catch that attack? I think the answer is: they cannot. If the phisher successfully spoofed the an SMTP over TCP session, there is nothing that SPF or Sender ID can do about that. You might want to look at section 6.2 of draft-ietf-marid-core-02.txt. Regards, Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C4768F.27384824 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: How would SPF or Sender Id caught this one?

> How would SPF or Sender ID have managed to catch that attack?

I think the answer is: they cannot.  If the phisher successfully
spoofed the an SMTP over TCP session, there is nothing that SPF
or Sender ID can do about that.

You might want to look at section 6.2 of draft-ietf-marid-core-02.txt.

Regards,
Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C4768F.27384824-- From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 19:56:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09363 for ; Fri, 30 Jul 2004 19:56:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UNm6F5007565; Fri, 30 Jul 2004 16:48:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UNm6a0007564; Fri, 30 Jul 2004 16:48:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UNm6As007558 for ; Fri, 30 Jul 2004 16:48:06 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i6UNmBsD004793 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 30 Jul 2004 19:48:11 -0400 Date: Fri, 30 Jul 2004 19:48:11 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? In-Reply-To: <20040727221835.4794816E17@mail.nitros9.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 27 Jul 2004, Alan DeKok wrote: > > which creating significant impediments for legitimate email > > outsourcing. > > Which is why great care must be taken in its design and implementation. Well, it is interesting that the major corporate sponsors of SPF and RMX aren't against spam, but only spam not originating from them or not paying them. It is also in their interest to prevent outsourcing, so that they get the whole service package. I find it difficult to believe they are really taking great care to make sure it doesn't break outsourcing. But, great care or not, SPF does make it pretty much impossible to outsource. You need a record for each mailserver. It is reported that it is only possible to have 18 root Nameservers because that is the maximum that can fit in a DNS packet. The TXT record is not as efficient, but I don't have any exact number for the maximum number of servers will be possilbe. But it will probably approximately 18. This limits the number of servers that can be outsourced, or even internally used. Lets try a more concrete example: At present, I believe that AOL has a number of 4 inbound MX's and a larger number of outbound servers. I don't have any special knowledge of AOL internal operations, but I think they have each user server send outbound email directly. Presumably, they have more than 18 outbound servers. Then there are deployment issues. Besides the cost of adding the SPF records to tens of millions of domains and the complications of just getting that done, there are other complications: DNS protocols present provide for TCP connections to handle packets larger than 512 bytes. However, many server implementations still don't support TCP, or don't support it properly. This leaves a large number of domains that won't be able to work with SPF, and it means that a lot of mail will just mysteriously fail depending on the originating site's SPF configuration. Then there are domains that will have to re-architect their mail architecture so that all internal mail is first sent through an "SPF approved" server. Many systems are configured to send outgoing mail directly. This creates more burden on the outgoing mailservers. Some sites will need to buy new servers as a result. This will be significant and possibly devastating for some. Then there are issues getting SPF deployed in mail servers. Not everyone runs "Debian stable" with automatic update. For most, this will mean they will have to upgrade software sooner than they expected. So it will be a long while before SPF has any benefit for many sites. This is just scratching the surface. At each step, there are even more complications that could go wrong, and cost money or disrupt mail. Again: abuser takes a few days at most to adapt. Total cost to abuse: $0. --Dean From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 19:58:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09418 for ; Fri, 30 Jul 2004 19:58:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UNoQuU007679; Fri, 30 Jul 2004 16:50:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UNoQNq007678; Fri, 30 Jul 2004 16:50:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from messagelevel.com ([208.253.112.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UNoPoW007671 for ; Fri, 30 Jul 2004 16:50:25 -0700 (PDT) (envelope-from bill.mcinnis@messagelevel.com) Received: from BILL [64.83.63.84] by messagelevel.com with ESMTP (SMTPD32-8.05) id AEB04CA00BE; Fri, 30 Jul 2004 19:50:08 -0400 From: "Bill McInnis" To: "'Daryl Odnert'" , "IETF MARID WG" Subject: RE: How would SPF or Sender Id caught this one? Date: Fri, 30 Jul 2004 19:49:55 -0400 Message-ID: <7DF9D69B5FC4BB449AEFA3B1CCF7BF3525FFA3@exchange.rdcim.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C4766E.64609D70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Declude-Sender: bill.mcinnis@messagelevel.com [64.83.63.84] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C4766E.64609D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for the reply, I read that and that was my understanding as well. So does this make it a solution that works fine for mailing lists, but not for financial institutions, online retailers, and pretty much anyone transacting dollars online? The example was not made up. We are seeing that scenario more and more where I am sitting. Bill McInnis MessageLevel.com -----Original Message----- From: Daryl Odnert [mailto:daryl.odnert@tumbleweed.com] Sent: Friday, July 30, 2004 7:44 PM To: Bill Mcinnis; IETF MARID WG Subject: RE: How would SPF or Sender Id caught this one? > How would SPF or Sender ID have managed to catch that attack? I think the answer is: they cannot. If the phisher successfully spoofed the an SMTP over TCP session, there is nothing that SPF or Sender ID can do about that. You might want to look at section 6.2 of draft-ietf-marid-core-02.txt. Regards, Daryl Odnert Tumbleweed Communications Redwood City, California ------=_NextPart_000_0000_01C4766E.64609D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Thanks for the = reply,
 
I read that and that was my understanding = as=20 well.  So does this make it a solution that works fine for = mailing=20 lists, but not for financial institutions, online retailers, and = pretty=20 much anyone transacting dollars online?  =
 
The example was not made up.  We are = seeing that=20 scenario more and more where I am sitting. =20   
 
 
Bill=20 McInnis
MessageLevel.com
 
 -----Original = Message-----
From:=20 Daryl Odnert [mailto:daryl.odnert@tumbleweed.com]
Sent: = Friday, July=20 30, 2004 7:44 PM
To: Bill Mcinnis; IETF MARID = WG
Subject:=20 RE: How would SPF or Sender Id caught this = one?

> How would SPF or Sender ID have managed to catch = that=20 attack?

I think the answer is: they cannot.  If the = phisher=20 successfully
spoofed the an SMTP over TCP = session, there=20 is nothing that SPF
or Sender ID can do about=20 that.

You might want to look at section 6.2 of=20 draft-ietf-marid-core-02.txt.

Regards,
Daryl Odnert =
Tumbleweed Communications
Redwood = City,=20 California

------=_NextPart_000_0000_01C4766E.64609D70-- ---- This outgoing message is guaranteed to be authentic by MessageLevel users. Guarantee the authenticity of your email @ http://www.messagelevel.com. From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 20:29:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11897 for ; Fri, 30 Jul 2004 20:29:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V0CI1R009731; Fri, 30 Jul 2004 17:12:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V0CIWZ009728; Fri, 30 Jul 2004 17:12:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V0CFE4009606 for ; Fri, 30 Jul 2004 17:12:16 -0700 (PDT) (envelope-from madman@myeastside.com) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i6V0CIX5025718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Jul 2004 17:12:18 -0700 Message-ID: <021501c47693$0ac836e0$3201a8c0@rasta> From: "Harold A'Hole" To: "Bill McInnis" , "'Daryl Odnert'" , "IETF MARID WG" References: <7DF9D69B5FC4BB449AEFA3B1CCF7BF3525FFA3@exchange.rdcim.com> Subject: Re: How would SPF or Sender Id caught this one? Date: Fri, 30 Jul 2004 17:12:18 -0700 Organization: http://madman.myeastside.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Message> The example was not made up. We are seeing that scenario more and more where I am sitting. > Bill McInnis > MessageLevel.com How are they carrying on a TCP comm session with a spoofed IP address -- or did they hack the legit sending SMTP server with that IP address? Harry From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 20:30:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12078 for ; Fri, 30 Jul 2004 20:30:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V0AosW009507; Fri, 30 Jul 2004 17:10:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V0AoiJ009506; Fri, 30 Jul 2004 17:10:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V0An05009488 for ; Fri, 30 Jul 2004 17:10:49 -0700 (PDT) (envelope-from daryl.odnert@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v6.0.0)); Fri, 30 Jul 2004 17:10:24 -0700 X-Server-Uuid: 2FF20946-3D64-4888-885C-250F7FE4E04F Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Fri, 30 Jul 2004 17:10:40 -0700 Message-ID: From: "Daryl Odnert" To: "'Bill McInnis'" , "IETF MARID WG" Subject: RE: How would SPF or Sender Id caught this one? Date: Fri, 30 Jul 2004 17:10:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D143CFA2X49706648-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47692.CF61C981" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C47692.CF61C981 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Well, I think the idea is that SPF and/or Sender ID significantly raise the bar in terms of how difficult it is to spoof sender's identity. Today, just about anyone can send a spoofed message by changing some settings in their email client application. If tomorrow, it becomes necessary to spoof a TCP session to do the same thing, I think that's significant progress. If you really want to trust that the contents of a email message was authored by the person who claims to be the author, you need to use a digital signature based authentication mechanism (e.g. S/MIME). Many financial institutions and online retailers are considering that option together with other authentication and anti-spam/anti-phishing strategies. Daryl Odnert Tumbleweed Communications Redwood City, California -----Original Message----- From: Bill McInnis [mailto:bill.mcinnis@messagelevel.com] Sent: Friday, July 30, 2004 4:50 PM To: 'Daryl Odnert'; IETF MARID WG Subject: RE: How would SPF or Sender Id caught this one? Thanks for the reply, I read that and that was my understanding as well. So does this make it a solution that works fine for mailing lists, but not for financial institutions, online retailers, and pretty much anyone transacting dollars online? The example was not made up. We are seeing that scenario more and more where I am sitting. Bill McInnis MessageLevel.com -----Original Message----- From: Daryl Odnert [mailto:daryl.odnert@tumbleweed.com] Sent: Friday, July 30, 2004 7:44 PM To: Bill Mcinnis; IETF MARID WG Subject: RE: How would SPF or Sender Id caught this one? > How would SPF or Sender ID have managed to catch that attack? I think the answer is: they cannot. If the phisher successfully spoofed the an SMTP over TCP session, there is nothing that SPF or Sender ID can do about that. You might want to look at section 6.2 of draft-ietf-marid-core-02.txt. Regards, Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C47692.CF61C981 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message
Well, I think the idea is that SPF and/or Sender ID significantly raise the bar in terms of how difficult it is to spoof sender's identity.  Today, just about anyone can send a spoofed message by changing some settings in their email client application.  If tomorrow, it becomes necessary to spoof a TCP session to do the same thing, I think that's significant progress.
 
If you really want to trust that the contents of a email message was authored by the person who claims to be the author, you need to use a digital signature based authentication mechanism (e.g. S/MIME).  Many financial institutions and online retailers are considering that option together with other authentication and anti-spam/anti-phishing strategies.
 
Daryl Odnert
Tumbleweed Communications
Redwood City, California
 
-----Original Message-----
From: Bill McInnis [mailto:bill.mcinnis@messagelevel.com]
Sent: Friday, July 30, 2004 4:50 PM
To: 'Daryl Odnert'; IETF MARID WG
Subject: RE: How would SPF or Sender Id caught this one?

Thanks for the reply,
 
I read that and that was my understanding as well.  So does this make it a solution that works fine for mailing lists, but not for financial institutions, online retailers, and pretty much anyone transacting dollars online? 
 
The example was not made up.  We are seeing that scenario more and more where I am sitting.    
 
 
Bill McInnis
MessageLevel.com
 
 -----Original Message-----
From: Daryl Odnert [mailto:daryl.odnert@tumbleweed.com]
Sent: Friday, July 30, 2004 7:44 PM
To: Bill Mcinnis; IETF MARID WG
Subject: RE: How would SPF or Sender Id caught this one?

> How would SPF or Sender ID have managed to catch that attack?

I think the answer is: they cannot.  If the phisher successfully
spoofed the an SMTP over TCP session, there is nothing that SPF
or Sender ID can do about that.

You might want to look at section 6.2 of draft-ietf-marid-core-02.txt.

Regards,
Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C47692.CF61C981-- From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 20:38:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12693 for ; Fri, 30 Jul 2004 20:38:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V0RXU5010790; Fri, 30 Jul 2004 17:27:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V0RX5o010789; Fri, 30 Jul 2004 17:27:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V0RWrD010782 for ; Fri, 30 Jul 2004 17:27:32 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 60CB628619 for ; Sat, 31 Jul 2004 02:27:29 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30181-08 for ; Sat, 31 Jul 2004 02:27:17 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id AF1D628617; Sat, 31 Jul 2004 02:27:17 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: How is SPF different from RMX? Date: Sat, 31 Jul 2004 02:27:17 +0200 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407310227.17210@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le samedi 31 Juillet 2004 01:48, Dean Anderson a écrit : > > Well, it is interesting that the major corporate sponsors of SPF and RMX > aren't against spam, but only spam not originating from them or not paying > them. For sure, they are quite against "illegitimate spam" that dilutes their "legitimate corporate advertising" ;-) > But, great care or not, SPF does make it pretty much impossible to > outsource. You need a record for each mailserver. It is reported that it > is only possible to have 18 root Nameservers because that is the maximum > that can fit in a DNS packet. The TXT record is not as efficient, but I > don't have any exact number for the maximum number of servers will be > possilbe. But it will probably approximately 18. This limits the number > of servers that can be outsourced, or even internally used. I understand from this that you don't understand at all the way that an SPF record works. Please Read The Fu^Hine Documentation... > Then there are deployment issues. Besides the cost of adding the SPF > records to tens of millions of domains and the complications of just > getting that done, Tens of millions of domains are currently supposed to manage and maintain their DNS records, and each domain, even really "basic" needs at least 4 records in DNS, typically - 1 SOA - 2 DNS - 1 MX or more - 1 A for the MX (if in the same domain) - Generally one "www.thing.org" that points to the web server And of course the bigger the domain, the greater the number of machines and "A" records in DNS. Adding SPF to a domain is adding ONE TXT record to the domain. It is also wise to add one for each "A" record in the domain. Setting this up is a matter of minutes for one domain, so every domain that has an admin maintaining it should be able to afford it -- and those who do that externally actually pay for a service, don't they ? Expressing this in "billion dollars" is like trying to evaluate the time that I spent scratching my head today, multiply this by the number of inhabitants in my country, and calculate from there how many billion dollars are lost each month from work time lost scratching one's head... > there are other complications: > > DNS protocols present provide for TCP connections to handle packets larger > than 512 bytes. However, many server implementations still don't support > TCP, or don't support it properly. If they don't, they should. If broken, fix. Well, you're depicting a whole nightmare in which it seems that you much exagerate the problems that implementing SPF causes. Remember that more than 22,000 domains using SPF are known as of today, and some suppose the actual total figure is about 100,000 or more. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E Ne auderis delere orbem rigidum meum! From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 21:11:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13792 for ; Fri, 30 Jul 2004 21:11:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V0wsUx013402; Fri, 30 Jul 2004 17:58:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V0wsSw013401; Fri, 30 Jul 2004 17:58:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from messagelevel.com ([208.253.112.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V0wqSL013394 for ; Fri, 30 Jul 2004 17:58:53 -0700 (PDT) (envelope-from bill.mcinnis@messagelevel.com) Received: from BILL [64.83.63.84] by messagelevel.com with ESMTP (SMTPD32-8.05) id AEC512D800CC; Fri, 30 Jul 2004 20:58:45 -0400 From: "Bill McInnis" To: "'Daryl Odnert'" , "IETF MARID WG" Subject: RE: How would SPF or Sender Id caught this one? Date: Fri, 30 Jul 2004 20:58:32 -0400 Message-ID: <7DF9D69B5FC4BB449AEFA3B1CCF7BF3525FFA4@exchange.rdcim.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C47677.FA649CA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Declude-Sender: bill.mcinnis@messagelevel.com [64.83.63.84] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C47677.FA649CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What keeps an spoofer from sending the non-S/MIME message and it still reaching the end user? Bill McInnis MessageLevel.com -----Original Message----- From: Daryl Odnert [mailto:daryl.odnert@tumbleweed.com] Sent: Friday, July 30, 2004 8:11 PM To: Bill Mcinnis; IETF MARID WG Subject: RE: How would SPF or Sender Id caught this one? Well, I think the idea is that SPF and/or Sender ID significantly raise the bar in terms of how difficult it is to spoof sender's identity. Today, just about anyone can send a spoofed message by changing some settings in their email client application. If tomorrow, it becomes necessary to spoof a TCP session to do the same thing, I think that's significant progress. If you really want to trust that the contents of a email message was authored by the person who claims to be the author, you need to use a digital signature based authentication mechanism (e.g. S/MIME). Many financial institutions and online retailers are considering that option together with other authentication and anti-spam/anti-phishing strategies. Daryl Odnert Tumbleweed Communications Redwood City, California -----Original Message----- From: Bill McInnis [mailto:bill.mcinnis@messagelevel.com] Sent: Friday, July 30, 2004 4:50 PM To: 'Daryl Odnert'; IETF MARID WG Subject: RE: How would SPF or Sender Id caught this one? Thanks for the reply, I read that and that was my understanding as well. So does this make it a solution that works fine for mailing lists, but not for financial institutions, online retailers, and pretty much anyone transacting dollars online? The example was not made up. We are seeing that scenario more and more where I am sitting. Bill McInnis MessageLevel.com -----Original Message----- From: Daryl Odnert [mailto:daryl.odnert@tumbleweed.com] Sent: Friday, July 30, 2004 7:44 PM To: Bill Mcinnis; IETF MARID WG Subject: RE: How would SPF or Sender Id caught this one? > How would SPF or Sender ID have managed to catch that attack? I think the answer is: they cannot. If the phisher successfully spoofed the an SMTP over TCP session, there is nothing that SPF or Sender ID can do about that. You might want to look at section 6.2 of draft-ietf-marid-core-02.txt. Regards, Daryl Odnert Tumbleweed Communications Redwood City, California ------=_NextPart_000_0058_01C47677.FA649CA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
What=20 keeps an spoofer from sending the non-S/MIME message and it still = reaching the=20 end user? 
 
Bill = McInnis
MessageLevel.com
 
-----Original Message-----
From: Daryl Odnert=20 [mailto:daryl.odnert@tumbleweed.com]
Sent: Friday, July 30, = 2004 8:11=20 PM
To: Bill Mcinnis; IETF MARID WG
Subject: RE: How = would=20 SPF or Sender Id caught this one?

Well, I think the idea is that SPF and/or Sender ID = significantly raise=20 the bar in terms of how difficult it is to spoof sender's = identity.  Today,=20 just about anyone can send a spoofed message by changing some settings = in their=20 email client application.  If tomorrow, it becomes necessary to = spoof a TCP=20 session to do the same thing, I think that's significant=20 progress.
 
If=20 you really want to trust that the contents of a email message was = authored by=20 the person who claims to be the author, you need to use a digital = signature=20 based authentication mechanism (e.g. S/MIME).  Many financial = institutions=20 and online retailers are considering that option together with other=20 authentication and anti-spam/anti-phishing = strategies.
 
Daryl Odnert
Tumbleweed Communications
Redwood City, California
 
-----Original Message-----
From: Bill McInnis=20 [mailto:bill.mcinnis@messagelevel.com]
Sent: Friday, July 30, = 2004=20 4:50 PM
To: 'Daryl Odnert'; IETF MARID WG
Subject: = RE: How=20 would SPF or Sender Id caught this one?

Thanks for the = reply,
 
I read that and that was my understanding = as=20 well.  So does this make it a solution that works fine for = mailing=20 lists, but not for financial institutions, online retailers, and = pretty=20 much anyone transacting dollars online?  =
 
The example was not made up.  We are = seeing that=20 scenario more and more where I am sitting. =20   
 
 
Bill=20 McInnis
MessageLevel.com
 
 -----Original = Message-----
From:=20 Daryl Odnert [mailto:daryl.odnert@tumbleweed.com]
Sent: = Friday, July=20 30, 2004 7:44 PM
To: Bill Mcinnis; IETF MARID = WG
Subject:=20 RE: How would SPF or Sender Id caught this = one?

> How would SPF or Sender ID have managed to catch = that=20 attack?

I think the answer is: they cannot.  If the = phisher=20 successfully
spoofed the an SMTP over TCP = session, there=20 is nothing that SPF
or Sender ID can do about=20 that.

You might want to look at section 6.2 of=20 draft-ietf-marid-core-02.txt.

Regards,
Daryl Odnert =
Tumbleweed Communications
Redwood = City,=20 California

------=_NextPart_000_0058_01C47677.FA649CA0-- ---- This outgoing message is guaranteed to be authentic by MessageLevel users. Guarantee the authenticity of your email @ http://www.messagelevel.com. From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 21:37:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15022 for ; Fri, 30 Jul 2004 21:37:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V1RtpB016944; Fri, 30 Jul 2004 18:27:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V1RtKo016943; Fri, 30 Jul 2004 18:27:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V1RtVH016936 for ; Fri, 30 Jul 2004 18:27:55 -0700 (PDT) (envelope-from larry@larryseltzer.com) Message-Id: <200407310127.i6V1RtVH016936@above.proper.com> Received: (qmail 980 invoked from network); 31 Jul 2004 01:27:59 -0000 Received: from dsl081-214-187.nyc2.dsl.speakeasy.net (HELO elliot) (lseltzer@[64.81.214.187]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 31 Jul 2004 01:27:58 -0000 From: "Larry Seltzer" To: "'IETF MARID WG'" Subject: RE: How would SPF or Sender Id caught this one? Date: Fri, 30 Jul 2004 21:27:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcR2lXd7Ccg9wtgKTaOPX1GTU6NilQAB6tPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2149 In-Reply-To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>If you really want to trust that the contents of a email message was authored by the person who claims to be the author, you need to use a digital signature based authentication mechanism (e.g. S/MIME). S/MIME isn't necessary to address this scenario, which does demonstrate the basic flaw of any IP-based solution. Domain Keys would have stopped it though. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer larryseltzer@ziffdavis.com From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 21:58:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15621 for ; Fri, 30 Jul 2004 21:58:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V1okkI018797; Fri, 30 Jul 2004 18:50:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V1okl8018796; Fri, 30 Jul 2004 18:50:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V1ojZL018790 for ; Fri, 30 Jul 2004 18:50:45 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i6V1vtlD015165; Fri, 30 Jul 2004 18:57:55 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i6V1vtlX015162; Fri, 30 Jul 2004 18:57:55 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 30 Jul 2004 18:57:55 -0700 (PDT) From: "william(at)elan.net" To: Larry Seltzer cc: "'IETF MARID WG'" Subject: RE: How would SPF or Sender Id caught this one? In-Reply-To: <200407310127.i6V1RtVH016936@above.proper.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 30 Jul 2004, Larry Seltzer wrote: > >>If you really want to trust that the contents of a email message was > authored by the person who claims to be the author, you need to use a > digital signature based authentication mechanism (e.g. S/MIME). > > S/MIME isn't necessary to address this scenario, which does demonstrate > the basic flaw of any IP-based solution. Domain Keys would have stopped > it though. At a cost of loosing legitimate email if you rely on and if intermediate systems (mailservers, forwarders, etc) do not support DK. On the other hand, s/mime is designed to be end-end system that works no matter what intermediate system does with email. If we're to build mail server signature insertion system (which is not a bad idea since neither s/mime nor pgp are used widely by end-users, so so we must "help" them out by having mail servers sign email instead and verify it), then such system should should be similar to real email signatures and be end-end capable, meaning you don't have to be the next hop in email transmission to be able to verify the signature safely. One such proposal paper is available at http://www.elan.net/~william/asrg/mta_signatures.htm -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 21:58:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15639 for ; Fri, 30 Jul 2004 21:58:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V1kpb7018568; Fri, 30 Jul 2004 18:46:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V1kp7r018567; Fri, 30 Jul 2004 18:46:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V1koYk018557 for ; Fri, 30 Jul 2004 18:46:50 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i6V1kj3g006818 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 30 Jul 2004 21:46:45 -0400 Date: Fri, 30 Jul 2004 21:46:45 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Michel Bouissou cc: IETF MARID WG Subject: Re: How is SPF different from RMX? In-Reply-To: <200407310227.17210@totor.bouissou.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 31 Jul 2004, Michel Bouissou wrote: > > > But, great care or not, SPF does make it pretty much impossible to > > outsource. You need a record for each mailserver. It is reported that it > > is only possible to have 18 root Nameservers because that is the maximum > > that can fit in a DNS packet. The TXT record is not as efficient, but I > > don't have any exact number for the maximum number of servers will be > > possilbe. But it will probably approximately 18. This limits the number > > of servers that can be outsourced, or even internally used. > > I understand from this that you don't understand at all the way that an SPF > record works. Please Read The Fu^Hine Documentation... I read http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-00.txt The example records seem a lot shorter than 512 bytes. But that limit comes pretty quick. I seem to recall that HESIOD records could quickly eat that up. Wait, wasn't that one of the reasons why we thought that TCP was necessary in the first place? In this respect, RMX was probably better. But it was still rejected because It didn't solve the problem and was therefore gratuitous. > > Then there are deployment issues. Besides the cost of adding the SPF > > records to tens of millions of domains and the complications of just > > getting that done, > > Tens of millions of domains are currently supposed to manage and maintain > their DNS records, and each domain, even really "basic" needs at least 4 > records in DNS, typically > - 1 SOA > - 2 DNS > - 1 MX or more > - 1 A for the MX (if in the same domain) > - Generally one "www.thing.org" that points to the web server The vast majority of domains have 5 records. So, we are talking about increase the global dns database of 20 percent. And a corresponding increase in DNS traffic, and a corresponding increase in DNS server load. > And of course the bigger the domain, the greater the number of machines and > "A" records in DNS. Agree. It has less impact on the large domains. > Setting this up is a matter of minutes for one domain Setting anything is "a matter of minutes for one domain". Try doing it for hundreds or thousands of domains. > , so every domain that has an admin maintaining it should be able to > afford it -- and those who do that externally actually pay for a > service, don't they ? Service that doesn't include 20% increase in frivolous domain record maintanence: And it is ongoing maintenance. Change the IP of your mailservers, and lots most stuff has to change. It gets correspondingly more difficult to renumber. > Expressing this in "billion dollars" is like trying to evaluate the time that > I spent scratching my head today, multiply this by the number of inhabitants > in my country, and calculate from there how many billion dollars are lost > each month from work time lost scratching one's head... Yes, to some extent. But that means its not a good idea to make everyone on the planet scratch their heads a lot. Policy analysis includes these sort of costs in the cost analysis. > > there are other complications: > > > > DNS protocols present provide for TCP connections to handle packets larger > > than 512 bytes. However, many server implementations still don't support > > TCP, or don't support it properly. > > If they don't, they should. If broken, fix. Much more easilly said than done. There are complications and costs to doing this. > Well, you're depicting a whole nightmare in which it seems that you much > exagerate the problems that implementing SPF causes. Remember that more than > 22,000 domains using SPF are known as of today, and some suppose the actual > total figure is about 100,000 or more. 22,000 out of perhaps 22 million domains? That's less than one tenth of one percent. I'm sure more than that use "hair growth cream". It doesn't matter how many use it if it doesn't work. "It works for me at the moment" is not a sufficiently convincing technical analysis to spend a great deal of money and inconvenience a lot of people. Simply rejecting all mail with a 450 response for 5 minutes "works for some at the moment", too. But it won't work for long, because abusers simplely need to try again in 5 minutes, and remember for which addresses they got a temporary error response. Not a big problem for the abuser to solve. Unfortunately, making them solve it means that temporary respite from spam that one obtains from a crashed server will go away, too. Gee thanks. Now there is nothing to make those events less bad. Keep shooting us in the foot, folks. Maybe you'll hit something vital. Or maybe, you'll just kill something like outsourcing email, and no one will notice. Before something will be accepted, it needs to work for a long time. That means that it has to do more than just break the current and past abuse engines for a few days. It has to break them permanently. Wait, information theory says something about that. It says you can't ever achieve that. So, it seems that you have to track down virus operators and put them in jail. --Dean From owner-ietf-mxcomp@mail.imc.org Fri Jul 30 23:07:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18540 for ; Fri, 30 Jul 2004 23:07:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V2tOm3024940; Fri, 30 Jul 2004 19:55:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V2tO3g024938; Fri, 30 Jul 2004 19:55:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V2tNVO024930 for ; Fri, 30 Jul 2004 19:55:24 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: How would SPF or Sender Id caught this one? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 30 Jul 2004 21:55:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA932@srv1.pan-am.ca> Thread-Topic: How would SPF or Sender Id caught this one? Thread-Index: AcR2iBpuh5uyXea4QbOpBVRim9VkYgAITusQ From: "Gordon Fecyk" To: "IETF MXCOMP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6V2tOVO024932 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Last weekend a phishing attack took place against US Bank. > The phisher > spoofed and connected with the appropriate IP for US Bank, > 170.135.72.63. How would SPF or Sender ID have managed to catch that > attack? You mean this thing? A client of mine had a few of these and they didn't originate from 170.whatever. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. Received: from mail75.messagelabs.com ([216.82.255.83]) by [deleted] with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jul 2004 18:55:37 -0500 X-VirusChecked: Checked X-Env-Sender: 800USBanks@usbank-email.com X-Msg-Ref: server-11.tower-75.messagelabs.com!1091231734!3639048 X-StarScan-Version: 5.2.10; banners=-,-,- X-Originating-IP: [68.112.226.25] X-SpamInfo: spam detected heuristically X-Spam-Flag: YES X-SpamOriginallyTo: [deleted] X-SpamReason: Yes, hits=50.0 required=7.0 tests=Double IP in prior Received Received: (qmail 21202 invoked from network); 30 Jul 2004 23:55:35 -0000 Received: from cpe-68-112-226-25.ma.charter.com (68.112.226.25) by server-11.tower-75.messagelabs.com with SMTP; 30 Jul 2004 23:55:35 -0000 Received: from 143.6.51.232 by 68.112.226.25; Fri, 30 Jul 2004 22:48:32 -0200 Message-ID: From: "U.S. Bank" <800USBanks@usbank-email.com> Reply-To: "U.S. Bank" <800USBanks@usbank-email.com> To: [deleted] Subject: New U.S. Bank Security Standards Date: Sat, 31 Jul 2004 03:53:32 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--40920341319358678064" X-Priority: 1 X-IP: 248.174.232.74 Return-Path: 800USBanks@usbank-email.com X-OriginalArrivalTime: 30 Jul 2004 23:55:37.0494 (UTC) FILETIME=[B60DC360:01C47690] From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 01:55:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25619 for ; Sat, 31 Jul 2004 01:55:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V5fs7o052783; Fri, 30 Jul 2004 22:41:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V5fsvV052782; Fri, 30 Jul 2004 22:41:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts20-srv.bellnexxia.net (tomts20-srv.bellnexxia.net [209.226.175.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V5frnV052751 for ; Fri, 30 Jul 2004 22:41:53 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.206.18]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040731054156.HILO26030.tomts20-srv.bellnexxia.net@ibmrkydk2ufvdd>; Sat, 31 Jul 2004 01:41:56 -0400 From: "John Glube" To: "'Bill McInnis'" , "'Daryl Odnert'" , "'IETF MARID WG'" Subject: RE: How would SPF or Sender Id caught this one? Date: Sat, 31 Jul 2004 01:41:26 -0400 Message-ID: <011301c476c1$070d89f0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0114_01C4769F.7FFBE9F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <7DF9D69B5FC4BB449AEFA3B1CCF7BF3525FFA4@exchange.rdcim.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0114_01C4769F.7FFBE9F0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I happen to have received the US Bank =93phish=94 email. =20 Since I live in Toronto, Canada and don=92t do business with US Bank, I recognized it for what it was. =20 Because I felt the message was a problem, I made a copy of the email header, along with a report.=20 =20 So everyone can see what we are talking about, I am forwarding a copy of the message header. =20 For privacy reasons, I have made the following changes to the header: =20 * I have changed the domain information as found in the header information concerning existing domains within Canada or the United States. =20 I am now showing the spammed email address as phished@example.com =20 The various addresses, domains and the final address have been altered, with the ultimate recipient address being shown as personal@bigisp.com.=20 =20 I have left the return path as originally shown, being Return-Path: =20 * I have altered each of the related IP addresses slightly, except that of the one which is shown below as ([220.168.12.3]). =20 (A =93who is=94 inquiry through DNS & stuff shows this IP address is assigned to Chinanet, being the Hunan province network with offices in Beijing.) =20 * All other information in the header has not been changed. =20 According to the header, it seems the phisher made a direct connection from the IP address assigned to Chinanet to the MX server of the spammed email address.=20 =20 Of course, if this was a legitimate bank message, it would not have been sent in this fashion. Also, it was sent with low importance. =20 Given the header information, I am curious to know how this particular message header would have been treated, based on the presumption the spammed domain has published an SPF record (compliant with Sender =96ID) and the receiving MX server associated with the spammed email address is set up to check for either SPF or Sender ID records?=20 =20 If anyone wishes an original of the header for personal analysis, please email me and I will send it on. =20 John Glube Toronto, Canada =20 The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html =20 --------------- Header --------------- =20 Return-Path: Received: from toip1.bigisp.net ([209.220.175.84]) by tomts38-srv.bigsip.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040726103003.BFKZ8124.tomts38-srv.bigisp.net@toip1.bigsip.net> for ; Mon, 26 Jul 2004 06:30:03 -0400 Received: from erato.host2u.net (216.70.64.161) by toip1.bigisp.net with ESMTP; 26 Jul 2004 06:30:02 -0400 Received: from 66.79.231.191 ([220.168.12.3]) by erato.host2u.net (8.11.6/8.11.6) with SMTP id i6QATuo17389 for ; Mon, 26 Jul 2004 05:29:57 -0500 Message-Id: <200407261029.i6QATuo17389@erato.host2u.net> X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 FCC: mailbox://anti-fraud.ref.num341742039034844@usbank.com/Sent X-Identity-Key: id1 Date: Mon, 26 Jul 2004 14:25:49 +0300 From: U S Bank X-Mozilla-Draft-Info: internal/draft; vcard=3D0; receipt=3D0; uuencode=3D0 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: phish@example.com Subject: Important notification Content-Type: multipart/related; boundary=3D"------------010705020107040506040001" =20 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004 =20 ------=_NextPart_000_0114_01C4769F.7FFBE9F0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Message

I happen to have received the US = Bank =93phish=94 email.

 

Since I live in = Toronto, Canada and don=92t do business = with

US Bank, I recognized it for what = it was.

 

Because I felt the message was a = problem, I made a copy of

the email header, along with a = report.

 

So everyone can see what we are = talking about, I am

forwarding a copy of the message = header.

 

For privacy reasons, I have made = the following changes to

the header:

 

* I have changed the domain = information as found in the

header information concerning = existing domains within

Canada or the United States.

 

I am now showing the spammed email = address as

phished@example.com

 

The various addresses, domains and = the final address have

been altered, with the ultimate = recipient address being

shown as personal@bigisp.com. =

 

I have left the return path as = originally shown, being

Return-Path: <anti-fraud.ref.num341742039034844@usbank.com>

 

* I have altered each of the = related IP addresses slightly,

except that of the one which is = shown below as

([220.168.12.3]).

=

 

(A =93who is=94 inquiry through = DNS & stuff shows this IP

address is assigned to Chinanet, = being the Hunan province

network with offices in = Beijing.)

 

* All other information in the = header has not been changed.

 

According to the header, it seems = the phisher made a direct

connection from the IP address = assigned to Chinanet to the

MX server of the spammed email = address.

 

Of course, if this was a = legitimate bank message, it would

not have been sent in this = fashion. Also, it was sent with

low importance.

 

Given the header information, I am = curious to know how this

particular message header would = have been treated, based on

the presumption the spammed domain = has published an SPF

record (compliant with Sender = =96ID) and the receiving MX

server associated with the spammed = email address is set up

to check for either SPF or Sender = ID records?

 

If anyone wishes an original of = the header for personal

analysis, please email me and I = will send it on.

 

John Glube

Toronto, Canada

 

The FTC Calls For Sender = Authentication

http://www.learnsteps4profit.com/dn= e.html

 

--------------- Header = ---------------

 

Return-Path: <anti-fraud.ref.num341742039034844@usbank.com>

Received: from toip1.bigisp.net = ([209.220.175.84])

      = ;    by tomts38-srv.bigsip.net

      = ;    (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with = ESMTP

      = ;    id = <20040726103003.BFKZ8124.tomts38-srv.bigisp.net@toip1.bigsip.net>

      = ;    for <personal@bigisp.net>; Mon, 26 Jul = 2004 06:30:03 -0400

Received: from erato.host2u.net = (216.70.64.161)

  by toip1.bigisp.net with = ESMTP; 26 = Jul 2004 06:30:02 -0400

Received: from 66.79.231.191 ([220.168.12.3])

      = ;      by erato.host2u.net (8.11.6/8.11.6) with SMTP id = i6QATuo17389

      = ;      for <phish@example.com>; Mon, 26 Jul = 2004 05:29:57 -0500

Message-Id: <200407261029.i6QATuo17389@erato.host2u.net>

X-Mozilla-Status: = 0001

X-Mozilla-Status2: = 00000000

FCC: = mailbox://anti-fraud.ref.num341742039034844@usbank.com/Sent=

X-Identity-Key: = id1

Date: Mon, 26 Jul = 2004 14:25:49 +0300

From: U S Bank <anti-fraud.ref.num341742039034844@usbank.com>

X-Mozilla-Draft-Info: = internal/draft; vcard=3D0; receipt=3D0; uuencode=3D0

User-Agent: Mozilla/5.0 (Windows; = U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 = (ax)

X-Accept-Language: en-us, = en

MIME-Version: = 1.0

To: = phish@example.com

Subject: Important = notification

Content-Type: = multipart/related;

 boundary=3D"------------= 010705020107040506040001"

 


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004

------=_NextPart_000_0114_01C4769F.7FFBE9F0-- From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 05:59:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18181 for ; Sat, 31 Jul 2004 05:59:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V9IHLk024169; Sat, 31 Jul 2004 02:18:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V9IH6W024168; Sat, 31 Jul 2004 02:18:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V9IFZa024148 for ; Sat, 31 Jul 2004 02:18:16 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 0E0772861A for ; Sat, 31 Jul 2004 11:18:16 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18894-02 for ; Sat, 31 Jul 2004 11:18:03 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id D5003283E4; Sat, 31 Jul 2004 11:18:03 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Is the back door open? Date: Sat, 31 Jul 2004 11:18:03 +0200 User-Agent: KMail/1.6.1 References: <1090970806.11296.441.camel@ddev.mail-abuse.org> <1900.64.142.13.68.1091264829.squirrel@harry.mail-abuse.org> In-Reply-To: <1900.64.142.13.68.1091264829.squirrel@harry.mail-abuse.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407311118.03402@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le samedi 31 Juillet 2004 11:07, Douglas Otis a écrit : > > > Picking an identity based on the 2822 headers is closer to what > > recipient thinks of as the identity and can require fewer and simpler > > changes for MTAs that need them (in the form of SUBMITTER). > > This will likely create a practice where providers simply insert an RFC > 2822 Resent-From header, to avoid difficulties, if Sender-ID checks become > an encumbrance. I'm sure that it's what will happen. Any mail coming out from big providers or forwarders will bear a "Resent-From: " and then PRA/Sender-ID will then show completely useless. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 05:59:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18228 for ; Sat, 31 Jul 2004 05:59:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V97Edh020693; Sat, 31 Jul 2004 02:07:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V97E7c020692; Sat, 31 Jul 2004 02:07:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V97Ewb020647 for ; Sat, 31 Jul 2004 02:07:14 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id 004B3414B5; Sat, 31 Jul 2004 02:07:08 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 31 Jul 2004 02:07:09 -0700 (PDT) Message-ID: <1900.64.142.13.68.1091264829.squirrel@harry.mail-abuse.org> In-Reply-To: References: <1090970806.11296.441.camel@ddev.mail-abuse.org> Date: Sat, 31 Jul 2004 02:07:09 -0700 (PDT) Subject: Re: Is the back door open? From: "Douglas Otis" To: "Mark Lentczner" Cc: "IETF MARID WG" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > This group has agreed up front that a piece of the spam puzzle hinges > on being able to check that the sending MTA's IP address is authorized > by the domain of some identity associated with the e-mail message. By > holding that domain responsible, and staking it's reputation on the > actions of the MTAs it authorizes, the scheme enables systems that > result in a reduction of spam. The domain must not be held accountable, if it did not grant user access for the message sent. Sender-ID obscures the identity of the domain granting such access. Any accreditation scheme would be impractical with Sender-ID. The list of these reasons are long and intractable. Accreditation with EHLO authenticated and authorized is the best solution for curtailing spam, where Sender-ID can not. > For better or worse, RFC 2821 and RFC 2822 are not concerned with this > kind of identity. The EHLO identity is related to the domain granting user access, either directly or indirectly. Either way, it must be held accountable for abuse emitted, irrespective of message identities. If the domain decides to restrict freedom of the RFC 2821 MAIL FROM or RFC 2822 From, that is a practice the domain would be free implement without using Sender-ID. If their users are responsible, such restrictions could be unwarranted. Not even Sender-ID prevents RFC 2822 From spoofing by other domains. Rather than including the PRA, include a visible authenticated and authorized EHLO domain to bolster these message identities. > Due to both the design of the standards, and deployed current practices, > none of the identities: not the HELO domain, not the MAIL FROM, nor any of > the headers, presents a clear identity of the form we need. Currently the EHLO domain can not be authenticated or authorized. CSV allows the EHLO domain to be used. This EHLO identity is accountable for the traffic, unlike any other identity, and allows a history to be established, and is most closely associated with system logs tracking abuse. > The schemes discussed in this group, CSV, original SPF, and Sender-ID > each pick an identity from the RFC 2821/RFC 2822 set and imbue it with > the meaning we need. We expect that upon adoption of such a scheme, by > virtue of being checked by receiving MTAs, it will acquire this new > meaning. > > However, by doing so, the new scheme will be at odds with some segment > of current practice, and cause some entities to change their processes. > Picking an identity is a matter of weighing pluses and minuses - there > is no clear choice. Picking the EHLO domain does not change any use or practice, but allows meaningful accreditation where history can be considered for the first time. Making this EHLO domain visible, if authenticated, at the MUA, when combined with the RFC 2822 From, would make this identity authoritive. Call Sender-ID, and this would provide a lightweight method that would curtail spoofing, spam, and allow accreditation. Add to that, BATV and the world would be a better place. > Picking PRA > ----------- > Originally, SPF was based on the 2821 MAIL FROM identity. Briefly, it > is a convenient identity to check, and it had the additional advantage > of directly confronting bounce-back attacks ("joe-jobs"). However, > downsides were that it requires some significant changes for some MTAs > (in the form of SRS) and that this identity isn't generally connected > with anything the recipient sees. SRS is just one option, if to continue that scheme. It should be noted that by attempting to constrain the RFC 2822 From address, the use or practice of mail changes dramatically. This is attempting to include a form of user authentication as part of message acceptance. This has a high cost, but makes accreditation impractical. > Picking an identity based on the 2822 headers is closer to what > recipient thinks of as the identity and can require fewer and simpler > changes for MTAs that need them (in the form of SUBMITTER). This will likely create a practice where providers simply insert an RFC 2822 Resent-From header, to avoid difficulties, if Sender-ID checks become an encumbrance. > The current form of the PRA algorithm (in core-02) is neither heuristic > nor proprietary nor arcane: It is a direct embodiment of the 2822 > concept of the mailbox that sent or resent the message. The priorities > and orderings of the headers checked is follow directly from the 2822 > definition of the headers. I'm sure the description in core-02 could > be more clear in this regard. Microsoft has claimed this to be their intellectual property? > One minor related issue: Multi-part messages have no bearing on PRA, > since the MIME multi-part construct, including the headers of any > included messages, is all part of the body of the outer message. Such > attached headers are never involved. This is not clearly stated in the draft. > DNS DDoS and Other Attacks > -------------------------- > The number of DNS queries has been grossly overstated in this > discussion. It is a simple matter of limits imposed by the draft. Currently these limits are at 200 seconds and perhaps after hundreds of DNS queries. > As for DDoS attacks based on SPF records designed to cause large number > of DNS queries, or through excessive querying of legitimate SPF > records, this is discussed in the protocol draft. In short, while > conceivable, the possible DDoS attacks are harder to mount and have > less impact that other, existing mail based DDoS attacks. The intent of such an attack would be to force removal of the Sender-ID check. It is not just any type of DDoS attack, but one with a goal and a motive. > It seems to me that ALL schemes discussed in MARID are subject to DNS > poising schemes. Indeed, we talk about it clearly in the protocol > draft. This is nothing new. Did you mean poisoning? How would this happen with a CSV-CSA record? > The notion that SPF computation is so high that that sites will > postpone the Sender-ID check until the receiver is a known good user > does not hold up to scrutiny. Large volume mail receivers routinely > apply checks that are far more resource expensive than Sender-ID. For a typical office environment, the average size of spam runs approximately 4k and normal mail at about 8k bytes. The amount of DNS traffic Sender-ID could generate, can exceed the traffic carrying mail. Only one Sender-ID check is needed. If trusted MTAs are performing a relay, these checks are not required at the first hop. > The vulnerability of sending via backup MXs is there in EVERY scheme - SPF and BATV prevents these configurations from being a source of undesired bounce traffic. Sender-ID does not prevent this traffic. > and exists today -- no one can really use backup MXs that aren't under > their administrative control, and aren't configured to support the > identical local mail policy. No. > The era of reciprocal friendly back-up MXs is gone. However, deploying > secondary and backup MXs within an organization, with common > administrative control and policy still works in the face of Sender-ID. But now there is an added source of bounce traffic, that could have been prevented. > And yes, the Sender-ID check needs to be done at the border, as do any > checks that are checking the authorization of the sending MTA. If there is trust within the relay chain, the point where a check is made can happen with other checks that may also result in message rejection, such as checking the local part of the recipient address. The bounce traffic could be less than repeated Sender-ID checks, and may encourage this check to be performed only at the MDA. > Yes - Sender-ID no longer directly combats bounce attacks. But it does > insofar as the only bounced mail is mail that doesn't fail a Sender-ID > check (as that mail would be rejected at the 2821 layer.) No. A bounce would not be coming from a domain that would likely fail a Sender-ID check. Such a bounced message could receive a Pass(+) rating. The spammer would only need to be accepted at any rating. > Of course, the reputation of the domain in a message that passes Sender-ID > stakes its reputation on the message and hence if the bounces are joe > jobs, it would suffer. Sender-ID makes accreditation impractical. To suggest a bounce be included in such accreditation would be more trouble. Accreditation must use higher standards. The source domain for each bounce could be unique. Don't forget about all those "open" records. Does this mean anyone with an "open" record should have their mail refused? If so, remove this option! > Does this mean that anyone launching a bounce attack will use a domain > without a published SPF record? No. The domain can be borrowed. The spammer could simply compile a list of domains with "open" records. The reason for leaving the records "open" could be to allow users the normal freedom of sending from different domains. > Yes - but no scheme proposed on MARID purports to break the status quo. SPF (if closed) and BATV does attempt to stop the bounce traffic. > And, when I discuss my work with anyone, bounce attacks are at the bottom > of the pile of spam concerns. Huh? > Lastly, neither Sender-ID, CSV, nor original SPF will stop phishing > directly: Once a phisher catches on, they will have domains set up > correctly. Only the addition of reputation can fix this, and then only > if MUAs present the information in a way that users can understand. > "big-bank.cc" is going to be forever confused with "big-bank.com". > Sender-ID however helps the most: Since it is based on the reputation > of a domain the user will see, and we can only hope the "big-bank.cc"s > of the world will get a bad reputation quickly. The next could be big-bank.one.cc etc. Sender-ID prevents meaningful accreditation, so informing users of such a problem quickly is made more difficult. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 06:00:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18308 for ; Sat, 31 Jul 2004 06:00:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V8lZK2014819; Sat, 31 Jul 2004 01:47:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V8lZIN014818; Sat, 31 Jul 2004 01:47:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V8lXYs014802 for ; Sat, 31 Jul 2004 01:47:34 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 4CFFC2862A; Sat, 31 Jul 2004 10:47:33 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18290-04; Sat, 31 Jul 2004 10:47:20 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 555B928625; Sat, 31 Jul 2004 10:47:20 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: How is SPF different from RMX? Date: Sat, 31 Jul 2004 10:47:19 +0200 User-Agent: KMail/1.6.1 References: In-Reply-To: Cc: Dean Anderson MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200407311047.19852@totor.bouissou.net> X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le samedi 31 Juillet 2004 03:46, Dean Anderson a écrit : > > The example records seem a lot shorter than 512 bytes. But that limit > comes pretty quick. I seem to recall that HESIOD records could quickly eat > that up. Wait, wasn't that one of the reasons why we thought that TCP was > necessary in the first place? So if this is much of a concern for you, and if you have more servers than what can fit on a reasonably short SPF record, then use the "exists" mechanism and put up an SPF record such as: v=spf1 a:main_server.company.com mx exists:%{ir}.mailserver._spf.%{d} -all This one fits in 75 characters, I could have made it shorter, and it allows defining an unlimited number of mailservers, each one with one DNS record, using the SPF "exists" mechanism. > The vast majority of domains have 5 records. So, we are talking about > increase the global dns database of 20 percent. The keyword here is "distributed". A company server that manages DNS for a company with a dozen DNS records can easily accomodate another dozen. And if a big DNS provider that manages hundreds of thousands domains needs to upgrade some servers, it will make the industry happy. > And a corresponding increase in DNS traffic, and a corresponding increase in > DNS server load. False deduction. You cannot make a link between the number of records and the number of requests for these records. The "www." A record will be requested by people who want to access the domain's website, when the TXT SPF record will be requested by MTAs wanting to check mail pretending to come from the domain. You cannot deduct a ratio between those unrelated events. Furthermore, you omit considering DNS caching. If one MTA starts receiving a lot of mail pretending to come from a given domain, it will have this domain's SPF record in its local DNS cache. > > Setting this up is a matter of minutes for one domain > > Setting anything is "a matter of minutes for one domain". Try doing it > for hundreds or thousands of domains. If you manage a couple of domains, it's a matter of minutes. If you manage hundreds or thousands of domains : 1/ You are not forced to do all of them in the same day ;-) 2/ You probably have the necessary resources for scripting this according to your customer database 3/ If you have some kind of web interface for allowing customers to manage part of their DNS records (as many DNS hosting companies have), you just need to add one field in your web interface, and possibly an engine to generate or check syntax and consistency of SPF records. > > Expressing this in "billion dollars" is like trying to evaluate the time > > that I spent scratching my head today, multiply this by the number of > > inhabitants in my country, and calculate from there how many billion > > dollars are lost each month from work time lost scratching one's head... > > Yes, to some extent. But that means its not a good idea to make everyone > on the planet scratch their heads a lot. Policy analysis includes these > sort of costs in the cost analysis. Policy analysis sometimes show rather stupid, it would be worth analyzing the working hours lost in policy analysis ;-) > > > DNS protocols present provide for TCP connections to handle packets > > > larger than 512 bytes. However, many server implementations still don't > > > support TCP, or don't support it properly. > > > > If they don't, they should. If broken, fix. > > Much more easilly said than done. There are complications and costs to > doing this. When designing a protocol, we don't have to take into consideration the fact that there may be a number of servers that already do not conform to long-date established standards. If machines out there are DNS-broken and don't conform to the DNS standards that have been in place for years, it's *their* problem to fix it. Cost for them is their problem. > 22,000 out of perhaps 22 million domains? That's less than one tenth of > one percent. In 6 months, just with "word of mouth" and when SPF isn't yet defined as a "standard", I find this rather impressive. 22,638 is just the number or known (registred to http://spftools.infinitepenguins.net/register.php as of today) SPF-enabled domains, but registering there isn't mandatory at all, and some estimate that the actual figure is more than 100,000. Especially because some DNS / Mail hosting companies may have SPF-enabled thousands of the domains they manage at once, and surely didn't bother entering them all into http://spftools.infinitepenguins.net/register.php. I don't know many new systems that receive such a spontaneaous massive adhesion from the sysadmins community, especially if they impose some kind of constraint and may force to rethink the outgoing mail path for the domain. > "It works for me at the moment" is not a sufficiently convincing technical > analysis to spend a great deal of money and inconvenience a lot of people. Well, "It works for me at the moment" ;-) > So, it seems that you have to track down virus operators and put them in > jail. Just do it ;-) -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 07:01:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21186 for ; Sat, 31 Jul 2004 07:01:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V9lmsR032706; Sat, 31 Jul 2004 02:47:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V9lmIR032705; Sat, 31 Jul 2004 02:47:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost3.mail.uk.easynet.net (smarthost3.mail.uk.easynet.net [212.135.6.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V9lldi032666 for ; Sat, 31 Jul 2004 02:47:47 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost3.mail.uk.easynet.net with smtp (Exim 4.10) id 1BqqSh-0008es-00 for ietf-mxcomp@imc.org; Sat, 31 Jul 2004 10:47:31 +0100 Message-ID: <063001c476e3$312c3110$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <7DF9D69B5FC4BB449AEFA3B1CCF7BF3525FFA1@exchange.rdcim.com> Subject: Re: How would SPF or Sender Id caught this one? Date: Sat, 31 Jul 2004 10:46:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "Bill McInnis" reported: > > I sent this to the ASRG list as well so I apologize if you got it twice. > > Last weekend a phishing attack took place against US Bank. The phisher > spoofed and connected with the appropriate IP for US Bank, > 170.135.72.63. How would SPF or Sender ID have managed to catch that > attack? > > Thanks, > > Bill McInnis > MessageLevel.com I believe that sending a single spoofed packet (containing all the data the MUA needs to send to complete the SMTP dialog) is relatively easy, but conducting an extended TCP session from a spoofed host address requires the hacking of in-network routing (which would imply a seriously-escalated threat). Was the MTA which received the message designed to _ensure_ that a valid TCP session was in place? A good test of session validity is to ensure that response packets are getting back to the source. When using SMTP I believe a common technique used is for the receiving MTA to flush the input buffer before sending each SMTP response, so that the protocol is used to impose 'flow control', which, _requires_ there to be a valid, multi-packet TCP session. I would be very cautious about suggesting that SPF is ineffective unless I had established that the MTA involved was not vulnerable to this basic kind of deception at the transport level. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 10:15:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29448 for ; Sat, 31 Jul 2004 10:15:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VE1kdH070862; Sat, 31 Jul 2004 07:01:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VE1kCQ070861; Sat, 31 Jul 2004 07:01:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VE1jb5070855 for ; Sat, 31 Jul 2004 07:01:46 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i6VE1lmM028048; Sat, 31 Jul 2004 07:01:47 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 31 Jul 2004 07:01:47 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Bill McInnis'" , IETF MARID WG Subject: RE: How would SPF or Sender Id caught this one? Date: Sat, 31 Jul 2004 07:01:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What do you mean by 'appropriate' ? The address does not seem to be connected at the moment. It has no reverse DNS, I can't find an SPF record. I think it is important to accept that the Sender-Id design is intended to be low barrier to deployment for email senders, it is not meant to be highest possible security. Even if it only eliminates bulk spam it helps to drain the pond. The phishing gangs have significant technical capabilities but there is still a value to raising the bar for new entrants. I would rather be chasing ten gangs than a thousand. We may well have to use more sophisticated authentication technology to defeat the phishing gangs. But that will take some time. We cannot afford to do what we keep doing in the security area and allow scope creep to cause us to never deploy the good while we attempt the perfect. > -----Original Message----- > Last weekend a phishing attack took place against US Bank. > The phisher > spoofed and connected with the appropriate IP for US Bank, > 170.135.72.63. How would SPF or Sender ID have managed to catch that > attack? > > Thanks, > > Bill McInnis > MessageLevel.com From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 11:16:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01956 for ; Sat, 31 Jul 2004 11:16:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VF4kPq074147; Sat, 31 Jul 2004 08:04:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VF4k4f074146; Sat, 31 Jul 2004 08:04:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VF4jae074140 for ; Sat, 31 Jul 2004 08:04:45 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id DDBDA132CD1; Sat, 31 Jul 2004 11:06:14 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 3525960E; Sat, 31 Jul 2004 11:04:46 -0400 (EDT) Date: Sat, 31 Jul 2004 11:04:46 -0400 From: Meng Weng Wong To: Bill McInnis Cc: IETF MARID WG Subject: Re: How would SPF or Sender Id caught this one? Message-ID: <20040731150446.GR16317@dumbo.pobox.com> References: <7DF9D69B5FC4BB449AEFA3B1CCF7BF3525FFA1@exchange.rdcim.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7DF9D69B5FC4BB449AEFA3B1CCF7BF3525FFA1@exchange.rdcim.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jul 30, 2004 at 06:34:52PM -0400, Bill McInnis wrote: | | I sent this to the ASRG list as well so I apologize if you got it twice. | | Last weekend a phishing attack took place against US Bank. The phisher | spoofed and connected with the appropriate IP for US Bank, | 170.135.72.63. How would SPF or Sender ID have managed to catch that | attack? could you please post a message with full headers, verbatim and non-obfuscated? From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 11:45:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02950 for ; Sat, 31 Jul 2004 11:45:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VFYCdq076354; Sat, 31 Jul 2004 08:34:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VFYCxB076353; Sat, 31 Jul 2004 08:34:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VFYB8c076342 for ; Sat, 31 Jul 2004 08:34:11 -0700 (PDT) (envelope-from larry@larryseltzer.com) Message-Id: <200407311534.i6VFYB8c076342@above.proper.com> Received: (qmail 20490 invoked from network); 31 Jul 2004 15:34:12 -0000 Received: from dsl081-214-187.nyc2.dsl.speakeasy.net (HELO elliot) (lseltzer@[64.81.214.187]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 31 Jul 2004 15:34:11 -0000 From: "Larry Seltzer" To: "'Meng Weng Wong'" , "'Bill McInnis'" Cc: "'IETF MARID WG'" Subject: RE: How would SPF or Sender Id caught this one? Date: Sat, 31 Jul 2004 11:33:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2149 Thread-Index: AcR3EVLEownKEaCgSjG/l/iCvJrorQAAd/Ng In-Reply-To: <20040731150446.GR16317@dumbo.pobox.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This page (http://www.messagelevel.com/spoofing.cfm#spoofex) appears to have details on this particular phishing example, although nothing so straightforward as an actual message with headers. They have a stupid Flash movie here (http://www.messagelevel.com/register/movies/ipspoofing.cfm) that details some of the techniques. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer larryseltzer@ziffdavis.com From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 12:02:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03399 for ; Sat, 31 Jul 2004 12:02:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VFpjQQ077401; Sat, 31 Jul 2004 08:51:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VFpjvU077400; Sat, 31 Jul 2004 08:51:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VFpihT077394 for ; Sat, 31 Jul 2004 08:51:44 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id D8A1E132CD1; Sat, 31 Jul 2004 11:53:15 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id BFAA05B2; Sat, 31 Jul 2004 11:51:46 -0400 (EDT) Date: Sat, 31 Jul 2004 11:51:46 -0400 From: Meng Weng Wong To: Larry Seltzer Cc: "'Meng Weng Wong'" , "'Bill McInnis'" , "'IETF MARID WG'" Subject: Re: How would SPF or Sender Id caught this one? Message-ID: <20040731155146.GB3243@dumbo.pobox.com> References: <20040731150446.GR16317@dumbo.pobox.com> <20040731153412.B473B1B8@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731153412.B473B1B8@dumbo.pobox.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jul 31, 2004 at 11:33:46AM -0400, Larry Seltzer wrote: | This page (http://www.messagelevel.com/spoofing.cfm#spoofex) appears to | have details on this particular phishing example, although nothing so | straightforward as an actual message with headers. A message with headers would be most informative, plus a description of what OS and TCP software the receiving server was running. http://lcamtuf.coredump.cx/newtcp/ If TCP sequence number spoofing remains a viable attack, we can construct an ESMTP ECHO field of the following form: 20040731-11:49:09 mengwong@dumbo:~% telnet dumbo 25 Trying 208.210.125.24... Connected to dumbo. Escape character is '^]'. 220 dumbo.pobox.com ESMTP Postfix EHLO dumbo.pobox.com 250-dumbo.pobox.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-ECHO 3yw4thwwhw345h2w35w9-huwtruhnsjbfdpsiodbnwaorghj 250 8BITMIME MAIL FROM: SUBMITTER= ECHO=3yw4thwwhw345h2w35w9-huwtruhnsjbfdpsiodbnwaorghj From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 12:13:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03953 for ; Sat, 31 Jul 2004 12:13:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VFxCWP077791; Sat, 31 Jul 2004 08:59:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VFxC4E077790; Sat, 31 Jul 2004 08:59:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VFxBob077783 for ; Sat, 31 Jul 2004 08:59:11 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id F3EB4414BC; Sat, 31 Jul 2004 08:59:09 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 31 Jul 2004 08:59:10 -0700 (PDT) Message-ID: <2148.64.142.13.68.1091289550.squirrel@harry.mail-abuse.org> In-Reply-To: <1900.64.142.13.68.1091264829.squirrel@harry.mail-abuse.org> References: <1090970806.11296.441.camel@ddev.mail-abuse.org> <1900.64.142.13.68.1091264829.squirrel@harry.mail-abuse.org> Date: Sat, 31 Jul 2004 08:59:10 -0700 (PDT) Subject: Different Sender-ID definition From: "Douglas Otis" To: "Mark Lentczner" Cc: "IETF MARID WG" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I wrote Sat 7/31/2004 2:07 AM: > > Call Sender-ID, and this would > provide a lightweight method that would curtail spoofing, spam, and allow > accreditation. I meant to say could be called Sender-ID. This would identify the sender with the channel, assuming the EHLO domain was authenticated and was authorized. This would stop spoofing, phishing and allow accreditation. It would not impact the way mail is used, nor break anything. Unlike the current definition, this could abate spam. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 12:25:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04484 for ; Sat, 31 Jul 2004 12:25:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGDCCP078488; Sat, 31 Jul 2004 09:13:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VGDCf9078487; Sat, 31 Jul 2004 09:13:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts13-srv.bellnexxia.net (tomts13-srv.bellnexxia.net [209.226.175.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGDCVn078480 for ; Sat, 31 Jul 2004 09:13:12 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.206.18]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040731161314.DWZQ21087.tomts13-srv.bellnexxia.net@ibmrkydk2ufvdd>; Sat, 31 Jul 2004 12:13:14 -0400 From: "John Glube" To: "'Hallam-Baker, Phillip'" , "'Bill McInnis'" , "'IETF MARID WG'" Subject: RE: How would SPF or Sender Id caught this one? Date: Sat, 31 Jul 2004 12:13:48 -0400 Message-ID: <012201c47719$5d1a7800$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6VGDCVn078482 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I am having some difficulty with the analysis of this situation. Let me explain. The header which I provided earlier to the list indicates to me a malformed "SMTP mail from address," with the SMTP mail from address being null. (As an aside, the server logs found on the messagelevel.com web site in the review of this message confirms how I read the message header.) What does this mean? It means the sender is directly accessing the receiving server through his or her computer. I am writing this in non technical terms for a reason. The much aligned US federal law regulating commercial email tells us: "Whoever, in or affecting interstate or foreign commerce, knowingly-- (3) materially falsifies header information in multiple commercial electronic mail messages and intentionally initiates the transmission of such messages" is committing a federal crime. (see section 4 of the CAN SPAM Act of 2003. You can find a copy of the Act at http://www.learnsteps4profit.com/antispamus.html) In this same section, materially is defined as follows: "...header information or registration information is materially falsified if it is altered or concealed in a manner that would impair the ability of a recipient of the message, an Internet access service processing the message on behalf of a recipient, a person alleging a violation of this section, or a law enforcement agency to identify, locate, or respond to a person who initiated the electronic mail message or to investigate the alleged violation." It is a material falsification to spew a message into the system with "malformed" information "that would impair" one's ability to "identify, locate, or respond to the person who initiated the electronic mail message." So what you may ask? Any protocol for sender authentication has to instruct the receiving mail server to check for malformed "mail envelope" information and if found, reject the message at the transport stage. Why? This serves the basic purpose of helping to confound the spammer's ability to spoof messages, which is the FTC's basic premise for supporting sender authentication. (See page 12 of the FTC's report on the feasibility of a National Do Not Email Registry. http://www.learnsteps4profit.com/dne.html) Now the question becomes does the SPF or Sender-ID protocol help to achieve this goal? Using the original SPF algorithm, the receiving MTA first checks the SMTP mail from address for a domain name. If there is none, the instruction was to retrieve the domain from the helo line. Upon retrieving the domain from the helo line, the receiving MTA would then check for the domain's SPF record. Since usbank.com has not published a sender policy framework record, the answer would be none and therefore under the original protocol the receiving MTA was to allow the message to pass. I am relying on the following draft: - http://spf.pobox.com/spf-draft-200406.txt This analysis exposes a potential error in the original SPF algorithm. Let me explain. The instruction should have been: * First check the SMTP mail from address for a domain. * If there is no domain to check, this means the message mail envelope is malformed. The receiving MTA must reject the message. The only question I have is, "when the receiving MTA rejects, does it send a note to the helo address (being the return path) explaining the reason for the rejection?" Under the SPF marid protocol document, which ties in with the Sender-ID marid core document, I suggest this issue is resolved. Since there is no domain in the SMTP mail from address, the mail envelope is not formed properly. The instruction is to reject the message. (I presume this is the intention of section 3.3 titled initial processing as found in http://spf.pobox.com/draft-ietf-marid-protocol-00.txt.) If this is not the case, then I suggest the authors of the SPF marid protocol document can easily change the initial processing instruction to rectify this problem. Why? Sending direct from the server, using port 25 to bypass accessing an SMTP mail server and connecting directly to the receiving mail server is a classic spamming technique used to hide ones identity. I suggest sender authentication should and can easily defeat this technique which is used time and again to spew messages into the system and hide identity. Of course, I acknowledge there could be a flaw in any of my premises or understanding of the respective protocols. If there is, please correct me. John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004 From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 12:44:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05468 for ; Sat, 31 Jul 2004 12:44:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGU7lx079008; Sat, 31 Jul 2004 09:30:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VGU7wS079007; Sat, 31 Jul 2004 09:30:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost4.mail.uk.easynet.net (smarthost4.mail.uk.easynet.net [212.135.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGU6TT079001 for ; Sat, 31 Jul 2004 09:30:06 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost4.mail.uk.easynet.net with smtp (Exim 4.10) id 1BqwkK-000Ghk-00 for ietf-mxcomp@imc.org; Sat, 31 Jul 2004 17:30:08 +0100 Message-ID: <074f01c4771b$713fb780$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <7DF9D69B5FC4BB449AEFA3B1CCF7BF3525FFA1@exchange.rdcim.com> <063001c476e3$312c3110$0200000a@ringo> Subject: Re: How would SPF or Sender Id caught this one? Date: Sat, 31 Jul 2004 17:28:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I opined: > > "Bill McInnis" reported: > > > > > I sent this to the ASRG list as well so I apologize if you got it twice. > > > > Last weekend a phishing attack took place against US Bank. The phisher > > spoofed and connected with the appropriate IP for US Bank, > > 170.135.72.63. How would SPF or Sender ID have managed to catch that > > attack? > > > > Thanks, > > > > Bill McInnis > > MessageLevel.com > > > I believe that sending a single spoofed packet (containing all the data the MUA > needs to send to complete the SMTP dialog) is relatively easy, but conducting an > extended TCP session from a spoofed host address requires the hacking of > in-network routing (which would imply a seriously-escalated threat). > > Was the MTA which received the message designed to _ensure_ that a valid TCP > session was in place? > > A good test of session validity is to ensure that response packets are getting > back to the source. When using SMTP I believe a common technique used is for > the receiving MTA to flush the input buffer before sending each SMTP response, > so that the protocol is used to impose 'flow control', which, _requires_ there > to be a valid, multi-packet TCP session. > > I would be very cautious about suggesting that SPF is ineffective unless I had > established that the MTA involved was not vulnerable to this basic kind of > deception at the transport level. > > Chris Haynes > Having thought about this for a few hours, I withdraw the implied recommendation above to use buffer-flushing to counter this form of IP spoofing. I 've worked out how, presented with an MTA using this tactic I could still spoof the IP - were I so inclined. My current thoughts are that a relatively simple change to SMTP is needed to provide the desired TCP session integrity - but that breaks the nice aspect of SPF-Classic that no changes to SMTP are needed. If, however, the MARID proposals proceed, I understand that the SMTP protocal will have to be enhanced (to support SUBMITTER), so the change I have in mind could be added at the same time. Stop-press: - Meng has just (Sat, 31 Jul 2004 11:51:46 -0400) posted the same solution as I was about to propose: a pseudo-random ECHO. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 12:56:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05937 for ; Sat, 31 Jul 2004 12:56:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGhsmg079879; Sat, 31 Jul 2004 09:43:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VGhsYs079878; Sat, 31 Jul 2004 09:43:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGhr98079872 for ; Sat, 31 Jul 2004 09:43:53 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1Bqwxa-0004L6-H6 for ietf-mxcomp@imc.org; Sat, 31 Jul 2004 11:43:56 -0500 To: "IETF MARID WG" References: <200407311534.i6VFYB8c076342@above.proper.com> From: wayne Reply-To: "IETF MARID WG" Date: Sat, 31 Jul 2004 11:43:47 -0500 In-Reply-To: <200407311534.i6VFYB8c076342@above.proper.com> (Larry Seltzer's message of "Sat, 31 Jul 2004 11:33:46 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: How would SPF or Sender Id caught this one? Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.5 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <200407311534.i6VFYB8c076342@above.proper.com> "Larry Seltzer" writes: > This page (http://www.messagelevel.com/spoofing.cfm#spoofex) appears to > have details on this particular phishing example, although nothing so > straightforward as an actual message with headers. This web page appears to have a large error. It claims: However, email delivery is basically a ONE WAY BROADCAST transaction. Meaning that your computer isn't really requesting anything of the other computer, it's simply delivering in a broadcast sense. This means that you can drop emails into the internet stream any where in the world, write the appropriate from addresses and origination IP addresses into the "text" headers of the email and they'll be delivered. It's that simple. [snip] It is not that simple. All TCP connections, SMTP included, use a three-way handshake to start up the connection. This means that email is *not* a one way broadcast, there *is* a request from your computer to the sender. If the operating system on the receiving MTA uses good, random sequence numbers, IP spoofing will be hard enough to do to make it impractical. All major OSes that are reasonable current have sufficiently random sequence numbers and many OSes have been secure for much longer. I agree with others, we need far more details about the actual email and the receiving OS that was involved. -wayne From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 13:16:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06455 for ; Sat, 31 Jul 2004 13:16:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGxV24080573; Sat, 31 Jul 2004 09:59:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VGxVnP080572; Sat, 31 Jul 2004 09:59:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGxUUA080566 for ; Sat, 31 Jul 2004 09:59:30 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id i6VGxSds027813; Sat, 31 Jul 2004 09:59:28 -0700 Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 31 Jul 2004 09:59:28 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Chris Haynes'" , IETF MARID WG Subject: RE: How would SPF or Sender Id caught this one? Date: Sat, 31 Jul 2004 09:59:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > If, however, the MARID proposals proceed, I understand that > the SMTP protocal > will have to be enhanced (to support SUBMITTER), so the > change I have in mind > could be added at the same time. > > Stop-press: - Meng has just (Sat, 31 Jul 2004 11:51:46 -0400) > posted the same > solution as I was about to propose: a pseudo-random ECHO. I suggest that we work on the MARID problem and raise the issue in SAAG as a knock on effect. I have absolutely no problem causing security problems in other parts of the Internet to become visible. We have to start somewhere and if not in this forum the work will take place somewhere else. MARID also has implications for BGP routing security, DNS security as well as IP level security. This is stuff that has to be fixed anyway. From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 13:29:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06941 for ; Sat, 31 Jul 2004 13:29:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VHCMWI081283; Sat, 31 Jul 2004 10:12:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VHCMpn081282; Sat, 31 Jul 2004 10:12:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VHCL53081276 for ; Sat, 31 Jul 2004 10:12:21 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i6VHJYrI011564; Sat, 31 Jul 2004 10:19:34 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i6VHJYkU011561; Sat, 31 Jul 2004 10:19:34 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 31 Jul 2004 10:19:33 -0700 (PDT) From: "william(at)elan.net" To: Meng Weng Wong cc: Larry Seltzer , "'Bill McInnis'" , "'IETF MARID WG'" Subject: Re: How would SPF or Sender Id caught this one? In-Reply-To: <20040731155146.GB3243@dumbo.pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 31 Jul 2004, Meng Weng Wong wrote: > On Sat, Jul 31, 2004 at 11:33:46AM -0400, Larry Seltzer wrote: > | This page (http://www.messagelevel.com/spoofing.cfm#spoofex) appears to > | have details on this particular phishing example, although nothing so > | straightforward as an actual message with headers. > > A message with headers would be most informative, plus a > description of what OS and TCP software the receiving server > was running. > > http://lcamtuf.coredump.cx/newtcp/ > > If TCP sequence number spoofing remains a viable attack, we > can construct an ESMTP ECHO field of the following form: Spoofing TCP is quite difficult as TCP relies on acknoledgements from both sides on each transmission. It takes very very very carefull planning to do it right and get all the data properly timed. On the other hand spoofing UDP is easy (its generally one-way communication with no real establishment of sessions, etc) so if somebody really wanted to get by with appearance of existing SPF record they could do it by spoofing DNS TXT at the time of connection. BTW - I strongly suspect the real USBANK ip address given came from forged Received header but that the actual connection that delivered that phishing email really came from another ip. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 14:01:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08027 for ; Sat, 31 Jul 2004 14:01:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VHn5dB083202; Sat, 31 Jul 2004 10:49:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VHn5iF083201; Sat, 31 Jul 2004 10:49:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from fed1rmmtao06.cox.net (fed1rmmtao06.cox.net [68.230.241.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VHn4AM083194 for ; Sat, 31 Jul 2004 10:49:05 -0700 (PDT) (envelope-from richard@electrophobia.com) Received: from [192.168.0.183] (really [68.109.196.147]) by fed1rmmtao06.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040731174903.SFXU6135.fed1rmmtao06.cox.net@[192.168.0.183]> for ; Sat, 31 Jul 2004 13:49:03 -0400 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.3 Date: Sat, 31 Jul 2004 10:49:02 -0700 Subject: Re: How would SPF or Sender Id caught this one? From: Richard Parker To: "'IETF MARID WG'" Message-ID: In-Reply-To: <200407311534.i6VFYB8c076342@above.proper.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit on 7/31/04 8:33 AM, Larry Seltzer at larry@larryseltzer.com wrote: > This page (http://www.messagelevel.com/spoofing.cfm#spoofex) appears to > have details on this particular phishing example, although nothing so > straightforward as an actual message with headers. > > They have a stupid Flash movie here > (http://www.messagelevel.com/register/movies/ipspoofing.cfm) that > details some of the techniques. Larry, I've looked at the log file excerpt in the Flash movie. While it is presented as evidence that true IP spoofing occurred in the case of this phishing example, the log file excerpt does not support that hypothesis. The commentary in the flash movie claims that the excerpt shows an attempt to deliver spam to the richmond.com mail server, however, I believe they have misinterpreted the log. In my opinion the contents of the log show an entirely valid SMTP transaction taking place in the opposite direction - namely the richmond.com mail server connecting to a usbank.com mail server in an attempt to deliver a bounce message, presumably because the spammer forged the MAIL FROM to include reference a usbank.com address in a mail handled by the richmond.com mail server. -Richard From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 14:51:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09728 for ; Sat, 31 Jul 2004 14:51:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VIcQnx086055; Sat, 31 Jul 2004 11:38:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VIcQSp086054; Sat, 31 Jul 2004 11:38:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VIcLGb086045 for ; Sat, 31 Jul 2004 11:38:23 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B15D91711E for ; Sat, 31 Jul 2004 09:52:32 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? In-Reply-To: Your message of "Fri, 30 Jul 2004 19:18:11 EDT." Date: Sat, 31 Jul 2004 09:52:32 -0400 Message-Id: <20040731135232.B15D91711E@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > It wouldn't make any difference if they send mail through AOL's mail > servers instead, using a forged (or accurate) @aol.com From: > address. Really? I'm sure AOL would disagree. Another 10^8 or so messages a day passing through their system would make them take notice. > Essentially, all SPF is a way to force everyone to block outbound SMTP > except from their relays. That's exactly wrong. SPF is a way of enabling the recipient to tell if a message was from an outgoing MTA or not. Blocking outbound SMTP is orthoganal. > > IMHO, MARID (RMX, etc) is about closing a hole in SMTP, which says > > "messages MUST be accepted for delivery or bounced", but it makes no > > provisions for ensuring that the message CAN be bounced. > > Ahh. Still trying to contact the abuser. Uh, no. It's a way of finding if there is a responsible party for the message. For many spam & virus messages, the alleged domain can refuse to accept responsibility, and the recipient can discard the message. > This is impossible. You already have an accountable entity: the IP address > delegate. Evidently, they either aren't responsible enough or aren't > responsive enough to halt abuse. They are often the same entity as the > domain delegate: AOL owns the IP address, AOL owns the aol.com domain. > You haven't "proven" anyone's accountability. People sell IP conectivity with few restrictions. Someone sending 2-3 spams a day from an IP isn't much of a problem so far as the IP owner is concerned. But a fraud artist claiming association with your business name *is* a big deal. > The domain owner has no more control over the infected machine than the IP > address owner. That being so, sender verification is pointless. Nonsense. The domain owner controls his domain name. If the infected machine uses his name, he can deny responsibility for that message. > The virus operator has to add a couple lines of code to his program to use > the infected machines legitimate email address, and use psyBNC to > distibute this to his virus stable. Time to implement: few days. Cost: 0. > > I am sorry to be critical, but this was why the DNSEXT group rejected RMX. > One has to wonder why it was brought up again without more critical > analysis. Some people think it's useful. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 14:51:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09746 for ; Sat, 31 Jul 2004 14:51:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VIgAd5086207; Sat, 31 Jul 2004 11:42:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VIgAqO086206; Sat, 31 Jul 2004 11:42:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VIg9Jf086199 for ; Sat, 31 Jul 2004 11:42:09 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from harry.mail-abuse.org (localhost.mail-abuse.org [127.0.0.1]) by harry.mail-abuse.org (Postfix) with SMTP id C3F31414B5; Sat, 31 Jul 2004 11:42:10 -0700 (PDT) Received: from 207.46.112.37 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 31 Jul 2004 11:42:10 -0700 (PDT) Message-ID: <3041.207.46.112.37.1091299330.squirrel@harry.mail-abuse.org> In-Reply-To: References: <20040731155146.GB3243@dumbo.pobox.com> Date: Sat, 31 Jul 2004 11:42:10 -0700 (PDT) Subject: Re: How would SPF or Sender Id caught this one? From: "Douglas Otis" To: "william(at)elan.net" Cc: "Meng Weng Wong" , "Larry Seltzer" , "'Bill McInnis'" , "'IETF MARID WG'" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > On Sat, 31 Jul 2004, Meng Weng Wong wrote: > >> On Sat, Jul 31, 2004 at 11:33:46AM -0400, Larry Seltzer wrote: >> | This page (http://www.messagelevel.com/spoofing.cfm#spoofex) appears >> to >> | have details on this particular phishing example, although nothing so >> | straightforward as an actual message with headers. >> >> A message with headers would be most informative, plus a >> description of what OS and TCP software the receiving server >> was running. >> >> http://lcamtuf.coredump.cx/newtcp/ >> >> If TCP sequence number spoofing remains a viable attack, we >> can construct an ESMTP ECHO field of the following form: > > Spoofing TCP is quite difficult as TCP relies on acknoledgements from both > sides on each transmission. It takes very very very carefull planning to > do it right and get all the data properly timed. > > On the other hand spoofing UDP is easy (its generally one-way > communication with no real establishment of sessions, etc) so if somebody > really wanted to get by with appearance of existing SPF record they could > do it by spoofing DNS TXT at the time of connection. > > BTW - I strongly suspect the real USBANK ip address given came from forged > Received header but that the actual connection that delivered that > phishing email really came from another ip. It could have spoofed as an internal bounce, as it did have a null return path. This may be reason to reconcider protections for the return path. It is also a reason to doubt SMTP is secure enough to offer assurances beyond the immediate machine. With respect to DNS, there is a 16 bit indentifier, but this is weak. This can be enhanced to 32 bits, if the source port for a DNS query is also random, rather than from Port 53 or a sequential selection. With respect to SMTP innovations to offer improved protections, SCTP prevents much of the possible attacks, with the use of a state cookie, and reduced typical connection overhead. It also protects against DoS attacks. There are stacks to readily adapt TCP to SCTP. This stack was offered to a well-known desktop OS company, to stimulate acceptance of this transport. ; ) -Doug From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 21:37:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28074 for ; Sat, 31 Jul 2004 21:37:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i711MY0T008801; Sat, 31 Jul 2004 18:22:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i711MYk9008800; Sat, 31 Jul 2004 18:22:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i711MXYD008794 for ; Sat, 31 Jul 2004 18:22:33 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Sat, 31 Jul 2004 21:22:36 -0400 id 000DFBE2.410C45DD.0000208E In-Reply-To: <200407311118.03402@totor.bouissou.net> References: <1090970806.11296.441.camel@ddev.mail-abuse.org> <1900.64.142.13.68.1091264829.squirrel@harry.mail-abuse.org> <200407311118.03402@totor.bouissou.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <42F983F9-E359-11D8-BB8D-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Michel Bouissou From: Andrew Newton Subject: Re: Is the back door open? Date: Sat, 31 Jul 2004 21:22:32 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jul 31, 2004, at 5:18 AM, Michel Bouissou wrote: > I'm sure that it's what will happen. Any mail coming out from big > providers or > forwarders will bear a "Resent-From: " > and > then PRA/Sender-ID will then show completely useless. I'm not sure if this is meant to be an opinionated assumption or a statement regarding a flaw in PRA. If it is a statement regarding a flaw in PRA, please give us the use/abuse cases and the details. On the other hand, if you are merely stating an assumption, I do not think it is very helpful. On Jul 31, 2004, at 11:59 AM, Douglas Otis wrote: > I meant to say could be called Sender-ID. > This would identify the sender with the channel, assuming the EHLO > domain > was authenticated and was authorized. This would stop spoofing, > phishing > and allow accreditation. It would not impact the way mail is used, nor > break anything. Unlike the current definition, this could abate spam. So do you now believe that a Sender-ID record at EHLO host name is more desirable than an SRV record? I'm confused by your suggestion. -andy From owner-ietf-mxcomp@mail.imc.org Sat Jul 31 22:58:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00557 for ; Sat, 31 Jul 2004 22:58:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i712hJT6014650; Sat, 31 Jul 2004 19:43:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i712hJBu014649; Sat, 31 Jul 2004 19:43:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i712hHwB014627 for ; Sat, 31 Jul 2004 19:43:18 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Br6Jj-0002jO-00 for ; Sun, 01 Aug 2004 04:43:19 +0200 Received: from a089071.dialin.hansenet.de ([213.191.89.71]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Aug 2004 04:43:19 +0200 Received: from nobody by a089071.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Aug 2004 04:43:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Is the back door open? Date: Sun, 01 Aug 2004 04:37:57 +0200 Organization: Lines: 55 Message-ID: <410C5785.39C2@xyzzy.claranet.de> References: <1090970806.11296.441.camel@ddev.mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: a089071.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > Yes - Sender-ID no longer directly combats bounce attacks. [...] > when I discuss my work with anyone, bounce attacks are at > the bottom of the pile of spam concerns. Then your situation must be very different from my situation: More than 1,000 useless bounces to forged addresses per day in my catch-all (vanity) domain are the main reason why I'm interested in RMX resp. later SPF. If Sender-Id / Submitter want to be incompatible with v=spf1 then they should use another tag v=marid or similar. No 3rd party should be able to force a SPF PASS, where I could get the bounce for a mail not sent by "me" (= any customer of the same ISP in this case). Apparently a Sender-Id PASS does not more guarantee this. And of course I don't want to get a Sender-Id FAIL instead of a SPF UNKNOWN only because legacy software doesn't copy the obvious MAIL FROM address to an equivalent Sender: header. If some MUAs really want this they could handle the MAIL FROM address as default Sender: address. > neither Sender-ID, CSV, nor original SPF will stop phishing > directly As soon as I know the domains of my business partners SPF can catch phishing attempts: amazon.de TEXT = "v=spf1 include:amazon.com -all" and SPF are all I need to identify forged amazon mails. [...] > only if MUAs present the information in a way that users can > understand. At the moment that's easy, anything in the headers is forged. Only the IP in the last Received header is reliable. SPF adds the Return-Path. In theory Sender-Id could add its "PRA", but in practice Sender-Id expects that senders (MUAs resp. MSAs) replace their existing software to copy the MAIL FROM to the (missing) Sender: header. But it's the MUA of the _recipient_ who wants to do something with the "PRA", so why doesn't it handle the Return-Path: as default Sender: address ? As long as that's not the case my v=spf1 sender policy is strictly incompatible with Sender-Id, because it doesn't cover my usage of 2822 From: addresses. Bye, Frank